Preliminary design of a telecommunications satellites constellation - Pentium LLC Study case - Group 5 Angles Tristan Chanudet Cl ́ ement Falcou Samuel Hern ́ andez Casas Jos ́ e Mar ́ ıa Mauriello Tommaso Prost Maxence Semaine conception fonctionelle 2A - 2021/2022 Abstract The ever-growing commercial space sector promises to revolutionize life on Earth by provid- ing commercial services through space infrastructures. Satellite constellations are one example of such systems, and they are already providing communications services to people and organi- zation all around the globe. The purpose of this study is to provide an analysis of such a constellation including its ob- jectives, life-cycle and context, its functional design and architecture, its technical requirements and its means of verification and validation. The design process will be carried out according to the system engineering guidelines. Contents 1 Introduction 3 1.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 System analysis 3 2.1 Intended use of the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 System life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Operational phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Context analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4.1 External entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4.2 Kano’s model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 Functional design 8 3.1 External functional analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1 Nominal situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2 Incoming SC or debris situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Internal functional analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.1 Product Breakdown Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.2 Physical Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4 Preliminary TMTCS dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4 Verification and validation 18 4.1 Technical requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 Allocation matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5 Conclusions 28 1 Nomenclature Acronyms ACT Actuators ADCS Attitude Determination and Control Subystem AMP Amplifier ANT Antenna BAT Batteries CCSDS Consultative Committee for Space Data Systems CPIOM Core Processing Input/Output Module DS Data Storage ECSS European Cooperation for Space Stan- dardization ED Encoder/Decoder EEU External Environment of Use EM Electric Motors EPS Electronic Power Subsystem FT Fuel Tanks GS Ground Station HEA Heaters INS Insulation LEO Low Earth Orbit NVM Non-Volatile Memory OBDHS On Board Data Handling Subsystem PBD Physical Block Diagram PBS Physical Breakdown Structure PC Power Control PRO Processor PS Propulsion Subsystem PV Pipes Valves RAD Radiators S/C Spacecraft SEN Sensors SP Solar Panels SS Structure Subsystem STR Structure TBD To Be Defined TCS Thermal Control Subsystem THR Thrusters TMTCS Telemetry and Tracking Subsystem TRA Transceiver TRF Transformer 2 1 Introduction 1.1 Objectives Pentium LLC is a satellite operator broadcasting video content to users that lack a terrestrial connection and that would like to extend its business to provide voice communication and data services to a diverse set of customers in the government, maritime and aeronautical fields. The goal is to provide a system with 100% global pole-to-pole coverage, highly available, reliable and secure communications, extremely low latency to support many critical and operational applications, and flexibility of independence from regional terrestrial ground infrastructures. 2 System analysis 2.1 Intended use of the system Purpose : why does the system exist? To extend the Pentium LLC business, i.e. provide mobile communications to a diverse set of cus- tomers. Mission : what does it do? It provides mobile communications services to government, maritime and aeronautical customers by means of a LEO satellite constellation. Objectives : how does it do it? 1. It shall provide 100% global pole-to-pole coverage up to 13 km of altitude; 2. It shall consist of a LEO satellite constellation (77 sats, 7 orbital planes, near polar orbit); 3. The GS shall have a lifetime of at least 20 years; 4. The GS shall use a field of antennas to communicate with the visible satellite; 5. The GS shall have enough communication channels for voice conference; 6. The GS shall use 27.5GHz-30GHz bandwidth for the uplink; 7. The GS shall implement a tracking function; 8. The system shall provide highly available and reliable communications; 9. The system shall provide secure communications, independently from ground infrastructures; 10. The system should provide low latency communications. 2.2 System life cycle The identified phases for the system are: 1. Deployment - in which the following actions are performed: • Detachment of the satellites from the launch vehicle; • Obtaining of a stable attitude; • Eventual deployment of movable appendages (solar panels, antennae. . . ); • Connection with the mission control GS for telemetry data, health status check etc.; • Obtaining of the operational orbit (maneuvers or drifting phases may be required). 3 2. Operational phase - which consists of different grouping of modes (that will be analyzed more in detail later on): • Intersatellite communications; • Satellite to GS or to ground user communications; • Satellite to mission control GS communications. 3. Maintenance - this phase is intended to maintain the satellite constellation as a whole and the single satellites’ attitude and orbital position. It will consist of: • Orbital maneuvers; • Change of attitude maneuvers; • Drifting phases; • Satellite to mission control GS communications. 4. Decommissioning - this is the final phase of the mission: • Orbital maneuver to deorbit the S/C or to enter a graveyard orbit; • Fuel tanks emptying; • Sleep mode (in case of placement in graveyard orbit). The system as a whole is actually composed of the satellite constellation plus the dedicated ground station. Their installation, operation and dismissal shall also be considered in the system life cycle. 2.3 Operational phase Two main situations have been identified and studied for the operational phase (these and their modes and associated interactions have been illustrated in the Fig.1, where the blue boxes represent the modes, the violet ones the situations and the large green one the phase): • The nominal situation ; • The incoming SC or debris situation For the nominal situation the modes collaborating to the same overall purpose have been collected in three groupings: • Mission control communication: it allows the SC to exchange data with the mission control ground station in terms of telemetry, health status of the SC, risk identification, software updates, orbital and attitude maneuvers scheduling, SC software update; • Intersatellite communication: it allows the SC to exchange data with the other satellites in the constellation in order to forward the communication data (internet/voice calls). The data are relayed between multiple satellites until the satellite dedicated to communicate with the end user on the ground is reached; • Satellite to ground communication: it allows the SC to exchange data with the ground users in order to obtain or send the communication data (internet/voice calls). In case it’s not possible to establish a connection with the ground user (e.g. because of bad weather at receiver side): – If the end user is a GS than a connection with a new GS is attempted, and this new GS would then need to relay the data to the original end user by a terrestrial link; – If the end user is a ground user then the data are relayed to other satellites of the constel- lations which keep the information as long as a stable connection cannot be established, and then the data are relayed when possible. 4 Figure 1: Situations and modes in the operational phase. The incoming SC or debris situation is entered when the mission control GS detects a potential collision with an orbit SC or debris. In that case a collision avoidance maneuver mode is performed. When completed, the state of the collision risk is assessed again by the mission control GS. If no additional risk is detected, the nominal situation can be resumed. 5 2.4 Context analysis 2.4.1 External entities The following are the external entities that the system will need to interact with and that will be taken into account in the design process. The needs that most influence the stakeholders have also been taken into account and they are presented in the following table. Figure 2: Connections of the system with the external entities. Stakeholder Needs/interests Priority User Internet/communication access 9 Operators (ground) Ease to control and manage the constellation 4 Concurrence Concurrent offers 5 Authorities Comply with the regulations 10 Table 1: Stakeholders table 2.4.2 Kano’s model A Kano’s model study has been carried out to identify which types of system needs influence customer satisfaction and how. The following key parameters have been considered (with the associated functional and disfunctional forms of the questions): • Performance of internet access – If the system can assure a low latency communication, how do you feel? – If the system cannot assure low latency communication, how do you feel? 6 • Coverage – If the system is able to yield world coverage, how do you feel? – If the system is not able to yield world coverage, how do you feel? • Quality of voice conference – If the system can enable good quality communications, how do you feel? – If the system is not able to provide good quality communications, how do you feel? • Cost – If the system is cheap, how do you feel? – If the system is not cheap, how do you feel? The questions have been answered on a scale from 1 to 5: 1. I like it that way 2. It is the necessary minimum 3. I am neutral 4. I accept it that way 5. I dislike it that way The results of a small statistical study on the questions are presented in the following table and plot: System need A P F I R U Categ. Coeff.of satisf. Coeff. of dissatisf. Internet latency 50% 17% 16% 17% 0% 0% A 0.66 -0.32 Coverage 33% 0% 0% 67% 0% 0% I 0.33 0 Video quality 0% 67% 17% 16% 0% 0% P 0.67 -0.83 Cost 67% 0% 33% 0% 0% 0% A 0.67 -0.33 Table 2: Kano’s model results. Figure 3: Results of the Kano’s model study. 7 Hence we deduce that: • “Acceptable” disadvantage − → Coverage • “Irrelevant” advantages − → Internet latency and cost • Hold strategic advantages − → Quality of video conference Hence the design process shall not be too strict with respect to the expected performances in terms of internet latency and cost, and even a sub-global coverage could be accepted. However, efforts should be focused on assuring a high quality of voice conference since it is found to be a strategic advantage. 3 Functional design 3.1 External functional analysis A functional analysis of the system has been carried out; the different EEUs and the functions connecting them to the system have been identified. The functions are divided into two groups: • Principal Functions (PF) − → the reasons why the product exists and imply a relation between two EEUs; • Functions of Constraints (FC) − → imposed by the existence of the product and imply a relation between a EEU and the system. 3.1.1 Nominal situation Principal Functions: • PF1 : To allow the users to exchange data. • PF2 : To allow the users to exchange voice calls. • PF3 : To allow the users to access the internet. Functions of constraints: • FC1 : To resist the space environment. • FC2 : To maintain the operational orbital parameters and attitude of the satellites. • FC3 : To avoid collisions with other space objects. • FC4 : To be able to handle bad ground weather conditions. • FC5 : To have a source of energy. • FC6 : To comply with the regulations. These are represented in the octupus diagram in Fig.4. 3.1.2 Incoming SC or debris situation Principal Functions: • PF1 : To place the satellite on an orbit with no risk of collision with the incoming SC or debris. Functions of constraints: • FC1 : To enter an orbit which avoids other space objects. These are represented in the octupus diagram in Fig.5. 8 Figure 4: Octopus diagram for the functional analysis in the nominal situation. Figure 5: Octopus diagram for the functional analysis in the incoming SC or debris situation. 3.2 Internal functional analysis The following are the expected system functions for the nominal situation. Functions and subfunctions • PF1: Communicate – FT1 Communication between satellites ∗ FT1.1 Send data · FT1.1.1 Transmit information data · FT1.1.2 Encode signal · FT1.1.3 Amplify signal · FT1.1.4 Emit signal ∗ FT1.2 Receive data · FT1.2.1 Receive information data · FT1.2.2 Decode signal 9 · FT1.2.3 Amplify signal · FT1.2.4 Receive signal ∗ FT1.3.1 Store signal data ∗ FT1.3.2 Process Data – FT2 Satellite to ground communications ∗ FT2.1 Send data · FT2.1.1 Transmit information data · FT2.1.2 Encode signal · FT2.1.3 Amplify signal · FT2.1.4 Emit signal ∗ FT2.2 Receive data · FT2.2.1 Receive information data · FT2.2.2 Decode signal · FT2.2.3 Amplify signal · FT2.2.4 Receive signal ∗ FT2.3 Data processing · FT2.3.1 Store signal data · FT2.3.2 Process signal data ∗ FT2.4 GS communications · FT2.4.1 Power the GS antenna · FT2.4.2 Move the GS antenna • FC1: Resist the space environment – FT3 Maintain the nominal temperature ranges ∗ FT3.1 Withstand low temperatures ∗ FT3.2 Withstand high temperatures ∗ FT3.3 Isolate the SC from the environment – FT4 Resist mechanical loads • FC2: Maintain the operational orbital parameters and attitude – FT5 Execute orbital maneuvers ∗ FT5.1 Produce thrust ∗ FT5.2 Store fuel ∗ FT5.3 Transfer fuel between tanks and thruster – FT6 Maintain attitude ∗ FT6.1 Obtain attitude information ∗ FT6.2 Execute attitude maneuvers • FC3: Avoid orbital collisions – FT7 Execute orbital maneuvers · FT7.1 Produce thrust · FT7.2 Store fuel · FT7.3 Transfer fuel between tanks and thruster • FC4: To be able to handle bad ground weather conditions 10 – FT8 Maintain communication with the user ∗ FT8.1 Adapt frequency bandwidth ∗ FT8.2 Increase emitting power ∗ FT8.3 Change pointing target • FC5: To have a source of energy – FT9 Be energetically autonomous ∗ FT9.1 Produce electric power ∗ FT9.2 Store electric energy • FC6: Comply with the regulations – FT10 Use the CCSDS communication protocol. For the FC6 - Comply with the regulations only one subfunction has been considered as a notable example for the subsystem which drives the design (TMTCS). Clearly more regulations will need to be respected. Using the Core9 software the internal functions, whose relationships can be identified in the diagram in Fig.1, have been studied and analysed. The representation of these function is shown in the following images. The green items are either input or output of the subfunctions. These have been simulated and they provided adequate results, one of which (temporal evolution of the functions for the intersatellite communication) is shown in the last picture. Figure 6: eFFBD diagram for SC to mission control GS communication function. Figure 7: eFFBD diagram for intersatellite communications function. 11 Figure 8: eFFBD diagram for SC to ground communications function. Figure 9: Results of the simulation of the intersatellite communications function. 12 3.3 Architecture 3.3.1 Product Breakdown Structure Figure 10: PBS for the satellite. 13 Figure 11: PBS for the GS. 14 3.3.2 Physical Block Diagram Figure 12: PBD for the SC. The proposed system architecture is presented in the diagrams in this section. The single com- ponents have been grouped in subsystems as it is common practice in the design of space systems, and it has been tried to keep the system as simple as possible. Some components could use different technologies, e.g. the PS could either use chemical propulsion or electrical propulsion. The latter could be preferred as it allows a very low fuel consumption, hence it could enable a long operational life of the SC, even if the produced thrust is little. In fact only small levels of thrust will be needed for this mission scenario to perform orbital corrections and withstand orbital perturbations. Regarding the antenna technology, it is assumed that the TRL for the needed applications is high enough to make the architecture viable, as similar constellations are already operational (e.g. Starlink). 15 Figure 13: PBD for the GS. 3.4 Preliminary TMTCS dimensioning For a preliminary design of the TMTCS a standard information package according to the CCSDS communication protocol has been taken into account, which considers a data frame constituted of 56 bytes of control data and 1028 kbytes of payload. Assuming a 1s delay time for the on-board data processing (which is a really conservative overestimation) and a communication delay due to the speed of light over 800 km of distance (minimum distance between satellite and GS) we can compute a rough estimation of the data rate of: 56 + 1028 e 3 1 + 800 e 3 3 e 8 = 1 025 M byte/s (1) This estimation considers that only one information packet can be transmitted each time and that no other packet can be sent while the signal is traveling. So it doesn’t take into account the possibility of sending multiple packages in sequential order (in a time which is less than the free-space delay), nor the possible encoding techniques, nor the actual frequency of the link, but it allows to have an order of magnitude of the bit rate to be expected. In reality a much higher bit rate can be achieved, and common values for operating constellations (Starlink, TeleSat, OneWeb) are in the order of 10 Gbs [3]. The avionics subsystem consists of 3 CPIOMs. Inside CPIOM, the logbook is a NVM which allows to record useful information for maintenance. Each CPIOM is composed of one I/O function and one NVM function at least. All the functions of a CPIOM interact with the NVM function. Two possible avionic subsystem architectures are shown in the picture hereinafter. 16 Figure 14: The two potential architectures for the avionics subsystem. By computing their coupling quality parameter CQ we can compare the two options, as shown in the following table. CQ1 CQ2 CQ3 Average CQ Option A 2 2 - 4 28 = 6 7 4 6 - 4 36 = 5 9 6 10 - 4 20 = 2 5 571 945 = 0.6042 Option B 2 2 - 4 28 = 6 7 2 2 - 4 28 = 6 7 8 14 - 4 16 = 9 28 19 28 = 0.6786 Table 3: Coupling quality parameters. As could be expected, the second option has a higher score since it shows more internal cohesion and less external couplings (F1 is included in C3). Hence, option B is to be preferred. 17 4 Verification and validation 4.1 Technical requirements A preliminary analysis of the functional, operational and performance requirements has been carried out for the system under study, according to ECSS guidelines [2]. Nomenclature & Acronyms ID Format AA-Z-YY-XXX AA (Prject name) PC (Pentium Constellation) Z Requirement category YY System component XXX Requirement unique numbering in each category F Functional O Operational P Performance M Mission L Logistic INT Interface 18 Functional requirements − → What has to be done Req. ID Requirement Parent req. Importance & Motivation PC-F-TMTCS-010 The SC shall exchange data with the other SCs in the constellation. High - Enable an intersatellite for- warding of the data. PC-F-TMTCS-011 The SC shall exchange data with the Pentium ground user. High - Enable the data exchange through the constellation. PC-F-TMTCS-012 The SC shall exchange data with the Pentium ground stations. High - Enable the data exchange through the constellation. PC-F-PS-010 The SC shall be able to perform orbital maneuvers. High - Avoid potential in-orbit col- lisions. PC-F-M-010 The constellation should provide global coverage. Medium - Serve the most users. Not high importance as a result of the Kano’s modely study. PC-F-INT-010 The GS shall exchange data with the terrestrial internet network. High - Enable internet connection for the users served by the constel- lation. PC-F-L-010 The GS shall have a lifetime of at least 20 years. High - Design specification. PC-F-L-011 The GS shall have a field of an- tennas to communicate with visi- ble satellites. High - Design specification. PC-F-TMTCS-013 The GS shall have enough commu- nication channels for voice confer- ence. High - Design specification. PC-F-INT-011 The GS shall implement a tracking function. High - Design specification. PC-F-TMTCS-014 The GS shall use the 27.5 - 30 Ghz bandwidth for the uplink. High - Design specification. PC-F-TMTCS-015 The constellation shall provide highly available communications. High - Design specification. PC-F-TMTCS-016 The constellation shall provide re- liable communications. High - Design specification. 19