Payload Design - Lecture Notes, Dispense di Ingegneria Aerospaziale

Scarica Payload Design - Lecture Notes e più Dispense in PDF di Ingegneria Aerospaziale solo su Docsity!

Payload Design

Prof. Mauro massari

A.Y. 2020/

Lecture Notes by Andrea Pizzetti

Payload Design Pagina 1

The Payload can be considered a space system. The very basic of designing a payload is pretty much the same of the design of any other system. A lot of the problems the payload is going to face are in common with them. Why a different course? Because in SMAD the focus is on the entire mission, more on the larger picture, while here we focus on the instrument. In this course we don't learn how to design a spacecraft, but how to design a space system, so it's more general. The s/c serves the payload, which is typically 1/3 of the entire spacecraft. The instrument is the driver for the design of the entire mission. The one shown in the following figures is the latest stage of the design, we are not going to have this design, but just a preliminary one. An example of an instrument is the multi-spectral imager in the Sentinel 2 spacecraft. This instrument can take images at different wavelengths, that may be separated by filters or detected via the use of instruments that are sensitive to particular wavelengths. The Sentinel 1 instrument is instead a 12 meters size radar antenna, that takes photos of the surface. When the antenna is moving over the target, we speak of synthetic antenna, while usually we have a physical antenna. This because the distance the SAR device travels over a target in the time taken for the radar pulses to return to the antenna creates a larger aperture than the physical one. As the SAR device on board the aircraft or spacecraft moves, the antenna location relative to the target changes with time. Signal processing of the successive recorded radar echoes allows the combining of the recordings from these multiple antenna positions. This process forms the synthetic antenna aperture and allows the creation of higher-resolution images than would otherwise be possible with a given physical antenna. Introduction martedì 23 febbraio 2021 10:

than in summer.

In the work of a space engineer 90% of the time is spent in documents and reports. This type of approach is followed by all agencies in the world. Space projects are usually realized with collaborations of more nations, from the launch to the design and the operation controls. A System is a bunch of components that works together to carry out a function. It can be distributed (a part in Earth and a part in space) or concentrated. The Project is the coordination of the systems and the management, so engineers and managers. Usually there are always present a system engineer and a project manager in every space project. Finally, the highest level is the Programme, the overall coordination of the activity. It involves also the interface with the funding partners, the users and the external companies. Each project can be broken down into Phases, temporally sequential. During each phase, in most of the cases at the end of each of them, Project Reviews are planned to perform critical examinations performed by the team. There are 4 basic models used to define the project life cycle:

• Waterfall or Sequential
• V-shaped
• Incremental
• Evolutionary

Waterfall Model

The waterfall model is based on a flow of activities from top to bottom in sequential phases. The starting point is given by the Customer needs and requirements and their translation into System requirements , to start the D esign of the components. For instance, if we are required to measure the thickness of the ice on the poles, we understand that we need specific instruments such as antenna and power amplifier and we can already start developing them. After designing all the components and the Component Development , we start putting them all together with the Integration and the Verification to check if they satisfy the requirements, from the components to the subsystems and finally the system. Once the system is ready, we need to carry out the Validation to check if it fulfil the mission objectives. It's important to consider that we are designing one single object as final output, this is the peculiarity of space system project cycles (unless we are designing a constellation of satellites). Moreover, it's a Project Life Cycle martedì 23 febbraio 2021 10:

This is useful because we can have an operative device in a relatively little time and add further components later on. This is also the case of constellations, the first bunch of satellites can already give us useful data. In this case and in the one of the ISS, we have goals that are too hard to reach in a single system. However, this model is characterized by the problem that in case of issues occurring in testing of later modules, we cannot solve them acting on the first ones, because these last are already operative.

Evolutionary Model

Finally, the evolutionary model is used for multi-generation instruments. When the first one has been designed and it' operative, the design is improved or corrected for the second generation according the output of the previous generation that enters as feedback. The model is composed of sequential V- shaped schemes: An example is the GPS system. Currently, we are at the third generation and the fourth is under development. This project cycle scheme is addressed for needs that are always present or for when the requirements are not well addressed and we need a basic version of the system to understand better which are the actual requirements.

