AN INTELLIGENT BUILGING BLOCKS CONCEPT FOR ON-ORBIT-SATELLITE SERVCING

TURIN, ITALY 4-6 SEPTEMBER 2012

J. Weise (1), K. Brieß (1), A. Adomeit (2), H.-G. Reimerdes (2), M. Göller (3), R. Dillmann (3)

(1) Technische Universität Berlin, Institut für Luft- und Raumfahrt; Marchstr. 12; D-10587 Berlin; Germany jana.weise@ilr.tu-berlin.de

(2) RWTH Aachen, Lehrstuhl und Institut für Leichtbau; Wüllnerstr. 7; D-52062; Germany adomeit@ilb.rwth-aachen.de

(3) FZI Forschungszentrum Informatik, Interaktive Diagnose- und Servicesysteme; Haid-und-Neu-Str. 10-14; D-76131 Karlsruhe; Germany

goeller@fzi.de

ABSTRACT

With the focus on maintenance of space systems, On-Orbit Servicing (OOS) offers a highly attractive solution for life extension of satellites and hence debris reduction. Manipulability and accessibility are the main requirements that need to be addressed by a serviceable system. In this context, the fragmentation of a conventional satellite into standardized and intelligent building blocks containing the necessary system’s components introduces a novel approach. This paper describes the developed concept and system design of a modular satellite developed to allow the robotic replacement of single building blocks in orbit. Beside the essential design aspects, software concepts to provide the modular client satellite with the necessary degree of autonomy and intelligence will also be addressed.

1. INTRODUCTION

A problem resulting from the high numbers of launched satellite missions is the accumulation of space debris. In order to avoid pollution of space, countermeasures need to be initiated such as the assisted removal of non-operational satellite systems. As an alternative approach, OOS can extend the lifetime of satellites by replacing damaged components. Furthermore, the opportunity of upgrading the satellite with enhanced state-of-the-art systems is another considerable benefit. Recent international research and development projects such as DLR's DEOS focus mainly on the concept of the servicer satellite and on the necessary servicing technologies, neglecting important aspects associated with the design of the target space system.

But in order to reach the fullest potential of OOS it is essential to work on this matter as well. In this context, researcher of TU Berlin, FZI Karlsruhe, and RWTH

Aachen have developed a concept for a modular and reconfigurable satellite in the framework of a joint project. The main approach aims at breaking down a conventional satellite bus into single standardized and intelligent building blocks for on-orbit-satellite servicing (iBOSS). Inside each building block the relevant subsystem components are accommodated.

2. GENERAL CONSIDERATIONS AND REQUIREMENTS

Depending on the desired level of serviceability a wide range of requirements emerge regarding the design, the functionality and the accessibility of the system to be serviced. The selection of appropriate modular system architectures will be influenced by considerations of the following demands:

• easy accessibility for robotic manipulators • great flexibility in rotation and reorientation of

blocks within the satellite system • reconfigurability of entire satellite • nonrestrictive compatibility between blocks • mass, size and volume optimized system • implementation of standards to lower costs • system wide identification and knowledge of

block localization within the cluster

As a result the main challenges lay in the design of the interfaces to mechanically connect the blocks and the interfaces to transfer energy, data and heat. Those consequently need to meet the characteristics described below:

• rotational and axially symmetrical • low complexity, mass and volume • repeatedly detachable and reusable interfaces • high precision and connecting tolerance

The number of side walls equipped with interfaces

strongly depends on the components accommodated inside the blocks and the thereby imposed constraints. To ensure the required flexibility in rotation and reorientation (implementation) of blocks within the satellite system at least 3 side wall should be equipped.

3. SYSTEM ARCHITECTURE (ILB)

3.1. Level of Modularity

Fundamental for the conceptual design of a modular satellite is the definition of the desired level of modularity. Based on consideration of the expected complexity as well as the envisaged standardization of the blocks and interfaces, a reasonable fragmentation of the bus system should take place at component level. Fig. 1 illustrates the classification of defined building blocks according to their subsystems.

Figure 1. Content of system blocks

Depending on the mission an expansion and adding of alternative blocks is possible. A combination of several components into one building block may be appropriate. In particular this applies for sun sensors, which can be basically implemented in each building block as well as the Power Control Unit and on-board computer (OBC). To gain a high level of flexibility during reconfiguration and at the same time guarantee a certain degree of reliability a distributed implementation of OBCs into several building blocks is intended. Equipped with standardized mechanical, electrical and data interfaces a flexible composition of blocks into a satellite system is possible. Necessary criteria for the locations of a block within the system are defined by mission objectives and corresponding functional requirements of subsystem components and will be modeled in an ontology.

3.2. Structural Design

The design of the structural components is driven by different mission phases. On the one hand the system

has to sustain the dimensioning static and dynamic loads during launch on the other hand the structural elements have to fulfill the requirements concerning modularity in orbit. This situation led to the concept, to distinguish between structural and system building blocks.

Fig. 2 shows an exemplified assembly of structural and system boxes corresponding to the reference mission EnMAP. The structural boxes sketched in green and blue ensure the safe introduction and transfer of loads during launch and yield the required system stiffness with respect to lateral and axial eigenfrequencies. The structural boxes are tightly fixed in vertical direction via preloaded screws located in the corners of the boxes.

Figure 2: Assembly of structural and system building

blocks

The stiffness in horizontal direction is achieved by a brickwork type arrangement of structural boxes. Both, structural and system boxes will be made of CFRP members in combination with metal load introduction elements. CFRP will be used to limit thermal expansion processes during operation in orbit, where significantly changing temperature boundary conditions are present. The design of structural tailored components by smart arrangement of carbon fibers offers the possibility to develop thermally stable structures. This thermal stability is necessary to ensure reliable reconfiguration scenarios, where displacements within the modular structure may hinder the system reconfiguration due to misalignment.

Fig. 3 shows a possible design of a structural building block. Important parts are the stiffening cross-sections in vertical direction and the metal made load introduction elements to connect different boxes via screws. The elements are embedded in a sandwich wall-structure.

Figure 3. Structural building block

In contrast to the structural building blocks, the system boxes are not part of the load carrying structure. They are attached independently to the structural boxes and are dynamically de-coupled. The system boxes house the necessary subsystem components. Therefore the requirements regarding the structural elements of the system boxes are on a minor level. Primary tasks are the shielding of components against radiation and thermal effects and the appropriate mounting of system components.

Figure 4. System building block

Fig. 4 shows a system box containing a star tracker. The main element of the system boxes is the sketched base plate, where the main components are mounted on. Via this base plate the system box will be attached to the structural boxes. To achieve an appropriate fixture of boxes during launch phase, releasable bolts are used. The central docking device, which is also shown in the figure and will be discussed later, will not be used to carry the dimensioning loads during launch. The relative small diameter of the interface would cause high stresses and deformations and significantly additional mass would be necessary to overcome this problem. The bolts are located close to the corners of the plate and will be released by Frangibolts that are mechanisms

using the effect of shape memory alloys. This way of attachment minimizes the bending moments present in the structure and reduces the deformations. Thus required eigenfrequencies can be realized.

4. INTERFACES AND BUS SYSTEMS

4.1. Docking Mechanism

To accomplish a successful reconfiguration or replacement of building blocks within an on-orbit servicing scenario reliable interfaces and docking devices a mandatory. For the iBOSS project a central docking device has been developed which fulfils several important requirements:

• androgynous design • mirror symmetry • autonomous locking and releasing • retractable mechanism • capability of orbital load transfer

Fig. 5 shows the design of the docking device that uses components similar to common bayonet locking devices. In order to separate the deployment process from the locking process, the docking mechanism uses the principle of linear bearings. Therefore, the device consists of three main parts shown in Fig. 5:

• coupling element • drive element • static guide element

