Diplomarbeit Analysis of Columbus Systems On-Orbit ... - TUM

Lehrstuhl für Raumfahrttechnik 

Prof. Dr. rer. nat. 

Ulrich Walter 

Diplomarbeit 

Analysis of Columbus Systems On-Orbit 

Performance by Processing and Evaluation of 

Telemetry Data 

RT-DA-2009/03 

Autor: 

Fabian Rojas 

Betreuer: Dipl.-Ing. Jan Harder 

Lehrstuhl für Raumfahrttechnik / Institute of Astronautics 

Technische Universität München

Page II 

Analysis of Columbus Systems On-Orbit Performance by Processing and 

Evaluation of Telemetry Data 

Erklärung 

Erklärung 

Ich erkläre, dass ich alle Einrichtungen, Anlagen, Geräte und Programme, die mir im 

Rahmen meiner Diplomarbeit von der TU München bzw. vom Lehrstuhl für 

Raumfahrttechnik zur Verfügung gestellt werden, entsprechend dem vorgesehenen 

Zweck, den gültigen Richtlinien, Benutzerordnungen oder Gebrauchsanleitungen 

und soweit nötig erst nach erfolgter Einweisung und mit aller Sorgfalt benutze. 

Insbesondere werde ich Programme ohne besondere Anweisung durch den 

Betreuer weder kopieren noch für andere als für meine Tätigkeit am Lehrstuhl 

vorgesehene Zwecke verwenden. 

Mir als vertraulich genannte Informationen, Unterlagen und Erkenntnisse werde ich 

weder während noch nach meiner Tätigkeit am Lehrstuhl an Dritte weitergeben. 

Ich erkläre mich außerdem damit einverstanden, dass meine Diplom- oder 

Semesterarbeit vom Lehrstuhl auf Anfrage fachlich interessierten Personen, auch 

über eine Bibliothek, zugänglich gemacht wird, und dass darin enthaltene 

Ergebnisse sowie dabei entstandene Entwicklungen und Programme vom Lehrstuhl 

für Raumfahrttechnik uneingeschränkt genutzt werden dürfen. (Rechte an evtl. 

entstehenden Programmen und Erfindungen müssen im Vorfeld geklärt werden.) 

Ich erkläre außerdem, dass ich diese Arbeit ohne fremde Hilfe angefertigt und nur 

die in dem Literaturverzeichnis angeführten Quellen und Hilfsmittel benutzt habe. 

Garching, den ________________ 

______________________________________ 

Unterschrift 

Name: Fabian Rojas 

Matrikelnummer: 2676500



Fabian Rojas 

Danksagung 

Die vorliegende Diplomarbeit entstand am Deutschen Zentrum für Luft- und 

Raumfahrt (DLR) in Oberpfaffenhofen und am Lehrstuhl für Raumfahrttechnik (LRT) 

der TU München. An dieser Stelle möchte ich allen meinen herzlichen Dank 

aussprechen, die mich bei dieser Arbeit gefördert und unterstützt haben. 

Im Besonderen möchte ich dabei meine Betreuer Alexander Nitsch und Jan Harder 

erwähnen. Sie haben es mir ermöglicht, meine Diplomarbeit über dieses spannende 

Thema zu schreiben und sind mir dabei immer mit Rat und Tat zur Seite gestanden. 

Auch Barbara Yesnosky aus den USA gebührt ein besonderer Dank für das 

Korrekturlesen meiner Arbeit. Thank you very much! 

Meine Freundin Kelly hat mich mit ihrer Geduld, Aufmerksamkeit und Liebe immer 

unterstützt und begleitet – gracias por haber estado siempre a mi lado! 

Am Schluss möchte ich noch zwei ganz speziellen Personen danken: ihre Förderung 

und ihr unverrückbarer Glaube an meine Fähigkeiten haben mich dahin gebracht wo 

ich jetzt bin! Muchas gracias Mamá y Papá! 

Page III



Fabian Rojas 

Zusammenfassung 

Im Februar 2008 wurde das Weltraumlaboratorium Columbus vom Space Shuttle 

Atlantis im Rahmen der Mission STS-122/1E zur Internationalen Raumstation (ISS) 

gebracht. Während seiner vorhergesehenen 15-jährigen Lebensdauer soll es für 

Wissenschaftler auf der Erde eine Plattform sein, um – in Zusammenarbeit mit der 

Crew auf der ISS – wissenschaftliche Experimente in Schwerelosigkeit (Biologie, 

Materialwissenschaften, Strömungsphysik, …) durchführen zu können. 

Columbus wird vom Columbus-Kontrollzentrum (Col-CC) in Oberpfaffenhofen bei 

München aus kontrolliert. Um einen reibungslosen Ablauf der Experimente und eine 

sichere und komfortable Arbeitsumgebung für die Astronauten gewährleisten zu 

können, werden alle System (Lebenserhaltung, Thermalhaushalt, Energieversorgung, 

Datenmanagement, …) ständig überwacht. Die dabei anfallenden Daten werden 

Telemetrie genannt und – nach deren Übertragung auf die Erde mit anschließender 

Aufbereitung – auf einem Server im Col-CC archiviert. Aufgrund der Komplexität von 

Columbus und der vielen Parameter die überwacht werden, fallen dabei jeden Tag 

große Mengen an Telemetriedaten an. 

Es ist dabei eine große Herausforderung, diese Daten effizient und schnell zu 

verarbeiten, weswegen in dieser Arbeit auf die sinnvolle Reduktion und Verarbeitung 

großer Datenmengen eingegangen wird. Zu diesem Zweck wurde ein 

Computerprogramm geschrieben, dass es einem Benutzer erleichtern soll, große 

Mengen von Telemetrie in kurzer Zeit zu analysieren und zu visualisieren. 

Da Columbus sich erst seit kurzer Zeit im Orbit befindet, gibt es noch wenig 

Erfahrung mit dem Verhalten und der gegenseitigen Beeinflussung seiner 

Subsysteme über längere Zeiträume. Auch die Wechselwirkungen mit der ISS und 

der Weltraumumgebung (Wärmehaushalt, Strahlung, …) bieten sich für 

Untersuchungen an. Ziel dieser Arbeit ist deshalb auch eine Erweiterung des 

operationellen Wissens aufgrund von umfangreichen Analysen der Telemetrie. 

Page V

Page VI 



Abstract 

In February 2008, the Columbus laboratory was transported to the International 

Space Station (ISS) by the space shuttle Atlantis performing the mission STS- 

122/1E. During its 15-year projected lifespan, Earth-based researchers, together 

with the ISS crew, will be able to conduct thousands of experiments in life sciences, 

materials science, fluid physics and a whole host of other disciplines, all in the 

weightlessness of orbit. 

Columbus is operated and controlled by the Columbus Control Center (Col-CC) in 

Oberpfaffenhofen (near Munich). To guarantee smooth progress of experiments and 

a safe and comfortable working environment for the astronauts, all systems (life 

support, thermal, power distribution, data management, etc.) are monitored 

permanently. In this way gathered data (which is called telemetry) are transmitted to 

earth, processed and afterwards stored on a server in Col-CC. Due to the 

complexity of Columbus and the large number of monitored parameters, the daily 

amount of telemetry data is considerably large. 

To process this data efficiently and quickly, this thesis introduces methods to 

reasonably reduce large amounts of data. For this purpose, a computer program 

has been developed. It shall support a user in analyzing and visualizing large 

amounts of telemetry in a short time. 

Since Columbus has not been in orbit for a long time yet, there is little knowledge 

regarding the behavior and the reciprocal influences of its subsystems on a longterm 

basis. The interactions with the ISS and the space environment (thermal 

household, radiation, etc.) provide possibilities for investigations too. Therefore, the 

goal of this thesis is also the derivation of operational knowledge based on 

comprehensive analyses of telemetry data.



Fabian Rojas 

Table of Contents 

1 INTRODUCTION 1 

1.1 Overview 1 

1.2 Problem Definition and Objectives 1 

2 THE COLUMBUS MODULE 2 

2.1 Introduction 2 

2.2 Columbus Location on ISS 2 

2.3 ISS Attitude, Solar β-Angle and Orbit 3 

2.3.1 ISS and Columbus Reference Coordinate Systems (Body Axes) 3 

2.3.2 Attitude Definition 4 

2.3.3 ISS Reference Frames 4 

2.3.3.1 Local Vertical/Local Horizontal (LVLH) Reference Frame 5 

2.3.3.2 X-Axis Perpendicular to Orbit Plane (XPOP) Reference Frame 5 

2.3.4 ISS Solar β-Angle 6 

2.3.5 ISS Orbit 7 

2.4 Interfaces to ISS 7 

2.4.1 Power Interface 7 

2.4.2 ECLSS Interface 8 

2.4.3 DMS Interface 9 

2.4.4 TCS Interface 9 

2.5 Columbus ECLSS 10 

2.5.1 Atmosphere Control & Supply (ACS) 10 

2.5.2 Cabin Ventilation (AVR)/Temperature & Humidity Control (THC) 10 

2.5.3 Other ECLSS Subsystems 12 

2.5.3.1 Support to System Fire Detection and Suppression (FDS) 12 

2.5.3.2 Controlled Cabin Depressurization 12 

2.5.3.3 Module Pressure Relief 13 

2.6 Columbus Thermal Control System (TCS) 13 

2.6.1 Passive TCS 14 

2.6.1.1 Columbus Electrical Shell Heating 14 

2.6.2 Active TCS 16 

2.6.3 USOS External TCS (ETCS) Architecture 17 

3 COLUMBUS TELEMETRY 19 

3.1 Introduction 19 

3.2 Onboard Data Acquisition 20 

3.2.1 Vital DMS Layer 20 

3.2.2 Nominal DMS Layer 21 

3.3 Downlink 22 

3.3.1 S-Band 22 

3.3.2 Ku-Band 22 

3.4 Telemetry Data Storage 23 

3.5 Telemetry Extractor Tool 23 

3.6 Telemetry Parameter Names 25 

Page VII

Page VIII 



4 DATA ANALYSIS CONCEPTS 26 

4.1 Whittaker-Shannon Sampling Theorem 26 

4.2 Reasonable Data Reduction 28 

4.3 Mathematics 30 

4.3.1 Numerical Integration 30 

4.3.2 Mean Values 32 

5 THE TELEMETRY ANALYZER TOOL 33 

5.1 General Program Workflow 33 

5.2 Program Architecture 34 

5.2.1 UML Diagrams of Telemetry Analyzer 34 

5.2.1.1 Class Diagram 34 

5.2.1.2 Use-Case Diagram 36 

5.3 Class Description 37 

5.3.1 The MAINFORM Class 38 

5.3.2 The ReaderTools Class 38 

5.3.2.1 Reading/Storing Process 39 

5.3.3 The ConversionTools Class 39 

5.3.4 The MATHTOOLS Class 40 

5.3.4.1 Integration Algorithm 40 

5.3.4.2 Mean Value Algorithms 41 

5.3.4.3 Interval Minimum/Maximum 42 

5.3.4.4 Arithmetic Operations 43 

5.3.5 The CHANGEANALYSISTOOLS Class 44 

5.3.6 The DIAGRAMTOOLS Class 46 

5.3.6.1 Introduction 46 

5.3.6.2 Comparing Diagrams from different Input Files 47 

5.3.7 The SHOWDIAGRAMFORM Class 48 

5.4 Adaptation of the Telemetry Analyzer Software 49 

6 COLUMBUS MODULE TCS ANALYSES 51 

6.1 Shell Temperature depending on ISS Flight Attitude 52 

6.2 Position of the TCV influences the Active TCS Water Loop 54 

6.3 ISS 90 Minutes Orbit Cycle influences Columbus Water Loop Temperature 56 

6.4 Correlation between Plenum Heat Load absorbed by Water Loop and PDU1 & 2 Power Output 58 

6.5 Impact of Cabin Air Heat Load on TCS Water Loop 63 

6.6 Comparison of Heat Loads absorbed by CHX and Plenum to Heat Loads rejected to ISS 67 

6.7 Comparison of absorbed Air Heat Loads in CHX “Condensing” and “Low Condensing” Mode 70 

7 COLUMBUS MODULE ECLSS ANALYSES 72 

7.1 Dependencies between IRFA Power Consumption, EU Temperatures and Fan Speed 72 

7.2 Comparison of IRFA Failure Signatures at Shut-Off 75 

7.3 24 Hour Periodicity of Cabin Temperatures and Fan EU Temperatures 77



Fabian Rojas 

7.4 Correlation of Cabin Illumination and Subsystem Power Consumption with 24 Hour Periodicity 82 

7.5 TCV influences Cabin Air Flow 85 

7.6 CHX Dry-Out Procedure influences Cabin Air Loop 86 

8 CONCLUSION AND SUMMARY 91 

A Appendix 93 

A.1 Bibliography 93 

A.2 Columbus Technical and Mission Specifications 95 

A.3 Columbus ECLSS Overview 96 

A.4 Columbus Air Conditioning & Redundancy 97 

A.5 Columbus Active TCS 98 

A.6 Columbus Shell Heater and Thermistor Overview 99 

A.7 Flow Chart Symbols according to ISO 5807 100 

A.8 Telemetry Extractor Tool GUI 101 

A.9 ISS β-Angle Diagrams 102 

Page IX



Fabian Rojas 

List of Figures 

Fig. 2–1: Columbus Internal and External Configuration [RD09] ..................................................... 2 

Fig. 2–2: Columbus Module’s location on ISS, view from Nadir [RD07], p. 2-3 .............................. 3 

Fig. 2–3: ISS and Columbus Reference Coordinate System [RD12], p. 3-4 ................................... 3 

Fig. 2–4: Columbus Reference Coordinate System [RD12], p. 3-3 ................................................. 4 

Fig. 2–5: LVLH Reference Frame [RD16], Appendix C.2.2 .............................................................. 5 

Fig. 2–6: XPOP Reference Frame [RD16], Appendix C.2.3 ............................................................. 5 

Fig. 2–7: Solar β-Angle .................................................................................................................... 6 

Fig. 2–8: Columbus-to-ISS Interfaces [RD12], p. 3-2 ...................................................................... 7 

Fig. 2–9: Power Distribution Functional Block Diagram [RD07], p. 6.2-9 ........................................ 8 

Fig. 2–10: Active TCS Interface [RD12], p. 3-122 ............................................................................. 9 

Fig. 2–11: Cabin Ventilation/Temperature & Humidity Control [RD10]/ECLSS ............................... 11 

Fig. 2–12: Columbus Air Conditioning Architecture [RD10]/Overview ............................................ 12 

Fig. 2–13: Breakdown of Columbus TCS, [RD10]/TCS ................................................................... 13 

Fig. 2–14: Columbus Multi Layer Insulation (MLI) [RD03], p. 2-113 ................................................ 14 

Fig. 2–15: Shell Heater Organization and Location [RD03], p. 2-119 .............................................. 15 

Fig. 2–16: Location Coding [RD04] ................................................................................................. 16 

Fig. 2–17: Columbus Active TCS Water Cooling Loop, [RD10]/TCS .............................................. 16 

Fig. 2–18: USOS External TCS (ETCS) [RD03], p. 2-142 ................................................................ 17 

Fig. 3–1: General Columbus Up- and Downlink Path [RD11] ........................................................ 19 

Fig. 3–2: Columbus Data Management System (DMS) [RD10] ..................................................... 20 

Fig. 3–3: Telemetry Extractor Workflow ........................................................................................ 24 

Fig. 4–1: Fourier Transform s(f) ..................................................................................................... 26 

Fig. 4–2: TCV Position displayed with different Sample Rates ..................................................... 29 

Fig. 4–3: Trapezoidal Rule of Integration ....................................................................................... 31 

Fig. 5–1: General Program Workflow ............................................................................................ 33 

Fig. 5–2: Classes and Windows Forms used for the Telemetry Analyzer ..................................... 35 

Fig. 5–3: Class Diagram of the Telemetry Analyzer ....................................................................... 36 

Fig. 5–4: Use-Case Diagram for the Telemetry Analyzer .............................................................. 37 

Fig. 5–5: Flow Chart of the File Reading and Storing Process ...................................................... 39 

Fig. 5–6: Flow Chart of the Integration Algorithm ......................................................................... 41 

Fig. 5–7: Mean Value (left: Arithmetic, right: Geometric) Algorithms ............................................. 41 

Fig. 5–8: Maximum (left) and Minimum (right) Calculation Algorithm ............................................ 42 

Fig. 5–9: Flow Chart of the Arithmetic Calculations Algorithm ...................................................... 43 

Fig. 5–10: Storage Concept for new Data Arrays ............................................................................ 44 

Fig. 5–11: Concept for Analysis of Changes ................................................................................... 45 

Fig. 5–12: Change Analysis Algorithm ............................................................................................. 46 

Fig. 5–13: Diagram Options A – D ................................................................................................... 47 

Fig. 5–14: Primary/Secondary File Inputs ....................................................................................... 48 

Fig. 5–15: MainForm and ShowDiagramForm ................................................................................ 49 

Fig. 6–1: Steps for Conducting an Analysis .................................................................................. 51 

Fig. 6–2: STS-123/1JA Forward Shell Temperatures .................................................................... 52 

Fig. 6–3: STS-124/1J Forward Shell Temperatures ...................................................................... 53 

Fig. 6–4: Shell Temperature and HCU2 Power Consumption ....................................................... 53 

Page XI

Page XII 



Fig. 6–5: Active TCS Water Temperature after CHX; TCV Position .............................................. 55 

Fig. 6–6: High Resolution of both Curves (Green Area in last Figure) ........................................... 56 

Fig. 6–7: Influence of ISS Orbital State on NH3 Temperatures after Radiators ............................. 57 

Fig. 6–8: Influence of ISS Orbital State on Columbus Water Loop Temperatures ........................ 58 

Fig. 6–9: Simplified Model of Plenum Heat Load Rejection .......................................................... 59 

Fig. 6–10: WPA with Water Temp. Sensor Location [RD03], Appendix V, p. v ............................... 61 

Fig. 6–11: Heat Flow QP1 & compared to total PDU Power Output (WPA1 Active) ........................... 62 

Fig. 6–12: Heat Flow QP2 & compared to total PDU Power Output (WPA2 Active) .......................... 62 

Fig. 6–13: CHX Flow [RD03], p. 2-36 .............................................................................................. 64 

Fig. 6–14: Water Modulating Valve 1/2 (WMV1/2) ........................................................................... 64 

Fig. 6–15: Air Heat Flows A1 

Q& & QA2 & (WPA1/2 Active), PDU1/2 Power Output, ΔTA .................... 66 

Fig. 6–16: Balance of Heat Loads in Columbus Active TCS, [RD10]/TCS ...................................... 68 

Fig. 6–17: Mass Flows, Temperatures and Heat Flows, [RD10]/TCS ............................................. 68 

Fig. 6–18: Rejected Heat Flow, Plenum Heat Flow, Air Heat Flow (WPA1 Active) .......................... 69 

Fig. 6–19: CHX Setpoint (orange); Air Heat Flow (yellow: WPA1, blue: WPA2) ............................... 70 

Fig. 7–1: Fan Speeds and Speed-to-Current Ratios at Nominal Operation .................................. 73 

Fig. 7–2: Fan Speed-to-EU-Temperature Ratio at Nominal Operation ......................................... 73 

Fig. 7–3: Fan Speeds and Speed-to-Current Ratios before/after IRFA shutdown ........................ 74 

Fig. 7–4: Fan Speed-to-EU-Temperature Ratios before/after IRFA shutdown ............................. 74 

Fig. 7–5: Input Currents of the Fan Assemblies DOY347, 2008 .................................................... 75 

Fig. 7–6: IRFA Input Current before Shut-Down on DOY106, 2008 .............................................. 76 

Fig. 7–7: Superposition of IRFA Failure Signatures, April (Blue)/December (Red) ........................ 77 

Fig. 7–8: Avg. Cabin Temperature/Fan EU Temperatures over approx. 2 weeks ......................... 78 

Fig. 7–9: 24 hour periodicity .......................................................................................................... 79 

Fig. 7–10: STS-123/1JA Shuttle Docking ........................................................................................ 80 

Fig. 7–11: STS-123/1JA Shuttle Undocking ................................................................................... 80 

Fig. 7–12: CWSA1 & 2 Temperatures Supplement ......................................................................... 81 

Fig. 7–13: Columbus Cabin Illumination Block Diagram [RD03], p. 2-97 ........................................ 82 

Fig. 7–14: Cabin Illumination Power Consumption and Fan EU Temperatures before 1JA ............ 83 

Fig. 7–15: Cabin Illumination Power Consumption and Fan EU Temperatures after 1JA ............... 83 

Fig. 7–16: MLU Power Bus Current and PDU1 Systems Power Out .............................................. 84 

Fig. 7–17: MLU Power Bus Current and PDU2 Systems Power Out .............................................. 84 

Fig. 7–18: Cabin Air Flow and TCV Position ................................................................................... 86 

Fig. 7–19: CHXA Functional Design [RD10]/ECLSS ........................................................................ 87 

Fig. 7–20: Cabin & Water Loop Parameters/WOOV10 Status ........................................................ 88 

Fig. 7–21: TCV Position at CHX Core Switch .................................................................................. 89 

Fig. 7–22: Concept of CHX Core [RD07], p. 6.3-52 ........................................................................ 89 

