Trade studies in space systems engineering

This is a guest post published on behalf of Adithya Rajendran, Head of Engineering at Lux Aerobot.

Space system architectures are inherently complicated due to the various segments, stakeholders and subsystems involved. It has been proven that changes to the architecture later in the design lifecycle are costly to implement, so informed decisions must be made early in order to select an optimal system architecture.

Furthermore, there exists no standard for guiding the optimal architecting process of a small satellite, which results in a sub-optimal management of resources and risk. Agile missions, such as CubeSat projects undertaken at universities and space startups, are characterised by their use of COTS components to achieve low-cost and fast-delivery missions, with a minimal focus on optimising the architecture to improve reliability and mitigate development risk.

A trade study provides a framework for understanding the differences between alternative designs in a project and allows for “informed and upfront decisions” early in the design lifecycle. These alternatives can be evaluated in terms of Measures of Performance (MOPs) and system lifecycle costs.

The NASA Systems Engineering Handbook describes trade studies as one of the final stages of the system design process after the functional requirements have been composed and alternate architectures have been produced. It recommends the use of quantitative models in these trade studies that consider the entire mission lifecycle, as well as selection criteria that consider constraining factors such as cost, development time, risk and reliability.


Implementation of a quantitative trade model

As part of my Bachelor’s thesis I implemented a quantitative tradespace model to assess low-level system architectures. I then applied this to a real-world university project to generate tangible results in optimising a pseudo-satellite bus that I was architecting within the team.

This was carried out in the following four stages:


1. Identify key attributes and weights

In the first step, the key attributes used to score the system will be identified. They will then be ranked, and a weighting assigned to each with the sum of all weights equal to 1. It is crucial to note that all attributes must be quantifiable in some way to be used in this model.

Development time was a critical constraint on the project and was therefore ranked highest, as seen in the image below:


satsearch adithya guest post trade studies table 1


2. Determine threshold and objective values

In this step, threshold values for attributes are determined which are the bare minimum performances that an architecture needs to achieve, and objective values are the desirable performance levels. It can be seen that this step is valuable in defining the MOPs for the system:


satsearch adithya guest post trade studies table 2


3. Populate design alternatives and performance values

This step involves researching available alternatives for each design vector (i.e. OBC, communications and power) as seen in the image below. The satsearch platform would be instrumental to quickly find alternatives for any required satellite subsystem or category, with detailed datasheets easily available to extract relevant parameters for analysis within the trade study:


satsearch adithya guest post trade studies table 3


4. Calculate weighted scores and final rankings

This stage involves multiple calculation steps, detailed in my thesis, resulting in a ranked list of design alternatives based on a ‘value engineering’ equation which factors in critical criteria as well as individual weighted scores, referred to as Overall Measure of Effectiveness (‘OMOE).

Various value equations can be formulated to assess alternatives against different critical criteria, as shown in the table below. For example, some rankings are minimised with a desired low score, such as ‘Months/OMOE/Density’ while others are maximised with a desired high score such as ‘OMOE/$/Month’.


satsearch adithya guest post trade studies table 4


In summary, I have implemented a tool to bring the design rigour found in large engineering projects down to small and agile projects such as university CubeSats. If you would like to know more about my tradespace analysis tool, feel free to reach out to me via LinkedIn.