which are the actual requirements.

Project Phases

Every project in Europe follows a documentation scheme given by the European Cooperation for Space Standardization (ECSS) rules. In this course we'll cover the pre-phase of design activities, called Phase 0. Then there are phase A, B and C where we only design. From phase D to E and F we respectively manufacture, use and dismiss the system. At the end of phase A, we have an idea of the requirements (PRR) and we can start some design proposals, which are reduced to 2 at the end of phase B, where we get a preliminary design and the requirements are frozen (PDR). At the end of phase C, also the architecture and the subsystems are chosen (CDR). We can start building the components and the system, which are also integrated and tested in phase D. The project life cycle terminates at the end of phase E, after the end of life of the device. Then we enter the de-commissioning phase F. Nowadays it's mandatory to have the device re- entry into the atmosphere before a maximum of 20 years.

The entire design process in phase 0 and A is to arrive to a list of preliminary requirements. To achieve this, a lot of design iterations must be carried out, starting from an high-level set of requirements and changing them by iterating the design. This is why we have superposition of definition activities during the requirements definition. After the end of phase A, a general list of requirements is obtained and in phase B we re-do the design from scratch, which can change a lot from the previous solutions which led to the requirements. At the end of phase B the requirements are frozen and the design solutions would be pretty similar to the final one, that's why we have a PDR. We don't have all the subsystems and components, which will be finalized in phase C, leading to the CDR. What are the differences with respect to NASA or the Department of Defence project phases? In USA what changes is the acceptance review, which is not a critical event. For the rest, the phases and the reviews are pretty much the same, even if they are called with different names. Regarding DoD, instead, we have military purposes projects, so maybe more than one device output. But for the very first phases, the approach for the requirements definition is the same. The reason why we have homogenous project planning and approaches for different agencies in the world is due to the ISS and the forced collaboration between them. In Europe we have companies called Large Space Integrators , which gets the contracts for design and production of the systems, such as Airbus, Thales, etc…. From the acceptance review to the end, the project is then property of ESA which operates the device with the operation centres. In USA, instead, the contracts are also for the launch and operation of the s/c. If NASA wants to launch its own s/c, they have JPL to design, build and manage it.

At the beginning we don't have nor the requirements nor the design. What comes first? The iterative study to this problem is called System Design Method and it's what is used in the phase 0/A. It's based on the exploration of all the possible options and configurations which may fulfil the high-level requirements (3, 4 sentences from the user). However, these designs are carried out with low details, it's impossible to design all the possible solutions in full details. The first thing is to get Baselines from the literature, based on the experience or on previous designs. Some performance parameters can increase the power and mass required by the system, while other programatic parameters or constraints can reduce them. The iterative design process stops when the best compromise is found. At the beginning we need to identify which non-tradable constraints are present, while play on sensitivity of the ones that can be changed. For instance, let's consider a mission for a satellite which has to measure the thickness of the ice on the poles. In this case the altitude of the orbit is a non-tradable constraint. Also the cost is another one in case of the design for a space telescope of 30-meter length to be put in the L2 point.

High Level Requirements

As previously said, the customer needs to give some sentences to be translated into the High-Level Requirements. Regarding the previous example, one of them is that the satellite shall look at the polar caps. Just this lead to different options for the orbit, a polar, a sun-synchronous, or an highly elliptical one. This is an example of a Technical Constraints. There will be also Design Drivers, which will tell us which solution is preferrable. Example of possible design drivers are the lowest mass, the lowest power, the highest accuracy. Once identified these two elements, we can start the Trade-off Analysis, to draft all the possible high-level solutions which respect the technical constraints and select between them according to the design drivers. System Design Method mercoledì 24 febbraio 2021 10:

them when passing to TRL 8. It's better to choose a technology of TRL 4 or 5, which is more risky but more promising in terms of mass and power reduction.

Trade-off Analysis