Fig. 7–23: Water Loop Temperature Oscillation after CHX Core Switch......................................... 90 

Fig. A–1: Columbus Technical and Mission Specifications [RD07], p. 2-4 .................................... 95 

Fig. A–2: ECLSS Overview Schematic ([RD03], Appendix XII) ...................................................... 96 

Fig. A–3: Columbus Air Conditioning & Redundancy ([RD10], ECLSS) ......................................... 97 

Fig. A–4: Columbus Active TCS Functional Overview ([RD03], Appendix XIII) .............................. 98 

Fig. A–5: Shell Heater and Thermistor Overview ([RD03], Appendix XXV) .................................... 99 

Fig. A–6: Standard Symbols of a Flow Chart (ISO 5807) ............................................................. 100 

Fig. A–7: GUI of the Telemetry Extractor Tool ............................................................................. 101



Fabian Rojas 

Fig. A–8: ISS Solar β-Angle according to ATL ............................................................................. 102 

Fig. A–9: ISS Solar β-Angle according to BASEPLATE ............................................................... 102 

Page XIII



Fabian Rojas 

T [°C] Temperature in °C 

Q & [W] Heat Flow 

⎡ 

⎤ 

c P ⎢ 

kg ⋅ K 

⎥ 

⎦ 

⎣ 

J 

⎡ J ⎤ 

h ⎢ ⎥ 

⎣kg 

⎦ 

Symbols 

Specific Heat Capacity 

Specific Enthalpy 

⎡kg 

⎤ 

m& 

⎢ ⎥ Mass Flow 

⎣ s ⎦ 

⎡ 

λ X ⎢m 

⋅ K ⎥ 

⎦ 

⎣ 

W ⎤ 

Thermal Conductivity of X 

P [W] (Electrical) Power 

ξ [%] Valve Position WMV1,2 

λ [%] Valve Position WMV3,4 

β [rad] Solar Beta Angle 

Page XV



Fabian Rojas 

Abbr. Abbreviation 

ACS Atmosphere Control & Supply 

AFS Air Flow Sensor 

API Application Programming 

Interface 

APM Attached Pressurized Module 

AR Atmosphere Revitalization 

ATCS Active Thermal Control System 

ATL As-Flown ISS Attitude Timeline 

AVR Air Ventilation and Revitalization 

CDA Cabin Depressurize Assembly 

CFA Cabin Fan Assembly 

CHX Condensate Heat Exchanger 

CMU Command & Measurement Unit 

COF Columbus Orbital Facility 

Col-CC Columbus Control Center 

CTCU Cabin Temperature Control Unit 

C&C Command & Control 

C&T Communication & Tracking 

CWSA Condensate Water Separation 

Assembly 

DC Direct Current 

DDCU DC/DC Conversion Unit 

DLL Dynamic Link Library 

DMC Data Management Computer 

DMS Data Management System 

DOY Day of Year 

ECLSS Environmental Control & Life 

Support System 

EPS Electrical Power System 

EPDS Electrical Power Distribution 

System 

EWACS Emergency Warning & Caution 

System 

FDS Fire Detection And Suppression 

Fig. Figure 

GNC Guidance, Navigation and 

Control 

Abbreviations 

GUI Graphical User Interface 

HCU Heater Control Unit 

HDR High Data Rate 

HEPA High Efficiency Particle Air 

(Filter) 

HRM High Rate Multiplexer 

HRFM High Rate Frame 

Multiplexer 

HS Humidity Sensor 

ICD Interface Control 

Document 

IMV Inter-Module Ventilation 

IRFA Inter-Module Return Fan 

Assembly 

ISFA Inter-Module Supply Fan 

Assembly 

ISPR International Standard 

Payload Rack 

ISS International Space Station 

JEM Japanese Experiment 

Module 

LCOS Liquid Carry Over Sensor 

LDR Low Data Rate 

LRT Lehrstuhl für 

Raumfahrttechnik/Institute 

of Astronautics 

LTHX Low Temperature Heat 

Exchanger 

LVLH Local Vertical/Local 

Horizontal 

MCC-H Mission Control Center 

Houston 

MCC-M Mission Control Center 

Moscow 

MCS Monitoring and Control 

System 

MDM Multiplexer/Demultiplexer 

MDPS Meteoroid and Debris 

Protection System 

Page XVII

Page XVIII 



MLI Multi Layer Insulation 

MLU Module Lighting Unit 

MMC Mission Management Computer 

MMU Mass Memory Unit 

MOVE Munich Orbital Verification 

Experiment 

MTHX Medium Temperature Heat 

Exchanger 

MTL Master Timeline 

NPRA Negative Pressure Relief 

Assembly 

NSTS National Space Transportation 

System 

OSS Optical Smoke Sensor 

PDGF Power and Data Grapple Fixture 

PDU Power Distribution Unit 

PEV Pressure Equalization Valve 

P/L Payload 

POIC Payload Operations Integration 

Center 

PPRA Positive Pressure Relief 

Assembly 

PTCS Passive Thermal Control 

System 

RAM Random Access Memory 

ROS Russian Orbital Segment 

SPC Standard Processing Computer 

SSMB Space Station Manned Base 

Tab. Table 

TCS Thermal Control System 

TCV Temperature Control Valve 

TDRSS Tracking and Data Relay 

Satellite System 

THC Temperature & Humidity Control 

TUM Technische Universität 

München 

UML Unified Modeling Language 

URL Uniform Resource Locator 

USOS United States Orbital Segment 

UTC Universal Time Coordinated 

VDPU Video Data Processing Unit 

VDS Video Distribution 

Subsystem 

VSU Video Switching Unit 

VTC Vital Telemetry & 

Telecommand Controller 

WFSV Water Flow Selection 

Valve 

WMV Water Modulating Valve 

WOOV Water On-Off Valve 

WPA Water Pump Assembly 

WRM Water Recovery and 

Management 

WTSB Wet Temperature Sensor 

Block 

XML Extensible Mark-Up 

Language 

ZOE Zone Of Exclusion

1 Introduction 

1.1 Overview 

Introduction 

On February 7 2008, the space shuttle Atlantis started on its mission STS-122/1E. 

The goal was the delivery of the Columbus laboratory to the International Space 

Station (ISS). Four days later, on February 11, the laboratory was - by means of a 

complex berthing maneuver - attached to the forward end of the ISS, at the 

starboard side of the “Harmony” module, also known as Node 2. 

The general purpose of the Columbus element is to serve as a laboratory for 

microgravity missions in the material, fluid physics and compatible life science and 

technology disciplines. The Columbus module […] represents the core element of 

the European contribution to the International Space Station. This genuine 

multipurpose science laboratory, at the forefront of microgravity research, will 

enable Europe to acquire first-hand experience of continuous operations of a 

manned orbital platform and to regularly fly its own astronauts in order to run and 

conduct experiments. [RD05], p. 6/[RD07], p. 2-3 

1.2 Problem Definition and Objectives 

Every day, a vast quantity of data about the status of the Columbus systems is 

received and stored at the Columbus Control Center (Col-CC) in Munich, Germany 

(chapter 3). 

With such an amount of data called telemetry, the problem which arises first is how 

to adequately process the information in a useful and efficient manner. Data 

reduction and data handling are the keywords of this issue. 

In this thesis, the Thermal Control System (TCS) and the Columbus Environmental 

Control and Life Support System (ECLSS) are subject to such telemetry analyses. 

Chapters 6 and 7 define the phenomena to be investigated, their constraints are 

defined, subsequently analyzed and elaborated. 

Furthermore, during the course of the investigation, a computer program has to be 

developed. This program shall support the analysis process and allow users easy 

access and processing of telemetry data (chapter 5). 

To sum up, the four main objectives of this thesis are: 

1. acquirement of methods and knowledge to efficiently process great quantities 

of telemetry data 

2. acquirement of methods to efficiently analyze this telemetry data 

3. development of a computer program which supports this analysis process 

4. analyze and derive operational knowledge from Columbus systems telemetry 

data 

Page 1

Page 2 

The Columbus Module 

2 The Columbus Module 

2.1 Introduction 

The following picture provides a quick overview to Columbus and its configuration. 

Thesis-relevant subsystems will be described in-depth for a better understanding in 

subsequent chapters, supporting the analyses to be conducted in chapters 6 & 7. 

Appendix A.2 contains a table with Columbus technical and mission specifications. 

Fig. 2–1: Columbus Internal and External Configuration [RD09] 

Sometimes, Columbus is referred to as APM (Attached Pressurized Module) or COF 

(Columbus Orbital Facility). 

2.2 Columbus Location on ISS 

Since Columbus is docked on the starboard side of ISS, located “forward” relatively 

to its orbital motion, the module is particularly exposed to impacts from 

micrometeoroids (with a relative velocity of about 17 - 18 km/s) and space debris (10 

- 11 km/s). Its protection is provided by an armored shield, the Meteoroid and 

Debris Protection System (MDPS). This shielding consists of 81 armored panels 

which are composed of layers of aluminum and Kevlar. The following figure 

demonstrates the location of Columbus.


Fig. 2–2: Columbus Module’s location on ISS, view from Nadir [RD07], p. 2-3 

2.3 ISS Attitude, Solar β-Angle and Orbit 

2.3.1 ISS and Columbus Reference Coordinate Systems (Body Axes) 

Prior to the introduction of the most important Columbus systems, it is important to 

get acquainted with its reference coordinate system, sometimes called body axes. 

Since Columbus is part of the International Space Station, both - Columbus and ISS 

- reference coordinate systems are going to be introduced in the following two 

figures. 

Fig. 2–3: ISS and Columbus Reference Coordinate System [RD12], p. 3-4 

Page 3

Page 4 


The body axes depicted in the last figure allow us to define the orientation of ISS 

relative to defined reference frames (see chapter 2.3.3). The axes origin is at the 

geometric center of the S0 truss. 

As it can be seen, the +ZISS body axis points toward the Earth center (Nadir), while 

+ZAPM points towards the opposite direction into the celestial sphere. The positive Yaxis 

of Columbus +YAPM points toward the flight direction of the ISS, this 

corresponds to +XISS in the ISS reference coordinate system. Columbus furthermore 

is attached to the ISS on port side. 

The modules’ orientation can be described with six directions, these are: port, 

starboard, deck, overhead, aft and forward. The following figure illustrates the 

locations of these directions. 

Fig. 2–4: Columbus Reference Coordinate System [RD12], p. 3-3 

2.3.2 Attitude Definition 

The attitude of the ISS is defined as difference between the body axes (XISS, YISS, 

ZISS, chapter 2.3.1) and the current reference frame (chapter 2.3.3). It can always be 

described by the Euler sequence (yaw, pitch and roll). 

2.3.3 ISS Reference Frames 

With the definition of body axes in chapter 2.3.1, it is now possible to define 

reference frames.


2.3.3.1 Local Vertical/Local Horizontal (LVLH) Reference Frame 

Fig. 2–5: LVLH Reference Frame [RD16], Appendix C.2.2 

The LVLH reference frame is shown in Fig. 2–5, it has its origin at the vehicle center 

of mass. While the positive Y-axis points perpendicular to the orbit plane, the 

positive Z-axis points toward Earth’s center (Nadir). The positive X-axis is the 

horizontal projection of the velocity vector and is in this case called XVV (X Velocity 

Vector). Usually, Guidance, Navigation and Control (GNC) describes the ISS attitude 

by using the LVLH reference frame. 

Due to the fact that the velocity vector rotates to remain tangential to the orbit, the 

LVLH system also rotates around Earth thus making it “non-inertial”. It makes one 

complete rotation during each orbit which results in a 4-deg/min pitch of the frame 

with respect to the J2000 coordinate system described in [RD16], Appendix C.2.1. 

2.3.3.2 X-Axis Perpendicular to Orbit Plane (XPOP) Reference Frame 

Fig. 2–6: XPOP Reference Frame [RD16], Appendix C.2.3 

The XPOP reference frame is shown in Fig. 2–6. It is a quasi-inertial reference frame 

which can be understood as a 90° yaw of the LVLH frame at orbital noon. While 

Page 5

Page 6 


both the Y- and Z-axis lie in the orbital plane, the X-axis points out perpendicularly 

to it. XPOP remains fixed with the ISS X-axis pointing out of plane and the Z-axis 

aligned with the orbit noon vector. Unlike LVLH, which is rotating with the ISS, 

XPOP is a “quasi-inertial” reference frame, because as the orbital plane slowly 

regresses, the XPOP reference frame also regresses to keep the X-axis pointing out 

of the orbital plane ([RD16], Appendix C.2.3). 

Up until ISS Assembly Mission 12A, the ISS did not have both of the solar array 

gimbals necessary for effective solar pointing. When the solar β-angle (chapter 2.3.4) 

was large (> 37° on some assembly flights, > 52° for others), the ISS was unable to 

obtain sufficient electrical power from the arrays, while flying an LVLH attitude. The 

XPOP orientation allowed the single solar array rotary joint along the ISS body Yaxis 

to track the Sun at any solar β-angle. Please note, that the use of XPOP 

reference frame generated problem issues regarding thermal control, 

communication & tracking and GPS antenna blockage, due to that, it has not been 

used as regular attitude reference frame ([RD16], chapter 7.3.4.3 and 7.3.4.4). 

2.3.4 ISS Solar β-Angle 

The solar β-angle is defined by the angle measured between the Sun vector and the 

orbital plane of the Earth-orbiting object, in this case the ISS. 

ISS orbit plane 

Fig. 2–7: Solar β-Angle 

The β-angle changes throughout the year because of inertial precession of the orbit 

plane and the Earth’s orbit around the Sun. It varies between +/- 75° annually, the 

maximum variation depends on the orbit inclination. 

For the Station’s 51.6° orbital inclination, the β-angle is within: 

• 37° about 62 % of the year 

• 52° about 81 % of the year


Appendix A.9 contains diagrams with ISS β-angles beginning with Columbus 

mission STS-122/1E. 

2.3.5 ISS Orbit 

The ISS orbits Earth in an altitude between 370 to 460 kilometers while having an 

inclination of 51.6°. Due to the non-negligible drag forces in low earth orbits, which 

lead to constant decrement of ISS altitude, the station has to be elevated from time 

to time. The orbit is nearly circular and has a period time of 91 minutes. Thus, the 

ISS orbits Earth about 16 times per day ([RD16], chapter 1.2). 

The current ISS trajectory data and orbital elements can be found in [RD17]. 

2.4 Interfaces to ISS 

Since Columbus is not only mechanically attached to the ISS, there are – amongst 

others – power lines, data lines and lines for the life support systems between the 

two objects. The following figure shows the conceptual layout for the interfaces 

between Columbus and the ISS. 

2.4.1 Power Interface 

Fig. 2–8: Columbus-to-ISS Interfaces [RD12], p. 3-2 

Electrical power for Columbus is received from ISS via two Main Power Feeders 

which are each supplied by two DC/DC Converter Units (DDCU) on ISS side. Each 

pair feeds up to 12.5 kW to one of the PDU’s (Power Distribution Unit). They 

subsequently distribute the power to the different power consumers, subsystems 

and payloads in Columbus. 

Page 7

Page 8 


The two Main Power Feeders which supply Columbus can be considered 

functionally redundant to each other. Power demands of Columbus including P/L 

however cannot be satisfied by one single Main Power Feeder. Due to that, the 

power distribution is not redundant in its full operation but redundancy is given for 

individual functions, including P/L. The Columbus system functions may be available 

if only one Main Power Feeder is available, but in normal operation the Columbus 

equipment shares the two Main Power Feeders to achieve an almost balanced 

loading ([RD03], chapter 2.3). 

The following figure depicts the power distribution way. To the left of the blue 

dashed line is ISS, to its right side Columbus. 

Fig. 2–9: Power Distribution Functional Block Diagram [RD07], p. 6.2-9 

2.4.2 ECLSS Interface 

ECLSS means Environmental Control and Life Support System and it is responsible 

for providing habitable conditions for the crew working in Columbus. For a detailed 

description of the ECLS System, it is referred to in chapter 2.5. 

The International Space Station supports the Columbus ECLSS with the following 

functions [RD12], p. 3-166: 

A. Temperature and Humidity Control (THC) 

ISS provides fresh air for Inter-Module Ventilation (IMV). The air is actively 

drawn and returned by Columbus. 

B. Atmosphere Control and Supply (ACS) 

ISS provides the following functions directly to Columbus: 

1. Total pressure control. 

2. Control of oxygen (O2) and nitrogen (N2) partial pressure. 

3. Columbus repressurization/pressure equalization (via Node 2 Pressure 

Equalization Valve (PEV) and Columbus Hatch as applicable).


4. Nitrogen supply for payloads and subsystem use, including supply 

pressure monitoring (contained in ancillary data). 

C. Atmosphere Revitalization (AR) 

ISS provides the following: 

1. Monitoring of the main components of the Columbus atmosphere (i.e., O2, 

N2, CO2, H2O, H2, CH4) via a dedicated sampling line, including sampling 

line assembly functionally monitoring, as provided by SSMB (Space 

Station Manned Base) Air Revitalization System (ARS) rack. 

2. CO2 removal from Columbus indirectly via the IMV. 

3. Trace gas contaminant control of Columbus indirectly via the IMV. 

4. With the Columbus hatch closed, trace gases are monitored by taking a 

sample through the PEV. 

With the hatch open the sample can be taken in the Columbus cabin air. 

D. Water Recovery and Management (WRM) 

ISS receives condensate from the THC in Columbus. 

2.4.3 DMS Interface 

Please take a look at chapters 3.1 and 3.2 of this thesis for a description of the Data 

Management System (DMS) interface between ISS and Columbus. 

2.4.4 TCS Interface 

Fig. 2–10: Active TCS Interface [RD12], p. 3-122 

The active thermal control system (TCS) consists of one water loop on Columbus 

side and of two separate loops on ISS side (see figure above). Please take a look at 

Page 9

Page 10 


chapters 2.6.2 and 2.6.3 for a detailed description of the Columbus active TCS 

water loop and its interactions with the cooling loops on ISS side. 

2.5 Columbus ECLSS 

The Columbus ECLSS has to provide a healthy and comfortable working 

environment for up to three crew members and utility supply for up to 10 

international standard payload racks (ISPR). It can be distinguished between these 

three functional groups: 

1. Air Conditioning (ventilation, filtering, cooling, dry-out) 

2. Atmosphere Pressure Control (only in contingency cases!) 

3. Payload Supply (vacuum, venting, N2) 

Although Columbus is self sufficient in certain areas, most of the resources are 

provided by ISS except for vacuum (see chapter 2.4.2). The next subchapters will 

describe the different ECLSS subsystems. 

2.5.1 Atmosphere Control & Supply (ACS) 

The ACS system provides monitoring and supply capabilities. It monitors the total 

pressure in the cabin, the O2 partial pressure and the CO2 partial pressure. ACS 

furthermore provides nitrogen (N2), vacuum and venting functionalities for the P/L (if 

the experiment demands it). Venting and N2 is provided for all ISPRs, vacuum only 

for forward and aft ISPRs ([RD10]/ECLSS). 

2.5.2 Cabin Ventilation (AVR)/Temperature & Humidity Control (THC) 

The Columbus air conditioning system is one of the three functional groups of the 

Columbus ECLSS mentioned in chapter 2.5 and it incorporates: 

• Inter Module Ventilation (IMV), 

• control of cabin temperature and humidity/condensate water separation from 

the cabin air, 

• monitoring of the Columbus atmosphere (total pressure, partial pressure of O2 

and CO2)


Fig. 2–11: Cabin Ventilation/Temperature & Humidity Control [RD10]/ECLSS 

[RD10]/ECLSS: fresh air is supplied by Node 2 through the ISFA (Intermodule Supply 

Fan Assembly) and is returned to Node 2 through the IRFA (Intermodule Return Fan 

Assembly), its flow rate is monitored by Air Flow Sensors (AFS). Circulation of the air 

in the cabin is taken care of by a Cabin Fan Assembly (CFA), which – unlike ISFA 

and IRFA – consists of two redundant assemblies. 

Before the incoming and circulated air enters the Condensate Heat Exchanger 

(CHX), it is cleaned by the HEPA filter (High Efficiency Particle Air Filter). The cabin 

air temperature is controlled by two redundant Cabin Temperature Control Units 

(CTCU). Six Cabin Temperature Sensors (CTS) measure the temperature in the cabin 

and compare it against pre-defined thresholds. These temperatures serve as inputs 

for the CTCUs to operate the Temperature Control Valve (TCV) which distributes the 

airflow between active (cool) and inactive (warm) CHX core in order to regulate cabin 

air temperature. If cooled air is needed, the TCV routes the majority of the air into 

the active CHX core and vice versa. Drying of the air is performed by the 

Condensate Water Separator Assemblies (CWSA) which separate the humidity from 

the air. After that process, the condensate is returned to the ISS by a dedicated 

conduit. 

Moreover, the CHX is the interface between cabin ventilation, temperature & 

humidity control and the active thermal control system (active TCS) described in 

chapter 2.6.2. Both, the water lines of the active TCS and the air lines of the cabin 

ventilation pass through the CHX, where the water in the TCS loop absorbs the heat 

load of the cabin air transported by the ventilation loop (the water loop is the light 

blue line marked “TCS” in the figure above). 

Page 11

