Concept Phase

In the following articles, SE activities to be performed in a particular phase are discussed. The concept phase is the first phase. Prior to this, the organization has already defined the mission and identified the stakeholders. The system and its surroundings are defined along with the interfaces between them. Objectives to be met by the system are set.

Based on the objectives set for the system, validation tests are chalked out. Validation tests are performed to check whether the system is able to meet the objectives set for it. Validation test for a CubeSat could include monitoring the in-orbit performance for the first couple of orbits. Several parameters like voltages, currents, temperatures, location, timestamp etc are typically logged. Observing these can help monitor in-orbit performance.

Requirements

Design for the system begins by identifying functions which need to be achieved. To photograph Earth, receive signals etc are some examples of functions which need to be achieved. These functions are derived from the objectives set of the system. At this stage, objectives are to be translated into quantifiable and unambiguous statements termed as requirements. A mnemonic SMART is often referred to while writing requirements. Well written requirements are SMART

• Specific
• Measurable
• Attainable/ Achievable/ Actionable/ Appropriate
• Realistic/ Relevant
• Time-bound/ Timely
  

Every requirement originates “from” an entity and is imposed “on” an entity. For example, the requirement to photograph Earth in a prescribed resolution is a requirement which originates from the “mission” on to the “system” being designed. Similarly, the requirement that the system to be launched should withstand the prescribed launch loads, exerted during launch, originate from the “launch vehicle” on the “system”. Another example could be a regulatory restriction from the IARU which prohibits RF transmissions at frequencies outside your allocated frequency band is a requirement from “IARU” on your “system”. Some requirements can arise and drive the design of the interface, one such example is of the SNAP (Remove Before Flight) of the satellite.
At the same time, along with requirements on the system, a verification test plan for the systems has to be chalked out. Verification tests are performed to check whether the system has been designed as per the requirements. For CubeSats, vibration and thermovac tests are examples of system-level verification tests. Discussion on these tests can be found here. Some requirements may arise from the testing methodology. For example, during thermovac testing, it is required to monitor the temperature of certain points inside the satellite, however, these may not be required later, during the operation of the satellite. These requirements have to be incorporated.

Another set of requirements may arise from the need for transportation of the system. For example, the satellite may be integrated at a cleanroom facility and then the satellite has to be transported to the launch site for integration of the satellite with the launch vehicle. Appropriate requirements, suitable for the mission, have to be generated. Some discussion on this can be found here

Once the requirements for the system are defined, writing functions becomes more meaningful. Functions like “to photograph Earth” become more specific “to photograph Earth with a resolution of ... ”. In the same way, “receive signal” changes to “receive signal at a given frequency and specific data rate”. Time needs to be invested in analysing the mission and arriving at these specific values.

Subsystem Breakdown

For complex interdisciplinary systems, it is beneficial to further breakdown the system into subsystems. This breakdown brings about managerial convenience. Typically, organizations have several team members with different skills sets and educational backgrounds. The teams within the organization are organized on the basis of skill set and educational backgrounds. It is of convenience to form subsystems such that these teams in the organization can work on the subsystems with little overlap between them. It should be noted that interdependence of the subsystems is unavoidable. While defining interfaces of the subsystems, it should be tried to minimise the complexity, minimise the interaction, minimise the integration efforts while trying to achieve ease in realisation or ease in testability. The interaction between the subsystems should be understood. One such organization of the system, for a satellite mission, can be into the subsystems can be as follows:

• Payload Subsystem
  The payload subsystem looks into the science of the payload, its working and implementation in the satellite. This subsystem has to have interacted with various subsystems for understanding their capabilities as well as know what all requirements it can set on the other subsystems to achieve the payload.
• Mechanical Subsystem
  The mechanical subsystem is responsible for designing and manufacturing the satellite structure while ensuring that the satellite can bear all the structural and thermal loads. It is responsible for the design of deployment mechanisms.
• Electrical Subsystem
  The electrical subsystem is responsible for generation, regulation and distribution of power and handles data storage, interface between various onboard peripherals, health monitoring and provides computation required for control of the satellite.
• Attitude Determination & Controls Subsystem
  The Attitude Determination and Control Subsystem (ADCS) is responsible for stabilizing the satellite in orbit and ensuring that it points in the direction it is supposed to point in.
• Communications Subsystem
  The communications subsystem is responsible for establishing a link for information transfer between the satellite and the ground station.

From the requirements defined for the system, requirements on the subsystem are derived. Some requirements will arise due to the interdependence of the subsystems. From these, the functions to be performed by each subsystem are defined.

Concept Generation

For achieving a particular function, a concept is to be selected. The concept is a sufficiently developed idea. Physical principles that govern the concept is well understood and it is expected that it will operate as anticipated. Examples of concepts for the function “to photograph Earth with a resolution of ... ” include imaging technologies like CMOS, CCD etc. Some concepts for a function could be completely novel. In such cases, understanding of physical principles behind the concept and insight behind operation will be limited. In such cases, time and resources have to be invested accordingly in developing this novel concept. It is typically advised that multiple concepts should be considered for every function before the selection of the final concept. Literature surveys, brainstorming, brainwriting, TRIZ etc can be used for concept generation. A suitable concept has to be selected from several concepts identified for each function. Selection can be qualitative or quantitative. Pugh matrix or decision matrix are quantitative approaches. Concepts are rated and ranked using the matrix. Combining the concepts can be considered as well. The readiness of the concept, expertise in the team, availability of the relevant resources to realise the function, time, and cost are some of the factors to be considered while concept selection. At this stage, consulting experts in the respective fields will be helpful. They can provide crucial insight into concepts.

At the same time, along with requirements on the subsystem, a test plan for each of these subsystems has to be chalked out. When the subsystem is realised and subjected to the battery of tests, it should be able to verify that the subsystem meets the requirements set for it.

An example is discussed to explain the points presented. The requirement to photograph Earth in a prescribed resolution, originating from “mission” on to the “system” translates to following:

• Payload subsystem is responsible for the design and development of the imaging instrumentation involved
• Electrical subsystem is responsible to provide
  • computation necessary process the generated images
  • data storage
• Communication subsystem is responsible to relay these images to the ground station
• Mechanical subsystem is responsible for designing the satellite structure. Some imaging sensors, impose additional thermal requirements
• ADCS is responsible to control and maintain the orientation of satellite within bounds so as to obtain a clear image

This list is not exhaustive. The example makes it clear that when requirements are broken down from system to subsystems, it shall give rise to several requirements which each subsystem has to meet along with some requirements imposed by subsystems on each other. One such example is the requirement imposed by the mechanical subsystem on other subsystems regarding the size and volume constraints which need to be followed. The requirements are dependent on the concept selected to achieve functionality. For example, CMOS and CCD imaging sensors impose different thermal requirements. Some requirements may arise from the testing methodology to be employed to evaluate the subsystems.

Non-Conformance of Requirement

In the case of non-conformance, that is, when a particular requirement cannot be met, then a meeting has to be held to discuss trade-offs and resolve the non-conformance. Typically, change of a single requirement could mean a change of several other requirements as well. It is necessary to maintain full traceability of all the requirements and the tests which are associated with them. Objectives set for the system give rise to requirements on the system which are further broken down to subsystem requirements. Verification tests at the subsystem and system level are associated with these requirements. Validation tests are associated with the objectives set for the mission. These associations should be clearly documented. This traceability clearly helps to highlight which part of the system needs to be re-evaluated when certain tests aren't cleared satisfactorily and also indicates which of the requirements aren't satisfied. Traceability helps while handling non-conformance discussions.

Examples of Requirements

For a satellite mission, the following pages have discussed requirements on and by the subsystems. Note that qualitative statements have been presented as these are enlisted for the purpose of discussion and are not derived for any particular mission. Also, the requirements listed here are not exhaustive.

• Requirements on and by Mechanical Subsystem
• Requirements on and by Electrical Subsystem
• Requirements on and by Communication Subsystems
• Requirements on ADCS & Requirements by ADCS

At several steps in this phase, orders of magnitude of the values are of interest. Referring to the literature on earlier missions can be of use. An initial assessment of feasibility can be done based on this. An example of this is the amount of power generated by solar panels on a 1U, 2U and 3U CubeSat can be referred to, from available literature of past missions in these form factors. For particular imaging instrumentation, if it requires more power than the 1U satellite can generate, then this would help eliminate the 1U form factor. In a real design problem, there are more such comparisons which are to be made, before selection. However, these kinds of decisions can be taken without detailed analysis at the initial stage. A detailed analysis is to be performed later, to ensure that the system as a whole, can function together and meet the requirements. Design in an iterative process and some changes may happen in the design after the detailed analysis is performed.

Operational Modes

The modes of operation for the system should be defined. Some of the modes are defined on the basis of the use-case of the system. Certain provisions are to be made in case of emergency situations as well. The modes are programmed and executed by the system’s software. Appropriate switching conditions, on the basis of which, the modes will be selected by the system, need to be defined. For example, for a satellite, whose mission is to deploy a solar sail and observe the orbital decay, we can define the mode of operation as follows:

Mode	Description
Pre-flight	This mode allows access to peripherals and microcontrollers on the satellite. Microcontrollers can be programmed only in this mode. This mode is used for testing and debugging of the satellite, before launch.
Launch	All the electronic systems are switched off. (This requirement is posed by the launch service provider)
Detumbling	After injection into the orbit, the satellite may be tumbling. In this mode, suitable control action is employed to reduce the angular rates.
Fine-Control	In this mode, the satellite employs fine attitude control, to track and maintain the desired orientation.
Solar Sail Deployment	In this mode, the satellite performs activities which are required for its mission of solar sail deployment.
Low Power	The satellite does not have enough power to sustain its typical operations. An appropriate procedure needs to be planned so as to manage this situation.

This list is not exhaustive nor sufficient, but there are some points which are to be noted from the example. Some modes of operation for the satellite are related to one of the subsystems. Detumbling and fine-control modes are related to the controls aspect of the satellite while low power mode is based on an emergency situation, related to the electrical aspect of the satellite. Solar sail deployment is a mode which is dictated by the mission. The payload subsystem will be responsible to define this in detail. The microcontrollers in the satellite will have to conduct some measurements and based on logic, select appropriate mode - measuring the voltage at appropriate points can indicate insufficient power and the decision to switch to low power mode can be taken. Following questions may arise and need to be answered while defining the modes and the logic for switching between them.

• What happens if there is insufficient power while we are in the detumbling phase?
• How will the orbital decay be measured?
• Will there be any change in communication with ground-station in both, detumbling phase and fine-control phase?

While discussing the modes and coming up with the logic for switching conditions, the understanding of the mission and the operation of the system becomes more clear and formal. It may generate some requirements - like the requirement to measure voltages to identify insufficient power. The process guides the development of the codes for the microcontrollers as well as the design of the circuits of the system. Further, the action to be taken by each subsystem, in different modes, also needs to be defined. A discussion on power distribution in different modes, followed for the Pratham satellite, can be found here.

At the end of this phase, the baseline design of the system should be ready. The baseline design of the system is ready when there is clarity on the subsystems in terms of the technology being used to achieve required functionalities and the sizing of these technologies. Along with these, the systems engineering documents on requirements, its traceability and test plans should be ready. A design review with experts can be conducted at this stage. For a satellite mission, the following table enlists some parameters of the design, which should be ready at this stage.

Example

Payload	Solar Sail Deployment Mechanism Technology Demonstration
Orbit	LEO
Launch Vehicle	PSLV
Mass	3 kg
Size	3U CubeSat
Deployer	P-Pod
Power Generated	8W
Control Law	Detumbling Mode: B - Dot
	Nominal Mode: B - Dot / LQR
Estimator	Multiplicative Extended Kalman Filter
Sensors	Gyroscope, Magnetometer
Actuators	Attitude Control: Magnetotorquers
Processors	ATMegaS128
Beacon	145.9 MHz
Downlink	435.7 MHz
Uplink	355.8 MHz

---

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