This design offers the possibility to move out the coupling element from its initial position without a simultaneous rotation, which is a significant advantage compared to screw type docking devices. The coupling element starts a rotational movement just before the maximum point of the axial traverse path is reached. To achieve this, grooves with varying slopes in both the drive section and the static guide element are used. Near the maximum point the element starts to perform a rotational movement of several degrees and is slightly retracted in direction of its initial position and thus locks the connection between two opposite docking interfaces. The opposite coupling element does not perform any movement during the complete docking procedure.

Figure 5: Components of Central Docking Device

The change of movement direction of the coupling element is achieved without changing the movement of the drive section. This part performs a continuous rotation around its longitudinal axis. The docking device is actuated by an electrical motor, where the rotation of the motor is transmitted via gears into the rotation of the drive section. The complete system of docking device, gears and motor will be installed inside the sandwich walls.

4.2. Electrical Interface and Bus Concept

To operate a modular satellite the distribution of electrical power throughout the entire system must be guaranteed. Hence it is mandatory to provide each building block with some kind of electrical interface for power transmission and distribution. Alongside the considerations of specific design requirements the interface must be capable to deal with the identified power demands of approximately 5 kW. Further the supply of a minimum voltage level of 50 Volts DC shall be possible. These requirements result from the intention to develop a set of building block suitable for both LEO and GEO missions, the latter defining the constraints for the power requirements.

For the design of the electrical bus concept a main power bus is proposed, which supplies the building blocks via the interfaces with an unregulated voltage of 100 Volts. Inside each block several DC-DC converters reduce the voltage to the required level to operate the satellite’s subsystem components. As depicted in Fig. 6, each building block will be equipped with interfaces for docking (MI), power (PI) and data (DI) transfer as well as with diverse sensors (S) for temperature, rotation detection and sun sensors.

Figure 6. Bus concept of iBOSS using the example of

two building blocks

The design of the electrical interface itself will be particularly driven by the previously listed design requirements such as axial and rotational symmetry. Here, the androgynous design depicted in Fig. 7 seems most appropriate and complies with the aforementioned issues.

Figure 7. Spring loaded contact and counter piece

An electrical interface consists of four single electrical connectors with two contact pins each for primary power supply and primary grounding. Locating the spring loaded contact pins around the mechanical docking port as depicted in Fig. 8 supports an easy alignment and serves as positioning assistance as well.

Figure 8: Integrated cluster of electrical interfaces in the side walls of a building block

4.3. Data Interface and Data Bus

The data bus connects the individual components inside each building block and connects to adjacent blocks. The bus is set up using fiber optics and utilizing optical free space communication for the connection between the blocks (see the section on the interfaces for more information). The use of fiber optics provides several advantages: besides the high data rates, which reach up to 10 Gbit/s or even more, the cables are lightweight compared to bus systems based on ordinary cables. The block-based concept of the iBOSS approach offers inherent redundancy for the bus system. As shown in Fig. 9 the data can use several paths on the way between two block using different cables, routers and interfaces. The drawback is that the IT-architecture becomes more complex, because a spanning-tree protocol is needed to resolve cycles in the network’s topology.

Figure 9. Redundancy provided by the building block concept: information can travel on different paths, reducing the impact on failures of cables, interfaces or routers

The data interface connects the data bus systems of the individual building blocks. According to the design of the bus it is based on a single-wire fiber optic cable. This way, the design of an androgynous and symmetric data interface can be accomplished by fitting lenses on the cables (see Fig. 10) allowing bi-directional com-munication with high data rates with a minimum of mass and complexity. Fig. 8 shows the plug embedded in the centre of the mechanical interface.

The concept of the data interface does not restrict the abilities of the data bus. Hence it allows high data rates from 100 Mbit/s up to several Gbit/s, bi-directional communication and even multi-mode data transfer, meaning that several networks can be operated in parallel using only one fiber.

Figure 10. Left: Plug bearing lens to enable optical free space communication between building blocks; Right: The lens embedded in the centre of the mechanical interface

4.4. Thermal Interface

The design of a thermal management concept for modular space systems is highly influenced by two different aspects: On the one hand it depends on the thermal requirements of each building block such as temperature limits, threshold for thermal variations inside a block and the estimated heat load to be transferred.