Page 12 


Fig. 2–12: Columbus Air Conditioning Architecture [RD10]/Overview 

After passing the CHX, the air is distributed into the cabin by a series of nozzles. The 

air from the cabin is in turn collected by the return grid (see Fig. 2–11 and 2–12) 

where it flows to the CFA and IRFA. 

2.5.3 Other ECLSS Subsystems 

2.5.3.1 Support to System Fire Detection and Suppression (FDS) 

By circulating the cabin air with the intermodule ventilation (chapter 2.5.2) and by 

analyzing the such created air flow using Optical Smoke Sensors (OSS), it is 

possible to detect combustion processes in Columbus. To reliably maintain 

performance, the OSS need a certain predefined air flow rate [RD03]. 

2.5.3.2 Controlled Cabin Depressurization 

Design requirements demand Columbus to have the capability to eject its 

atmosphere. There are two operational reasons for this: a fire and/or a toxic 

atmosphere (which may be caused by a fire). 

Theoretically, if all other measures to extinguish a fire fail (e.g. using fire 

extinguishers or the removal of the fire’s electrical ignition source by cutting power 

to the component aflame or to the whole module), the crew would have the option 

to isolate the module and dump its atmosphere, thus removing the fire’s oxygen 

source. In practice, the effects of an air flow on the fire are unknown, thus, the cabin 

depressurization is only applicable on a contaminated atmosphere. However, if the 

cabin would be depressurized, the question would arise, from where to get new air. 

So, although the Cabin Depressurize Assemblies (CDA) are designed to perform that 

task ([RD03], chapter 2.2.5), in reality they are put out of operation.

2.5.3.3 Module Pressure Relief 


During its operation in space, Columbus is exposed to positive pressure since the 

pressure inside the module is greater than outside. Therefore, the structure and the 

hull are designed to withstand positive pressures. To relieve excess positive 

pressure, Columbus has two sets of valves called Positive Pressure Relief 

Assemblies (PPRA) ([RD03], chapter 2.2.6.2). 

The Negative Pressure Relief Assemblies (NPRA) ensure that the Columbus shell 

does not crush in case of excessive negative pressures (pressure outside the 

module greater than inside). This function is not needed on-orbit, since Columbus 

cannot experience negative pressures in space. It is only important for the 

protection of Columbus on Earth, when the atmosphere surrounding the module is 

at about the same pressure as at sea level ([RD03], chapter 2.2.6.1). 

2.6 Columbus Thermal Control System (TCS) 

The main function of the TCS is to maintain Columbus shell, system equipment and 

P/Ls within their required temperature range. This is done: 

• by cooling, i.e. first collecting waste heat from system cold plates, payloads, 

and cabin atmosphere, and then transporting and rejecting it to the ISS 

thermal bus, 

• by heating, i.e. maintaining minimum temperatures using thermostatically 

controlled heaters, 

• by insulating and surface coating, i.e. minimizing heat leaks/gains and 

reducing heat absorption and reflection. 

It can be distinguished between a passive and an active TCS. The passive TCS 

consists of insulation, coating, and shell heaters to provide limited thermal control 

and to prevent condensation on Columbus shell; there is no fluid interface. Although 

Columbus shell heaters are part of TCS, they are monitored and controlled through 

ECLSS displays (chapter 2.5). The active TCS is actively pumping a cooling fluid 

through a closed loop to provide cooling for Columbus systems, P/Ls and cabin air 

by means of heat collection, heat transportation, and heat rejection. It is composed 

of one cooling loop with two separate temperature sections: a low temperature 

section at 4 – 6 °C and a moderate temperature section at 16 – 18 °C [RD10]/TCS. 

Passive 

TCS 

Insulation 

Coating 

Heating 

Active 

TCS 

Closed Fluid 

Loop 

Fig. 2–13: Breakdown of Columbus TCS, [RD10]/TCS 

Page 13

Page 14 


The previous figure illustrates this distinction into a passive and an active TCS. The 

following subchapters will describe the two parts in more detail. 

2.6.1 Passive TCS 

The passive TCS provides limited thermal control, with minimal operational needs 

and maintenance tasks, i.e. little crew time. It is implemented by using Multi Layer 

Insulation (MLI, Fig. 2–14), surface coating, plumbing insulation and electrically 

powered shell heaters (chapter 2.6.1.1). 

Fig. 2–14: Columbus Multi Layer Insulation (MLI) [RD03], p. 2-113 

2.6.1.1 Columbus Electrical Shell Heating 

Let’s assume dropping cabin air temperatures: if the composition of the air does not 

change as temperature drops, the relative humidity will increase (the lower the 

temperature of a gas, the fewer the amount of water it can hold). If the temperature 

keeps dropping, the amount of vapor in the air will eventually equal the amount that 

it can maximally hold, and thus become saturated. This temperature is known as the 

dew point. As the air becomes even colder, it cannot hold all the vapor anymore, 

and the excess vapor changes phase. The vapor starts to condense on smooth 

surfaces which are colder than the current dew point. Therefore, the main purpose 

of the Columbus electrical heating is to prevent water condensation within the 

module by electrically heating the shell and thus keeping its temperature above the 

current dew point. The shell heaters moreover have the task to prevent water 

freezing in the active TCS water loop. 

Another purpose of the heating system is to control the temperature of the CDA 

venting nozzles during a cabin depressurization. That however is a contingency and 

thus is not used in nominal mode.


Fig. 2–15: Shell Heater Organization and Location [RD03], p. 2-119 

As it can be seen in the last figure, the shell heaters, which are located on the outer 

shell (below MLI and protective meteoroid shielding), are split up into six primary 

and six redundant heater circuits. Every circuit consists of 13 parallel connected 

shell heaters. The circuits are controlled by Heater Control Units (HCU) which are 

located on the outer starboard cone of Columbus, also below MLI and protective 

meteoroid shielding. HCU1 controls the primary heater circuits and HCU2 controls 

the redundant heater circuits. Although HCU1 is considered the nominal control unit 

for the shell heaters, both - primary and redundant - heater circuits are able to fulfill 

exactly the same tasks since they are identical in design. It is more a question of 

power requirements which HCU is in charge of shell heating, since HCU1 is 

powered by PDU1 and HCU2 by PDU2 (see chapter 2.4.1). If PDU1 already has to 

supply a lot of systems and payloads, it is reasonable to supply the shell heaters via 

PDU2 and HCU2 to reduce the power load of PDU1. 

Since the HCUs control the shell heaters thermostatically, the shell temperatures 

have to be measured in order to use those temperatures as inputs for the HCU 

control algorithm. These measurements are done by thermistors (thermal resistor) 

which are also located on the shell. If the measured temperature of a thermistor 

drops below a predefined threshold, the HCU begins to heat up the corresponding 

shell heater. This process stops when the thermistor measured temperature reaches 

the predefined upper threshold temperature ([RD03], chapter 2.4.2). 

The locations of the thermistors are based on Columbus location coding ([RD03], 

chapter 2.4.2.1). There are six location areas: FD (Forward Deck), FR (Forward), FO 

(Forward Overhead), AO (Aft Overhead), AR (Aft) and AD (Aft Deck). Every location 

area contains six thermistors (three primary and three redundant) from which two 

are on the starboard cone (index 1), two on the shell (index 2) and two on the port 

cone (index 3). The parameter name HCU2_AO_THR1_Temp_MVD for example 

indicates, that the respective thermistor is located in aft direction overhead and on 

starboard side (because of the index “1”). 

Page 15

Page 16 


Fig. 2–16: Location Coding [RD04] 

In addition, Appendix A.6 contains a drawing with the locations of the shell heaters 

and thermistors on the Columbus shell (please note that the nomenclature on that 

drawing does not match with the prior introduced location coding). 

2.6.2 Active TCS 

As already mentioned earlier, the active TCS consists of a single-phase water loop. 

([RD04], chapter 1.1.3). The figure below demonstrates this water loop and its 

components: 

Fig. 2–17: Columbus Active TCS Water Cooling Loop, [RD10]/TCS 

When the water emerges from the plenum (collective term for all payload and 

subsystem electronics), it is at its warmest (see figure above). The heat collected 

from the plenum by this means, is pumped to ISS Node 2 by a water pump 

assembly (WPA). There, the heat is rejected by two heat exchangers which are


connected in series (see chapter 2.6.3). Both, medium temperature heat exchanger 

(MTHX) and low temperature heat exchanger (LTHX) can be bypassed by using 

water on-off valves (WOOV). These valves block or open the water lines, thus being 

able to control the path of the water. 

After emerging from the LTHX, the water is at its coldest point. This water enters the 

first water modulating valve (WMV), a three-way mix valve that also uses warmer 

bypass coolant to regulate the outlet coolant and provides a constant temperature 

for downstream loads. WMV3 (or redundant WMV4) provides water cooled down to 

5 ±1 °C to the condensate heat exchanger (CHX), the Columbus module’s air 

temperature conditioning unit. Chapter 2.5.2 closer describes the interface between 

active TCS and cabin temperature and humidity control. After passing the CHX, the 

water emerges from it slightly warmer. 

Then, the water enters WMV1 (or redundant WMV2) to be mixed with another leg of 

warmer bypass coolant. The water is regulated to 17 ±1 °C and flows to the plenum. 

The flows to the payload racks are controlled by the water flow selection valves 

(WFSV), one at the inlet of each rack. After emerging from the Plenum, the loop 

starts again. 

Since the Columbus active TCS operates in “single loop” mode, there is no 

possibility to split it into more than one operational segment. In spite of that, the 

loop is single-fault tolerant: malfunctioning equipment can be bypassed by WOOVs 

thus re-routing the water flow path to the corresponding redundant component (e.g. 

WPA2 in case of WPA1 failure). 

2.6.3 USOS External TCS (ETCS) Architecture 

Fig. 2–18: USOS External TCS (ETCS) [RD03], p. 2-142 

Page 17

Page 18 


The external thermal control system (ETCS) of the United States Orbital Segment 

(USOS) consists of two ammonia (NH3) loops (Loop A and B) which collect the heat 

loads from the Columbus water loop and other thermal loops (JEM for example). 

Heat is exchanged and collected in low temperature and moderate temperature heat 

exchangers (LTHX, MTHX), which cool down the water from the water loops in the 

attached modules and in exchange heat up the NH3. When the NH3 passes the ISS 

radiators, excess heat is radiated into space thus cooling down the ammonia. 

While Columbus consists of one water loop (with single-fault tolerance, chapter 

2.6.2), the USOS ETCS two NH3 loops are completely independent, preventing total 

loss of system in case of failure. Please take a look at chapter 2.4.4 of [RD03] for 

more details on the USOS ETCS components and functionalities.

3 Columbus Telemetry 

3.1 Introduction 

Columbus Telemetry 

To perform proper telemetry analyses, it has to be understood how telemetry is 

acquired, processed and transmitted to the ground. In this chapter, the different 

ways of how TM data is being linked down are investigated and the differences, 

advantages, disadvantages and restrictions are elaborated. 

Fig. 3–1: General Columbus Up- and Downlink Path [RD11] 

The figure above shows the general Columbus up- and downlink path. Both the Ku- 

and S-Band data is using the Tracking and Data Relay Satellite System (TDRSS) 

to/from the respective ground terminal. The data is further distributed through the 

Interconnection Ground Subnet to/from the worldwide users. As demonstrated in 

the figure, there is no direct down- or upload link from Columbus Control Center 

(Col-CC) in Munich to Columbus. 

S-Band Band data data for for downlink is is sent: 

sent: 

• directly by the Columbus DMS (Data Management System) through the US 

Multiplexer/Demultiplexer (MDM), 

S-Band Band data for uplink is sent: 

• directly through the US MDM to Columbus DMS. 

Page 19

Page 20 


Ku Ku-Band Ku 

Band Band data data for downlink is sent either: 

• as analogue video from the Columbus VDPU (Video Data Processing Unit) 

through the Node 2 Video Switching Unit (VSU4), VSU and the HRFM (High 

Rate Frame Multiplexer) in the US Lab or 

• as digital video and/or digital data from the VDPU through the Columbus 

HRM (High Rate Multiplexer) and the Automated Payload Switch (APS) to the 

HRFM in the US Laboratory. 

• through the HRM as part of Ku-Band downlink (Path TM packets). 

Actually the JEM antenna for the Ka-Band is not available (01/2009), but in the future 

it could also be taken into account as another downlink resource. 

3.2 Onboard Data Acquisition 

Fig. 3–2: Columbus Data Management System (DMS) [RD10] 

Fig. 3–2 shows the Columbus DMS system with its different functional layers 

(separated by background color) and its interface to the ISS. The layers can be 

described as follows. 

3.2.1 Vital DMS Layer 

The Vital Layer covers safety critical functions which could in case of failure cause 

life threatening or catastrophic situations. This includes for example smoke


detectors, positive pressure relief assemblies, shut-off valves, etc. Some tasks of 

the Vital Layer are the monitoring and control of vital equipment, the handling of vital 

commands/telemetry and the activation/deactivation of Columbus. It furthermore 

handles the Caution & Warning System (EWACS). 

The VTCs (Vital Telemetry and Telecommand Controller) are Input/Output controllers 

with data processing capabilities involved in vital functions such as for example 

handling of telecommands coming from ground station, SSMB and crew, data 

acquisition on direct inputs and 1553B busses (sampling frequency 1 Hz) and 

generation of TM packets for downlink to ground via the C&C (Command & Control) 

bus. They are connected to the System and Vital Bus on the one hand and to the CB 

INT 1/2 busses (these connect the Columbus module with the ISS) on the other 

hand. 

3.2.2 Nominal DMS Layer 

It’s the function of the Nominal Layer to monitor and control nominal equipment and 

to provide an interface for nominal commanding and telemetry. Furthermore, it is 

responsible for following tasks: Data Storage & Retrieval, Data Processing, Data 

Acquisition/Distribution, Telemetry/Telecommand, Exception Monitoring and 

Communication. 

Telemetry data is generated cyclically (1 Hz or 0.1 Hz) or on-request. Important 

hardware components of the Nominal Layer are the SPCs (Standard Processing 

Computer), the CMUs (Command and Measurement Unit) and the MMUs (Mass 

Memory Unit). 

The core components of the nominal DMS are the four SPCs as processing units. 

SPCs play three different functional roles: data management (SPC1), mission 

management (SPC2) and payload management (SPC3).The main function of the 

Data Management Computer (DMC) is the acquisition, monitoring and control of 

nominal DMS equipment. The payload management computer (Payload Control Unit 

- PLCU) provides the nominal DMS infrastructure to payload developers to 

implement their specific applications. SPC4 is a spare that can be configured to take 

over each of these roles, if the originally assigned SPC fails. 

The DMS data storage function is provided by a file server function located in the 

MMU computer and accessed through the LAN by the DMS nodes. A data storage 

access failure tolerance is ensured by two active MMU computers (one primary and 

one secondary) with data duplication mechanism ensuring that both MMU disk 

contents are identical during operations and with automatic primary MMU failure 

detection and switch-over by the secondary MMU, without disturbing the nominal 

S/W functions. The MMU furthermore serves as the telemetry router to the high rate 

multiplexer (HRM). 

The design of the CMUs is based on commonality with the VTC. They serve as 

acquisition units which are connected to the nominal equipment ([RD02], chapters 

2.2.1, 2.2.3, 2.2.4 and 2.2.5). 

As depicted in Fig. 3–2, the acquired telemetry can be transferred to the ground on 

two paths: via S-Band link passing through MDM or via Ku-Band by passing the 

Page 21

Page 22 


high rate multiplexer (HRM). The Ku-Band link is primarily used for experiment data 

and thus only used to download recorded telemetry dumps if there is bandwidth 

available (see chapters 3.3.1 and 3.3.2). 

3.3 Downlink 

This subchapter describes the different downlink paths as they can be seen in Fig. 

3–1. For the sake of completeness, a short description of the uplink paths is 

included. 

3.3.1 S-Band 

The S-Band communication subsystem is used for primary command and control of 

the ISS and its subsystems (e.g. Columbus). It transmits and receives at a High Data 

Rate (HDR) of 192 kbps return link, and 72 kbps forward link; and in a Low Data 

Rate (LDR) of 12 kbps return and 6 kbps forward. There is no audio transmission in 

LDR mode. 

Commands are transported from Mission Control Center Houston (MCC-H) via S- 

Band subsystem to the ISS by using TDRSS, system and critical telemetry is 

returned on the same transmission path. Please note that also commands from Col- 

CC to Columbus always have to pass through MCC-H (or MCC-M) on ground side 

and through the United States Orbital Segment (USOS) on space side before they 

reach Columbus. Telemetry from Columbus to Col-CC in turn has to pass through 

USOS and is then transmitted to MCC-H via TDRSS and S-Band. From there, it is 

processed and subsequently sent to Col-CC by an interconnected ground subnet 

([RD16], chapter 4.6). 

3.3.2 Ku-Band 

Scientific research in space is the main mission of the ISS, the gathered experiment 

and P/L data shall help scientists and engineers on Earth to achieve scientific and 

technological breakthroughs. Research data is sent to Earth by the Ku-Band 

subsystem, its purpose is to provide an HDR return link for the U.S. Segment of the 

ISS. This return link is for real-time and recorded payload data (e.g. Columbus 

experiment data), video (real-time and recorded), and recorded ISS systems 

telemetry (recorded on the Zone of Exclusion – ZOE – recorder). There is also a 

forward link capability to support the two-way transfer of files and video 

teleconferencing. 

Experiments and video activity generate enormous amounts of data to be sent to 

the ground. The capacity of the Ku-Band, while large, is limited. Because of that, 

Payload Operations Integration Center (POIC) has to distribute the available capacity 

due to the requirements of the ISS systems and the payloads on board. 

The ISS Ku-Band subsystem nominally sends 50 megabits per second (Mbps) of 

serial data to the ground from up to twelve different channels. Subsystem


“overhead” is approximately 6.8 Mbps, so there is about 43.2 Mbps of usable 

capacity. Up to four of the twelve channels can contain video images from the Video 

Distribution Subsystem (VDS) and up to eight channels are reserved for payload 

data. Two of the payload data channels are shared between transmitting recorded 

telemetry and recorded payload data. 

The Ku-Band subsystem is furthermore able to receive up to 3 Mbps of serial data 

from the ground ([RD16], chapter 4.9). 

3.4 Telemetry Data Storage 

After being transferred from MCC-H to Col-CC by a ground subnet (Fig. 3–1), the 

raw telemetry is processed by the Monitoring Control System (MCS) and then stored 

on a telemetry server. This server can be accessed from inside Col-CC by using 

following URL (Uniform Resource Locator): 

\\Satmonof1\tlm 

A user and a password are necessary to access the archive. After successfully 

connecting to the server, the stored telemetry can be found in the folder: 

\\Satmonof1\tlm\K4\ColPrime1 

There are two subfolders in this directory, one is called “raw” and the other 

“zipped”. The “raw”-folder contains raw telemetry files with the file extension *.TLM. 

These files are not packed and hence need a lot of hard disk space. As a rule of 

thumb, it can be said that every day of raw telemetry consumes about 7 to 8 

Gigabytes of memory on the hard drive. 

Please note that the term “raw” here refers to telemetry data which has already been 

processed by MCS in order to be readable by Satmon (a telemetry visualization tool 

at Col-CC). It can be considered “raw” as input for the TM Extractor Tool described 

in the subchapter to follow. Actually, when Columbus telemetry arrives at MCC-H, it 

is still embedded into ISS telemetry frames as a sequence of bits, this unprocessed 

bit-sequence can really be called “raw”! 

However, the TLM-files on those server furthermore serve as input files for the 

Telemetry Extractor Tool (chapter 3.5), since they are trademarked and cannot be 

accessed directly. The folder “zipped” contains the packed telemetry files which in 

this state need much less space (about 400 Megabytes per day) on the hard disk. 

Due to the fact that the extraction process needs a lot of time and computational 

resources, it is recommended to work with the already extracted files. 

3.5 Telemetry Extractor Tool 

The Telemetry Extractor Tool has been developed to extract parameters from a 

TLM-file (chapter 3.4). This makes sense since the values of more than 12.000 

Page 23

Page 24 


Columbus telemetry parameters are incorporated into those TLM-files and the user 

is probably not interested in analyzing all of them at the same time. 

Parameter File 

(*.XML) 

File Input User Input 

Telemetry Extractor 

Telemetry Files 

(*.TLM) 

Extraction 

Time Frame 

Requested 

Parameters 

Extraction Process 

Extracted Telemetry 

File (*.TSV) 

Sample 

Number / Rate 

Fig. 3–3: Telemetry Extractor Workflow 

The program requires two input files and three user inputs. A list of every available 

Columbus telemetry parameter is provided by the parameter file, which is described 

by the XML (Extensible Markup Language) standard. Attention has to be paid to the 

fact, that always the newest parameter file has to be used, otherwise the extraction 

process might generate unexpected or false results. The telemetry files have to be 

provided by defining the folder in which they lie (see chapter 3.4). 

After providing the file inputs, the user has to define the time frame from which 

telemetry is extracted and the parameters to be analyzed. Also the number of 

samples (respectively sample rate) can be defined by the user. Please note, that the 

size of the output file and the time needed for extraction depends considerably on 

the chosen sample rate. Please take a look at chapter 4.2 for considerations of this 