Usually what it's done is the partition of our system in subsystems, each one with a specific function or duty. The subsystem is not constrained to a specific amount of mass and components or to a specific volume into the s/c. We can have subsystems spread around all the architecture, such as the thermal control one. A team of engineers work all together to the system design and each one to his specific subsystem. In space system we want to exploit as much as possible all the interfaces between each subsystem to have the best compromise, instead of designing each one separately and then put all together. This because we have loops between consequent designs which repeats continuously, and each one influences another. The idea of Concurrent Engineering is to place all the engineers in a room and let them work together to find the best possible compromise. When a solution is decided, each one works on his subsystem and then the system is re-evaluated in the next meeting. After the trade-off processes we end up with a Baseline and a Back-up System. The first one is the solution which is better in paper but maybe more risky than the second one, which is indeed the backup plan. So maybe the first one uses technology at TRL 4, while the second one at TRL 7. The two solutions will likely be very similar.

Marginal Approach

In general during the development of the subsystems, the value of every early estimation of power, mass and cost is likely to increase due to several reasons. This creates a loop process in the design with repeating changes in the numbers without reaching convergence. The Marginal Approach does not consider sharp numbers in the computations, but imposes higher values of mass and power than what

consider sharp numbers in the computations, but imposes higher values of mass and power than what expected from the beginning to pre-consider these issues. For instance, we get to 1 kg of mass, but we assume to have 1.2 kg for the structural design. When, after the detailed design, we'll come out with a real mass of 1.1 kg, the structural analysis does not have to be repeated. The margin value is chosen depending on the TRL level. We go to the 20% margin for the lowest TRL to the 10% for the highest. The margin is applied to each subsystem but also again on the system itself, 20% for a new technology or 10% for a re-used system. These margins must always be present with Cubesats, when we cannot change launcher after found a final design which weights a lot more and so the prediction of increasing mass must be done from the start.

Technical Requirements

How do we define the technical requirements? We need to come up with a sentence that addresses at least 3 different key points: Each component has a survival temperature range. However, some detectors maybe works at temperature ranges different. So it's not right to put a general temperature range for the entire system. In the requirement we must add also the performance requirement of the instrument and how this requirement will be verified, according to the V-shape scheme.

Design Budgets

The list of mass and power requirements for each subsystem and component are the Design Budgets. This gives a picture on the overall design process. Preliminary budgets are mandatory for the start of the iteration process and are estimated from previous mission data. Where OBDH is the On-Board Data Handling, TT&C is Telemetry, Tracking and Command, ECLSS is Environmental Control and Life Support System.

The system engineering is the interdisciplinary approach governing the total technical effort required to transform a requirement into a system solution. The System Engineer is responsible for the design of the overall system, not in all the details but for the coordination of all the subsystems. It's responsible for the functioning of the system as a whole and for the fulfilment and satisfaction of the customer needs. Its work is based on four pillars:

• Management of the project,
• Product Assurance
• Operations and Logistics
• Development and Production The system engineer should know all these aspects:
• how the manufacturing is done, to interface with the production guy
• How to make sure that the product assurance activities could be performed correctly
• how the management is done, to interface with the budget people how the design is performed, to coordinate the people such as physicists or electronic engineers which works on the payload

how are all the connections between all the subsystems, to have the building blocks to construct the whole system

Moreover, in some cases the system engineer it's the only one person that can make improvements being able to consider simultaneously inputs and outputs of multiple subsystems, such as the thermal dissipation of the payload to be exploited in the thermal control system. The system engineers are responsible for all the budget definition (mass, power, link, cost, schedule, etc..) and check and correct them throughout all the project. The system engineer relies on the design drivers to guide himself. A typical list of activities which are performed by the system engineer are: System Engineers mercoledì 24 febbraio 2021 10:

change must be reported in the system documentation and all concerned parties must be notified.

The goal is to transform the customer needs in a list of requirements capturing them. At the end of the process we need a complete set of validated requirements. From the mission point of view, we typically want to highlight the concepts of operations to define and design the several modes. From the instrument point of view, we need the concepts of operations to define the survival intervals of the payload. The requirements can be subdivided in some more general categories:

• Functional
• Performance
• Interface
• Environment
• Reliability
• Safety Obviously, the most important are the Functional requirements. They are defined following this hint: From the functional requirements we can then write the Performance requirements assigned to each function: Every performance requirement should have a threshold value and a desired baseline value of Requirement Engineering martedì 2 marzo 2021 10: