Development Phase

From Satellite Wiki
Jump to: navigation, search

Prior to this phase, subsystems which make the system have been defined. Requirements and verification tests for the subsystems are laid down. Functions for each of the subsystems are identified and suitable concepts have been selected in order to achieve these functions. In the development phase, these concepts are further refined, specifically for the system to be designed. Details regarding the realization of the system have to be finalized, in this phase.

Flow Diagrams

One of the ways to refine the concepts is to represent the functions to be achieved in terms of flow diagrams. This is explained by the following example. The electrical subsystem is responsible to ensure the supply of power to the system. For this example, let’s assume that uninterrupted supply of 1 A current is needed at 5 V. Generation and regulation of power are functions which are to be met by the electrical subsystem. This can be represented using the following schematic:

Development Phase - 1.png

Note that the output from power regulation is passed on to relevant sections of the system. At the end of power regulation, 1 A current should be available at 5 V. This is the power of 5W. Let the power generation block give an output of yA at xV and this is to be converted to 1A at 5V by the power regulation block. Please note that, until this stage, we have not selected concepts for each of the blocks. Several concepts of power generation have been discussed here. Based on the analysis, let solar power be selected as a concept for the power generation. Solar power is harnessed by using solar panels. The amount of power generated will depend on the following factors:

  • Configuration of solar panels - number of cells in series and parallel on each panel and the interconnection between panels, if there are multiple panels.
  • Placement of solar panels on the satellite - the solar panels can be body mounted or deployed
  • The orbit of the satellite - the orbit for the mission dictates on the visibility of Sun throughout the orbit
  • The orientation of the satellite in the orbit - the power generated depends upon the angle of incidence between the Sunlight and the solar panel

Apart from this, there are several factors like the intensity of radiation, solar cell technology, etc which will affect the power generation. Note that throughout the orbit, uniform power generation may not be assured. Hence, there are is an additional function which needs to be achieved:

  • To supply power to power regulation block if power from solar panels is insufficient

This power cannot be generated out of nothing. One way to arrange for this is to store power when it is available in excess and release this power when solar power is insufficient. One of the ways to achieve this is by use of a battery. Typically, a dedicated circuitry is needed to handle the charging and discharging of the battery. This is represented as the “power storage management” in this updated schematic.

Development Phase - 2.png

The discussion on this example is paused at this point to share some insights on the process followed. While discussing this example, a schematic was created, keeping in mind only the power aspect. The subsystem was broken down to blocks. Concepts required to realise these blocks were understood in detail and requirements were further defined for these blocks. In the process, an updated schematic was also created. Such schematics can be developed for other subsystems as well. Each schematic is designed keeping in mind one or more perspectives, like the flow of power, the flow of data, based on mechanical interfaces etc. These schematics or representations are called system architecture. There could be more than one system architecture which meets the requirements. These alternatives are to be evaluated by further system analysis.

Let’s evaluate the starting point for the example as well. The requirement that 1A at 5V is to be supplied to the system is an estimate which is to be arrived at before all the components of the system have been finalized.

The physical realisation of the blocks follows. Some details about realisation, for example, solar panels, were fixed after an initial survey of available power generation technologies. However, the details of the solar panel configuration, placement on the satellite etc are to be finalized. The circuit required for power storage management can have multiple alternatives. At this point, it becomes clear that the design needs inputs from other subsystems. For example, the satellite structure - where and how will the solar panels be mounted. Note that at this point, the satellite structure is being developed simultaneously by the mechanical subsystem.

Note that each subsystem is interdependent and it is being designed simultaneously. At each stage, every subsystem will require some inputs from other subsystems and at the same time, it will be required to state requirements on other subsystems. Hence, periodic discussions between subsystem heads and the systems engineers are essential for these discussions. The subsystem heads should later pass on these discussions amongst the members in their subsystem. The design is developed over several iterations and consistent design is obtained at the end of it when it meets all the requirements. Optimization of the design, in the feasible design space, may be carried out.

Trade-offs and Constraints

Several trade-off studies need to be performed in the process. It may so happen that one of the designs, which meets all the requirements may have more data storage than required or it may generate more power than required for the operation of the system. The overdesign, in this case, contributes to excess margins of the system. One of the reasons for the overdesign could be the use of off-the-shelf components instead of custom-designed components. Also, redundancy may be introduced at some points in the system but this may bring additional complexity in the system. At times, a penalty may need to be paid for the overdesign. An example of this could be the monetary penalty to be paid due to added mass.

A typical system like a satellite will require power for its operation. Provisions for onboard data storage and its management have to be made. The mass of the system is also a crucial parameter as the launch cost is directly dependent on this. As the system is being developed and the implementation is yet to be finalized, several of these parameters will change, after every design iteration. In order to track these, tables known as system-level budgets are maintained.

  • Power Budget - This budget maintains a record of power generated and power consumed. Power lost in regulation may also be tabulated. Power consumed may be different based on the mode of operation of the system. The margin of excess power available can be evaluated from this budget. The budget can help evaluate alternative components or circuit designs on the basis of excess power margin made available.
  • Data Budget - This budget keeps a log of data being generated and its storage. Based on the mission, data will be generated onboard the satellite. The amount and rate of data generation play a role in selecting the appropriate processor along with the storage scheme to be followed.
  • Mass Budget - This budget tabulates the mass of every part of the system.
  • Link Budget - This budget is a set of calculations giving the feasibility and performance summary of a particular communication link from the transmitter to the receiver end.

System-level budgets are simple but powerful tools. The tools can be used to evaluate alternative design concepts. Estimates for several system parameters can be estimated and refined over several design iterations.

Integration Plan

While the details about the physical realization of subsystems are being fixed, the mechanical subsystem has to ensure that the structure of the system can accommodate these. The system is a collection of several parts, connected to each other. These connections are called interfaces. Either of the heat, force, torque, power, or data is exchanged across the interfaces. Once all parts of the system have been manufactured or procured, the system is assembled. This is known as system integration. While the structure of the system is being designed to accommodate changing requirements from subsystems, it is necessary to assess feasibility from the perspective of manufacturing and integration. Designs which may seem feasible on paper may be impractical. A configuration layout is a map of all parts of the system - indicating how all the parts have been interconnected. A document known as the Interface Control Document is maintained by the systems engineer. This document is an exhaustive list of all the interfaces of the system. Along with the list of interfaces, details regarding the nature of interface are also noted. An ID has to be assigned to each interface. Based on this, an integration sequence has to be developed. This is the sequence in which parts are to be assembled during the system integration. Along with a sequence for the integration, a sequence for disintegration also has to be prepared.

System Analysis Through Modelling

Techniques of modelling and simulations are widely used for system analysis. As a part of the analysis, an abstraction or representation for the following is developed. This process is termed as modelling. For the purpose of analysis, these models are subjected to certain experiments. These are termed as simulations.

  • A part of the system, for example, a magnetorquer. Magnetorquer is a commonly used actuator in satellites. Torque acts on the satellite when the Earth’s magnetic field interacts with the field generated by the current in the magnetorquer. The relationship between the current supplied to magnetorquers and the field generated by magnetorquer can be expressed by a mathematical relation. This is a physics-based model. Along with actuators, sensor-models are also developed. These models are used in the control system design and some details about the same are discussed here.
  • Verification of the controls system of a satellite is generally done by numerical methods, by running extensive simulations for different initial conditions on a model comprising the environment, satellite dynamics, estimation algorithm, sensors, controller and actuators. This has been discussed in some detail here.
  • The system as a whole can be modelled. For the analysis of satellite structure, a CAD model is developed and using a Finite Element Analysis (FEA) software, simulations are performed. More details, on the types of structural simulations, can be found here.

A variety of methods are followed, based on the entity being modelled; physics-based, FEM-based, data-based methods are some of them.

Developing models helps organize the available information and in the process, highlights areas where additional information is needed. Models increase understanding of the problem. They also serve as a tool for evaluation.