issue. 

If everything has been defined properly, the extraction process can be started. Since 

the data volume is very large in the majority of cases, this process might take a few 

minutes if not an hour or more. The output file is a tab separated value (*.TSV) file 

which at the same time serves as an input file for the Telemetry Analyzer Tool 

(chapter 5). 

In this thesis, every analysis has been done by analyzing data which has previously 

been extracted by the Telemetry Extractor. There is no direct access to the 

telemetry files, since the format is trademarked. 

Please take a look at Appendix A.8 for a screenshot of the Telemetry Extractor Tool 

GUI (Graphical User Interface).

3.6 Telemetry Parameter Names 


The designation of Columbus telemetry parameters which are accessible via 

telemetry server (chapter 3.4) can be classified by the following appendices: 

Appendix DMC: 

Parameters ending with appendix “DMC” (e.g. ISFA_EU_Temp_DMC, 

WPA1_Water_Flow_DMC) were acquired by the Data Management Computer (DMC) 

in the Nominal DMS Layer with a sample rate of either 1 Hz or 0.1 Hz. 

Appendix VTC: 

Parameters ending with appendix “VTC” (e.g. IRFA_Fan_Speed_VTC, 

ISPR_F4_SD_Scatter_VTC) were acquired by the Vital Telemetry & Telecommand 

Controllers (either VTC1 or VTC2) in the Vital DMS Layer with a sample rate of 1 Hz. 

In general, these parameters are not used for telemetry analyses. 

Appendix MVD: 

Parameters ending with appendix “MVD” (e.g. VTC2_SUP4_SD_Stat_MVD, 

ISPR_F4_Warning_Flag_MVD) were acquired by the Vital Telemetry & Telecommand 

Controllers (either VTC1 or VTC2) and mirrored into the Data Pool of the Nominal 

DMS (MVD means “mirrored vital data”). 

Page 25

Page 26 

Data Analysis Concepts 

4 Data Analysis Concepts 

Since the amount of data in science and engineering grows rapidly, its assessment, 

analysis and interpretation often turns out to be the actual challenge when dealing 

with scientific problems. On the other hand, computing power and memory capacity 

have also increased immensely during the last few years as well as powerful 

algorithms have been developed. It is not easy to adequately make use of these 

tools without proper knowledge of the basic principles. This subchapter’s purpose is 

to shed light on these principles. 

4.1 Whittaker-Shannon Sampling Theorem 

First, we investigate the number of samples which are necessary to digitize an 

analogue (continuous) signal without loss of information. This is an important point 

because of the fact that Columbus telemetry is available as digital data with different 

sampling rates and the user might want to know the accuracy of an assumption he 

or she took regarding frequencies or periodic events. 

The Whittaker-Shannon sampling theorem shows how we can approach that 

problem. We assume an analogue signal u(t) which can be represented by the 

following Fourier-integral: 

+∞ 

∫ 

−∞ 

2πift 

u( 

t) 

= s( 

f ) e df 

(4–1) 

Here, the frequency is represented by f and the Fourier transform by s(f). In any 

application, the Fourier-spectrum is cut at an upper frequency f0 which is the 

bandwidth of the signal (in reality, no application with an infinite bandwidth exists!). 

Hence, we can say: 

u( 

t) 

= 

+ f 

∫ 

0 

− f 

s( 

f ) e 

0 

2πift 

df 

Fig. 4–1: Fourier Transform s(f) 

(4–2)


The last figure shows the Fourier transform s(f). Its range is per definition –f0 to +f0. 

Since the Fourier integral of u(t) only stretches across ±f0, s(f) can be continued 

periodically outside these limits without changing u(t) (Fig. 4–1 shows those curves 

with dashed lines). We call this new function s’(f), it has a period of 2f0. Between –f0 

and +f0, s’(f) is identical with s(f). Hence: 

u( 

t) 

= 

+ f 

∫ 

0 

− f 

s'( 

f ) e 

0 

2πift 

df 

Due to its periodicity, s’(f) can be represented as a Fourier series with period 2f0: 

s'( 

f ) 

+∞ 

∑ 

(4–3) 

−2πnif 

/ 2 f0 

= (4–4) 

n= 

−∞ 

ane 

The Fourier coefficient is: 

a 

+ f 

n ∫ 

0 − f 

0 

1 2π 

= s'( 

f ) e 

2 f 

0 

nif / 2 f 

0 

df 

(4–5) 

Let us now take a look at the special case when t = n/2f0 (n = 0, 1, 2, …). If we insert 

this in equation (4–3), we can write 

+ f 0 

n 

2πnif 

/ 2 f 0 u( ) s'( 

f ) e df = 2 f0 

2 f 

0 

= ∫ 

− f 

0 

a 

n 

(4–6) 

by comparison with equation (4–5). The Fourier coefficients an are in a direct 

relationship with the values u(n/2f0) of the signal and the Fourier transform can be 

written as: 

s'( 

f ) 

1 

2 f 

+∞ 

∑ 

−2πnif 

/ 2 f0 

= u( 

) e 

(4–7) 

0 n= 

−∞ 

n 

2 f 

0 

The function s’(f) defines the signal unambiguously and by means of equation (4–3). 

Because of that, the signal function can clearly be determined by the values u(n/2f0) 

at the sampling times 

n 

tn = , n = 0, 1, 2, … (4–8) 

2 f 

0 

Page 27

Page 28 


From this we can conclude: the function u(t) is representable unambiguously and 

without loss of information by samples with sampling intervals of TS = 1/2f0. 

This statement is called the “sampling theorem”. [RD01], p. 20 

What impact does this statement have on the analysis of data? Since the sampling 

frequency is defined by the reciprocal value of the sampling time (fS = 1/TS), we can 

write: 

T 

f 

f 

S 

S 

0 

1 

≤ 

2 f 

≥ 2 f 

fS 

≤ 

2 

0 

0 

(4–9) 

The sampling intervals must be equal to or less than 1/2f0. The sampling intervals 

may of course be smaller, but never larger; otherwise we get a loss of information! 

After calculating the sampling frequency fS, we can determine the maximum 

bandwidth f0 by transforming the equation. It has to be equal to or smaller than half 

the sampling frequency, which means that in order to reconstruct the original signal 

without loss of information, the highest frequencies in the signal may not be higher 

than half the sampling frequency. 

If we apply this knowledge for example to Columbus telemetry acquired with 1 Hz 

(chapter 3.2), we can say that the highest frequency in the original analogue signal, 

which can be covered by the sampled discrete signal without loss of information, is 

0.5 Hz. That means, that we can observe events which have a period of 2 seconds 

and more, but not less! 

4.2 Reasonable Data Reduction 

When having the task to extract telemetry with the Telemetry Extractor Tool (chapter 

3.5), data reduction becomes an important issue. The table below gives some 

examples of data volumes of extracted telemetry file in *.TSV format: 

Tab. 4–1: File Sizes of extracted Telemetry in *.TSV Format 

File Name Number of Parameters Sample Rate File Size 

DOY065-065_Power_Outlets.tsv 21 0.1 Hz 1.07 MB 

DOY295-297_CHX_DryOut_Details.tsv 8 0.33 Hz 4.80 MB 

DOY245-342_HCU1_Thermistor_Temperatures.tsv 18 0.01 Hz 12.70 MB 

DOY095-108_critical_fan_period.tsv 3 1 Hz 48.80 MB 

Impacts of the sample rate on the size of the file can be seen very well. While the file 

in the first row for example only has a size of 1.07 MB although it contains 21


parameters (extracted over a period of one day), the file in the last row has 48.80 

MB with only 3 parameters and extracted over a period of 13 days. The main 

difference of both is the sample rate, which in the latter case is 1 sample per second 

(1 Hz) and in the former 1 sample every 10 seconds (0.1 Hz). It can be seen that 

there is a large difference between 1 MB and 50 MB which have to be processed. 

Thus, it is recommended to carefully choose sample rate in order to keep file size 

and processing time small. 

Chapter 4.1 dealt with the sampling theorem and its implications on digital data 

processing. In the following it is explained how different choices of sample rates 

influence the analysis of Columbus telemetry: 

Fig. 4–2: TCV Position displayed with different Sample Rates 

The two figures above demonstrate how the sampling rate influences real 

measurements. While in the upper of the two figures a large time period is 

demonstrated, the lower one only zooms in on the middle peak. Change of Thermal 

Page 29

Page 30 


Control Valve (TCV) position is monitored in this example, the red curve represents 

an extraction with a sample rate of 0.01 Hz, the blue one with 0.33. We can see that 

the peaks have different amplitudes and periodic times in the low resolution (red 

curve) extract. This is not the case when we observe the high resolution extract (blue 

curve), there amplitude and periodic time remain nearly equal. 

When we measure the periodicity of the peak in high resolution, we see that it has a 

periodic time T0 of about 74 seconds. Hence, we can calculate the bandwidth f0 to: 

1 1 

f0 = = = 0. 

0135Hz 

T 74 

0 

By using the sampling theorem equations (4–9), we can calculate the minimum 

sampling frequency which has to be used to sample that signal without loss of 

information to: 

f S ≥ 2 f0 

= 0. 

027 Hz 

Thus, we have to sample with at least 0.027 Hz (one sample every 37 seconds) to 

get accurate readings. This is only the case in the blue curve (0.33 Hz), the red curve 

does not comply with the sampling theorem (0.01 Hz < 0.027 Hz). 

Recommendations: 

To reduce effort and time to process telemetry data, it is recommended to first 

extract data in the required time frame with a low sample rate (for example one or 

two samples per minute). This keeps file size small and reduces time of processing 

with the Telemetry Analyzer. Subsequently, when smaller time frames have to be 

investigated, it is better to increase the sample rate. Due to the lack of high 

frequency phenomena, it is rarely necessary to fully use the 1 Hz sampling capability 

of Columbus. For high resolution extracts, one sample every three or ten seconds 

(0.33 or 0.1 Hz) often delivers fully satisfying results. 

4.3 Mathematics 

4.3.1 Numerical Integration 

For some analyses, it might be useful to calculate the area under a plot. The 

multiplication of a device voltage by its current consumption (both direct current, 

DC) for example, corresponds to the power which is consumed by the device (in 

watts). If we calculate the area under the power consumption plot, we can determine 

the total amount of energy which is consumed in a certain time frame. 

There are various methods to calculate the definite integral of a set of discrete data 

points. The simplest method is the trapezoidal rule, which will now be discussed.

y 

1 

T1 

Δt 

2 

3 

Δt Δt Δt Δt 

4 


f(t) 

t1 t2 t3 t4 t5 t6 

Fig. 4–3: Trapezoidal Rule of Integration 

Let’s assume the given data points y1 to y6 and the interpolated curve f(t) which is 

going through them (Fig. 4–3). The definite integral of f(t) from t1 to t6 is defined by: 

t 

6 

∫ 

I = f ( t) 

dt 

(4–10) 

t 

1 

Since telemetry data is always time dependent, we use dt and Δt right from the 

start. We can now begin to divide the area under the curve into N trapezoid-shaped 

segments with the width ∆t (in Fig. 4–3, we have five such segments, N = 5). The 

area of such a trapezoid can be calculated by summing up the area of a rectangle 

and a triangle (we begin with the leftmost trapezoid from t1 to t2): 

A 

A 

T1 

Ti 

= 

t 

= 

2 1 2 1 

( t − t ) y + ( y − y ) = ( y + y ) = ( y + y ) 

2 

1 

− t 

2 

1 

2 

( y + y ) = ( y y ) 

i+ 

1 i 

i i+ 

1 

i + 

1 

t − t 

2 

∆t 

2 

t 

i+ 

1 

− t 

2 

1 

2 

∆t 

2 

1 

5 

2 

6 

t 

(4–11) 

The first line of equation (4–11) describes the area of the leftmost trapezoid, while 

the second line is the same equation in a general form using indices for 

mathematical processing. 

We can now calculate the trapezoidal rule integral IT by summing up the areas of all 

N trapezoid-shaped segments. By using equation (4–11), we get: 

I 

T 

= 

N 

∑ 

i= 

1 

A 

Ti 

= 

N 

t 

− t 

2 

( y + y ) = ( y + y ) 

i+ 

1 i 

∑ i i+ 

1 ∑ 

i= 

1 i= 

1 

N 

∆t 

2 

i 

i+ 

1 

(4–12) 

Page 31

Page 32 


Please note, that this method works as well with uniform-width segments (all ∆t 

equal), as with segments not having the same width. The more segments the plot is 

subdivided into, the better is the accuracy of the trapezoidal rule. Since linear 

approximations are used to segment the function f(t), calculating the integral of a 

linear function with this method would be exact. 

We finalize the discussion with the estimation of the error of IT, which can be done 

by using a Taylor series expansion. Since deriving this expansion would go beyond 

the scope of this thesis, it is referred to in [RD01], chapter 5.5.3. There we can find 

the result of this derivation to: 

I 

( t − t ) 

3 

'' 

T − I ≈ f ( t) 

⋅ i+ 

1 i 

2 

(4–13) 

12N 

This means, that the error of a definite integral calculated with the trapezoidal rule 

decreases with a proportionality factor of 1/N 2 with increasing number of segments 

N. Thus, the more segments N we subdivide our function f(t) into, the more accurate 

are the results we get from the trapezoidal rule integral calculation. 

4.3.2 Mean Values 

Two mean values could be useful for certain analyses: the first one is the arithmetic 

mean value (MA). It is defined by following equation: 

M 

A 

= 

1 

N 

N 

∑ = 

i 1 

x 

i 

(4–14) 

The single data points xi are summed up and subsequently divided by the number of 

data points N. The result of this calculation is the average value of all data points. 

Another kind of mean value is the geometric mean value. It can be calculated 

according to the following equation: 

N 

M N 

G = ∏ 

i= 

1 

x 

i 

(4–15) 

In statistics, the arithmetic mean value plays an important role while the geometric 

mean value is a feature which is nice to have but is of low importance in the most 

cases.

5 The Telemetry Analyzer Tool 

The Telemetry Analyzer Tool 

Part of this thesis was the development of a software tool, which allows the user to 

easy analyze and process telemetry data. Due to restrictions in the direct access of 

raw TM data for analysis, it is necessary to extract the required parameters by the 

Telemetry Extractor Tool (chapter 3.5). The so generated tab-separated-value file 

(extension: *.TSV) can be read and processed by the Telemetry Analyzer. 

The TM Analyzer was completely programmed in C#; its code can easily be 

extended or modified due to its object oriented nature. Although the current version 

only supports Windows, the program could probably be ported to Linux by using a 

Linux-compatible compiler. 

Chapter 4 dealt with the increasing amount of recorded data, its impact on science 

and engineering and with methods of how those large data volumes can be handled 

and processed. After that rather theoretical chapter, the general program workflow 

of the TM Analyzer is discussed now, followed by the program architecture. 

Furthermore, its concepts are introduced and the classes including their 

implementation via algorithms and standardized diagrams are described. 

5.1 General Program Workflow 

Before dealing with class diagrams and other specific information, we have to give 

some thoughts on the general workflow of the program. 

Fig. 5–1: General Program Workflow 

First, a file hast to be loaded and read by the program. After that, data from the file 

can be extracted and stored internally by the program. The user can now add or 

Page 33

Page 34 


delete diagrams, perform various kinds of analyses and save their outcomes to a 

file. 

With this raw concept, we will now begin to go into the details of the program 

architecture. 

5.2 Program Architecture 

As already mentioned, the TM Analyzer has been programmed in an object oriented 

programming language. This concept allows the user to design a program with a 

modular structure which can be extended or modified virtually endlessly. Another 

advantage is, that the programmed code can be reused in other applications with 

nearly no adjustment efforts. 

We will begin with the general program design. Which requirements does the 

program have to meet and which functions does it have to offer? After that, the TM 

Analyzer is described in a graphical way by using a class diagram (structure 

diagram) and a use-case diagram (behavior diagram). 

5.2.1 UML Diagrams of Telemetry Analyzer 

5.2.1.1 Class Diagram 

The Unified Modeling Language (UML, [RD18]) is a standardized graphical language 

which is used in software engineering for visualizing and specifying software 

intensive systems. 

The class diagram of the TM Analyzer is based on the UML notation and can 

therefore be read and understood by any person who is familiar with UML. It 

illustrates the interrelationships between the different classes and hence is 

representative for the structure of the software.


Fig. 5–2: Classes and Windows Forms used for the Telemetry Analyzer 

In the former figure, a quick overview of the classes and forms used by the TM 

Analyzer is provided. Please note, that this picture does not represent the class 

diagram yet. It only demonstrates the classes with its methods and fields and their 

inheritance from the superclasses “Object” and “Form”. In this case, the term 

“superclasses” denominates classes from which other classes are derived (via 

inheritance for example). Inheritance is represented by a clear triangular-shaped 

arrow pointing to the superclass. 

In addition, the methods and fields of every class are shown. The lock symbols 

beside the methods signify that the method is “private” and hence only can be 

accessed from inside the class. In general, every method which is used by other 

classes has to be accessible (“public”). 

The following figure shows the class diagram of the TM Analyzer. A connection 

element with a clear diamond shape on one side is called “aggregation”. An 

aggregation typically has the following characteristic [RD18]: It can occur when a 

class (subclass) is part of another class (superclass) without having a strong life 

cycle dependency, which means that the content of the subclass not necessarily 

has to vanish if the superclass is destroyed. The diamond shape points to the 

superclass. 

The dashed line with the open arrow describes a dependency [RD18]. In this case, 

the dependencies describe the use of a class during the runtime of a method in 

another class. MATHTOOLS for example uses as well an instance of the 

DIAGRAMTOOLS class as an instance of the CONVERSIONTOOLS class. Both instances 

are generated during the runtime of certain methods in MATHTOOLS but disposed at 

the end of the respective method. 

Page 35

Page 36 


Fig. 5–3: Class Diagram of the Telemetry Analyzer 

The class MAINFORM is the heart of the program and contains all the necessary code 

for the GUI and the control elements by which the user is able to control the 

program. It is directly connected with the class SHOWDIAGRAMFORM which is 

responsible for the visualization of the data as graphs in an extra window. 

All the classes which contain the word “tools” are classes which have a certain 

function. READERTOOLS for example reads a file and stores the values internally for 

further processing, while MATHTOOLS provides functions for mathematically 

analyzing telemetry data. Chapter 5.3 provides details about every class, its 

algorithms and special functions. 

5.2.1.2 Use-Case Diagram 

The use-case diagram is, like mentioned before, based on the standards defined in 

UML [RD18]. Since it describes a behavior, it can be classified as behavior diagram. 

The use-case diagram describes the functionalities of a system by visualizing the 

relations between an actor (in this case the user who uses the program) and the 

different use cases (the functionality of the program). The diagram has been 

designed properly if it describes every function of the system including its relations 

to each other and to actors outside. 

The following figure illustrates the use-case diagram for the Telemetry Analyzer. It 

shows the different functions of the program and how they interact with a user and 

with each other. Please note that this kind of diagram – like a class diagram – is not 

able to model time dependent processes. Because of that, every possible use case 

can be seen in the diagram at the same time, only distinguished by its 

interdependencies to other use cases or the user.


Fig. 5–4: Use-Case Diagram for the Telemetry Analyzer 

The rectangle marks the system boundary, use cases are represented by ellipses. A 

dashed line with an “include”-label means, that the use case to which the arrow is 

pointing is a use case which can be derived from the use case on the other side. For 

example: only if a file has been loaded (“load file”), the user can add a parameter to 

the graph (“add parameter to graph”). Hence, one case “includes” the other one. 

The continuous lines with the triangle-shaped arrowheads describe specializations. 

The use case to which the arrowhead is pointing is the general case, while the use 

case on the other side represents a specialized case. “mathematical operations” for 

example would be the general case whereas “arithmetic operations” or “calculus” 

are special cases of mathematical operations. 

The lines between the user and the use cases represent the relations between them. 

The “1” and “n” describe the cardinality between the elements. “n” means, that the 

use case can be represented an arbitrary number of times. As it can be seen in the 

former figure, one user (“1”) can for example open an arbitrary number of programs 

(“n”). But: one user (“1”) can only choose one color (“1”) per parameter showed in 

diagram. 

5.3 Class Description 

Every class has a specific purpose, which is described in the following subchapters. 

Considering the complexity of the code, the descriptions will be kept in a certain 

Page 37

Page 38 


frame to not go beyond the scope of this thesis. Since the code has been 

documented properly, details which have not been discussed in this thesis can be 

found there. 

5.3.1 The MAINFORM Class 

The MAINFORM class is the heart of the Telemetry Analyzer and is 

derived from the WINDOWS.FORMS class [RD15] via inheritance. It 

initializes and disposes the program, it contains every control 

element of the GUI (basically, it is the GUI!) and it also controls the 

SHOWDIAGRAMFORM. In essence, it is the platform on which the 

program is constructed. If the user enters a value or clicks a button, 

the MAINFORM class processes the request. 

To have access to the TM Analyzer specific methods, MAINFORM 

aggregates an instance of every “tools”-class described in the 

following chapters. 

5.3.2 The ReaderTools Class 

Before conducting any analysis, a file has to be loaded and its 

contents have to be stored to a program internal storage location. 

The READERTOOLS class provides the necessary methods for these 

operations. 

Chapter 3.5 dealt with the Telemetry Extractor tool, which extracts 

the chosen parameters and writes them into a text file. Values in 

those text file are separated by tabs and always organized the same 

way. 

An example of a so generated tab separated value file (TSV-file) can be seen in the 

following table. The indices 0 to N in the first row and 0 to M in the first column (both 

zero based) shall provide a little orientation when analyzing the structure. In a real 

file, they do not exist! 

Tab. 5–1: Structure of a Telemetry Extractor generated TSV-File 

0 1 … N 

0 “Sample Time” “Parameter 1” … “Parameter N” 

1 "2008-061-00:16:07.479" “15.2” … “0.014” 

2 "2008-061-00:16:08.265" “14.7” … “0.033” 

3 "2008-061-00:16:09.505" “14.12” … “0.036” 

… … … … … 

M “2008-072-11:45:353” “11.2” … “0.456” 

The structure of the file appears like a matrix with N rows and M columns (M x N 

matrix). Sample times are listed in the first column, while every other column 

contains the corresponding parameter values.

5.3.2.1 Reading/Storing Process 


Considering the matrix structure of the file, a two-dimensional array offers the 

perfect storage possibility. And not only storage, also the index-based access to the 

stored values is efficient and easy. Thus, a two-dimensional array is chosen for 

internal storing of the loaded data. 

Fig. 5–5: Flow Chart of the File Reading and Storing Process 

The former figure demonstrates the algorithm of the method ReadDataFromFile(). A 

dialog prompts the user to choose a file, if the chosen file is valid (meaning that it 

has the M x N matrix structure) the program determines the number of rows and 

columns. With two counter variables and two loops the values (elements in the 

“cells” of the matrix structure) are read and subsequently stored into the twodimensional 

array. Since the data in the TSV-file is stored as text, it is reasonable to 

use a two-dimensional string array, which is declared as string[M,N]. 

For more details, please refer to the code documentation. 

5.3.3 The ConversionTools Class 

Due to the fact that every value is stored as a string variable (chapter 

5.3.2), it is important to be able to check if the string contains a 

numeric value or not. The method IsNumeric() is responsible for 

doing that. 

Furthermore, the class offers methods for date and time conversions. 

The input file from the Telemetry Extractor Tool saves the sample 

times in the following format: 

“2008-061-00:16:09.505” 

It begins with the year (2008), followed by the day of year (DOY, 061). 

Finally the time (00:16:09.505) is provided. To make it more comfortable for users 

who work with the data, the DOY is converted to a less abstract format like for 

example “February 25, 2008” instead of “056” as the corresponding DOY value. The 

Page 39

Page 40 


two methods ExtractDOYYearHHMMSS() and ConvertDOY2DateTime() perform 

these conversions by using simple algorithms which can be found in the code. 

5.3.4 The MATHTOOLS Class 

The MATHTOOLS class has been developed for mathematical 

operations. It performs various kinds of calculations with the data 

which has been loaded and stored before by the READERTOOLS 

element. 

It can be distinguished between calculations where only one 

parameter is involved (C1) and calculations where two parameters 

are involved (C2). The results of C1 calculations can be used for 

analyses or as input for other applications. 

C2 calculations are only performed for visualization. The results 

cannot be accessed directly from the Telemetry Analyzer tool; they 

can only be displayed as diagrams. Nevertheless, C1 calculations can be performed 

by using the results of a C2 calculation. 

The respective calculations contain the following functions: 

C1 calculations: 

• arithmetic mean value 

• geometric mean value 

• definite integration 

• interval minimum / 

maximum 

C2 calculations: 

• sum of two parameters 

• difference of two parameters 

• product of two parameters 

We will begin with the description of the C1 algorithms. 

5.3.4.1 Integration Algorithm 

• quotient of two parameters 

Chapter 4.3.1 dealt with the numerical way of calculating a definite integral. The next 

figure shows, how this numerical method (the trapezium rule) is being implemented 

and used in the Telemetry Analyzer through the CalcIntegrationTrapezium()-method.

Start 

determine: 

N := number of 

data points 

N > 0 ? 

yes 

i = 0 

P1 := value of 

point P(i) 


point P(i+1) 

no 

yes 

i++ 


End 

i < N ? 

calculate 

trapezoid area AT 

(eq. 4–12) 

determine time 

interval ∆t 

IT += AT 

Fig. 5–6: Flow Chart of the Integration Algorithm 

The algorithm begins with the determination of the total number of data points. It 

then extracts two consecutive points, calculates the ∆t between them and applies 

equation (4–12) for calculation of the trapezoidal area (AT) beneath the two points. 

This is done in a loop as long as the last two data points have been reached. During 

the runtime of the loop, the calculated trapezoidal areas AT are summed up (blue 

framed rectangle in the former figure) thus getting the value IT of the definite integral 

of the given function represented by the data points. 

5.3.4.2 Mean Value Algorithms 

Fig. 5–7: Mean Value (left: Arithmetic, right: Geometric) Algorithms 

no 

Page 41

Page 42 


The in chapter 4.3.2 defined mean values are calculated by the functions 

CalcArithmeticMean() and CalcGeometricMean(). The flow chart on the left side of 

previous figure 5–7 describes the algorithm for the arithmetic mean value 

calculation. At its beginning, the method determines the number of data points N. If 

this has been done, the algorithm enters into a loop in which the values of all data 

points are summed up one after another. After the determination of the sum of all 

data point values, we may apply equation (4–14) to calculate the arithmetic mean 

value MA. Geometric mean values are calculated nearly the same way as arithmetic 

mean values are. The number of data points N is important and the loop does not 

calculate the sum but the product of all data point values. With this product, the 

number N of data points and the application of equation (4–15), the geometric mean 

value can then be calculated. 

5.3.4.3 Interval Minimum/Maximum 

Start 

determine: 


data points 

N > 0 ? 

yes 

no 

End 

i++ 

i = 0 MAX = P(i = 0) P1 := P(i) 

P2 := P(i+1) 

yes 

P2 > P1 ? 

AND 

P2 > MAX ? 

no 

no 

yes 

i < N ? 

MAX = P2 

Start 

determine: 


data points 

N > 0 ? 

yes 

no 

End 

i++ 

i = 0 MIN = P(i = 0) P1 := P(i) 

P2 := P(i+1) 

yes 

P2 < P1 ? 

AND 

P2 < MIN ? 

Fig. 5–8: Maximum (left) and Minimum (right) Calculation Algorithm 

Sometimes it might be useful to get the minimum or maximum value of a parameter 

within a defined interval. The determination of these values is very simple since the 

data is available in discrete form. This fact reduces the effort of finding the 

minimum/maximum to a simple comparison-algorithm. 

As we can see in the last figure, the algorithm begins with the determination of the 

number of data points N. We need this value for a loop which has N iterations and is 

controlled by the count variable i. 

We’ll begin with the description for the maximum value algorithm: before entering 

the loop, the value of the first data point P(i=0) is stored to the MAX variable. After 

that, the algorithm enters into the loop and determines the values of two 

consecutive data points (P(i) and P(i+1)). It is now that the algorithm determines if 

the second value P(i+1) is larger than the first one P(i). Furthermore, a comparison 

between the second value P(i+1) and the MAX variable is conducted. If both 

comparisons are positive (which means that P(i+1) is larger than P(i) and the MAX 

no 

no 

yes 

i < N ? 

MIN = P2


variable), MAX is overwritten with the value of P(i+1). The loop continues until the 

algorithm has processed all data points. 

The minimum value is determined exactly the same way except that the two 

consecutive data points are not compared if the second one is larger than the first 

but the other way around. Fig. 5–8 at the beginning of this subchapter describes 

both processes by using a flow chart, more detailed information can be found in the 

code documentation. 

5.3.4.4 Arithmetic Operations 

The last feature which is offered by the MATHTOOLS class is the possibility to 

conduct arithmetic operations with two parameters. This might be useful for 

example, if we want to calculate the power consumption of a device by multiplying 

its input current and input voltage. Since there are more than one parameters 

involved in these calculations, they are considered C2 calculations (chapter 5.3.4). 

Start 

determine: 


data points 

N > 0 ? no End 

yes 

i = 0 

get value of parameter 1 

at index i 

P1 = P1(i) 

get value of parameter 2 

at index i 

P2 = P2(i) 

i < N ? 

yes 

no 

i++ 

calculate (depending on 

user input): 

P1 + P2 

P1 - P2 

P1 x P2 

P1 / P2 

save outcome of 

calculation to new twodimensional 

array 

Fig. 5–9: Flow Chart of the Arithmetic Calculations Algorithm 

The algorithm described by the flow chart in former figure shows how arithmetic 

operations between two parameters are done. Unlike C1 calculations (described in 

the last few subchapters) which always return exactly one value, these C2 

operations return a new two-dimensional data array containing the values calculated 

by the arithmetic operation. The new data array may be used for graphical 

interpretation or for the conduction of further C1 calculations. 

Like the other calculation algorithms, this one also begins by determining the 

number of data points N. A loop goes through all data points of both (!) parameters 

and conducts the arithmetic operations defined by the user. Every operation is 

conducted point-wise so that the calculation effort is relatively low. The only 

disadvantage is the fact, that in order to keep the calculated results available, they 

have to be stored to a new two-dimensional data array which again consumes 

computer memory. 

Page 43

Page 44 


In order to store the new data arrays, a simple concept has been developed: 

Fig. 5–10: Storage Concept for new Data Arrays 

The new data arrays are embedded into a List class object. List represents a 

strongly typed list of objects that can be accessed by index. Furthermore, it 

provides methods to search, sort, and manipulate the list (please take a look at the 

online documentation of List in [RD15]). 

The first object to be stored into the List entity is the primary data array which is 

filled during the loading and reading process (chapter 5.3.2.1). It is the only object 

which is never removed from List since it contains all data sets (of course this 

data array is replaced by another one if the user loads a new file!). If a C2 calculation 

has been conducted, the results of the calculation are stored into a new twodimensional 

data array which is then appended to the List object. 

If the user wants to access a specific data set (e.g. for graphical analysis or for a C1 

calculation), a search algorithm already implemented in the List object is able to 

search for it. The single data sets are identified through their IDs (Fig. 5–10) which 

always contain the name of the respective data set. 

Advantages of the List usage are furthermore the simple manipulation 

possibilities (sort, search, delete) of single data sets. This gives the programmer the 

liberty of designing the program with slim and efficient code without having to worry 

about the implementation and maintenance of lists and its objects. 

5.3.5 The CHANGEANALYSISTOOLS Class 

There are situations in which it is interesting to investigate, when the 

change of a parameter value exceeded a certain threshold. Such an 

investigation could for example be useful if the parameter is a signal 

which is superimposed by white noise. By defining a certain threshold 

level by which the signal may increase or decrease without appearing 

unnatural, spikes could be detected if the threshold level would be 

exceeded.


Of course the threshold level could be defined only in positive or negative direction, 

but it could be useful for some applications to be able to “monitor” thresholdchanges 

in both directions. The CHANGEANALYSISTOOLS class offers a method which 

is able to perform both cases, we will subsequently learn how. 

Fig. 5–11: Concept for Analysis of Changes 

Figure (5–11) illustrates how the method GetChangeTimes() processes a data set. 

The user defines a reference ∆Xref which represents the threshold level. Two 

consecutive points of the parameter (blue-colored in the figure) are compared and 

their difference ∆X is calculated (marked red and green). The calculated difference is 

compared to the user defined threshold level. Depending on the user choice, the 

comparison is conducted in one of the following ways: 

• +∆X: the method checks if the calculated value ∆X exceeds the user defined 

threshold level ∆Xref in positive direction (second value is larger than first one) 

• -∆X: the method checks if the calculated value ∆X exceeds the user defined 

threshold level ∆Xref in negative direction (second value is smaller than first 

one) 

• ±∆X: the method checks if the calculated value ∆X exceeds the user defined 

threshold level ∆Xref in positive and negative direction (second value is 

larger/smaller than first one) 

A log file in the following format is the result of the change analysis: 

Change Analysis, 10.12.2008 11:07:10 

Parameter: PDU1_Sys_Pwr_Out_DV 

Change Threshold ∆X = ± 1.5 

Start Date: 13.02.2008 22:39:52 

End Date: 26.02.2008 23:00:47 

Page 45

Page 46 


13.02.2008 23:00:56 ∆X = 0.3538461598 

13.02.2008 23:03:29 ∆X = 0.0676923 

13.02.2008 23:47:47 ∆X = 0.194872 

14.02.2008 00:48:00 ∆X = -0.174359 

17.02.2008 12:43:17 ∆X = -0.157264 

17.02.2008 16:07:41 ∆X = 0.157265 

22.02.2008 22:50:58 ∆X = -0.184616 

As it can be seen, the method saves every point in time in which the user defined 

threshold level is exceeded. In this example, a ∆Xref of 1.5 has been defined and the 

analysis has been conducted for positive and negative changes (±). 

The following figure demonstrates the algorithm of the method in a graphical way: 

determine: 


data points 

user input: 

+, -, ± 

Start 

N > 0 ? 

i = 0 


point P(i) 


point P(i+1) 

5.3.6 The DIAGRAMTOOLS Class 

5.3.6.1 Introduction 

yes 

i++ 

no 

yes 

End 

no 

i < N ? 

no 

Input = ± ? 

no 

Input = - ? 

no 

Input = + ? 

determine value 

difference 

P1 – P2 := ∆X 

yes 

yes 

∆X < ∆Xref 

AND 

∆X > ∆Xref 

∆X < ∆Xref 

∆X > ∆Xref 

Fig. 5–12: Change Analysis Algorithm 

yes 

yes 

yes 

yes 

no 

add point in time 

of occurrence to 

protocoll 



protocoll 

no 



protocoll 

The handling of diagrams is done by the DIAGRAMTOOLS class. It 

provides methods which convert the data read from a file into pairs of 

points which can furthermore be displayed as a diagram. The so 

generated curves can also be modified by the methods in this class, 

the area under a curve could for example be filled or the data points 

could be indicated by squares, diamonds or stars. There is also a 

method which removes a specified curve so that the user is able to 

no 

continue 

continue


manage the number of curves in a diagram and a method which smoothes the 

curve. The smoothing process is done by an internal interpolation, the user is able to 

choose between the interpolated and smoothed curve (which exactly passes 

through the data points) or the curve which simply connects the data points with a 

straight line. 

It follows a short description of every available method and a picture demonstrating 

the changes. 

GeneratePointPairList(): generates a list of point pairs (x|y) from the data loaded by 

the user. The list can be used to display a curve (case A, standard case). 

RemoveCurve(): removes a user specified curve from the diagram. 

SetLineItemFill(): fills the area under a curve (case C). 

SetLineItemSmoothed(): interpolates the curve between the points (case B). 

SetLineItemSymbol(): sets the symbol type of the data points (e.g. squares, 

diamonds, stars, etc …), (case D). 

Fig. 5–13: Diagram Options A – D 

5.3.6.2 Comparing Diagrams from different Input Files 

Sometimes, it might come handy to display diagrams from different input files in one 

graph pane. This allows the user to compare the curves without having to extract 

the desired telemetry parameters from the telemetry archive again (which might be 

very time consuming). Another advantage is the fact, that the sample rates of the 

different input files do not matter because the program merely displays the data but 

does not perform calculations or analyses. 

Page 47

Page 48 


Fig. 5–14: Primary/Secondary File Inputs 

As depicted in the last figure, the processing spectrum of these so called secondary 

input files is highly restricted. The file read regularly by the Telemetry Analyzer is 

called primary input file. The important difference between primary and secondary 

input files is not only the spectrum of processing possibilities but also the 

multiplicity. When the TM Analyzer is running, only one primary input file can be 

opened at a time (containing a finite number of diagrams which can be displayed), 

this restriction does not apply to the secondary inputs. The user can add as many 

diagrams from as many input files as wanted to the graph pane, but it has to be 

considered, that the data can be processed merely graphically. 

5.3.7 The SHOWDIAGRAMFORM Class 

Finally, a form which shows and controls the diagrams with its 

curves has to be provided. This is done by the SHOWDIAGRAMFORM 

class which is – like the MAINFORM class (chapter 5.3.1) – a 

windows form with the ability to display things to the user. It could 

be said, that the SHOWDIAGRAMFORM is the second GUI of the 

Telemetry Analyzer. Since it would take a lot of time to develop a 

proper application programming interface (API) to display the 

graphical data, a free available open source solution has been 

chosen to fulfill this requirement. ZEDGRAPHCONTROL is a set of classes which 

contain powerful graphical tools with whom it is possible to display nearly any kind 

of diagram. They come as an already compiled DLL-file (dynamic link library) and 

can be included in any C# project [RD20].


Fig. 5–15: MainForm and ShowDiagramForm 

Every curve generated from the file read data can be found in the ZEDGRAPH control 

element (see last picture). In order to manipulate something, it is always necessary 

to get the ZEDGRAPH-control. While the MAINFORM class administrates the data read 

from a file and processes various user requests like for example performing a 

mathematical operation, the SHOWDIAGRAMFORM including its ZEDGRAPH-control only 

have the job to display and manipulate diagram data. The SHOWDIAGRAMFORM class 

never interferes with or manipulates data coming from the MAINFORM class! 

Please take a look at the code and the documentation of the ZEDGRAPH API [RD20] 

for further details. 

5.4 Adaptation of the Telemetry Analyzer Software 

The Telemetry Analyzer Software has especially been programmed to read 

Columbus telemetry. At the institute of astronautics (LRT) at Technische Universität 

München (TUM), the question has been raised, if it would be possible to adapt the 

TM Analyzer to read and process telemetry data of other satellite projects, for 

example MOVE or BayernSat [RD14]. This chapter shall investigate the possibilities 

and the adaptations which would have to be applied to the TM Analyzer if it were to 

be adapted to another satellite project. 

Generally, there are two possibilities to approach this problem: 

Page 49

Page 50 


1. The data format of the other satellite’s telemetry is adapted to the input 

format which the TM Analyzer is able to read (chapter 5.3.2). 

2. The reading subroutine of the TM Analyzer is adapted to the telemetry format 

of the other satellite. 

Both approaches have their advantages and disadvantages. The first approach 

would require no alteration of the program, but it would probably be difficult to 

adapt the telemetry format of the satellite project to the Columbus standard, 

especially if the format has already been specified. That problem on the other hand 

could be solved by using an intermediate program like the Telemetry Extractor Tool 

(chapter 3.5) to extract telemetry into a TSV-file which is compliant with the 

Telemetry Analyzer. 

The second approach would require the reading subroutine of the program to be 

adapted to the telemetry standard of the other satellite project. Since the reading 

subroutine is simple (chapter 5.3.2.1) and the program architecture object oriented, 

it should be relatively easy to design a new reading subroutine which is able to read 

telemetry from another satellite project. The program could even be modified to 

open two or more different kinds of telemetry input files. 

Since it is probably easier to write a new reading subroutine for the Telemetry 

Analyzer Tool than to modify the telemetry format of a satellite project from the 

scratch, the second approach is most likely the better solution to this problem.

6 Columbus Module TCS Analyses 

Columbus Module TCS Analyses 

Preliminary chapters 2, 3, 4 and 5 have provided the technical bases to now 

commence with the actual analyses of Columbus telemetry. Chapter 2 has gotten us 

acquainted with thesis relevant Columbus subsystems, chapter 3 with the 

acquisition and processing of telemetry. Basics of data processing and mathematics 

have been introduced in chapter 4 and the Telemetry Analyzer Tool has been 

addressed in chapter 5. 

Analyses are conducted by using following procedure: 

• formulate a hypothesis 

• determine necessary Columbus parameters 

• define approach to prove/disprove the hypothesis 

• draw conclusions from analysis 

There are several ways to make a hypothesis: either there are design requirements 

whose performance is subject to investigation (functionality of the water cooling 

loop for example), or hypothesis are formulated when noticing unexpected behavior 

of certain Columbus parameters. By studying technical schematics of the examined 

system, the required parameters (e.g. temperature sensors, water flow sensors, 

etc…) can be determined. The approach-phase is defined by extracting the required 

data with the appropriate sample rate in the right time frame and by using the right 

tools (TLM Extractor and Telemetry Analyzer). In this phase, calculations can be 

carried out and the relevant subsystem may be discussed in detail to support the 

engineering process. Finally, conclusions are drawn from the results obtained in the 

prior phases. 

Fig. 6–1: Steps for Conducting an Analysis 

The first analysis conducted in chapter 7.1 has the purpose to demonstrate the 

procedure defined above and the functionality of the Telemetry Analyzer, its 

conclusion is of low importance to engineering. 

Chapter 6.1 will now begin with analyses of the Thermal Control System (TCS), 

chapter 7 follows with analyses of the Environmental Control & Life Support System 

(ECLSS). Unless otherwise noted, the X-axes of the diagrams generated by the 

Telemetry Analyzer always show Universal Time Coordinated (UTC). 

Page 51

Page 52 


6.1 Shell Temperature depending on ISS Flight Attitude 

Hypothesis: 

ISS attitude has a direct impact on shell temperatures. 

Parameters: 

HCU2_FD_THR1_Temp_MVD [°C] HCU2_FD_THR2_Temp_MVD [°C] HCU2_FD_THR3_Temp_MVD [°C] 

HCU2_FR_THR1_Temp_MVD [°C] HCU2_FR_THR2_Temp_MVD [°C] HCU2_FR_THR3_Temp_MVD [°C] 

HCU2_FO_THR1_Temp_MVD [°C] HCU2_FO_THR2_Temp_MVD [°C] HCU2_FO_THR3_Temp_MVD [°C] 

HCU2_AO_THR1_Temp_MVD [°C] HCU2_AO_THR2_Temp_MVD [°C] HCU2_AO_THR3_Temp_MVD [°C] 

HCU2_AR_THR1_Temp_MVD [°C] HCU2_AR_THR2_Temp_MVD [°C] HCU2_AR_THR3_Temp_MVD [°C] 

HCU2_AD_THR1_Temp_MVD [°C] HCU2_AD_THR2_Temp_MVD [°C] HCU2_AD_THR3_Temp_MVD [°C] 

Approach: 

The thermistor measured temperatures of the Columbus shell are compared in 

different ISS attitude situations such as nominal flight and special situations such as 

space shuttle docking. In latter situation, the ISS makes a 180 degree attitude 

change in yaw axis. This maneuver leads the station to virtually fly backwards (see 

chapter 2.3 for information about ISS attitude). 

If there is an influence regarding attitude, shell temperatures should slightly change 

due to the change of ISS attitude (which also means a change of orientation in 

respect to the sun). To avoid visual overloading of the diagram, only the values of 

three thermistors are displayed. We chose the thermistors of one zone (FR) for that 

(see chapter 2.6.1.1 for location coding), where thermistor 1 is located on the 

starboard cone, thermistor 2 on the cylinder and thermistor 3 on the port cone. 

Moreover, we take a look at the power consumption of the HCU. That consumption 

indicates if shell heaters are active or not, which subsequently affects the 

temperature on the shell. 

Fig. 6–2: STS-123/1JA Forward Shell Temperatures


Fig. 6–3: STS-124/1J Forward Shell Temperatures 

As we can see in the first figure, shell temperatures fall before docking and rise 

sharply before undocking on mission STS-123. In the next figure, the temperatures 

also fall before docking, to rise sharply after. The undocking process on the other 

hand seems to affect the shell temperatures rather insignificantly. 

We now add the power (respectively current since in DC systems it is proportional to 

power) consumption of the active HCU (HCU2) to the diagram to see when the shell 

heaters were powered up and when not. 

Fig. 6–4: Shell Temperature and HCU2 Power Consumption 

Page 53

Page 54 


In the upper left corner, we can see the temperatures of the shell measured by the 

forward and aft middle ring thermistors (FR, AR) before, at and after STS-123 shuttle 

undocking. Since the ISS has to be in free drift for docking maneuvers, its solar 

panels cannot optimize the angle to the sun. This leads to power constraints which 

require Columbus to shut down its heaters. Because of that, the shell is preheated 

before going to free drift, so that the shell temperature does not drop below the 

predefined threshold in the time span when the heaters are not active (without 

heating and heat dissipation in the cabin, the internal module temperature drops 

about 1 °C per hour, [RD03], p. 2-128). We can observe, that the current 

consumption is at its maximum of 7.6 A for about 9 hours shortly before undocking, 

this causes the heaters to raise the temperature of the shell to about 25 °C and 

more. To be able to do that, the upper and lower limits of the shell temperatures 

have to be increased. The heaters will automatically adjust themselves to the 

predefined limits by following the heater control loop ([RD03], chapter 2.4.2.2.2). 

Conclusion: 

There is no direct evidence that the ISS attitude has a noticeable impact on the 

temperature of the Columbus shell. The behavior of the shell heaters and thus the 

change in shell temperatures seems to be affected mostly by the heater control 

loops and the predefined threshold limits of the shell temperature. A correlation 

between the gradients of the power (current) consumption of the HCU and 

thermistor temperatures can be seen clearly when studying the figure above. 

6.2 Position of the TCV influences the Active TCS Water Loop 

Hypothesis: 

The Temperature Control Valve (TCV) which is controlled by the Cabin Temperature 

Control Unit (CTCU) is responsible for the tuning of the cabin temperature by 

controlling and distributing the flow of air through the Condensate Heat Exchanger 

(CHX) cores (see chapter 2.5.2). Since the active temperature control system (TCS) 

and the cabin air conditioning have the CHX as common interface, an influence 

might be observable. 

Parameters: 

WTSB1_Nom_Plenum_Temp3_MVD [°C] CTCU1_TCV_Posn_DMC [%] 

Approach: 

In order to avoid condensate accumulation in the active CHX core (which may 

happen during low heat load phases with a high bypass flow), a procedure is 

implemented in the CTCU software to automatically move the TCV such that for a 

few seconds a high air flow is led through the active CHX core to push the 

condensate towards the slurper section of the CHX, where it can be sucked by the 

water separator. As default setting, this “TCV-Kick” is initiated every 75 minutes, but 

that time can be modified if necessary ([RD06], p. 29).


If there is a correlation between the water temperature in the active TCS and the 

position of the TCV, it might be observable in exactly the moments when the TCV 

“kicks”. 

May 16, 2008 (DOY137) – May 19, 2008 (DOY140), Low Resolution, Different 

Sample Rates 

Fig. 6–5: Active TCS Water Temperature after CHX; TCV Position 

As we can see in the figure above, there is a clear correlation between TCV position 

and water temperature of the water loop after the CHX. Every time the TCV kicks, 

the temperature of the water also rises shortly only to drop as fast as it has risen. 

Although it cannot be seen with the resolution above, the rise of the water always 

occurs about two minutes after the kick of the TCV. This suggests that the system is 

inert (probably due to the time the water needs to flow through the conduits) and 

needs some time to react to events. 

When we take a look at the figure above we also see, that not every TCV kick leads 

to a spike in the water temperature. The conclusion, that in some cases the kick 

does not influence the temperature of the water would be illogical due to the fact, 

that the two systems are not separated at any time. It is more probable, that the 

sample rate of the analysis above has been to low and that thus not every kick has 

been monitored. Another problem might be, that the two curves in the former figure 

possess different sample rates, which leads to inconsistencies when comparing 

effects which should take place nearly simultaneously. We will now take a closer 

look at the green framed area in the last figure. 

Page 55

Page 56 


May 18, 2008 (DOY139) – May 19, 2008 (DOY140), High Resolution, Equal Sample 

Rates 

Fig. 6–6: High Resolution of both Curves (Green Area in last Figure) 

The figure above confirms the theory, that the sample rate has been to low (and 

probably the different sample rates deteriorated that effect) in the penultimate figure. 

We can now see the spikes of the TCV position as well as the spikes in the water 

temperature match (nearly) at every point. 

The two remaining gaps, where a water temperature spike can be observed without 

an associated TCV kick, can be explained with the fact, that shortly before those 

two moments, acquisition of telemetry has not taken place (probably due to loss of 

signal). Because of that, the acquisition could in fact monitor the spike in water 

temperature (which is about 2 minutes later!) but could not monitor the TCV kick. 

Conclusion: 

There is a clear correlation between TCV position and water loop temperature after 

CHX. 

6.3 ISS 90 Minutes Orbit Cycle influences Columbus Water 

Loop Temperature 

Hypothesis: 

The radiators of the ISS external thermal control system (ETCS, chapter 2.6.3) are 

directly exposed to the space environment. Furthermore, the ISS rotates around 

earth approximately every 90 minutes (period time). The repeating changes between 

eclipse and exposure to sunlight should influence the temperature of the ETCS


coolant (NH3) after it has passed through the radiators. If this effect were big 

enough, it might also affect the Columbus water loop temperature since the active 

TCS of Columbus and the ISS ETCS are coupled via two heat exchangers (chapter 

2.6.2 and 2.6.3). 

Parameters: 

ETCS_LoopA_PM_Rad_Rtn_Temp_PP [°C] WTSB5_Medium_HX_Temp1_DMC [°C] 

ETCS_LoopB_PM_Rad_Rtn_Temp_PP [°C] WTSB6_Low_HX_Temp1_DMC [°C] 

Approach: 

We first take a look if the ISS ETCS coolant temperatures are influenced by the 

orbital state. If this were the case, we could search for an influence of the ETCS 

temperature on the Columbus water loop temperatures. 

Fig. 6–7: Influence of ISS Orbital State on NH3 Temperatures after Radiators 

In figure 6–7, we can clearly see that the orbital state of the ISS has a definite 

influence on the coolant temperature after having flowed through the radiators. The 

temperatures fluctuate in the range up to 15 °C in ETCS Loop A (red curve) and 10 

°C in ETCS Loop B (blue curve). The cycle times of both curves correspond to about 

90 minutes which would suggest that they are connected to the ISS period time. 

It is also remarkable, that the peaks of the two curves do not match regarding the 

time axis; they seem to be shifted from each other a few minutes. This could be 

explained with the fact, that the radiators can be adjusted in order to optimize their 

heat rejection capabilities. When they are not aligned in the same way, the 

sunlight/eclipse does affect them differently. There might also be some inertia 

effects when dealing with the change of radiator alignment. 

Page 57

Page 58 


Fig. 6–8: Influence of ISS Orbital State on Columbus Water Loop Temperatures 

In the figure above, the temperatures of the wet temperature sensor blocks 5 and 6 

(WTSB5, WTSB6) are displayed (multiplied by a factor of “-10” to make it easier to 

display them along with the NH3 temperatures after the radiators). WTSB5 measures 

the temperature of the water when it returns from the ISS MTHX and WTSB6 

measures the water temperature when the water emerges from the ISS LTHX (see 

Appendix A.5 or chapter 2.6.2). The green curve (WTSB5) shows a definite 90 

minutes periodic behavior which corresponds to the 90 minutes of ISS orbit period. 

A shift can be seen between coolant temperature gradient and Columbus water loop 

gradient, probably as a result of the time the fluids need to travel through the 

conduits. 

While periodicity can be seen clearly in the green curve, that tendency has degraded 

when observing the yellow curve. Since the two heat exchangers are connected in 

series (chapter 2.6.2), it can be assumed that the periodicity effect degrades more 

the longer the fluids flow through the conduits. 

Conclusion: 

The water loop temperature is definitely influenced by the orbit cycle of the ISS. At 

least when emerging from the MTHX, that effect can be observed very clearly. 

6.4 Correlation between Plenum Heat Load absorbed by 

Water Loop and PDU1 & 2 Power Output 

Hypothesis: 

The active TCS water loop collects heat from the plenum (collective term for all 

payload and subsystem electronics, see chapter 2.6.2) to afterwards reject it to the


ISS thermal bus (chapter 2.6.3). While flowing through the plenum, the water in the 

loop gets warmer due to the heat flow (dissipated by P/Ls and subsystem) it is 

exposed to. If we calculate the heat flow from temperature rise and mass flow, it 

should be in the range of the flow of electrical energy which is distributed from 

PDU1 and 2 to the payloads and subsystems. 

Parameters: 

PDU1_Tot_Pwr_Out_DV [kW] WPA1_Water_Temp_DMC [°C] WPA1_Water_Flow_DMC [kg/h] 


WPA1_WTSB1_Plenum_Temp1_DMC [°C] 

Approach: 

P/L 

SUB 

m 

m 

from WTSB1/2 

to WPA1/2 

Q & 

P/L 

Q & SUB 

T1 

T2 

control volume 

∆T = T2 – T1 

Fig. 6–9: Simplified Model of Plenum Heat Load Rejection 

Before beginning the analysis, a model of the system has to be created. The figure 

above shows that model, it demonstrates the basic functionality of the plenum and 

its interactions with the water loop. 

On the one hand we have (electrical) power supplied by PDU1 and PDU2 which 

feeds the subsystems and payloads. The electrical energy is converted in whatever 

form of energy is needed for the subsystem or payload. If the subsystem contains a 

motor for example, electrical energy is converted into mechanical energy. 

The total amount of electrical power can be written as: 

P tot PSUB 

+ P 

/ L = PPDU 

1, 

tot + PPDU 

2, 

tot 

= (6–1) 

Since the transfer and conversion of energy are never perfect, there is a loss through 

dissipation and a line loss. The dissipated energy is emitted in form of thermal 

radiation or transferred via heat flow which on the other hand increases water 

Page 59

Page 60 


temperature in the water loop. This loop absorbs the heat through a system of cold 

plates and heat sinks (chapter 2.6.2). 

Let us now take a look at the first law of thermodynamics to assess the magnitude 

of the heat flow which is absorbed by the water (we consider the red dashed 

rectangle in the last figure to mark our control volume): 

2 2 

⎡ ⎛ c c ⎞ 

⎤ 

Q& 12 + P12 

= m& 

⋅ ⎢ 

1 

(6–2) 

⎣ 

2 1 

( h2 

− h1 

) + ⎜ − ⎟ + g ⋅ ( z2 

− z )⎥ 

⎝ 2 2 ⎠ 

⎦ 

This is the equation for open systems which are flowed through by a fluid ([RD13], p. 

290), the indices indicate the input (“1”) and the output (“2”). Since we do not know 

the flow rates of the fluid at the inlet and outlet of the plenum (c1, c2), we assume 

them to be approximately equal and can thus eliminate that arithmetic expression. 

The term with the geodetic heights (z1, z2) can also be neglected on account of the µgravity 

environment in space (g ≈ 0). Due to the fact that no technical work is applied 

to the water, we can furthermore set P12 to zero. The mass flow is constant 

( m& = m& 

= m& 

1 2 ), the volume which enters the inlet exits the outlet. We now only have 

to consider the specific enthalpies (h1 and h2). They are defined as follows ([RD13], p. 

291): 

( T −T 

) = c ⋅∆T 

h2 − h1 

= cp 

⋅ 2 1 p 

(6–3) 

cp is the specific heat capacity which is 4182 J/(kgK) for water at 20 °C ([RD19], 

chapter 1.2.2). Its value is temperature dependent but is considered constant for 

these estimations, since the variations of its value in the observed temperature 

range is small. 

With the two preceding equations and the knowledge that the total heat flow is the 

sum of subsystem and payload heat flows (Fig. 6–9) we can write: 

& = Q& 

= Q& 

SUB + Q& 

P L = c ⋅ ∆T 

⋅ m& 

12 / 

(6–4) 

Q p 

This equation will be used to calculate the heat load absorbed by the water, the 

calculated value will then be compared to the total power output of both PDUs. In 

order to calculate the temperature difference ∆T, we subtract plenum inlet 

temperature (WPA1_WTSB1_Plenum_Temp1_DMC) from plenum outlet temperature 

(WPA1_Water_Temp_DMC). 

There is another point which impairs the accuracy of the calculation: no temperature 

sensors are available directly at the plenum outlet. Values from the water 

temperature sensor in the water pump assembly (WPA) have to be used, in order to 

determine the water temperature at the plenum outlet. This sensor is located at the 

venture flow meter inlet, directly behind the pump unit (see figure below and [RD03], 

Appendix V, p. v).


Fig. 6–10: WPA with Water Temp. Sensor Location [RD03], Appendix V, p. v 

Since the sensor measures the temperature of the water directly after it has passed 

through the pump unit, a slight rise of water temperature might be observable due to 

the mechanical forces the pump exerts on the water. This effect would increase the 

temperature difference ∆T measured between plenum inlet and outlet which would 

subsequently lead to a rise in the heat flow calculated by equation (6–4). 

Other sources for inaccuracies are for example the decrement of water temperature 

when flowing through long conduits (which are not insulated) or the fact that a part 

of the emitted heat radiation is absorbed by the cabin air and other surrounding 

objects. 

The following two figures demonstrate the heat flow (calculated pointwise according 

to equation (6–4)), the plenum temperature difference ∆T and the water mass flow 

through the conduits. To display everything in one graph, the water mass flow has 

been downscaled by a factor of 100. Please note, that appearing heat flows are 

always depicted in the unit “kilowatt” in order that it is easier to compare their values 

with PDU power consumption. 

Page 61

Page 62 


Fig. 6–11: Heat Flow QP1 & compared to total PDU Power Output (WPA1 Active) 

Fig. 6–12: Heat Flow QP2 & compared to total PDU Power Output (WPA2 Active) 

Fig. 6–11 shows the case when WPA1 is active, Fig. 6–12 when WPA2 is active. The 

two heat flows QP1 & and QP2 & have been calculated by using equation (6–4), the factor 

∆T is represented by the black curves and the sum of both PDU power outputs (Ptot) 

is represented by the red curves. It can be seen that the curves of the heat flows 

follow the curves of the total PDU power outputs but are always below or at least 

Q& ). This indicates that the temperature difference ∆T combined with 

