178
edits
Changes
no edit summary
*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 [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 [[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/>
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 | 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 | 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 | 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 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 | 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==
==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 [Introduction to Mechanical Subsystem | Requirements on and by Mechanical Subsystem]]* [https://www.aero.iitb.ac.in/satelliteWiki/index.php/Introduction_to_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 [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 by other Subsystems | Requirements on ADCS]] & [https://www.aero.iitb.ac.in/satelliteWiki/index.php/Requirements_by_ADCS_on_other_Subsystems [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==
*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/>
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.