Concept Phase - Revision history

Alok at 09:04, 26 September 2020

2020-09-26T09:04:32Z

Alok at 20:20, 25 September 2020

2020-09-25T20:20:10Z

Alok at 07:35, 23 September 2020

2020-09-23T07:35:37Z

Alok: /* Operational Modes */

2020-09-23T07:19:48Z

‎Operational Modes

Alok at 07:15, 23 September 2020

2020-09-23T07:15:42Z

Show changes

Alok at 13:56, 22 September 2020

2020-09-22T13:56:25Z

Alok at 13:53, 22 September 2020

2020-09-22T13:53:58Z

Alok: Created page with "''This article of the Satellite 101 Wiki has been contributed by Aniruddha Ranade, K T Prajwal Prathiksh, and Ritul Shinde, all of whom are members of the Student Satellite Pr..."

2020-09-22T13:40:55Z

Created page with "''This article of the Satellite 101 Wiki has been contributed by Aniruddha Ranade, K T Prajwal Prathiksh, and Ritul Shinde, all of whom are members of the Student Satellite Pr..."

New page

''This article of the Satellite 101 Wiki has been contributed by Aniruddha Ranade, K T Prajwal Prathiksh, and Ritul Shinde, all of whom are members of the Student Satellite Program of IIT Bombay.''

← Older revision		Revision as of 09:04, 26 September 2020
Line 123:		Line 123:
	\| style="text-align:center;" \|355.8 MHz		\| style="text-align:center;" \|355.8 MHz
	\|}		\|}
		+	----
		+	If you are done reading this page, you can go back to [[Starting a Student Satellite Project]].

@@ Line 1: / Line 1: @@
-''This article of the Satellite 101 Wiki has been contributed by Aniruddha Ranade, K T Prajwal Prathiksh, and Ritul Shinde, all of whom are members of the Student Satellite Program of IIT Bombay.''
 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. <br/> <br/>
 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.

@@ Line 10: / Line 10: @@
 *Realistic/ Relevant
 *Time-bound/ Timely <br/>
-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. <br/>
+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 [https://www.iaru.org/ 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. <br/>
-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. <br/> <br/>
+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 [[Various Tests performed on Integrated Satellite| 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. <br/> <br/>
 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
-[https://www.aero.iitb.ac.in/satelliteWiki/index.php/Transportation here] <br/> <br/>
+[[Transportation | here]] <br/> <br/>
 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. <br/>
 ==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:
-*[https://www.aero.iitb.ac.in/satelliteWiki/index.php/Payload_Subsystem  Payload Subsystem] <br/>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.
+*[[Payload Subsystem |  Payload Subsystem]] <br/>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.
-*[https://www.aero.iitb.ac.in/satelliteWiki/index.php/Mechanical_Subsystem Mechanical Subsystem] <br/> 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.
+*[[Mechanical Subsystem | Mechanical Subsystem]] <br/> 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.
-*[https://www.aero.iitb.ac.in/satelliteWiki/index.php/Electrical_Subsystem Electrical Subsystem] <br/> 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.
+*[[Electrical Subsystem | Electrical Subsystem]] <br/> 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.
-*[https://www.aero.iitb.ac.in/satelliteWiki/index.php/Attitude_Determination_and_Control_Subsystem Attitude Determination & Controls Subsystem] <br/> 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.
+*[[Attitude Determination and Control Subsystem | Attitude Determination & Controls Subsystem]] <br/> 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.
-*[https://www.aero.iitb.ac.in/satelliteWiki/index.php/Communications_Subsystem Communications Subsystem] <br/> The communications subsystem is responsible for establishing a link for information transfer between the satellite and the ground station.
+*[[Communications Subsystem | Communications Subsystem]] <br/> 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==
@@ Line 39: / Line 39: @@
 ==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.
-* [https://www.aero.iitb.ac.in/satelliteWiki/index.php/Introduction_to_Mechanical_Subsystem Requirements on and by Mechanical Subsystem]
+* [[Introduction to Mechanical Subsystem | Requirements on and by Mechanical Subsystem]]
-* [https://www.aero.iitb.ac.in/satelliteWiki/index.php/Introduction_to_Electrical_Subsystem Requirements on and by Electrical Subsystem]
+* [[Introduction to Electrical Subsystem | Requirements on and by Electrical Subsystem]]
-* [https://www.aero.iitb.ac.in/satelliteWiki/index.php/Interdependence_on_other_subsystems Requirements on and by Communication Subsystems]
+* [[Interdependence on other subsystems | Requirements on and by Communication Subsystems]]
-* [https://www.aero.iitb.ac.in/satelliteWiki/index.php/Requirements_on_ADCS_by_other_Subsystems Requirements on ADCS] & [https://www.aero.iitb.ac.in/satelliteWiki/index.php/Requirements_by_ADCS_on_other_Subsystems Requirements by ADCS]
+* [[Requirements on ADCS by other Subsystems | Requirements on ADCS]] & [[Requirements by ADCS on other Subsystems | 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==
@@ Line 72: / Line 72: @@
 *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 [https://www.aero.iitb.ac.in/satelliteWiki/index.php/Power_Distribution_and_Regulation#Power_distribution_in_different_modes here] <br/> <br/>
+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 [[Power_Distribution_and_Regulation#Power_distribution_in_different_modes | here]]. <br/> <br/>
 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.

@@ Line 72: / Line 72: @@
 *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 [[https://www.aero.iitb.ac.in/satelliteWiki/index.php/Power_Distribution_and_Regulation#Power_distribution_in_different_modes | here]]
+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 [https://www.aero.iitb.ac.in/satelliteWiki/index.php/Power_Distribution_and_Regulation#Power_distribution_in_different_modes here] <br/> <br/>
 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==
 {| class="wikitable"

← Older revision		Revision as of 13:56, 22 September 2020
Line 1:		Line 1:
	''This article of the Satellite 101 Wiki has been contributed by Aniruddha Ranade, K T Prajwal Prathiksh, and Ritul Shinde, all of whom are members of the Student Satellite Program of IIT Bombay.''		''This article of the Satellite 101 Wiki has been contributed by Aniruddha Ranade, K T Prajwal Prathiksh, and Ritul Shinde, all of whom are members of the Student Satellite Program of IIT Bombay.''
	----		----
		+	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.

← Older revision		Revision as of 13:53, 22 September 2020
Line 1:		Line 1:
	''This article of the Satellite 101 Wiki has been contributed by Aniruddha Ranade, K T Prajwal Prathiksh, and Ritul Shinde, all of whom are members of the Student Satellite Program of IIT Bombay.''		''This article of the Satellite 101 Wiki has been contributed by Aniruddha Ranade, K T Prajwal Prathiksh, and Ritul Shinde, all of whom are members of the Student Satellite Program of IIT Bombay.''
		+	----