equal (Ptot ≥ P1, 

2


the water mass flow is proportional to the total power consumption of the plenum. 

The (nearly constant) differential in the values of Ptot and QP1, 2 

& can be explained by 

the fact, that no device dissipates 100 % of its consumed input energy. It can thus 

be interpreted as the effective energy consumed by the device to fulfill its task. 

Conclusion: 

A correlation between plenum temperature difference, the absorbed heat flow which 

causes the rise in water temperature and the total power consumption of the plenum 

devices (P/L and subsystems) has been verified. 

6.5 Impact of Cabin Air Heat Load on TCS Water Loop 

Hypothesis: 

Analysis 4 (chapter 6.4) dealt with the correlation of the plenum heat flow absorbed 

by the active TCS water loop and the total power output of PDU1/2. The results 

obtained by that analysis are now compared to rough estimations of cabin air heat 

loads, which are also absorbed by the water loop via heat exchanger (CHX). 

Parameters: 



WPA1_WTSB1_Plenum_Temp1_DMC [°C] WPA1_WTSB3_CHX_Temp1_DMC [°C] 

WPA2_WTSB2_Plenum_Temp1_DMC [°C] WPA2_WTSB4_CHX_Temp1_DMC [°C] 

WPA1_WMV1_MDV_Vlv_Posn1_DMC [%] WPA2_WMV2_MDV_Vlv_Posn1_DMC [%] 

Approach: 

Since the temperature of the air flow is measured neither before nor after passing 

the CHX (air temperature is only measured in the cabin, see chapter 2.5.2), the water 

loop has to be considered for calculation of the air heat load absorbed by active 

TCS. The procedure is identical to the one used in the analysis of the Plenum heat 

load calculation: we take the temperatures of the water before and after it has 

passed the CHX, build the difference and apply equation (6–4) to calculate the 

resulting heat flow. 

The resulting air heat flow QA & which is absorbed by the water can thus be 

calculated to: 

( TCHX 

−TWTSB 

) mCHX 

Q& A = cp 

⋅ ∆T 

⋅ m& 

CHX = c 

& 

p ⋅ 

3 , 4 ⋅ 

(6–5) 

Unlike the Plenum heat flow calculation, there is a variable in this equation which 

cannot be taken directly from a sensor reading but has to be calculated. It is the 

CHX outlet temperature TCHX which has to be calculated prior to be able to calculate 

the air heat load absorbed by the water loop. 

Page 63

Page 64 


Fig. 6–13: CHX Flow [RD03], p. 2-36 

The figure above demonstrates the paths of the air and water flow in the CHX. Due 

to heat loads in the cabin air stream, the water emerges slightly warmer from the 

CHX than it has entered. To calculate the required water temperature TCHX, the 

Water Modulating Valve 1 (WMV1, redundant component WMV2) is analyzed. Its 

purpose is the regulation of the output water temperature prior to the Plenum 

(TWTSB1,2) to 17 ±1 °C (see chapter 2.6.2) by mixing two water streams with different 

temperatures in a certain ratio (which is determined by the valve position). 

In the case of WMV1 (or WMV2), the valve position ξ in % defines the mass flow of 

the warm bypass from the WPA which is mixed with the cold CHX water mass flow 

to afterwards enter the Plenum ([RD03], Appendix XIII). 

Fig. 6–14: Water Modulating Valve 1/2 (WMV1/2)


The previous figure shows how the water mass flows are mixed and also 

demonstrates the important temperatures which have to be considered. Following 

statements can be made: 

m& 

m& 

m& 

T 

tot 

BP 

CHX 

BP 

= m& 

≈ T 

CHX 

= ξ ⋅ m& 

= m& 

WPA 

tot 

+ m& 

tot 

− m& 

BP 

BP 

= 

( 1− 

ξ ) 

⋅ m& 

tot 

(6–6) 

As we can see, the mass flows which come from the bypass leg and from the CHX 

can both be expressed by using the valve position ξ and the total mass flow (which 

is the same one which flows through the Plenum and is monitored by Columbus 

telemetry parameter WPA[x]_Water_Flow_DMC, x=1,2). 

We now want to calculate the temperature TCHX of the water emerging from the CHX. 

To do that, we have to consider the enthalpies of the two mixing water flows 

(enthalpy balance). Due to the fact that the merged water flow possesses a common 

mean temperature, its enthalpy is zero. On the other hand, the two water flows 

which enter the WMV have an enthalpy since their temperatures still differ from the 

resulting mean mixing temperature (TWTSB1,2). Thus, the sum of both enthalpies has to 

be zero: 

( T −T 

) + c ⋅ m ⋅ ( T −T 

) = 0 

c & & 

(6–7) 

p ⋅ mCHX 

⋅ WTSB1 

, 2 CHX p BP WTSB1, 

2 BP 

when substituting with the equations from (6–6): 

( − ) ⋅ m& 

⋅ ( T −T 

) + c ⋅ξ 

⋅ m ⋅ ( T −T 

) = 0 

p ⋅ 1 tot WTSB1 

, 2 CHX p tot WTSB1, 

2 WPA 

c ξ & 

(6–8) 

The only unknown variable in equation (6–8) is TCHX, the rest is measured by 

Columbus sensors. After some algebraic transformations, we can write: 

ξ ⋅TWPA 

−TWTSB1, 

2 

T CHX = 

(6–9) 

ξ −1 

Equation (6–5) can now be complemented by using equations (6–6) and (6–9): 

& ⎛ ξ ⋅T 

− T 

⎞ 

⋅ 

⎝ ξ −1 

⎠ 

( 1− 

) mtot 

WPA WTSB1, 

2 

QA = cp 

⋅⎜ 

− T 

& 

WTSB3, 

4 ⎟ ⋅ ξ 

(6–10) 

Page 65

Page 66 


Now knowing the air heat flow absorbed by the water, it is easy to calculate the 

temperature difference ∆TA, by which the air temperature decreases while passing 

through the CHX: 

Q& = c ⋅m& 

⋅∆T 

 

A 

p A 

A 

A 

Q& 

A ∆ TA 

= 

(6–11) 

cp 

⋅ m& 

A A 

The specific heat capacity cpA of air is 1.005 kJ/kgK at 20 °C and 1 bar ([RD19], 

chapter 1.2.3.1). The air mass flow m& A can be calculated by using the readings of 

the air flow sensors (AFS). They determine the flow rate in m³ per hour; in order to 

transform that into kg per second, the value has to be multiplied with the density of 

air (about 1.225 kg/m³ at 1 bar) and divided by 3600. 

Fig. 6–15: Air Heat Flows QA1 & & Q 2 

& (WPA1/2 Active), PDU1/2 Power Output, ΔTA 

A


The two upper figures demonstrate the calculated air heat flow (yellow QA1 & and blue 

Q & ), total PDU1 and PDU2 output power (red) and the in chapter 6.4 calculated 

A2 

Plenum heat flows. It can be seen that the air heat flow is in the range of 300 to 600 

watt, which corresponds to a temperature drop of 3 to 4 °C in the active CHX core 

depending on the air flow rate (see black curve ∆TA in Fig. 6–15). 

Conclusion: 

The air heat load absorbed by the water loop seems to be more or less independent 

from the plenum heat load. This can be explained with the fact, that the plenum inlet 

temperature (measured by WTSB1) is kept constant by mixing water from the CHX 

outlet and the warm bypass leg via WMV1 (or 2). Thus, it is uncoupled from 

temperature variations which occur at the CHX outlet and mainly depends from the 

heat loads generated in the Plenum (payloads, subsystems). 

Remarkable is the fact, that air heat loads vary little, and when, then not in a volatile 

matter. One of the next steps is to investigate the impact of the CHX “Condensing 

Mode” and “Low Condensing Mode” on the absorbed air heat loads. This will be 

done in the subsequent analysis. 

6.6 Comparison of Heat Loads absorbed by CHX and Plenum 

to Heat Loads rejected to ISS 

Hypothesis: 

Since we now know the amount of cabin air and Plenum heat loads which are 

absorbed by the Columbus active TCS water loop, the next logical step would be 

the investigation of the total heat rejected to ISS by MT IFHX and LT IFHX on Node 

2. Theoretically, the Columbus heat loads which are rejected on ISS side should be 

equal to the heat loads which are absorbed by the water loop on Columbus side. 

Parameters: 



WPA1_WMV1_MDV_Vlv_Posn1_DMC [%] WPA1_WTSB3_CHX_Temp1_DMC [°C] 

WPA2_WMV2_MDV_Vlv_Posn1_DMC [%] WPA2_WTSB4_CHX_Temp1_DMC [°C] 

WPA1_WMV3_MDV_Vlv_Posn1_DMC [%] WPA2_WMV4_MDV_Vlv_Posn1_DMC [%] 

WTSB6_Low_HX_Temp1_DMC [°C] WTSB5_Medium_HX_Temp1_DMC [°C] 

Approach: 

By applying the first law of thermodynamics to the closed Columbus water loop, we 

can state (the equation to follow does not consider mechanical work Wmech which is 

applied for example by the WPA those impacts are considered negligible): 

Q& 

+ Q& 

= Q& 

(6–12) 

A 

P 

EX 

Page 67

Page 68 


Fig. 6–16: Balance of Heat Loads in Columbus Active TCS, [RD10]/TCS 

To calculate the rejected heat flow QEX & we could either use equation (6–12) or the 

same considerations used to calculate the air and Plenum heat flows. Since we want 

to verify equation (6–12), we cannot use it to calculate the rejected heat flow but 

have to determine it by applying the laws of thermodynamics. Fig. 6-17 shows all 

occurring mass flows, heat flows and temperatures which are needed for that 

calculation: 

Fig. 6–17: Mass Flows, Temperatures and Heat Flows, [RD10]/TCS 

First of all, we use equation (6–4), which has been derived from the first law of 

thermodynamics in chapter 6.4, to define the rejected heat flow: 

Q& 

EX = QEX 

−MT 

+ QEX 

−LT 

∆T 

∆T 

MT 

LT 

& 

= T 

= T 

WTSB5 

WTSB6 

& 

−T 

−T 

WPA 

WTSB5 

= c 

p 

⋅ m& 

EX 

⋅ ∆T 

MT 

+ c 

p 

⋅ m& 

EX 

⋅ ∆T 

LT 

= c 

p 

⋅ m& 

EX 

⋅ 

( ∆T 

+ ∆T 

) 

MT 

LT 

(6–13)


The only unknown variable in the previous equation is the water mass flow m& EX 

which passes through the MTHX and LTHX. It can be determined by considering the 

ratio of cold/warm mass flow passing through WMV3 (redundant WMV4). Since its 

valve position λ determines the amount of cold water used for mixing the output 

temperature ([RD03], Appendix XIII), following statements can be made: 

m& 

m& 

EX 

Z 

= m& 

= m& 

CHX 

CHX 

⋅ 

⋅λ 

( 1− 

λ) 

by additionally using CHX = ( −ξ 

) tot 

m& 

Q& 

EX 

EX 

= 

= 

m& 1 ⋅m& 

from equation (6–6), we can finally write: 

( 1− 

ξ ) ⋅ λ ⋅ m& 

tot 

c ⋅ ( 1− 

ξ ) ⋅ λ ⋅ m& 

⋅ ( T −T 

+ T −T 

) 

p 

tot 

WTSB5 

WPA 

WTSB6 

WTSB5 

(6–14) 

(6–15) 

Using equation (6–15), the rejected heat flow QEX & can be calculated, visualized and 

finally compared with the absorbed air and Plenum heat flows: 

Fig. 6–18: Rejected Heat Flow, Plenum Heat Flow, Air Heat Flow (WPA1 Active) 

As demonstrated in the figure above, equation (6–12) has been verified. The sum of 

absorbed air and Plenum heat load equals the total rejected heat load of Columbus 

to ISS (for example: September 17 - Air: 0.58 kW, Plenum: 1.42 kW sum: 2 kW; 

calculated rejected heat flow to ISS: -1.99 kW). Due to the fact that the rejected heat 

load leaves Columbus, its value possesses a negative sign. In the end, the heat 

Page 69

Page 70 


flows in the closed Columbus active TCS water loop add up to zero, thus complying 

with the first law of thermodynamics. 

Conclusion: 

The hypothesis of the heat load balance in the water loop (absorbed heat equals 

rejected heat) has been verified. 

6.7 Comparison of absorbed Air Heat Loads in CHX 

“Condensing” and “Low Condensing” Mode 

Hypothesis: 

Columbus active TCS water loop is able to absorb more heat load from cabin air in 

“Condensing” mode (CHX setpoint at 5 °C) than in “Low Condensing” mode (CHX 

setpoint at 7 °C). 

Parameters: 

WPA1_CHX_Temp_Setpoint_DMC [°C] QP1 [kW] QA1 [kW] 

WPA2_CHX_Temp_Setpoint_DMC [°C] QP2 [kW] QA2 [kW] 

Approach: 

The impact of a CHX mode switch on the capability of the TCS water loop to absorb 

air heat flow is investigated by analyzing telemetry at switch times: 

Fig. 6–19: CHX Setpoint (orange); Air Heat Flow (yellow: WPA1, blue: WPA2)


CHX inlet temperature (which is either 5 or 7 °C, depending on CHX mode) has been 

scaled down by a factor of 10 in order to display it along with the absorbed air heat 

flow (0.5 corresponds now to “Condensing”, 0.7 to “Low Condensing” mode). 

It can be seen clearly, that the absorbed air heat flow is lower when CHX is in “Low 

Condensing” mode (about 350 to 450 watts) and higher when in “Condensing” 

mode (about 500 to 600 watts). This means, that the TCS is able to absorb more 

heat loads from the cabin air when in “Condensing” mode. Temperature difference 

between CHX inlet and outlet is higher (since CHX inlet is at 5 °C and not at 7 °C) 

which subsequently leads to a higher air heat load rejection capability of the CHX to 

the cooling water loop (please take a look at equation (6–5)). 

Conclusion: 

The hypothesis, that TCS is able to absorb more air heat loads in “Condensing” 

mode, has been confirmed by analysis of telemetry. 

Page 71

Page 72 

Columbus Module ECLSS Analyses 

7 Columbus Module ECLSS Analyses 

All analyses conducted in this chapter deal with the Columbus Environmental 

Control & Life Support System (ECLSS, described in chapter 2.5). For a short 

introduction of the general analysis workflow, please refer to chapter 6 of this thesis. 

7.1 Dependencies between IRFA Power Consumption, EU 

Temperatures and Fan Speed 

Hypothesis: 

The speed of a fan assembly correlates linearly with its power consumption 

(respectively input current) and/or the temperature of its electronic unit (EU). 

Parameters: 

IRFA_Fan_Speed_MVD [RPM] IRFA_EU_Temp_DMC [°C] IRFA_Input_Current_DMC [A] 

ISFA_Fan_Speed_MVD [RPM] ISFA_EU_Temp_DMC [°C] ISFA_Input_Current_DMC [A] 

CFA1_Fan_Speed_MVD [RPM] CFA1_EU_Temp_DMC [°C] CFA1_Input_Current_DMC [A] 

Approach: 

We compare the supply fan (ISFA) and the return fan (IRFA) at two different periods 

in time: when they both are functioning within defined specifications and when the 

IRFA is experiencing malfunctions. The comparison might give insights into the 

behavior of the fan assemblies and the possible cause of the IRFA failure. 

March 6, 2008 – March 10, 2008 (DOY66 – DOY70), normal operating conditions 

The pink and green curves show the fan speeds while the blue and the orange 

curves show the fan speed to input current ratio of the respective fan assembly. If 

there was a linear correlation between fan speed and input current, both ratio curves 

should approximately have the same value at a given time. Since this is not the case 

(see next figure), we can assume that the fan speed is not linearly depending from 

the input current. The electronic unit probably regulates the fan speed within a 

certain range of input currents.


Fig. 7–1: Fan Speeds and Speed-to-Current Ratios at Nominal Operation 

Fig. 7–2: Fan Speed-to-EU-Temperature Ratio at Nominal Operation 

We will next investigate the ratio of fan speed to electronic unit temperature. The 

former figure shows both ratios for the supply and return fan assembly under 

nominal operating conditions. Interesting is the 24 hour periodicity of these curves, 

which may be worth a separate investigation. Moreover, the ratio for both fan 

assemblies is different at a given point, which indicates that there is no linear 

correlation between the EU temperature and the fan speed. Although there has to be 

another influence if we consider the periodicity! 

Page 73

Page 74 


April 13, 2008 – April 15, 2008 (DOY104 – DOY106), before/after IRFA shutdown 

Fig. 7–3: Fan Speeds and Speed-to-Current Ratios before/after IRFA shutdown 

Fig. 7–4: Fan Speed-to-EU-Temperature Ratios before/after IRFA shutdown 

If we examine the case shortly before/after IRFA shutdown, when the return fan 

began to show malfunctions, we can clearly see the degradation of the IRFA fan 

speed respectively the point on which it has been shut down (rightmost part in the 

two figures). The fluctuations of the input current cause the fan speed to input 

current ratio to fluctuate strongly as well. Despite the obvious malfunctioning of the 

return fan, we can still see the periodicity in the fan speed to EU temperature curves.

Conclusion: 


There is no clear evidence of a linear correlation neither of the fan speed with the 

input current nor of the fan speed with the EU temperature! 

7.2 Comparison of IRFA Failure Signatures at Shut-Off 

Hypothesis: 

IRFA failure signatures at device shut-off should both behave in a similar way on 

both shut-off incidents (April 15 and December 12, 2008). 

Parameters: 

IRFA_Input_Current_DMC [A] IRFA_Delta_P_MVD [kPa] 

ISFA_Input_Current_DMC [A] ISFA_Delta_P_MVD [kPa] 

CFA1_Input_Current_DMC [A] 

Approach: 

The failure signature of the IRFA can be characterized by slowly beginning peaks in 

the input current consumption which subsequently lead to higher power 

consumption of the fan assembly. During the course of time, the peaks increased in 

magnitude and frequency until the fan was shut down by flight controllers on April 

15 th , 2008. On Friday 12 th of December 2008, the IRFA has been reactivated shortly, 

only to show off-nominal behavior again (see next figure). 

Fig. 7–5: Input Currents of the Fan Assemblies DOY347, 2008 

It can be seen clearly, that the input current of the IRFA shows bumpy behavior from 

the moment it has been switched on (08:57 a.m.) until its switch-off (04:06 p.m.). At 

Page 75

Page 76 


the beginning, the peaks only possess low magnitudes; they occur every 10 to 20 

minutes with a slow tendency to higher input currents. If we consider 1 ampere as 

the upper threshold for the IRFA, we can observe, that the input current gradient 

violates this value the first time on 02:23 p.m. After that, the occurrence of peaks 

over 1 ampere repeats nearly every 5 to 10 minutes, which indicates that the peakfrequency 

rises and the catastrophic overstepping of the threshold value is not far 

away. In the last half hour before shutdown, the input current of the IRFA nearly 

does not drop below 1 ampere, thus constantly violating the threshold value. The 

peaks gain in magnitude and their frequency again increases to a period of about 1 

to 3 minutes. At 04:06 p.m., the IRFA is shut down again due to off-nominal 

behavior. The peak current has been 1.28 ampere at 03:55 p.m. Please note, that 

the delta-pressure generated by the IRFA (blue curve, unit: kPa) is constant and 

does not show off-nominal behavior. This leads to the assumption that the fan 

assembly forces the fan to maintain the delta-pressure despite any problem which 

the fan could experience. If we consider a mechanical problem with the ballbearings 

of the fan – which would cause higher friction - the rise in current 

consumption could be explained with the need to constantly maintain the deltapressure 

regardless of bearing malfunction which logically increases friction and 

thus power consumption. 

Fig. 7–6: IRFA Input Current before Shut-Down on DOY106, 2008 

We see a similar behavior of the IRFA before it was shut down the first time on April 

15, 2008 (DOY106). The current peaks and the increase in peak frequency and 

current magnitude can be seen in the figure above. Failure signatures from the 

penultimate and former figure do match very well, although it can be seen that the 

peaks in the figure above are higher than the peaks in figure 7–5. It is also 

interesting, that the violations of the threshold occur earlier (some days, not only 

some hours) than in December. The reason for that is perhaps the fact, that the IRFA 

was shut down earlier the second time it was tested in December. In April, it


probably was not shut down until the input current levels reached very high values 

(up to nearly 1.8 ampere!). 

Fig. 7–7: Superposition of IRFA Failure Signatures, April (Blue)/December (Red) 

The superposition of both failure signatures (IRFA input current from the December 

incident has been shifted to April) show, that the magnitude of threshold 

overstepping is much higher the first time the IRFA was shut down (blue curve). 

Despite of that, the tendency of IRFA input current to rise slowly with sharp 

intermediate peaks can be seen in both curves. 

Conclusion: 

The failure signatures behave similarly. In the future it is recommended to monitor 

the peaks in current consumption of the fan assemblies more carefully and 

eventually with narrower thresholds. Every occurrence of a threshold violation 

should be analyzed very thoroughly (magnitude, time frame, periodicity, etc …) in 

order to anticipate such a catastrophic failure in time. However, in case of a ballbearing 

failure, those measures would only be able to anticipate the failure, not to 

prevent it. 

7.3 24 Hour Periodicity of Cabin Temperatures and Fan EU 

Temperatures 

Hypothesis: 

As we can see in Analysis 1 (chapter 7.1, p. 72), a 24 hour periodicity can be 

observed when dealing with the average cabin temperature, the electronic unit (EU) 

temperatures of the fans (supply, return, cabin) and the condensate water 

separation assembly (CWSA). 

Page 77

Page 78 


It is believed, that this period of about 24 hours is caused by astronauts entering 

Columbus and subsequently heating it up. When they leave Columbus, the 

temperature drops and the cycle begins again when they enter the next day. 

Parameters: 

IRFA_EU_Temp_DMC [°C] CTCU1_Avg_Cabin_Temp_DMC [°C] 

ISFA_EU_Temp_DMC [°C] CWSA1_Temp_DMC [°C] 

CFA1_EU_Temp_DMC [°C] CWSA2_Temp_DMC [°C] 

Approach: 

The average cabin temperature and the temperatures of the electronic units of the 

fans and the condensate water separator assembly are being extracted and 

displayed over a long period, from March 1, 2008 to April 25, 2008 (DOY61 – 

DOY116). A low resolution of 100 seconds (0.01 Hz) has been chosen to reasonably 

reduce the amount of data. According to the sampling theorem, we can now 

observe at most periodic events with a periodicity equal or higher than 200 seconds 

(see chapter 4.1). 

Fig. 7–8: Avg. Cabin Temperature/Fan EU Temperatures over approx. 2 weeks 

The previous plot shows the average cabin temperature in blue. It’s remarkable that 

its gradient and the gradient of the green curve (IRFA EU temperature) are nearly 

identical apart from an offset and different sensor sensitivity (the cabin sensor 

shows more fluctuations than the EU temperature sensors). It can also be noticed, 

that the cabin temperature minima lie behind the other temperature minima (approx. 

10 – 20 min.). This can be seen when comparing the minima and maxima of the 

different curves.


Fig. 7–9: 24 hour periodicity 

The first six minima of the blue curve in the previous figure occur at following times: 

March 6, 08:18 a.m. March 7, 08:53 a.m. 



This clearly demonstrates the approximately 24 hours which lie between the minima 

and thus the periodicity. We can also see in the figure above, that although the blue 

avg. cabin temperature curve follows the EU temperatures continuously, we can 

observe that the minima of this curve are not always at the same time and that there 

are irregularities regarding the periodicity. On March 9 for example, we can see, that 

the cabin temperatures does not begin to increase until noon. The other 

temperatures also begin to rise late on that day (at about 09:30 a.m.). 

Generally it can be said, that the amplitudes of the temperatures vary about 1 °C 

during the 24 hour cycles. 

Page 79

Page 80 


Fig. 7–10: STS-123/1JA Shuttle Docking 

Fig. 7–11: STS-123/1JA Shuttle Undocking 

We can observe strong irregularities shortly before the space shuttle docks to ISS, 

during the whole mission and shortly after the shuttle undocks from the station. The 

start/end of the cycle of the periodic phenomenon seems to shift to the evening (see 

penultimate figure), while the regularity of it seems highly disturbed. It is not until 

April 2 nd that the cycle begins to start in the morning again. 

Another remarkable period is the time from March 26 to March 28 when the 

temperatures of all fan EUs and the average cabin temperature drop nearly 

simultaneously (see previous figure). The periodic event seems to make a break for


two days to afterwards return again in a non-regular manner (meaning that the curve 

does not look as periodic as before 1JA but a periodicity can still be seen). 

Fig. 7–12: CWSA1 & 2 Temperatures Supplement 

If we add the temperature gradients of the CWSAs to the diagram (and remove IRFA 

and ISFA EU temperatures for clarity), we can see an interesting phenomenon. The 

curves of the CWSA1 temperature and CFA1 EU temperature nearly match between 

March 5, 02:27 a.m. and March 19, 11:23 p.m. After that, the temperature of CWSA1 

rises suddenly about 5°C while at the same time the temperature of CWSA2 drops 

about the same amount. Both curves does not match with other curves any more, 

but it can be observed a similar behavior of CWSA1 and CFA1 temperatures after 

March 19, 11:23 p.m., they only differ by an offset. 

Conclusion: 

It cannot be said yet, if the cabin temperature of Columbus rises and drops in 

correlation with the presence and absence of astronauts. The problem is, that it is 

difficult to determine, how many astronauts have been working in Columbus at 

which times, have there been any breaks (the two days drop of temperature in Fig. 

7–11 indicates that) or other irregular activities. The fact, that the gradient of the 

average cabin temperature is chronologically behind the EU temperature curves, 

indicates, that the temperatures of the cabin equipment influence the cabin 

temperature and not vice versa. However, more evidence has to be gathered in 

order to prove if the phenomenon has something to do with the astronaut’s 

presence or absence. 

Page 81

Page 82 


7.4 Correlation of Cabin Illumination and Subsystem Power 

Consumption with 24 Hour Periodicity 

Hypothesis: 

There is a correlation between the phases when the cabin illumination (MLU – 

Module Lighting Unit) is switched on and the gradient of the cabin temperature 

curve. Active cabin illumination in Columbus indicates crew activity which 

furthermore is likely to have influence on the cabin air temperature whose 24 hour 

periodicity has been investigated in chapter 7.3. 

Parameters: 

ISFA_EU_Temp_DMC [°C] PDU1_MLU_Pwr_Bus_Current_DMC [A] 

IRFA_EU_Temp_DMC [°C] PDU2_MLU_Pwr_Bus_Current_DMC [A] 

CFA1_EU_Temp_DMC [°C] CTCU1_Avg_Cabin_Temp_DMC [°C] 

PDU1_Sys_Pwr_Out_DV [kW] PDU2_Sys_Pwr_Out_DV [kW] 

Approach: 

We first compare the cabin temperature with the power consumption (respectively 

current consumption) of the cabin illumination. Afterwards, the power output to the 

Columbus systems of the two PDUs is compared with the power consumption of 

the cabin illumination. The analysis is conducted on a long-term basis, which means 

that the sample rate of the analyzed telemetry is quite low (about 0.01 Hz). 

Fig. 7–13: Columbus Cabin Illumination Block Diagram [RD03], p. 2-97 

According to [RD03] chapter 2.3.4, the MLUs are low wattage fluorescent lights and 

can be divided into two independent groups (MLU1 – 4 and MLU 5 – 8) which are 

powered by the respective PDU (see figure above).


Fig. 7–14: Cabin Illumination Power Consumption and Fan EU Temperatures 

before 1JA 

Fig. 7–15: Cabin Illumination Power Consumption and Fan EU Temperatures 

after 1JA 

The MLU curves have been scaled by a factor of 30 to be able to compare the 

individual curves without difficulties. The grey dashed lines with arrows shall help 

the viewer to recognize the correlation between the switch-on and switch-off 

moments of the cabin illumination and the fan assembly EU temperatures. It is 

remarkable that the temperatures begin to rise whenever the illumination is switched 

Page 83

Page 84 


on and begin to drop when the illumination is switched off. It is also important to 

notice, that the gradients of the temperature curves are more irregular after Shuttle 

undocking and does not match any longer exactly the moments when the cabin 

illumination is switched on or off. 

Fig. 7–16: MLU Power Bus Current and PDU1 Systems Power Out 

Fig. 7–17: MLU Power Bus Current and PDU2 Systems Power Out 

The two figures above clearly demonstrate the correlations between PDU1 and 2 

power output and current/power consumption of the MLUs. Every time the current 

consumption of the MLUs indicates that the lighting is active, the power outputs of 

the PDU systems busses rise about 0.09 kW (90 W).

Conclusion: 


If we consider every MLU to be active, we can assume them to consume about 180 

W (2 x 90 W). Table 2-46 in [RD03] provides information that all MLUs are on during 

crew day and most (if not all) of them are switched off during crew night. It 

furthermore suggests that MLU control is always performed by the crew. 

Considering these facts, we can either assume that the cabin illumination is the 

cause for the periodic rise in cabin temperature or that it is an indication of crew 

activity within Columbus. This activity could also be the case for the periodic 

behavior of the cabin temperature due to heat emission of the human body. The 

previous figures indicate the latter because the on/off-state of the cabin lighting is 

not as synchronous with the change in cabin temperature as expected earlier. Thus, 

the on-state of the MLUs probably indicates when there is crew activity which 

furthermore could be the cause of the periodic 24 hour temperature gradient. 

7.5 TCV influences Cabin Air Flow 

Hypothesis: 

The kick procedure of the Temperature Control Valve (TCV, see also chapter 6.2) 

might affect the cabin air flow since the Air Flow Sensors (AFS) are situated 

upstream ahead of the TCV (schematic in chapter 2.5.2 or Appendix A.4). 

Parameters: 

CTCU1_TCV_Posn_DMC [%] AFS1_Cab_Air_Massflow_MVD [m³/h] 

CTCU2_TCV_Posn_DMC [%] AFS2_Cab_Air_Massflow_MVD [m³/h] 

Approach: 

Air flow sensor telemetry is compared with TCV position telemetry. If there is a 

correlation, it should be observable when comparing the plots. Due to the fact that 

the air flow sensor readings are in the range of about 450 m³/h and the TCV position 

when it kicks at about 70 %, the TCV curve has been scaled by a factor of 10 to 

display it along with the air flow. The following diagram contains the two curves: 

Page 85

Page 86 


Fig. 7–18: Cabin Air Flow and TCV Position 

Every time the TCV kicks (yellow spikes), the air flow reacts immediately with a 

negative spike. It drops about 5 m³/h for a few seconds to afterwards return to the 

former values again. These two phenomena match so precisely, that it is reasonable 

to assume that the one causes the other. 

Conclusion: 

There is a definite correlation between TCV kick and cabin air flow. 

7.6 CHX Dry-Out Procedure influences Cabin Air Loop 

Hypothesis: 

Chapter 2.5.2 described how cabin air temperature is regulated by routing the air 

flow through the active (cold) and inactive (warm) CHX core using the Temperature 

Control Valve (TCV). As the air passes through the active CHX core, it gets colder 

and its contained vapor begins to condensate on the CHX air fins. These are coated 

with a hydrophilic coating which induces the water to form a film over the metal 

instead of building droplets. The coating is impregnated with a biocidal silver oxide 

to inhibit growth of a wide spectrum of bacteria and fungi. Despite that fact, after a 

period of about 6 weeks, the active core must be completely dried out for at least 24 

hours to ensure that the coating surface is completely dry, thus killing any microbes 

or fungi that managed to grow despite the presence of biocidal coating. 

In order to carry out the dry-out procedure, the active CHX core has to be 

disconnected from the thermal water loop thus setting its status to inactive, the 

inactive core is in turn connected to the water loop and set to active. Meanwhile, the 

TCV position has to be changed as well, to be able to modulate the air flow 

according to cabin temperature and kick procedure requirements. The air flow which


now passes through the inactive CHX core is not cooled any more, but dries the wet 

surfaces of its air fins while the former inactive core now takes the role as active part 

and cools the air passing through it ([RD03], p. 2-36; [RD07], p. 6.3-95). 

Fig. 7–19: CHXA Functional Design [RD10]/ECLSS 

The figure above shall again demonstrate how the cabin air loop is connected to the 

CHX assembly (CHXA) and the active TCS. Just one CHX core is active at a time, 

the other is dried-out meanwhile, as described in the text above. By using Water 

On-Off Valves (WOOV), the water flow from the ATCS can be routed to the active 

CHX core. Core 1 is active if WOOV9 is open (WOOV10 closed) and core 2 if 

WOOV10 is open (WOOV9 closed). 

Since the CHX has interfaces to many important subsystems (ATCS, THC, AVR), it 

can be assumed, that the performance of a dry-out cycle will leave traces in various 

telemetry parameters. This chapter shall proof or disprove that hypothesis. 

Parameters: 

WOOV9_Open_Stat_DMC [0/1] HS1_Air_Humidity_DMC [%] CTCU1_TCV_Posn_DMC [%] 

WOOV10_Open_Stat_DMC [0/1] HS2_Air_Humidity_DMC [%] CTCU2_TCV_Posn_DMC [%] 

CTCU1_Avg_Cabin_Temp_DMC [°C] LCOS1_Level_DMC [%] LCOS2_Level_DMC [%] 

WPA1_WTSB1_Plenum_Temp1_DMC [°C] 

Approach: 

When studying Humidity Sensor (HS) telemetry data, the periodic occurrence of two 

spikes in the air humidity gradient was discovered. This phenomenon repeats itself 

approximately every six weeks, which led to the assumption that it is somehow 

connected to the CHX dry-out cycle. To prove that, the status of WOOV10 

(connects or disconnects CHX2 to the water loop) was also monitored and it was 

discovered, that every time WOOV10 switches its status to “open” (thus switching to 

CHX2) a sharp rise in air humidity can be observed. When WOOV10 closes (thus 

switching to CHX1 by opening WOOV9), another sharp rise in air humidity occurs. 

Since the Parameter WOOV10_Open_Stat_DMC describes the status of the valve in 

an alphabetical manner (“OPEN” or “CLOSED”), two numerical representations of 

that values have to be defined. The value “1” has been chosen to represent “OPEN” 

and “0” to represent “CLOSED”. WOOV10 status is shown in the next figure by a 

Page 87

Page 88 


white curve. Additionally, it has been scaled by a factor of 100 and the area below 

has been filled dark-grey so that it can be compared easier to other parameters. 

Fig. 7–20: Cabin & Water Loop Parameters/WOOV10 Status 

As demonstrated in the two figures above, the CHX dry-out cycle has a definite 

impact on cabin air humidity, average cabin temperature and water loop 

temperature after passing the CHX core. The most obvious influence can be seen 

when examining the progress of air humidity. As soon as the dry-out cycle begins 

(dark grey area), humidity rises over 20 % in about an hour only to afterwards slowly 

degrade to the values before. After 24 hours, when the dry-out cycle has been 

completed, cores are switched again and the same phenomenon can be observed. 

The sudden rise of air humidity could be explained by the fact, that the air which


passes through the inactive core (thereby drying the air fins) absorbs the moisture 

which subsequently leads to the increment in relative humidity. Since the curve rises 

for about one hour to afterwards decrease slowly (it looks like a 

charging/discharging curve of a capacitor), it can be assumed that after that time 

the drying process/effect is so faint that it does not affect air humidity any more 

(because of that, humidity begins to decrease slowly). 

Two other interesting effects are the decrement of cabin temperature and the peaks 

in the temperature of the water loop behind the CHX. 

Fig. 7–21: TCV Position at CHX Core Switch 

It can be seen in the figure above, that the TCV position varies according to the 

active CHX core. During the switching process, the TCV is in middle position for 

about 1 ½ hours, at the same time the cabin temperature drops slightly. The rise of 

air humidity can also be seen when observing the values of the Liquid Carry Over 

Sensors (LCOS), their function is to determine the presence of water droplets in the 

air duct. 

Fig. 7–22: Concept of CHX Core [RD07], p. 6.3-52 

Page 89

Page 90 


Fig. 7–23: Water Loop Temperature Oscillation after CHX Core Switch 

An explanation for the short off-nominal water temperature oscillation (see figure 7– 

21, definition is 17 ±1 °C, chapter 2.6.2) after switching to the other CHX core could 

be as follows (please also consider Fig. 7–22 for the architectural concept of the 

CHX core): 

When the cores are switched, the active core is dry at the beginning due to its prior 

inactivity. Heat exchange between air and water happens directly without a wet 

water film between air and metal fins (see figure above for a draft of the CHX core). 

Since the thermal conductivity λM of metal is higher than the one of water [RD19], 

heat from the air flows is absorbed more efficiently when there is no water film 

covering the metal fins yet. That is the reason why the temperature of the water rises 

so swiftly. When a water film has developed after a couple of minutes, heat from the 

air has to pass through the water film first, before it gets to the metal fins and 

subsequently can be absorbed by the water loop. Since the thermal conductivity of 

water λW is smaller than the one from metal [RD19], the absorbed heat flow drops, 

thus decreasing water temperature of the cooling loop. 

The transient oscillation which can be observed in figure 7–23 retains as long as a 

thermal equilibrium has been established, which in this case takes about 10 

minutes. 

Conclusion: 

The CHX dry-out procedure has a definite impact not only on cabin air ventilation 

parameters (air humidity, cabin temperature, etc.), but also on the active TCS water 

loop.

8 Conclusion and Summary 

Conclusion and Summary 

Thermal Control System (TCS) performance has proven to function as expected: 

heat loads absorbed by water cooling loop are rejected completely by ISS, which 

demonstrates that the system obeys the first law of thermodynamics. Although no 

evidence has been found that the solar β-angle influences hull temperature - which 

in turn influences cabin temperature behavior - different flight states (free drift, etc 

…) influence power consumption of the heater control units (HCU). On the other 

hand, clear evidence of ISS orbit cycle on Columbus water loop has been verified. 

When dealing with Environmental Control and Life Support System (ECLSS), it can 

be said that in the case of the IRFA failure, a failure signature has been found which 

in future could be applied to anticipate a similar incident. It is important to notice, 

that the anticipation of that failure via failure signature does not prevent the failure. 

The investigation of the cabin air parameters at CHX dry-out cycle has proven to be 

very demonstrative regarding the benefits of the Telemetry Analyzer Tool and its 

application in telemetry analyses. A clear advantage of this tool compared with e.g. 

Satmon, is its possibility to display long-term telemetry data. That advantage drew 

attention to the cabin air humidity peaks, which occur about every 6 weeks, 

subsequently pointing to the fact that it could have something to do with the 6 week 

CHX dry-out cycle (to draw such conclusions, a profound knowledge of Columbus 

subsystems is mandatory). Another advantage of the program is its ability to 

simultaneously display data from various input files, different parameters with 

different sample rates and different time frames. This makes handling comfortable 

and fast in comparison with Excel for example. In addition, the Telemetry Analyzer is 

virtually able to process and display an infinite number of data points. This is only 

restricted by processor speed and size of random access memory (RAM). 

Experience shows, that a modern personal computer (status: 2008) is able to handle 

about 200.000 to 500.000 data points with satisfactory speed. It is nevertheless 

recommended to reduce data points to less than 100.000. 

As demonstrated in chapters 4.2 and 6.2, the principles of the sampling theorem 

have to be considered carefully when dealing with telemetry data, especially when 

investigating highly fluctuating signals. To do otherwise would bear the risk of 

getting falsified readings, hence making it impossible to draw appropriate 

conclusions. It is difficult to find a balance between high sample rates and small file 

sizes (which subsequently influence processing time). If the sample rate is too high, 

the file gets too large, which makes its processing long- and tiresome. Low sample 

rates on the other hand always bear the risk of falsifying the available data but are 

comfortable to process. 

Since Columbus is not an isolated system, the impact of its environment (ISS, 

space, running experiments) has to be taken into account. That is often difficult 

because of the fact that the available information is spread over different information 

systems like eRoom, ATL (As Flown Timeline), different NASA systems and others. 

That makes it difficult for someone who is engaged with telemetry analyses, to find 

Page 91

Page 92 

Conclusion and Summary 

out when something happened in Columbus. It is often the case, that strange 

readings can be observed when analyzing telemetry, which afterwards turn out to be 

caused by extraordinary activities conducted at that time. However, that is an 

important point to be aware of. 

Possible fields for future analyses are for example the interactions of the Electrical 

Power Distribution System (EPDS) with other Columbus subsystems. Although some 

analyses in this thesis partly dealt with EPDS, there are a lot more issues which 

could be investigated. A power budget analysis could be conducted for example, 

similar to the analysis of the heat load balance of the TCS in chapter 6. 

Another interesting field would be the investigation of payload interaction with 

Columbus subsystems. There again the problem arises, that it is difficult to find out 

what has happened when in Columbus. Nevertheless, a lot of cases could be 

investigated, for example how payloads influence cabin air heat loads or electrical 

power distribution. 

As for the Telemetry Analyzer: it could be enhanced arbitrarily due to its objectoriented 

program architecture. Support for simple equations (dew point, heat flows, 

etc.), visual support by displaying a bar with the current value of every parameter or 

internal data reduction by filtering TSV-files, the possibilities are unlimited. 

Altogether it can be said, that the challenges for engineers and scientists nowadays 

lie in the processing and interpretation of data. The field of data analysis grows 

rapidly and will become more and more important. Technical principles and 

processes for fulfilling these important tasks have been demonstrated in this thesis 

by means of Columbus telemetry analyses.

A Appendix 

A.1 Bibliography 

Appendix 

Bibliography 

[RD01] Blobel V., Lohrmann E.: Statistische und numerische Methoden der 

Datenanalyse, B. G. Teubner Verlag Stuttgart, 1998 

[RD02] DLR-OP: Data Management System (DMS) Console Operations 

Handbook (OPS-HBK-1DMS-115-GSOC), Issue 1, Revision 0, January 

19, 2004 

[RD03] DLR-OP: Systems Engineer Console Operations Handbook (OPS-HBK- 

1SYS-116-GSOC_I1R3), Issue 1, Revision 3, November 10, 2006 

[RD04] DLR-OP: THOR Columbus Hardware Brief, November 8, 2007 

[RD05] EADS Astrium: Columbus, Europe’s laboratory for the ISS, Online 

Brochure, URL: http://www.astrium.eads.net/launchspecial/astrium-columbus_english.pdf/download/ 

(access: October 31, 

2008, 11:30 a.m.) 

[RD06] EADS Space Transportation: Col ECLSS Operations Manual (COL- 

DOR-MA-0001), Issue 4, Revision 0, January 13, 2004 

[RD07] EADS Space Transportation: COL-RIBRE-MA-0045, Issue 03, February 

2004 

[RD08] EADS Space Transportation: Columbus ECLS S/S Operations Manual 

(COL-DOR-MA-0002), Issue 3, Revision 0, January 1, 2004 

[RD09] ESA: Columbus Fact Sheet (Doc. N°: UIC-ESA-FSH-002), Revision 1.1, 

April 25, 2006 

[RD10] ESA: Columbus Systems User Level Training, 2007 

[RD11] ESA, NASA: NASA_ESA_TIM_July08_Comms_topics_Ciro.ppt, 

COMMS Powerpoint Presentation, July 2008 

Page 93

Page 94 

Appendix 

Bibliography 

[RD12] ESA, NASA: Space Station Manned Base to Columbus Attached 

Pressurized Module Interface Control Document (SSP 42001), Revision 

R, March 24, 2004 

[RD13] Fischer, Karl-Friedrich et al.: Taschenbuch der Technischen Formeln, 

Fachbuchverlag Leipzig, 2. Auflage, 1999 

[RD14] Institute of Astronautics TUM: Webpage containing Scientific Projects, 

URL: http://www.lrt.mw.tum.de/en/wissenschaft/projekte.phtml 

(access: February 28, 2009, 11:25 a.m.) 

[RD15] Microsoft Corporation: Microsoft Developer Network (MSDN) Library 

for MS Visual Studio 2008 and Dot.NET Framework Version 3.5, URL: 

https://msdn.microsoft.com (access: December 8, 2008, 3:40 p.m.) 

[RD16] NASA: International Space Station Familiarization (ISS FAM C 21109), 

Revision B, CPN-1, October 18, 2001 

[RD17] NASA: ISS Trajectory Data, URL: 

http://spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/Jav 

aSSOP/orbit/ISS/SVPOST.html (access: March 5, 2009, 10:34 a.m.) 

[RD18] Object Management Group: UML 2.0 Standard, Revision 2.2, URL: 

http://www.uml.org/#UML2.0 (access: November 10, 2008, 11:52 a.m.) 

[RD19] Sattelmayer T., Polifke W.: Wärmetransportphänomene/Wärme- & 

Stoffübertragung – Arbeitsunterlagen, Lehrstuhl für Thermodynamik, 

TU München, September 22, 2008 

[RD20] ZedGraph: Online Documentation Wiki, URL: http://zedgraph.org/ 

(access: December 15, 2008, 09:45 a.m.)

Appendix 

Columbus Technical and Mission Specifications 

A.2 Columbus Technical and Mission Specifications 

Fig. A–1: Columbus Technical and Mission Specifications [RD07], p. 2-4 

Page 95

Page 96 

Appendix 

Columbus ECLSS Overview 

A.3 Columbus ECLSS Overview 

Fig. A–2: ECLSS Overview Schematic ([RD03], Appendix XII)

Appendix 

Columbus Air Conditioning & Redundancy 

A.4 Columbus Air Conditioning & Redundancy 

Fig. A–3: Columbus Air Conditioning & Redundancy ([RD10], ECLSS) 

Page 97

Page 98 

Appendix 

Columbus Active TCS 

A.5 Columbus Active TCS 

Fig. A–4: Columbus Active TCS Functional Overview ([RD03], Appendix XIII)

Appendix 

Columbus Shell Heater and Thermistor Overview 

A.6 Columbus Shell Heater and Thermistor Overview 

Fig. A–5: Shell Heater and Thermistor Overview ([RD03], Appendix XXV) 

Page 99

Page 100 

Appendix 

Flow Chart Symbols according to ISO 5807 

A.7 Flow Chart Symbols according to ISO 5807 

Fig. A–6: Standard Symbols of a Flow Chart (ISO 5807)

A.8 Telemetry Extractor Tool GUI 

Appendix 

Telemetry Extractor Tool GUI 

Fig. A–7: GUI of the Telemetry Extractor Tool 

Page 101

Page 102 

Appendix 

ISS β-Angle Diagrams 

A.9 ISS β-Angle Diagrams 

The upper diagram depicts the β-angles according to the As-Flown ISS Attitude 

Timeline (ATL), the lower diagram according to the Beta, Attitude, Significant Event 

Planning Template (BASEPLATE) prediction table. Data is also available as TM 

Analyzer input files in TSV-format. Time frame of diagrams: February 15, 2008 – 

December 31, 2008 in each case. 

Fig. A–8: ISS Solar β-Angle according to ATL 

Fig. A–9: ISS Solar β-Angle according to BASEPLATE

Diplomarbeit Analysis of Columbus Systems On-Orbit ... - TUM

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?