Since the system is not ready, a model is created and simulations are performed, to analyze the behaviour. It helps confirm the concept of operation. Even if an equivalent system exists, performing tests over a wide variety of conditions is typically costly and time-consuming. However, the behaviour of the system can be evaluated over a wide range of conditions, by performing simulations, at relatively less cost. Some variables of the system may not be accessible in the real system. Simulation can provide access to all variables and at the same time, the experiments could be conducted in controlled conditions for a better understanding of the system.

Models developed during the initial stages of design are typically simple - they may be statistics based through which experience is captured or based on simple physics, covering a few aspects. At this stage, it is possible to conduct some system-level studies. As the design gets developed, and concepts are fixed, highly refined modelling is possible, enabling the capturing of several aspects. However, system-level studies, using highly refined models may not be possible and at times, even unnecessary.

It is also important to understand certain pitfalls. The model only represents some aspects of reality. Models have some simplifications and their behaviour is limited by these. Accordingly, the accuracy of the simulations will also be limited.


During development, prototyping is a common approach. An entity exhibiting one or more aspects of the system is termed as a prototype. Some examples are:

  • A prototype could be of the entire system - For the practice of integration of the satellite, some or all parts of the satellite can be manufactured. Since this is for practice, instead of using real sensors and PCBs, dummy parts, with the same size and interfaces can be used.
  • A prototype could be of a part of the system - Final PCBs of the satellite may be quite complex - in terms of design as well as using them. While designing them, various sections of the PCB can be developed separately. This allows design, fabrication and testing of each section of the PCB to proceed in a parallel fashion.
  • A prototype could be to better understand and explore a part of the system - If a certain piece of electronic hardware is to be part of the system and the team is unfamiliar with it, for example, the GPS module, then making a prototype PCB to interface the GPS module, could help the team gain some experience. Feedback can be used to improve the design.

There may be a need to design and develop certain auxiliary systems which will be used for testing the parts of the system or in some cases, the system as a whole. Vibration shaker tables, thermal-vacuum chambers are examples of such auxiliary systems which have been developed over the years and used in the testing. These are typically not mission-specific. There may be a need to develop some system-specific auxiliary systems. For example, for the Pratham satellite, a checkout system was developed. This checkout system was used during the thermo-vac tests to log data from the satellite and to monitor the health of the system. This checkout system was developed specifically for the Pratham satellite.

Manufacturing Plan

During this phase, one should also come up with a manufacturing plan. It involves planning on how various components/parts will be manufactured. This would involve comparing different methods to manufacture a particular part. According to the requirements and the type of material, different methods are chosen for different parts. For e.g., Wire EDM (Electrical Discharge Machining) to fabricate parts which are made of non-conductive materials. Thus, it can be ruled out as a method for manufacturing non-conductive parts.

Testing Plan

A part, a subsystem or the system as a whole, are subjected to different tests. Tests verify whether the particular part in consideration can fulfill certain objectives when subjected to real or simulated conditions. Aspects like operability, supportability or performance capability are quantified through testing. Certain tests require sophisticated instruments and will require certain interfaces to be built-in the part so as to support testing. More about testing can be found here.

Risk Management

Before going forward with the production phase, risk management and analysis can be conducted. The motivation for this task is to get to know as many failure modes as possible. This will help in developing a robust system as well as to conduct a root cause study in case of any failure during testing or operation. This is started by making a functional block diagram where a breakdown of the system is done into subsystems and further to component levels. All possible failures are identified at the component level and its effect on the subsystem as well as system-level can be analyzed. Once the identification is done, we try to address most of the failures and also conduct a criticality study to prioritise amongst such measures. One of the methods to address failures is by adding hardware or logical redundancies into your system.

Payload Data Management

Planning of the development of payload data management systems is also an integral part of developing a satellite. This involves setting up a ground station (the reason to do so is given here and the infrastructure required to build one is given here) along with a plan for the management of any data downlinked by the satellite. Such data can include health monitoring data or sensor measurements. Planning how to analyze the data beforehand can streamline the whole process of finding faults or achieving the mission. For example, Pratham’s payload of collecting data on the total electron count required the team to create a map of the electron count over the city of Mumbai after the data had been collected.

If you are done reading this page, you can go back to Starting a Student Satellite Project.