On the other hand the previously listed general interface requirements need to be taken into account as well. The demand for multiple robotic-assisted connections and

decoupling of interfaces during lifetime results in specific challenges concerning the choice of thermal elements enabling sufficient heat transfer between two blocks. So far this type of mechanism is barely used in conventional space systems. So called thermal brush fins used for the orbital replacement unit of the ISS represent a rare exception. These fins consist of numerous carbon fibers (μm-diameter), which allow conduction of heat. Comparing expected thermal loads of 100 W with a thermal conductance of currently maximum possible 660 W/m²K [1] the need for a comparatively large size of the fins is obvious.

For iBOSS four different thermal control architectures have been analyzed (Fig. 11), which differ in complexity and implemented elements.

Figure 11. Thermal management concepts

Three approaches are based on the implementation of a thermal bus system, running throughout the entire modular space system and allowing heat absorbance and transfer from one block to another. Additional radiators and heaters either as separate building block or integrated systems enable the control of the inner block temperature. The thermal isolation of each block and an autonomous control and regulation of the inner thermal balance characterizes the fourth architecture approach. No thermal interfaces are necessary here, but both passive and active thermal elements such as variable thermal layers [2], thermal switches and radiators with variable emissivity need to be integrated. Besides the used thermal elements thermal control design for a building block is closely linked to the structural design of the block. To distribute heat loads from one side wall to up to 5 walls isothermal panels may be used [3].

Having regard to the fact that iBOSS is an intelligent system design, the intelligence shall be used to regulate and manage the thermal behavior. Supported by the capabilities of the developed software for computer-

aided satellite design (see chapter 5) the placement of a building block will be determined considering the thermal characteristics of each block together with relevant mission specific constraints. Another alternative would be the distribution of processing power, and hence generated heat, to multiple building blocks.

For evaluation of the elaborated thermal control architectures and display of the thermal behavior as three dimensional graphic the ModuSat software has been developed. The software allows the flexible integration of the available building blocks to model a space system and takes into account the precise location of a block inside the entire modular system. Fig. 12 shows the skeleton of a modular satellite (a) and the corresponding thermal characteristics of the system with hot side walls in red and cold walls colored in blue.

Figure 12. Thermal characteristics of a modular satellite

created with ModuSat software

The algorithms used for thermal analyses account also for orbit parameters, solar radiation, Earth albedo and infrared as well as for satellite specific aspect such as shadowing of single blocks. Based on that, multiple cases have been simulated for cold and hot orbit scenarios and with varying parameters for heat conductance in structure and interfaces, identifying the thermally isolated concept as the most appropriate and feasible approach.

5. COMPUTER-AIDED SATELLITE DESIGN The modular approach finally leads to a catalogue of standardized building blocks. iBOSS provides software tools which assist engineers in selecting and arranging building blocks during the satellite design process. The automated design process takes place in the major steps modeling, deducing constraints and solving the corresponding optimization problems as is illustrated in Fig. 13.

Figure 13. Computer-aided design in three steps: mode-ling, deducing constraints, solving the optimization problems

Initially the catalogue has to be modeled. This is done in the ontology language OWL. The advantage of using an ontology is that it is human readable and hence does not require programming skills to be managed while likewise enabling algorithmic processing. The modeling of the catalogue has only to be performed once and provides the “catalogue ontology”.

The design process of the satellite starts with choosing suitable rules for the selection of building blocks. A greedy algorithm then chooses the blocks needed to fulfill the given rules as well as those needed to fulfill needs and resulting constrains posed by the initially chosen blocks, such as resource requirements like power consumption. The resulting list of blocks is called the “satellite ontology”.

In the next step a reasoner processes the satellite ontology and induces rules for the arrangement of the chosen blocks. These rules include for example distances to be kept between specific blocks or the orientation of blocks. This set of rules poses an optimization problem which has to be solved in the next steps. The lists of rules and chosen blocks are then handed over to an evolutionary algorithm, which finally solves the optimization problem. It starts initially with a set of legal but otherwise random arrangements of the blocks and then modifies and evaluates the current configuration over a large number of iterations (in our test cases about 500 iterations for satellites consisting of round about 30 blocks). Fig. 14 shows four randomly picked sequential iterations from the optimization process. In consequence of the random-based method of the evolutionary algorithm, a set of pareto-optimal solutions is presented to the engineer. Fig. 15 shows an example of a satellite configuration consisting of 32 blocks.

Figure 14. Four sequential iterations of the optimization process

Figure 15. Final configuration: the arrows show some ofthe correctly placed subsystem building blocks

6. SOFTWAREFRAMEWORK FOR MODULE CONTROL

The modular design of the hardware is matched by a corresponding modular approach in the software framework for controlling the individual building blocks. The framework uses a distributed, data-centric approach, which enables the flexible distribution and management of the software modules as well as the control of the individual building block’s interfaces. The publish-subscribe nature of the architecture makes it irrelevant for general software modules on which computational unit in which building block they are actually running. All information is available throughout the complete network and provided according to defined quality-of-service parameters. There are two types of modules:

Bound Modules: These are the exception to the above statement: they are bound to one specific building block. There are two candidates: (1) the ID-Module registers the building block when it is attached and provides information about the block’s abilities and needs as well as (2) the

BC-Module which controls the block’s hardware.

Free Modules: These modules perform the actual computation work. They are independent from the blocks and can even be shifted between blocks at runtime. Examples are the Monitor-Module which monitors the building blocks’ states and the configuration but also modules for processing sensory information or planning.

Fig. 16 shows a GUI provided by the monitor module showing information on the attached blocks, the network topology as well as the geometrical structure. For more detailed information the reader is kindle referred to the corresponding publication [4], which also picks up the issues of the actual control of the blocks as well as robotic manipulation.

Figure 16. The GUI of the monitor module. Left: Network topology and building block data; Right: geometrical structure

7. CONCLUSION This paper has outlined a concept for the design of intelligent building blocks for on-orbit-satellite servicing (iBOSS). The iBOSS approach involves the use of standardized building blocks for integration into a modular satellite or space platform. Taking essential requirements into account such as high flexibility, light weight design etc. the new design offers major advantages compared to conventional space systems.

• on-orbit serviceability and hence life extension • reduction of production costs through

standardized design • high reconfigurability of the entire satellite

through implementation of standardized interfaces

Necessary technical developments for all interfaces and structural components have been demonstrated on TRL 3 so far. With the next step TRL 5 will be reached, developing a representative and fully functional building block.

8. ACKNOWLEDGEMENT The iBOSS study has been co-funded by the German Aerospace Centre, DLR under national registration no. 50RA1005. Particular thanks go to all co-researchers involved in the project, who have not been named as

author despite their substantial contribution:

TU Berlin: C. Avsar, J. Riesselmann, T. Meschede, S. Salchow, M. Buhl

FZI Karlsruhe: J. Oberländer, L. Pfotzer, C. Billet, K Franke, A. Gorbunov, T. Büttner

RWTH Aachen: M. Lakshmanan, N. Strobel

9. REFERENCES 1. Seaman, C. L. et al. (1999). Enhanced Thermal

Conductance of ORU Radiant Fin Thermal Interface using Carbon Brush Materials; Space Technology & Applications Forum, Albuquerque, USA

2. Hafer, W. T. (2008). Design and Use of a Variable Thermal Layer for Rapid Satellite Component Integration, 6th Responsive Space Conference, LA, USA

3. Schick, S. (2011). Isothermal Structural Panels for Spacecraft Thermal Management, 25th Annual AIAA/USU Conference on Small Satellites, Logan, USA

4. Oberländer, J., Uhl, K. Pfotzer, P., Göller, M., Rönnau, A., Dillmann, R.: Management and Manipulation of Modular and Reconfigurable Satellites, 7th German Conference on Robotics (ROBOTIK 2012), Munich, 2012