Avionic Test-Bench Simulators for EagleEye
Evolution of the EagleEye functionality
Kasper Lars Andreas Wikman
Space Engineering, master's level
2019
Luleå University of Technology
In the space industry a lot of efforts is put towards verification and validation of the different parts of the spacecraft. This is a costly process and cause initial friction when trying to introduce new technology within the field. One of the demanding systems to validate and test is the on-board software. To make the process of evaluation and testing of new technologies easier, the European Space Agency has put effort towards creating an end-to-end avionic test bench containing four different simulators. In this test bench a fictional mission called EagleEye was constructed. EagleEye is a representative low-cost & low-power Earth observation mission to create a fictive environment to perform system tests. As of 2018 the mission still lacked the functionality of orbital maintenance. However, during the autumn of 2018 the system had the orbital control mode introduced to the Functional Engineering Simulator in the MATLAB Simulink environment.
Acknowledgements
On this page I want to acknowledge the people and organisations making this thesis possible. First and foremost I want to thank my supervisor Quirien Wi-jnands for giving me the opportunity to write my thesis at ESTEC and for always being up for discussion. I also want to thank my colleague Gaspar Cano for helping me when I was stuck or needed to discuss concepts. I would also like to thank the Software System division (TEC-SW) for making my stay memo-rable and exciting. I also would like to thank my Lule˚a University supervisor, Anita Enmark, for giving me good feedback. And finally I would like to thank my friends and family for always being there when needed and supporting me in all my journeys.
Table of contents
1 Abbreviations v 2 Introduction 7 2.1 Outline of thesis . . . 8 3 Background 9 3.1 EagleEye . . . 93.2 Orbital Control Mode . . . 10
3.3 Versions of EagleEye . . . 12
3.4 Simulators . . . 12
3.4.1 Functional Engineering Simulator . . . 13
3.4.2 Functional Validation Test-Bench . . . 13
3.4.3 Software Validation Facility . . . 13
4 Attitude & Orbital theory 14 4.1 Reference systems . . . 14 4.2 Orbital mechanics . . . 16 4.3 Attitude Transformation . . . 19 5 Method 22 5.1 FES to FVT . . . 22 5.2 FES to SVF . . . 24
5.3 Verification & testing . . . 28
5.3.1 Test 1 . . . 30
5.3.2 Test 2 . . . 30
5.3.3 Test 3 . . . 31
5.3.4 Test 4 . . . 31
6 Result 33 6.1 Functional Engineering Simulator . . . 33
6.1.1 Test case 1 - Full system test . . . 33
6.1.2 Test case 2 - Co-planar thrust . . . 34
6.1.3 Test Case 3 - Inclination change . . . 38
6.1.4 Test Case 4 - RAAN change . . . 39
6.2 Functional Verification Test Bench . . . 39
6.2.1 Test case 1 - Full system test . . . 39
6.2.2 Test case 2 - Co-planar thrust . . . 41
6.2.3 Test Case 3 - Inclination change . . . 44
6.2.4 Test Case 4 - RAAN change . . . 45
6.3 Software Verification Test Facility . . . 45
6.3.1 Test case 1 - Full system test . . . 45
6.3.2 Test case 2 - Co-planar thrust . . . 47
6.3.3 Test Case 3 - Inclination change . . . 50
TABLE OF CONTENTS
7 Discussion 52
7.1 Test case 1, Transition and thruster tests . . . 52
7.2 Test case 2 - 4, Sub mode functionality & Orbital Changes . . . 53
7.3 Future work . . . 55
8 Conclusion 57 References 58 Appendices 60 A Additional results for simulators . . . 60
A.1 FES Tests . . . 60
A.2 FVT Tests . . . 65
A.3 SVF Tests . . . 71
B Bus definitions . . . 77
C Models & Schedulers . . . 85
C.1 Matlab/Simulink Model . . . 85
1
Abbreviations
ATB Avionic Test-Bench
AOCS Attitude & Orbital Control System EE EagleEye
ECEF Earth-Centered, Earth-Fixed
ECSS European Cooperation on Space Standardisation ESA European Space Agency
FDIR Failure Detection, Isolation & Recovery FES Functional Engineering Simulator FVT Functional Validation Test-Bench GNC Guidance, Navigation & Control IMM Imaging Mode
NMM Normal Mode OBC On-board Computer OBSW On-board Software OCM Orbital Control Mode PUS Packet Utilisation Standard RTB Real-Time Test-Bench
RAAN Right Ascension of Ascending Node SMP Simulation Model Portability SW Software
SVF Software Validation Facility TC Telecommand
2 INTRODUCTION
2
Introduction
The investigation of our planet is reliant on data provided by advanced space missions launched to study specific characteristics that cannot be seen from the surface of the Earth. Depending on the mission objectives the complexity and required robustness of the spacecraft varies. These properties requires a substantial amount of resources to validate and test. One of the demanding systems for the verification procedure is the On-board Software (OBSW).
When new software technology techniques are needed a lot of effort is spent on validating and verifying the new flight software components. Each of the components needs to undergo several maturity steps from feasibility to flight demonstration before being usable in a space mission. This process is costly for a mission and is quite difficult for smaller Research & Development (R&D) activities.
To handle this flaw, ESA has developed an End-to-End (E2E) Avionic Test-Bench (ATB), which works as both a concept and a supporting framework providing a basic facility to try fictive simulated spacecraft and OBSW. This fictitious yet fully representative reference mission is called EagleEye (EE). Ea-gleEye represents an Earth observation satellite in a low Earth polar orbit. The ATB is intended to support the demonstration and validation at a system level for the upcoming avionics related to standards and technologies in a virtual en-vironment. The ATB also intends to support projects in their need of assessing particular technology related issues.
In this E2E-ATB context, the space avionics contain the following function-alities: data handling (processing and storage), telemetry and telecommand processing, Attitude & Orbital Control System (AOCS) and equipment (bat-teries, solar arrays, etc.). Other subsystems are included but only to the level needed on a system-level. The benefit of this system is to provide a represen-tative environment for the type of analysis, verification or validation that is difficult to assess, predict or estimate without simulations.
Thesis Objective
The objective of the thesis is to continue the development of the OCM for the mission EagleEye. This means porting the model over from a simulation model in the FES to the SMP blocks for the FVT and the OBSW for the SVF. Then validate the functionality of the OCM within the FVT and SVF.
2.1
Outline of thesis
3 BACKGROUND
3
Background
This chapter will look at the background of the mission EagleEye as well as the simulators used in the ATB, such as the FES, FVT and SVF.
3.1
EagleEye
EagleEye is a virtual Earth observation satellite mission created for the ATB. It is created to test new technologies, architectures and research within OBSW. The orbit of EagleEye is a polar low Earth orbit with the following properties [1][2].
• Eccentricity (e) < 0.001
• Semi-major axis (a) ≈ 7050km (+/- 20 km) • Inclination (i ), 98.2◦
• Local time of descending node around 10 h
As seen in the bullet-points above the orbit is nearly circular. The orbit is typical for an Earth observation satellite (e.g. Sentinel-2 [3]). Figure (1) depicts the structure of the EagleEye spacecraft.
at the functionality of EagleEye can be outlined. EagleEye operates with five different modes. Each of the modes is shown in Table (1).
Table 1: All operational modes for EagleEye Id Mode name Abbreviation Description
0 Idle Mode IDM Start-up mode
-1 Safe Hold Mode SHM Stabilise spacecraft rates and wait for TC
1 Normal Mode NMM Sun pointing
2 Imaging Mode IMM Earth observation
3 Orbital Control Mode OCM Perform orbital mainte-nance
How the modes in Table (1) interact is shown in Figure (2).
Figure 2: Eagle Eye mode transition diagram
Further explanation of how all the modes work can be found in [5], [1] or [6]. However, for this thesis the focus is on the OCM. Therefore, a more in depth explanation of the OCM was done here.
3.2
Orbital Control Mode
3 BACKGROUND
Table 2: The OCM’s sub modes Id Sub mode name Abbreviation Description
10 Nadir Pointing NP Orients the spacecraft into Nadir pointing
11 Reference Pointing RP Slew manoeuvre to a spe-cific attitude from Nadir pointing
12 Thruster Fire TF Fires the thruster in the direction given by RP 13 Sun Acquisition SA Rotates spacecraft to find
the sun
From the sub modes in Table (2) the system performs in the following se-quence to create the OCM.
Figure 3: OCM mode transition diagram
to-again before performing SA (3).
When NP is achieved the system moves to SA (4). During SA the system tries to find the sun by performing two rotations. First the spacecraft will rotate around the y-axis and then it will rotate around the x-axis [5]. When the sun is within a certain angular limit [5] the system goes back to NMM. In the figure an asterisk (*) can be seen. This represents a path in case the first NP fails. Then the system will automatically send a warning message to the system and go to SA.
3.3
Versions of EagleEye
Before going to the next topic of the chapter a brief text about the EagleEye versions is needed. The mission EagleEye has existed for many years and has undergone different changes of the functionality. This thesis uses version 7 of the system [8]. Version 7 of EagleEye is an ARM processor compatible system and changed the OBSW code to C from the previously used Ada. The system is built upon another big change done to EagleEye which was version 5 [9][10]. Version 5 introduced the concept of Time & Space Partitioning (TSP) into the EagleEye environment.
TSP is a procedure where the software system is defined into different in-dependent blocks that can run by themselves without affecting other blocks functionality. Therefore, it creates a separation between mission functionality. For example, the AOCS runs on its own partition and cannot be affected by the I/O partition directly. If the I/O wants to change parameters in the AOCS it wont be allowed to just change things freely due to the isolation of the AOCS. The AOCS will communicate through inter partition communication protocols to see if the change is allowed. This also works in the other direction as well. The concept of TSP is now starting to be introduced into future space missions. Additional information about TSP can be found in [10] or [11].
This is the end of the part about EE and the OCM. Additional information about EE and OCM can be found in [1][2][6][7][5]. The next section of the chapter will look at the simulators.
3.4
Simulators
3 BACKGROUND
3.4.1 Functional Engineering Simulator
The FES is a simulator of the mission EagleEye that exists within the Math-Works’ environment, MATLAB Simulink. The simulation is built on a model-based design [12] to simulate the EagleEye mission as described above. This is the first process in the simulator implementation. The FES is not intended to validate the OBSW fully but only the AOCS part of the system. In the FES the system is using a block structure to construct the functionality. The AOCS system is built according to the European Cooperation on Space Standardisa-tion (ECSS) [13].
A description of the model structure can be found in Appendix C and will not be covered in depth here. Previous work [4] has shown that the system has a one-to-one equivalence in the output when using auto-coded blocks in the Mathworks’ environment. But it has not been verified to give a one-to-one equivalence in the output when moving to other simulator environments yet. 3.4.2 Functional Validation Test-Bench
The second simulator is the FVT. The FVT runs in the simulation environment Eurosim [14]. In this simulator the EE mission is running SMP2 (Simulation Model Portability), following ECSS [15] models. The SMP2 models are blocks containing auto generated code that are connected together in Eurosim to create the EagleEye functionality. The reason for using the FVT is to verify that the AOCS functionality translates from Matworks’ to the Eurosim correctly and that the simulator functionality remains intact.
To run models in Eurosim the system uses a defined scheduler. The sched-uler defines parallel and sequential operations that are performed by the system. How the FVT scheduler looks can be seen in Appendix C. For additional infor-mation about the Eurosim scheduler consult [14].
3.4.3 Software Validation Facility
up the background about EagleEye and the simulators. The next chapter will cover the theory required for analysis of the results.
4
Attitude & Orbital theory
This chapter covers the theory for the analysis in Chapter 7, such as reference systems, orbital mechanics and attitude transformations.
4.1
Reference systems
When working with remote systems such as spacecrafts, an important feature to consider is the reference frame used to describe spacecraft behaviour. For this reason, there exist a vast number of different frames that one could use. However, it usually gets narrowed down to a standard set of frames. This chapter will cover three specific reference frames used in the simultor: The Earth-Centred Inertial (ECI) frame, the Earth-Centred & Earth-Fixed (ECEF) frame and the Satellite Body Reference Frame (SBRF). In Figure (4) the ECI – and ECEF frame are shown.
z xECI(ϒ) yECI xECEF yECEF
Greenwich Meridian
Vernal Equinox
Equatorial plane
Figure 4: Graphical representation of the orbital reference frames, ECI and ECEF
In Figure (4) it is possible to distinguish between the two reference frames. The frames share a similar origin and z-axis (defined at the celestial North pole) but differs in their behaviour in the equatorial plane.
4 ATTITUDE & ORBITAL THEORY
This event happens during March each year. The principal direction of the Vernal Equinox corresponds to the Julian date of which the crossing is defined. In this thesis it will be associated to the Julian year, J2000 [16]. The y-axis of the ECI is defined as the complementary right-hand rule [17] between the x -axis and the z -axis (ˆy = ˆz × ˆx). The ECI frame is usually used as a main reference for attitude measurements in the simulators [5].
The ECEF frame differs from the ECI by it being a rotating frame that rotates with the Earth, while the ECI is independent of the Earth’s rotation. The x -axis of the ECEF points towards the Greenwich Meridian as shown in Figure (4). The Greenwich Meridian is the prime meridian (defined centre of Earths equatorial circumference if it was drawn as a line) used for Earth and is based at the Royal Observatory in Greenwich [18]. Like the ECI the y-axis of the ECEF is complemented by the right-hand rule between the x -axis and z -axis (ˆy = ˆz × ˆx). In the simulators ECEF is used as the main reference for position and velocity [5]. The next frame to look at is the SBRF. A figure of the reference frame is shown in Figure (5).
z (Nadir) x
y
Figure 5: Graphical representation of the spacecraft frame, SBRF In Figure (5) the spacecraft of Figure (1) is shown. The origin of the reference system is placed at the centre of mass of the spacecraft. The z -axis is defined as,
ˆ
z = − r~sc | ~rsc|
, (1)
where ~rsc is the position vector to the spacecraft from the centre of Earth.
This reference frame is used to study attitude behaviour of the spacecraft and is also referred to as a Nadir frame throughout the thesis [5]. A quick summary of the frames is shown in the table below.
Table 3: Summary of reference systems used System Origin Principal Direction Z -axis
ECI Earth Vernal equinox () Celestial North pole ECEF Earth Greenwich Meridian Celestial North pole SBRF Spacecraft Velocity direction Nadir This wraps up the facts about the reference frames.
4.2
Orbital mechanics
This part of the theory chapter will cover some necessary orbital mechanics for the thesis and will assume some basic knowledge in orbital mechanics. If a refresher in the theory is needed have a look in [16][19]. The first thing to look at is how orbits are studied. In Figure (6) a two-dimensional orbit is shown.
y x a b F r c 𝛳 ra rp
Figure 6: 2D orbit representation
The figure represents a simplified case of an orbit. The spacecraft is orbiting a distance ~r from the planet (Earth) placed at the focal point, F. The important variables to have a knowledge of is a, ra and rp. The variable ra represents the
apoapsis of the orbit and is the furthest point from the focal point the spacecraft will travel. The second variable rp refers to the periapsis which is the closest
4 ATTITUDE & ORBITAL THEORY a = ra+ rp 2 = µ 2(rµ sc − v2 sc 2 ) . (3)
In eqn. (3) the variable µ represents the standard gravitational parameter for Earth (3.986004418x1014[ms23]). The variables rscand vscrepresents the position
and velocity vector of the spacecraft, respectively. Through the parameters ra
and rp the property of eccentricity can be defined,
e = ra− rp ra+ rp
. (4)
Eccentricity given in eqn. (4) gives a value from zero to infinity and yields an indication of how the orbit looks. The orbit could be circular (e = 0), elliptical (0 < e < 1), parabolic(e = 1) or hyperbolic (e > 1). Each of the cases are visualised in Figure (7) with the parabolic and hyperbolic being shown together.
e = 0
e ∈ ]0,1[ e ≥ 1
Figure 7: Orbital behaviour depending on eccentricity
The equation of eccentricity shown in eqn. (4) can be expanded further to only use the semi-major axis, position and velocity to determine it’s value. This is needed for the simulator and [19].
e = s
1 − |( ~rsc× ~vsc)|
2
• e, Eccentricity • i, Inclination
• Ω, Right Ascension of Ascending Node (RAAN) • ω, Argument of Perigee
To explain the variables a sketch of a 3D orbit can be studied.
𝝎 𝒾 Perigee x y z Spacecraft 𝒗 Orbital Plane Equatorial Plane Line of Nodes
Figure 8: Graphical definition of Classical Orbital Elements
Figure (8) gives a wealth of information. The first thing to talk about is the line of nodes. This is described as the line that intersects the orbital plane and the equatorial plane of the Earth. The intersection points are called ascending and descending node depending on the direction of passage. The first parameter look at is the inclination (i ). This is the angle between equatorial plane and orbital plane and can be seen close to the line of nodes in Figure (8). The equation to determine the inclination is,
i = arccos (( ~rsc× ~vsc)z |( ~rsc× ~vsc)|
). (6)
4 ATTITUDE & ORBITAL THEORY Ω = arcsin (√ ( ~rsc× ~vsc)x (( ~rsc× ~vsc)x)2+(( ~rsc× ~vsc)y)2 ) arccos (√ −( ~rsc× ~vsc)y (( ~rsc× ~vsc)x)2+(( ~rsc× ~vsc)y)2 ) . (7)
As seen in eqn. (7) the RAAN value can be determined in two different ways. When looking at these values one needs to consider which one of the functions to use as there can be some sign differences. The final variable is argument of perigee. The equation for it will not be considered here but can be seen in [19] alongside the previously shown equations. Argument of perigee shows the angular distance from the line of nodes to the perigee of the orbit.
This concludes the orbital mechanics part of the theory. For the final part of the theory the field of attitude transformations will be covered.
4.3
Attitude Transformation
This part of the chapter will cover the attitude transformations. The text assumes some prior knowledge in linear algebra and attitude dynamics. The topics that will be discussed are the Direction Cosine Matrix (DCM), Euler Angles and Quaternions.
When working with attitude dynamics it is important to be able to go from any reference frame A to the frame B. It is not only of interest to see how this transformation behaves, but also to be able to describe the orientation of the spacecraft in frame B viewed by frame A. To accomplish this an example is given.
In the equation above ¯Aa→bis the transformation matrix from A to B. One
of the methods to create matrix ¯Aa→b is to rotate the frame using cosines to
create the transformation. Hence the name Direction Cosine Matrix (DCM), which can be generalised to look as follows.
¯ Aa→b= a11 a12 a13 a21 a22 a23 a31 a32 a33 (9)
The transformation matrix Aa→b¯ gives the transformation required to go
from frame A to frame B, but it lacks characteristics to make any imaginary drawing of how the frame B relates to frame A. This is where the Euler angles comes into the picture. The Euler angles are rotation sequence of three rotations (a-b-c) that rotates the system around a certain axis to go from frame A to B. The potential rotations are described below.
• Roll (θ), Rotation around the x-axis • Pitch (φ), Rotation around the y-axis • Yaw (ψ), Rotation around the z axis
For these types of rotations there are twelve possibilities. They are divided into two different categories, proper Euler angles (one of the axis rotations repeat) and Tait-Bryan angles (all three rotations are unique). For this thesis the ((ψ)-(φ)-(θ)) rotation is considered. This rotation yields the following DCM.
¯ Aψφθ= ¯AθA¯φA¯ψ= cφcψ cφsψ −sφ −cθsψ + sθsφcψ cθcψ + sθsφsψ sθcφ sθsψ + cθsφcψ −sθcψ + cθsφsψ cθcφ (10)
One neat property with the Euler angles is that the engineer can visualise the rotation when talking about three angles compared to only looking at the DCM. With Euler angles there are multiple ways to reach the same orientation and it can sometimes be hard to imagine which rotations are the most efficient. A negative property of the Euler angles is that they become singular at 90◦ in the y-axis. Therefore, for large angle rotations they can become troublesome. One way to work around this is to use the singularity-free quaternions.
Quaternions is a four-dimensional system created by William Rowan Hamil-ton in the 19th century. The quaternion system works as an extension to the real numbers and are good for describing rotations of coordinate systems. The quaternion vector is defined as follows.
~
q = q4+ ˆiq1+ ˆjq2+ ˆkq3, q1, q2, q3, q4∈ R. (11)
4 ATTITUDE & ORBITAL THEORY ˆi2= ˆj2= ˆk2= −1 ˆiˆj = −ˆjˆi = ˆk ˆ jˆk = −ˆkˆj = ˆi ˆ kˆi = −ˆiˆk = ˆj q42+ q12+ q22+ q23= 1
As with the Euler angles the quaternions can be put into a rotation matrix shown in eqn. (9). ¯ Aq = q12− q2 2− q 2 3+ q 2 4 2(q1q2+ q3q4) 2(q1q3− q2q4) 2(q1q2− q3q4) −q12+ q22− q23+ q42 2(q2q3+ q1q4) 2(q1q3+ q2q4) 2(q2q3–q1q4) −q12− q22+ q23+ q42 (12)
5
Method
This chapter will cover the methodology and rationale to implement the Or-bital Control Mode (OCM) in the Functional Validation Test-Bench (FVT) and Software Validation Facility (SVF). The first part of the chapter will cover the implementation in the FVT and then the implementation in the SVF. The final part of the chapter looks at the verification process.
5.1
FES to FVT
The method of going from FES to FVT has different steps. The procedure can be summarised as follows and will be explained afterwards.
• Using MOSAIC to auto-code the models to SMP2 blocks
• Integrating each model to the FVT (Eurosim) and performing unit tests of each model
• Setting up the test cases to verify OCM functionality
The practice of porting the FES model to the FVT started with the use of MOSAIC [20]. MOSAIC stands for Model-Oriented Software Automatic Inter-face Converter and is a third-party product to MATLAB Simulink (and other similar simulation softwares) and is used to transfer models to a hard-real-time simulator such as EuroSim [14]. The intention of MOSAIC is to ensure that the models being transferred are following the standard given by Simulation Model Portability (SMP2, second generation SMP) or ECSS [15].
The process starts with isolation of the model that one wants to auto code. The model requires a well-defined bus structure of inputs & outputs to the system and the base model of the wanted system (thrusters, AOCS, etc.). When going from the FES to the FVT there are four different models that need to be transferred. These are,
• AOCS model • Ground model
• System management model • Thruster model
5 METHOD
Table 4: Bus definition of the thruster model
In/Out Name Dimension Description
Input THR OnOffCmd 1x4 On-Off signal system Input THR Fire 1x4 Fire signal for thrusters Output THR Sts 1x4 Status signal of thruster health Otuput THR TorqueBF 1x3 Torque in body frame Output THR ForceBF 1x3 Force in body frame Output THR Forces 1x4 Force from each thruster Output THR Failure Flags 1x6 FDIR Flags
In Table (4) the bus definitions are shown. From these bus definitions the model looks as follows.
Figure 10: Thruster model with correct bus definitions
When the model in Figure (10) is working, the MOSAIC program can be used to transfer the model to the SMP2 format. The code that the system will create is compatible with the ECSS [15]. A negative prospect of the approach is that the developer loses control of the content of the code, but yields benefits in reduced development time and expenses. The auto-coding process is a common method used nowadays within space industry and was therefore selected for the simulator.
THR
Environment
SMP2
Model
SMP2
Model
THR_Force THR_TorqueFigure 11: Visual example of connections between environmental and thruster SMP2 models
In Figure (11) the connections between SMP2 blocks are seen. Here the output given from the thruster is sent as one of the inputs to the environment model. Since in Eurosim each SMP2 block is independent of each-other all the different connections need to be manually defined. The figure only represents a simplified description of the procedure.
When the interfaces were specified, each component was put under unit tests to study the behaviour of the specific model. The thrusters for example was randomly activated during the simulation under a prolonged period. From this it was possible to see the activation signals, the warning signals, the thrust values as well as the movement or oscillation of the spacecraft depending on which thrusters were activated. This meant that the system had its intended output and interacted with the other models.
Because the small tests not being the focus of the thesis they will not be covered here. For the thesis the main objective is the full functionality of the system. The definition of the busses of the other models are shown in Appendix B and can be consulted if interested. Similar signal tests were performed on each of the models to verify that the signals went through as intended.
The final step of the integration was to create initial conditions for the FVT tests. What these are and how they are defined can be found later in this chapter.
5.2
FES to SVF
The second step after having moved the FES to the FVT was to move the FES to the SVF. The procedure for accomplishing this can be shown in the bullet-points below.
5 METHOD
• Integrating the model to the SVF (Eurosim)
• Setting up the TC/TM structure required to run the OCM • Setting up the tests cases to verify OCM functionality
For the move from FES to SVF the thruster SMP2 model was saved. The other three models were not kept. The reason for this is because the SVF intends to simulate the OBSW as a whole system and uses other implementations for the models. For the AOCS model it is auto-coded to C-code and replaced within the OBSW. As previously mentioned in the background chapter the system utilises a TSP approach [10]. This means that the Software (SW) has several different partitions that can be visualised as follows.
OBSW Interface
AOCS FDIR DMS I/O Payload
Figure 12: The partitions that EagleEye has
Receive thruster signal commanded
Is the thrust command going to cause tumbling?
Set thrust allowed Set thrust to notallowed No
Yes Start
Stop
Figure 13: System management for the thruster models
The implementation of the system management functionality in Figure (13) is to ensure that faulty commands for the thruster are not sent. An argument against this procedure is that maybe the spacecraft is already tumbling, and the asymmetrical thruster fire could stabilise the spacecraft. For this endeavour the system base functionality could be overwritten to solve this issue. However, for normal intended functionality it was of interest to put this system check in, just in-case a faulty command is received by the spacecraft.
The procedure of coding the AOCS system was to use the built-in auto-coding process of MATLAB using the .ert auto-auto-coding format. This means auto-coding to a format that is meant for an embedded real time target (hence .ert). The reason for choosing this format is because the Eurosim simulation model operates with a real-time system. When the procedure was done the code was moved to the SVF system on the ATB computer as mentioned previously.
5 METHOD
Figure 14: The Packet Utilisation Standard structure given from [22] Figure (14) shows the general structure of the PUS commands. Further information about PUS can be found in [22]. The reason for needing PUS telecommands was because the SVF used a scripted ground station that sends commands to the spacecraft. The required telecommands for the SVF is shown in Table (5).
Table 5: Telecommands required for OCM Name (-) Dimension Description
TC OCM Time 1x4 Time checkpoints for slew manoeuvre
TC OCM Yaw 1x4 Yaw angle checkpoints for slew manoeuvre
TC OCM Pitch 1x4 Pitch angle checkpoints for slew manoeuvre TC OCM THR Time 1x1 How long the thrust will
last
TC OCM THR Const 1x4 Which combinations of thrusters are used
Figure 15: Content of the PUS8 command content
The function ID defines what type of function identification the system uses. For the OCM the function id was chosen to be 13 after the imaging control that had number 12. N gives the information about the number of parameters. The parameter identification was used to say which parameters were to be used and the final slot got the data. Each of the telecommands were implemented into a pre-defined TC packet document.
After the implementation of the commands, further updates were needed for the system. The next part was ensuring that the system read them properly. This was done by utilising the code for the Imaging Mode (IMM) telecommand handling. After the implementation of all these things the final step was to create the test conditions for the tests required for verifying the functionality of the OCM. The procedure for doing this is described in the next subsection.
5.3
Verification & testing
Previously in the chapter a lot of emphasis was put on how the implementation of the OCM was done for the different simulators. The next thing to look at is how the verification of these models were done and why. To verify the functionality of the OCM the decision was made to use a previous approach used when verifying the FES models [7]. The FES will be used as the main reference for the FVT and SVF tests but is not the absolute truth of a working system. This approach focuses on four test cases to look at the functionality of the system. These can be summarised as follows.
Table 6: Test numbers and test description Test (#) Description
1 Full system test
2 Co-planar test
3 Inclination test
4 Right Ascension of Ascending Node test
5 METHOD
been kept low and the thrusters could have been active for longer. But this would require a different type of analysis and was outside of the scope of the thesis. The thrusters are also not intended to be active for long periods of time. The orbit corrections occur in an interval of a couple of seconds to a minute. So to ensure that the functionality of the OCM was there, a high thrust was the best decision.
All the tests were performed for all the three simulators and are collected in the results chapter. The reason for showing the FES results as well is to look at the reference and be able to reflect on the FVT and SVF behaviour. The graphs that will be presented in the results chapter is summarised in Table (7).
Table 7: All the different plots shown in the results chapter # What is plotted Description For which test 1 Sub mode
transi-tions
Looks that the system follows the functionality shown in Figure (3)
Test 1
2 Added force from thrusters
Studies if the thrusters provide the correct force
Test 1 3 Nadir frame
atti-tude for first NP manoeuvre from Figure (3)
First NP pointing sub mode behaviour
Test 2-4
4 Nadir frame atti-tude for second NP manoeuvre from Figure (3)
Second NP pointing sub mode behaviour
Test 2-4
5 Nadir frame atti-tude during Refer-ence Pointing (RP)
Looking at the spacecraft attitude change in RP to verify commanded value is achieved Test 2-4 6-9 Classical Orbital Element changes during thruster fire
Looks at the change in or-bit during manoeuvre
All
10 Velocity change during thruster fire
Spacecraft velocity change during thruster fire to ver-ify functionality
Test 2
Now lets look at the test descriptions. 5.3.1 Test 1
Test 1 in table (6) focuses on looking at the full operation of the system to ensure that the system performs the sub mode transitions as shown in Figure (2) and that the thrusters are working for the model. The reason for this is to give a comprehensive picture of how the system operates and see that it generally works as intended according to the requirements [1][2]. The next three tests are focusing on the sub mode functionality of each simulator as well as the orbital parameter changes that occur. Each of the tests will be covered more in depth. 5.3.2 Test 2
Test 2 looks at a co-planar change of the orbit. This means that that the expected changes occur in the semi-major axis (eqn. (3)), eccentricity (eqn. (5)) and spacecraft velocity. The orbit used by the spacecraft is the original orbit described in the requirement document for EagleEye [1] and is shown in Figure (16).
Figure 16: Orbital path of test 2 and 3
5 METHOD
some detail to ensure that the system behaves as it is intended compared to the final report from the internship [7]. A summary of Test 2 can be seen in the bullet points below.
• Thrust is performed in the direction of velocity at the equatorial crossing. • The orbit for the test is the original EagleEye orbit.
• The test focuses sub mode functionality and changes in a, e and vsc.
5.3.3 Test 3
Test 3 focuses on performing a change in the inclination (eqn. (6)) of the orbit. As mentioned previously it uses the original orbit for EagleEye and performs the thrust at the equatorial crossing. The direction of this thrust was determined to be ≈ +0.998◦ from the zero reference around the yaw-axis to create an inclination change of approximately 4◦. The angle was determined from previous
calculations provided in the intership report [7]. The reason for this test is that the inclination of the orbit declines with time and might be necessary to change during the lifetime of the spacecraft. Therefore, it is required to show that the simulator can operate such changes to ensure a realistic simulator. For this test the sub mode functionality is shown as well to ensure that the operation works for different tests. A summary of the test is shown below.
• Thrust is performed at an angle of ≈ +0.998◦ from the zero reference of
yaw at the equatorial crossing.
• The orbit for the test is the original EagleEye orbit.
• The test focuses sub mode functionality and changes in i. The expected change is approximately 4◦ (calculated from [7]).
5.3.4 Test 4
Figure 17: Orbital path of test 4
As for the inclination test the angle of thruster fire was determined to ap-proximately give a 4◦ change in the studied parameter. This is to ensure that
success can be defined for the test. Test 4 can be summarised as follows. • Thrust is performed above the north pole with ≈ 0.998◦ from the zero
reference around the yaw axis.
• The orbit used for the test is a circular orbit with a 90◦ inclination and is
unique for this test.
6 RESULT
6
Result
This chapter will cover the results from each test described previously. The chapter will be divided into three sections, one for each simulator (FES, FVT and SVF). The sections of the chapter will start by looking at the full system test. After that the three additional tests to verify the orbital control mode and sub mode functionality are shown. Each of the tests are studying the sub mode functionality. Because of this only the first tests show all the results from the sub mode operations. The other sub mode results can be seen in Appendix A.
6.1
Functional Engineering Simulator
This subsection centres around the Functional Engineering Simulator (FES). In the first subsection below a full system test is shown.
6.1.1 Test case 1 - Full system test
The first test result to be shown is the sub mode transition during a full OCM operation.
Figure 18: Sub mode transitions during OCM operation, FES
Figure 19: Thrust force during simulation, FES
In Figure (19) the provided force of the thrusters can be seen. As mentioned previously there are four thrusters and each gives 1300 N. Because of this 5200 N is the expected value.
6.1.2 Test case 2 - Co-planar thrust
This subsection looks at a thrust in the direction of travel. In Figure (3) the transitions of the OCM sub modes was shown. The results from the two Nadir Pointing (NP) operations seen in the figure are shown in Figure (20) and (21).
6 RESULT
Figure 21: Spacecraft nadir pointing attitude during second nadir pointing manoeuvre, FES
in Figure (22). The next three figures shows the Thruster Fire (TF) sub modes change in parameters a, e and v.
Figure 23: Semi major axis change during thruster fire, FES
6 RESULT
Figure 25: Velocity change during the thruster fire, FES
Figure 27: The norm of the body rates during sun acquisition, FES From Figure (26) and (27) the behaviour during the Sun Acquisition (SA) sub mode could be studied. Verification can be done by comparing the results to the test documentation for EagleEye [21].
6.1.3 Test Case 3 - Inclination change
This subsection looks at the inclination change previously described in Test 3. The change during the thrust can be seen in Figure (28).
Figure 28: Change in inclination during the thruster fire, FES
6 RESULT
system. Further analysis can be seen in the discussion. 6.1.4 Test Case 4 - RAAN change
The final subsection for the FES looks at the Right Ascension of Ascending Node (RAAN) change during the TF.
Figure 29: Change in RAAN during the thruster fire, FES
In Figure (29) the change can be seen and compared to the 4◦ described in the earlier chapter. If additional graphs for the Test 3 and 4 sub modes are wanted, please consult Appendix A.
6.2
Functional Verification Test Bench
This subsection looks at the Functional Validation Test-Bench (FVT). In the first subsection below a full system test is shown.
6.2.1 Test case 1 - Full system test
Figure 30: Sub mode transitions during simulator operation, FVT Figure (30) can then be compared to Figure (18) and Table (2). The next plot looks at the thruster force provided.
Figure 31: Thrust force during simulation, FVT
6 RESULT
6.2.2 Test case 2 - Co-planar thrust
This test looks at a thrust in the co-planar direction and the looks at the sub mode functionality of the FVT
Figure (32) and (33) can be compared to the FES results shown previously and the behaviour from the final report [7]. The next figure looks at the slew manoeuvre of the spacecraft from the commanded TC.
Figure 34: Spacecraft attitude during slew pointing manoeuvre, FVT In Figure (34) the commanded manoeuvre for the spacecraft is shown. The TC is the same as in the FES. The next three figures shows the TF change in a, e and v during the thruster fire in a similar fashion as the FES results.
6 RESULT
Figure 36: Eccentricity change during the thruster fire, FVT
Figure 38: Sun versor during sun acquisition, FVT
Figure 39: The norm of the body rates during sun acquisition, FVT In Figure (38) the sun versor relationship is shown for the spacecraft. Figure (39) displays the length of the body rate vector and can be compared to the results from the FES and the test result document [21].
6.2.3 Test Case 3 - Inclination change
6 RESULT
Figure 40: Change in inclination during the thruster fire, FVT
Figure (40) shows the change in inclination during the TF sub mode. Com-parision can be made with the FES results.
6.2.4 Test Case 4 - RAAN change
The final subsection for the FVT looks at the change in RAAN. The result can be seen in Figure (41).
Figure 41: Change in RAAN during the thruster fire, FVT Additional graphs for Test 3 and 4 can be found in Appendix A.
6.3
Software Verification Test Facility
Figure 42: Sub mode transitions during simulator operation, SVF Comparison for the transitions should be made with the FVT and FES. And then verified by Figure (3). The next figure looks at the thruster signals for the system.
Figure 43: Thrust force during simulation, SVF
6 RESULT
6.3.2 Test case 2 - Co-planar thrust
This subsection looks at test case two presented in the method chapter. The first graphs show the NP sub mode behaviour from Figure (3).
following figure looks at the slew manoeuvre performed in the SVF.
Figure 46: Spacecraft attitude during slew pointing manoeuvre, SVF The systems expected behaviour is to reach 90◦in the yaw angle as explained in the method chapter. The next three figures shows the TF change in a, e and v during the thruster fire similarly to the FES results.
6 RESULT
Figure 48: Eccentricity change during the thruster fire, SVF
Figure 49: Velocity change during the thruster fire, SVF
Figure 50: Sun versor during sun acquisition, SVF
Figure 51: The norm of the body rates during sun acquisition, SVF From Figure (50) & (51) the SA functionality can be verified. As previously mentions comparison should be made to the other simulators and the results given in the final report [7].
6.3.3 Test Case 3 - Inclination change
6 RESULT
Figure 52: Change in inclination during the thruster fire, SVF
The expected change in inclination during TF was estimated to be 4◦during the firing of the thrusters.
6.3.4 Test Case 4 - RAAN change
This is the final subsection of the chapter. This subsection looks at the change in RAAN for the SVF. The results can be seen in Figure (53).
7
Discussion
This chapter will cover the discussion and analysis of the results collected in the previous chapter. First the full system test will be covered and then an overview of the orbital change tests. Finally, some future work to be done is presented.
7.1
Test case 1, Transition and thruster tests
As seen in the result chapter there is one unique test for each simulator looking at the sub mode transition and the thruster signals during the simulation. Let’s first look at the sub mode transitions (Figure 18, 30 and 42 respectively) for each simulator. As seen in the graphs the behaviour of the system is as follows, N P (10) → RP (11) → T F (12) → N P (10) → SA(13) → N M M . This is the wanted behaviour as shown in Figure (3).
If one compares the FES (Figure (18)) to the FVT (Figure (30)) the relation-ship between the sub modes is one-to-one correlated in time and values. This is because the FVT mimics the FES functionality exactly. But when looking at the SVF (Figure (42)) the time is shifted but the values undergo a similar procedure. This is because the SVF starts in Idle Mode (IDM) and activates the OCM through TC messages (procedure seen in Figure (2)). However, as seen the behaviour is similar to the other simulators. Because of this the transition of the sub mode in each simulator is correct and can therefore be described as functioning as intended according to the internship report [7] and Figure (3).
The next thing to study is the thruster values for each of the simulators (Figure ((19), (31) and (43)). As previously mentioned, a value of 1300 N per thruster is expected. The thrust is added in the negative y-direction of the body frame due to the thruster’s placement below the spacecraft as mentioned during the background chapter (Figure (1)).
7 DISCUSSION
7.2
Test case 2 - 4, Sub mode functionality & Orbital
Changes
Sub mode functionality: The first thing to be studied is the sub mode func-tionality of each of the sub modes for the OCM and the comparison between the simulators. Lets start by looking at the NP sub mode for the OCM. This was presented in Figure (20), (21), (32), (33), (44) and (45) for the three simulators. From just looking at the figures the behaviour of each simulator is similar. As previously mentioned the FES (Figure (20) and (21)) and FVT (Figure (32) and (33)) performs a similar behaviour both in time and values. While the SVF (Figure (44) and (45)) differs slightly compared to them. For the NP sub mode, the system shall reach NP and remain stable before 250 s according to the requirements put on the system [5][1][2]. The system shall also give a stability within 0.5◦ during this time period.
As seen for all of the figures each of the system fulfils both requirements. Therefore, the NP general functionality is presumed to be fulfilling the require-ments set on the sub mode for the different simulators. However, when one starts to investigate the detailed values between the different simulators they behave slightly differently. This can be seen especially for the comparison be-tween FES and FVT which is supposed to almost be a perfect match in terms of time behaviour and values. Let’s examine the difference between the angular values for the FVT and FES for Test case 3.
the system is moved to the Eurosim environment.
An additional example of this was the first value of the x-axis of the orbit in the FES was given as 5.8491433632 × 103 km and the FVT had a value of
5.849143363 × 103 km. The last digit is removed within the Eurosim
environ-ment. Because of this there is a small difference between the Eurosim simula-tion and the Mathworks simulasimula-tion results. However, not enough time existed to solve this issue. But the argument can be made that the functionality still works properly even though the output does not give a one-to-one relationship. It could be stated that it is good enough for working with the simulator. Be-cause currently the FES is only an arbitrary reference. In reality things will be different, and the FES might not be fully re-presentable for the other simulation behaviours due to different factors within each simulation model.
The next thing to examine is the RP sub mode. The given test graphs are shown in Figure (22), (34) and (46). As with the NP sub mode a resemblance between the three simulators are seen. The spacecraft perform its manoeuvre from the Nadir pointing frame to the given reference from the TC given by the ground station. The requirement for the system is that the spacecraft moves from the initial condition to the wanted attitude and keeps it until the thruster fire occur and keeps the attitude within a 0.5◦ margin to ensure proper thrust. From the graph it is evident that this occurs. As mentioned for the NP sub mode there will be differences between the simulator at a low level. But it is not of interest to investigate further here as the problem already been identified and the focus of the thesis is around the functionality. Therefore, at a quantitative level the RP is assumed to work as intended.
The TF sub mode will be covered in the next part of the chapter. But first the SA sub mode shall be studied. In Figure (26), (27),(38), (39), (50) and (51) it is possible to see the sun versors and the norm of the angular body rate during simulation. As given in the detailed designed document [5] the spacecraft will perform two rotations to find the sun. The study of this was done through the norm of the body rates and the behaviour is compared between the simulators.The comparison was also made to previous tests done in the AOCS test report [21]. From this it was possible to conclude that the behaviour of the SA body rates worked. An additional comparison was done to Imaging Mode (IMM), SA sub mode that the OCM SA is based upon [7]. From this it could be confirmed that the behaviour was as intended.
7 DISCUSSION
Orbital changes: To start this part of the discussion a table of the percentage error of the FVT and SVF compared to the FES in terms of COE and velocity changes are shown.
Table 8: Percentage difference between the COE and velocity changes for FVT and SVF with the FES as a reference
Simulator δa δe δv δi δΩ
FVT 0.12061% 0.10334% 0.09997% 0.09952% 0.09952% SVF 0.11936% 0.10450% 0.10011% 0.10181% 0.10047% As seen in Table (8) the percentage value of the error is not large between all the simulators. It is however on average larger for the SVF than FVT. But this is to be expected due to the SVF not running with the same conditions as the other two simulators. Where this percentage error also stems from is the small differences in attitude between the Matlab environment and the Eurosim environment due to small value differences between the simulators mentioned earlier. But in general the result that can be seen is good enough to verify that the functionality exists in all of the simulators and that they perform the orbital change as intended.
Therefore, after looking at orbital changes, sub mode functionality and the full functionality of each simulator. The simulators FVT and SVF can be pre-sumed to work as they are intended for the OCM. And therefore verifying the success in the objective of the thesis. However, there is still things to be done for the system and this is presented in the next section of the chapter.
7.3
Future work
There is still lots of potential work that can be made on the Avionic Test-Bench (ATB) for EagleEye. A summary of all the future work for the simulator are shown below.
• The final step for the OCM implementation is to integrate it to the RTB and simulate the system with hardware-in-the-loop. This means running the on-board simulation software on a Leon processor in the ATB lab • There is currently an activity that is being performed to introduce PUS
• Future efforts can be put to get a one-to-one relationship between the Eurosim environment and the Matlab environment to ensure that the simulators relate properly.
• The SVF suffers some errors, which means that some functionality does not work as intended in the SVF operational behaviour. Therefore, work needs to be done to isolate and solve this issue.
8 CONCLUSION
8
Conclusion
References
[1] F. Pace, Earth Observation Reference Mission - System Specification, September 2009.
[2] F. Pace and V. Barrena, Earth Observation Reference Mission - SW Spec-ification, April 2010.
[3] ESA, “Orbit description of sentinel2.” https://sentinel.esa.int/web/ sentinel/missions/sentinel-2/satellite-description/orbit (vis-ited Jun 2019).
[4] C. Valentini, Final report - AOCS FSW Autocoding Verification Process, 2018.
[5] A. Sebastian, AOCS SW for the EagleEye Mission - AOCS SW Detailed Design Document, 2005.
[6] S. U. Palm, ATB Consolidation - Central Software Requirements, June 2014.
[7] K. L. A. Wikman, Orbital Control Mode, EagleEye - Requirement, Design & Verification, January 2019.
[8] A. Ferrazzi, EagleARM - CSW V7 Architectual Design, June 2018. [9] P. Mendham and V. Bos, EagleEye Evolution Towards TSP - CSW
Archi-tectural Design, December 2013.
[10] V. Bos, P. Kauppinen, and P. Mendham, EagleEye Evolution Towards TSP - Final report, December 2013.
[11] A. Esquinas, J. Zamorano, J. A. D. L. Puentem, M. Masmano, and A. Cre-spo, “Time and space partition platform for safe and secure space flight software,” In Data Systems in Aerospace–DASIA, 2012.
[12] A. Bergmann, “Benefits and drawbacks of model-based design,” KMUTNB INT J Appl Sci Technol, vol. 7, pp. 15–19, September 2014.
[13] E. Secretariat, Space Engineering - Satellite Attitude and Orbital Control Systems (AOCS) requirements, ECSS-E-ST-60-30C, August 2013.
[14] A. Defence and Space, EuroSim Mk6.6 - Software User’s Manual.
[15] E. Secretariat, Space Engineering - System Modelling and Simulation, ECSS-E-TM-10-21A, April 2016.
[16] D. A. Vallado, Fundementals of Astrodynamics and Applications - Fourth Edition. Microcosm Perss, 2013.
REFERENCES
[18] R. M. Greenwich. https://www.rmg.co.uk/discover/explore/ prime-meridian-greenwich, July 2019.
[19] M. J. Sidi, Spacecraf Dynamics & Control - A practical engineering ap-proach. Cambridge University Press, 1997.
[20] W.F.Lammen, MOSAIC 12.0: User Manual, December 2017.
[21] A.Sebasti`an and C. Venegas, AOCS SW For the EagleEye Mission - AOCS SW Test Report, 2005.
[22] E. Secretariat, Space Engineering - Telemetry and Telecommand Packet Utilization, ECSS-E-ST-70-41C, April 2016.
[23] P. Hougaard, Virtual Spacecraft Reference Facility EagleEye Onboard Pa-rameter Specification, February 2011.
[24] I. Gomes, P. Morgado, T. Gomes, and R. Moreira, An Overview on the Static Analysis Approach in Software Development, 2009.
Appendicies
A
Additional results for simulators
This section of the appendix covers the extra information acquired during the testing of the system.
A.1 FES Tests
This part shows additional graphs produced during the tests of the Functional Engineering Simulator (FES).
Test Case 3 - Inclination change
The figures shown in the result chapter were also created for the other tests. The first graphs below shows the nadir pointing sub mode values for Test 3.
APPENDICES
Figure 56: Spacecraft nadir pointing attitude during second nadir pointing manoeuvre
Figure 58: Sun versor during sun acquisition, FES
Figure 59: The norm of the body rates during sun acquisition, FES These graphs acts as additional information if needed for the result chapter. They cover similar information but under different test conditions.
Test Case 4 - RAAN change
APPENDICES
Figure 60: Spacecraft nadir pointing attitude during first nadir pointing manoeuvre
Figure 62: Spacecraft attitude during slew pointing manoeuvre, FES As with Test 3 the commanded angle was the same. The final two plots show the sun versor and the body rate norm of the spacecraft.
APPENDICES
Figure 64: The norm of the body rates during sun acquisition, FES This ends the result figures acquired for the FES. The following section will provide similar graphs for the Functional Validation Test-Bench (FVT). A.2 FVT Tests
This subsection provides additional graphs to study the sub mode functionality of the FVT.
Test Case 3 - Inclination change
Figure 65: Spacecraft nadir pointing attitude during first nadir pointing manoeuvre, FVT
Figure 66: Spacecraft nadir pointing attitude during second nadir pointing manoeuvre, FVT
APPENDICES
Figure 69: The norm of the body rates during sun acquisition, FVT For the sun versor plot the focus should be on the z-axis converging to -1. And for the norm the objective should be to look at the rotation behaviour and compare it to other tests and [21]. The next subsection looks at Test 4 for the FVT.
Test Case 4 - RAAN change
APPENDICES
Figure 70: Spacecraft nadir pointing attitude during first nadir pointing manoeuvre, FVT
Figure 72: Spacecraft attitude during slew pointing manoeuvre, FVT The purpose of this test is to see that it goes to the commanded value described in the method chapter. The next plots looks at the sun versor and length of the body rate during SA.
APPENDICES
Figure 74: The norm of the body rates during sun acquisition, FVT This concludes the test figures for the FVT. To get an appreciation of if the results are good or not one should look at [7] and previous results.
A.3 SVF Tests
This section looks at the extra results collected for test 3 and 4 sub mode functionality for the Software Validation Facility (SVF). The first subsection looks at the inclination change test.
Test Case 3 - Inclination change
Figure 75: Spacecraft nadir pointing attitude during first nadir pointing manoeuvre, SVF
Figure 76: Spacecraft nadir pointing attitude during second nadir pointing manoeuvre, SVF
APPENDICES
Figure 79: The norm of the body rates during sun acquisition, SVF These two graphs are used to validate the SA sub mode functionality. How they should operate is described in [5]. The next subsection looks at Test 4. Test Case 4 - RAAN change
As previously the first two plots show the NP sub mode functionality.
APPENDICES
Figure 81: Spacecraft nadir pointing attitude during second nadir pointing manoeuvre, SVF
Figure 83: Sun versor during sun acquisition, SVF
Figure 84: The norm of the body rates during sun acquisition, SVF One thing to mention for Figure (83) is that it differs with the other sim-ulator behaviours for Test 4. This can be explained through the difference in positioning between the SVF and the other simulators. But functionality wise it performs its task and the x-axis and y-axis is just mirrored with the other Test 4 results.
APPENDICES
B
Bus definitions
This section covers the bus definitions mentioned in the method chapter. Before looking at the tables the following definitions need to be made.
• GPS, Global Positioning System • GYR, Gyroscope
• MGM, Magnetometer • SAS, Sun Acqusition Sensor • STR, Star-Tracker
• MTB, Magnetic Torque Bar • RWA, Reaction Wheel • THR, Thruster
• EKF, Extendend Kalman Filter
Now when the abbreviations have been shown the first system can be shown. The table below shows the bus signals for the ground station block.
Table 9: Bus definition of the Ground station block from Simulink In/Out Name Dimension Description
Out TC Mode 1x1 AOCS mode change value
Out TC IMM
Time
1x10 Time vector for IMM TC
Out TC IMM
Roll
1x10 Roll vector for IMM TC
Out TC IMM
Pitch
1x10 Pitch vector for IMM TC
Out TC GPS1
STS
1x1 Status value for GPS1
Out TC GPS2
STS
1x1 Status value for GPS2
Out TC GYR1
STS
Out TC SAS1 STS
1x1 Status value for SAS1
Out TC SAS2
STS
1x1 Status value for SAS2
Out TC STR1
STS
1x1 Status value for STR1
Out TC STR2
STS
1x1 Status value for STR2
Out TC STR3
STS
1x1 Status value for STR3
Out TC MTB1
STS
1x3 Status value for MTB1
Out TC MTB2
STS
1x3 Status value for MTB2
Out TC RWA
STS
1x4 Status value for RWA
Out TC THR
STS
1x4 Status value for THR Out STR1 Track-Cmd 1x1 TC to enable STR track-ing Out STR2 Track-Cmd 1x1 TC to enable STR track-ing Out STR2 Track-Cmd 1x1 TC to enable STR track-ing Out STR1 Blind-CheckCmd
1x3 TC to enable star blind check
Out STR2 Blind-CheckCmd
1x3 TC to enable blind check Out STR3
Blind-CheckCmd
1x3 TC to enable star blind check
Out FDIR STS TC
1x1 Enable FDIR checks for TCs
Out FDIR STS Mode
1x1 Enable FDIR checks for current mode
Out FDIR STS Warning
1x1 Enable FDIR checks for warnings
APPENDICES
Out TC OCM
Time
1x4 Time vector for OCM TC
Out TC OCM
Yaw
1x4 Yaw vector for OCM TC
Out TC OCM
Pitch
1x4 Pitch vector for OCM TC
Out TC OCM
THR Time
1x1 Time TC for TF
Out TC OCM
THR Const
1x4 Which thrusters to fire
The next table to look at is the bus definition for the system management block.
Table 10: Bus definition of the System Management block from Simulink In/Out Name Dimension Description
In TC GPS1
STS
1x1 Status value for GPS1 TC
In TC GPS2
STS
1x1 Status value for GPS2 TC
In TC GYR1
STS
1x1 Status value for GYR1 TC
In TC GYR2
STS
1x1 Status value for GYR2 TC
In TC MGM1
STS
1x1 Status value for MGM1 TC
In TC MGM2
STS
1x1 Status value for MGM2 TC
In TC SAS1
STS
1x1 Status value for SAS1 TC
In TC SAS2
STS
1x1 Status value for SAS2 TC
In TC STR1
STS
1x1 Status value for STR1 TC
In TC STR2
STS
In TC THR STS
1x4 Status value for THR TC In TC Mode 1x1 AOCS mode change value
In FDIR STS
TC
1x1 Enable FDIR checks for TCs
In FDIR STS
Mode
1x1 Enable FDIR checks for current mode
In FDIR STS
Warning
1x1 Enable FDIR checks for warnings
In GPS Fail 1x2 Failure value for GPS In GYR Fail 1x2 Failure value for GYR In MGM Fail 1x2 Failure value for MGM In SAS Fail 1x2 Failure value for SAS In STR Fail 1x3 Failure value for STR In MTB Fail 1x2 Failure value for MTB In RWA Fail 1x4 Failure value for RWA In THR Fail 1x4 Failure value for THR In GPS1 STS 1x1 Current status value for
GPS1
In GPS2 STS 1x1 Current status value for GPS2
In GYR1 STS 1x1 Current status value for GYR1
In GYR2 STS 1x1 Current status value for GYR2
In MGM1 STS 1x1 Current status value for MGM1
In MGM2 STS 1x1 Current status value for MGM2
In SAS1 STS 1x1 Current status value for SAS1
In SAS2 STS 1x1 Current status value for SAS2
In STR1 STS 1x1 Current status value for STR1
In STR2 STS 1x1 Current status value for STR2
In STR3 STS 1x1 Current status value for STR3
In MTB1 STS 1x3 Current status value for MTB1
APPENDICES
In RWA STS 1x4 Current status value for RWA
In THR STS 1x4 Current status value for THR
In Submode 1x1 Current active submode In Warning 1x1 AOCS warning singal for
FDIR
Out IC GPS1
STS
1x1 Internal command for GPS1 status
Out IC GPS2
STS
1x1 Internal command for GPS2 status
Out IC GYR1
STS
1x1 Internal command for GYR1 status
Out IC GYR2
STS
1x1 Internal command for GYR2 status
Out IC MGM1
STS
1x1 Internal command for MGM1 status
Out IC MGM2
STS
1x1 Internal command for MGM2 status
Out IC SAS1
STS
1x1 Internal command for SAS1 status
Out IC SAS2
STS
1x1 Internal command for SAS2 status
Out IC STR1
STS
1x1 Internal command for STR1 status
Out IC STR2
STS
1x1 Internal command for STR2 status
Out IC STR3
STS
1x1 Internal command for STR3 status
Out IC MTB1
STS
1x3 Internal command for MTB1 status
Out IC MTB2
STS
1x3 Internal command for MTB2 status
Out IC RWA STS 1x4 Internal command for RWA status
Out RWA Choice 1x1 Nominal choice for RWA Out THR Choice 1x1 Nominal choice for THR Out IC Mode 1x1 Internal command for
AOCS mode
The final table to look at shows the bus definitions of the AOCS. Table 11: Bus definition of the AOCS block from Simulink In/Out Name Dimension Description
In GPS1 Posi-tion 1x3 Position measurement from GPS1 In GPS1 Veloc-ity 1x3 Velocity measurement from GPS1
In GPS1 Time 1x8 Time measurement from GPS1 In GPS2 Posi-tion 1x3 Position measurement from GPS2 In GPS2 Veloc-ity 1x3 Velocity measurement from GPS2
In GPS2 Time 1x8 Time measurement from GPS2
In GYR1 Rate 1x3 Body rate GYR1 In GYR2 Rate 1x3 Body rate GYR2 In MGM1 Mea-surement 1x3 Voltage for MGM1 In MGM2 Mea-surement 1x3 Voltage for MGM2 In SAS1 Cur-rents
1x3 Cell current for SAS1 In SAS2
Cur-rents
1x3 Cell current for SAS2
APPENDICES
In RWA
Tachometer
1x4 Reaction wheel assembly speed
In TC IIA Time 1x10 Time vector for IMM TC
In TC IIA
Pitch
1x10 Pitch vector for IMM TC In TC IIA Roll 1x10 Roll vector for IMM TC
In TC OCM
Time
1x4 Time vector for OCM TC
In TC OCM
Yaw
1x4 Yaw vector for OCM TC
In TC OCM
Pitch
1x4 Pitch vector for OCM TC
In TC OCM
THR Time
1x1 Time TC for TF
In TC OCM
THR Const
1x4 Which thrusters to fire In GPS Choice 1x1 Nominal choice for GPS In GYR Choice 1x1 Nominal choice for GYR
In MGM
Choice
1x1 Nominal choice for MGM In SAS Choice 1x1 Nominal choice for SAS In STR Choice 1x3 Nominal choice for STR In MTB Choice 1x1 Nominal choice for MTB In RWA Choice 1x1 Nominal choice for RWA In THR Choice 1x1 Nominal choice for THR In Mode
Com-mand
1x1 Internal command for AOCS mode Out GPS Posi-tion 1x3 GPS position in the AOCS Out GPS Veloc-ity
1x3 GPS velocity in the AOCS Out GPS Time 1x3 GPS Time in the AOCS Out GYR Rate 1x3 GYR body rate of
space-craft
Out MGM B 1x3 Magnetic field in space-craft frame
Out IGRF B 1x3 Magnetic field calculated using IGRF 2000
Out IIA ACE 1x3 Attitude control error Out IIA NAV Att 1x3 Attitude in IIA
Naviga-tion
Out Warning 1x1 Warning signal from AOCS
Out Submode 1x1 Current active sub mode Out MTB1 Amp 1x3 Magnetic torque bar 1
command
Out MTB2 Amp 1x3 Magnetic torque bar 2 command
Out RWA Torque 1x4 Reaction wheel command torque
Out THR Fire 1x4 Thruster fire command
APPENDICES
C
Models & Schedulers
This section covers some figures of the Matlab/Simulink model for the FES and the Eurosim scheduler.
C.1 Matlab/Simulink Model
The first figure to look at is the on-board computer. The model for the system looks as follows.
Figure 85: OBC for the FES
