“Space does not give you a second chance!”
- -Manvi Dhawan, Project Manager at the time of Pratham launch
Achieving the reliability and the robustness of a satellite is a significant challenge. This is where having a robust set of quality assurance practices comes into play. Quality Assurance (QA) quite simply put - are a set of practices followed to maintain the quality of a system.
Unlike the other subsystems of a student satellite, the task of enforcing quality assurance practices across all aspects of a system should not be supervised by a single subsystem or a group of people. Although organisations and space agencies across the globe have dedicated teams of people that deal solely with quality assurance practices for their respective missions, when it comes to a student team, however, such a setup would not be recommended. The reasons for which are enumerated below:
- Accountability: A designer would become complacent, knowing that the person-in-charge of QA would point out all flaws. Having a separate subsystem would inadvertently result in the shifting of accountability from the designer to the person-in-charge QA.
- Imbibing the mindset: QA should be an integral part of the thought process of all of the team members. Examining each other’s work, and questioning the rationale behind decisions amongst the members allows for people to improve system-level understanding and lead to a more refined decision.
- Effectiveness: By the time a person can reasonably understand a subsystem, she/he would have already spent two years and would be nearing their graduation. Such senior members will need to serve as subsystem heads and train recruits. However, having the senior members devote all their time on QA would not be effective either.
Thus, the model with QA as a separate subsystem does not seem appealing to be implemented in student satellite teams. Quality management and assurance need to be an integral part of the entire team’s working. Each person should be involved in QA-related activities at various levels across subsystems.
The spirit of QA is to be imbibed in the entire process of satellite design - starting from the selection of payload to the final retirement phase. Below listed are examples of QA practices that can be followed in each phase.
Selection of Payload Phase
The selection of payload phase involves the team deciding the payload - which is what the satellite would be tasked with doing when in space. The payload should be decided after a thorough review within the team members. Following which, the selected payload as well as a summary of the rejected payloads should be presented to someone more experienced in the relevant field, for a
review which is the standard practice.
All of the payloads that were pitched to the team should be documented using a standard template, which can prove to be invaluable in the future when the team has to work on such a phase again. Carefully selecting a suitable payload can take a significant period of time, which can be cut down massively by referring to previous documentation on payload analysis and selection.
This concept phase deals with coming up with the concept for the system. The design begins with understanding the need behind the design, understanding the set objectives and coming up with our expectations of the final product or prototype. The team would have to list down the requirements of the system and various subsystems. When doing so, an example of QA being followed in the requirement writing process would be to have all of the system’s requirements documented comprehensively. ID’s should be systematically assigned to these requirements so as to be able to trace the origin of a particular requirement, as well the entity on which it is being placed. The subsystems tasked with ensuring a given requirement is met also need to be explicitly defined in the requirement list in addition to having a precise definition of the requirement itself.
The possible methodologies to track and/or achieve the requirements should be also identified and documented. In case a non-conformance meeting needs to occur, the reason why the requirement was not met needs to be documented exhaustively, as well as the final decisions and the outcome of the meet. In such a scenario, having systematic requirement IDs would help in tracking all of the inter-dependent requirements that are affected.
The development phase deals with coming up with detailed concepts for realising the system.
When coming up with the design of a subsystem, QA plays an extremely important role. The phase involves making multiple decisions based on trade-offs.
Over the course of years, the reason for any such decision can get lost. This is where documentation in the form of regular updates, minutes of review meetings and design review documents come into play.
An exhaustive list of all the interfaces of the system, along with the details regarding the exact nature of the interface need to be noted systematically and categorised with IDs in the Interface Control Document (ICD) which would be reviewed by the concerned members. All of these practices in addition to maintaining the quality of the system, also help in passing down the knowledge gained by the team to future members ensuring that time is not wasted re-learning what was already known to the team members at one point.
Another effective method of relaying such information is through concise Skill Development Modules, which compile all the resources to learn a particular skill in one place, and can be completed within a fixed period of time, after which proficiency can be tested through a test at the end of the module.
The production phase involves manufacturing as well as sourcing of components in order to realize the system. Prototypes of the entire system or specific subsystems are built and subsequently may be iterated upon to address any flaws or the non-conformance of a requirement/s. Hence it is necessary to keep track of prototypes, Printed Circuit Boards (PCBs), mechanical parts, sensors, etc and document them comprehensively as well as their iterations. Reasons for the rejection/acceptance of a particular iteration need to be noted.
Components that are sourced from vendors or external agencies, would need to be scrutinized and tested appropriately by the team. The datasheets of such components would typically mention the tolerances and other relevant details of the component, which would need to be verified. For example, a PCB that is fabricated would need to be reviewed by members to ensure that all the connections are as specified and checking that the dimensions conform to the values supplied to the manufacturer, following which the electrical components will be soldered and the functioning is reviewed once again.
Utilization and Support Phase
In the case of satellites, this phase is the mission life of the satellite. It has to perform its basic life sustenance activities as well as payload activities for which the mission is designed. This phase mainly involves deliberation and documentation of any data (health monitoring or downlink) received from the satellite.
The retirement phase addresses the issue of retiring the satellite or extending its lifespan based on its performance. From the perspective of quality assurance, a thorough documentation of the learning from the completed mission must be done. Any unexpected events or the failure of an entity needs to be extensively documented, and if possible should be explained. This can save a lot of the team’s time in the long run. Trivial things that might have been forgotten the previous time around can be rectified quickly from the experience passed on in the team.
Breakdown of Activities
The thought process of QA should be imbibed in the entire team. The roles of various members in the team are divided in a hierarchy as shown below
- The project manager will be maintaining the various inventories and overseeing the activities being performed across subsystems. The proper transfer of the QA mindset to each next generation is also ensured by the project manager.
- The subsystem leaders will be overseeing the subsystem specific activities. Allocation of work to team members regarding the quality check, writing test cases and codes will also be done by subsystem leaders.
- Team members need to cooperate with each other for the whole QA system to run smoothly.
Subsystem-specific Quality Assurance Activities
Below given are some examples of Quality Assurance & Control practices to be followed that are specific to subsystems such as Mechanical, Controls and the Electrical & Communication Subsystem.
- A method to enforce version control on models made on SolidWorks, ANSYS, EAGLE, Simulink using a shared document to be made.
- Detailed flow-charts and/or pseudo-codes to be prepared and reviewed by the concerned members before writing of code.
- Standard nomenclature for different types of variables and functions to be followed for codes written by the Controls and Electrical subsystem.
- Version control (Eg: Git), and the practice of writing of test cases and test codes for a logical block of code to be followed along with the proper documentation.
- Codes written to be reviewed and checked by members to catch flaws/inconsistencies.
- A centralized repository consisting of all of the codes, and templates of documents/files to be created for the entire team.
- PCBs to be thoroughly checked and documented before and after fabrication by the Electrical and Communication subsystem
If you are done reading this page, you can go back to Starting a Student Satellite Project.