Systems engineering for CubeSat projects
Systems engineering is a discipline extensively used in almost any space project. CubeSat projects, especially the educational ones are simpler in terms of organization, documentation and planning but even though they benefit from the use of systems engineering principles.
Even if adopting the Systems engineering (SE) approach may sound like an extra burden, reality shows that it pays off doing so. Space projects are one-off and even the simplest ones imply the work of many people, many months and significant amount of money. All these are good reasons to use a method that ensures efficiency, prevents errors and increases the chances of success.
The picture below show the evolution of mission fullfilment for Cubesats since 2000. Note how significant is the fraction of DOA (Dead on arrival) and Early loss. The good news is that it has improved over the years, in part for the adoption of an SE approach in the project development.
Even if some of the reasons for failure or mission incompleteness are technical, a system engineering approach can also help revealing them in time. Being Cubesat projects simpler they can also have a slimmed down SE approach, especially with regards to test and documentation.
Where to get started with systems engineering?
The good news is there are good and free (many) sources about SE for space projects:
- The excellent, go-to, NASA Systems Engineering Handbook.
- The ECSS (European Cooperation for Space Standardization) ECSS-E-ST-10C standard.
- The INCOSE (International Council on Systems Engineering) Systems Engineering Handbook.
Plus plenty of books, courses, etc. on the internet. But the first two ones should be enough for a Cubesat development team to implement a SE approach to their project.
Model-based, not document-based
Traditional project organization focuses on documents that build up where later issues are developed based on previous ones in a linear fashion. This scheme doesn’t fit well current space projects for, mainly, two reasons:
- The multidisciplinarity of teams involved, like mechanical, electrical, thermal, software, control, RF, etc. that makes communication difficult for the limited knowledge of each other field of expertise.
- The continuous and simultaneous evolution of all project aspect that every other team needs to be updated in the changed details affecting their work.
Model-based system engineering (MBSE) is an initiative of INCOSE and is becoming popular, although it may not be necessary for Cubesat projects. Most MBSE uses modeling languages like System Modeling Language (SysML) or Unified Modeling Language (UML).
Phases, Reviews and Documents
Any space project will work closely with the corresponding Space Agency, that can be NASA in the US, ESA in the EU, JAXA in Japan, ISRO in India, etc. Spaces agencies have their way to do things fruit of inherited and accumulated experience in space projects and developers must adapt to it.
In a nutshell, a space project has a number of phases where in each of them work is done in some aspect of the project, some documentation is created or updated and review meetings are done at the end of each phase to move to the next.
That is only the organization facet visible to the space agency. Besides that there will be other internal organization for business development, finance, marketing, etc. that goes beyond the scope of this article.
A bit of a problem is that even if similar, each agency has different names for the project phases, but at the end is just different names. Table below is from NASA SE Handbook where phases are named A to F.
Between phases there is a KDP (Key Decision Point) typically dependent on the outcome of a review from the documents created and results obtained in the current phase. A fairly complete picture is shown below. note that it applies to both manned and robotic spacecraft, in the case of cubesats just the ‘Robotic Mission Project Life Cycle’ applies and the number of reviews can be less or can be lighter.
The table above also includes the reviews acronyms, where not all of them may apply for a small project. In terms of documents, the table below can be used as a guideline showing which document is created or updated in each phase.
A few tips to create useful documents
Engineers tend to be bad at writing and it’s easy for documents not to be unambiguous or complete. A space project documentation is created for a specific purpose and each of them should be clear, complete and with no space for doubts or misinterpretation.
- Interface Control Document (ICD): Contain all the details related to the interaction of a subsystem to other subsystems. It can be subdivided into mechanical, electrical, thermal, optical, etc. ICD documents or divided in chapters. Good ICD writing style keep the communication between teams,
- Requirements: These are conditions for a subsystem that have to be met and therefore impose constraints to other subsystems. For a requirement to be clearly specified it must meet these conditions:
- Specific (what?). It must be clearly stated.
- Quantifiable (how much?) It has to be measurable. Wording like “good” or “best” cannot be used.
- Verifiable (how?). The method to measure the stated requirement is also to be specified.
- Feasible. It has to be technically possible and reasonable within the project schedule and budget.
- Indispensable. The need for the requirement is to be justified.
- Stakeholders. These are all the parties that take part in the project. Can be internal (directors, managers, team members) or external (customer, suppliers, regulatory agencies, space agencies, etc).
- Needs. These are the different stakeholders requirements to be fulfilled. Are very diverse, from economical to environmental or marketing. It is often difficult and subjective to translate different needs to a common metrics.
- Risk assessment. The classical likelihood – severity matrix helps in integrating the impact of problems into the economical and technical frames.
The V model at the heart of Systems engineering
The V model is the base of systems engineering. It is called so for being represented by a descending slope where design goes into finer detail and, from the bottom, where implementation is actually done, an ascending slope where integration tests, validation and verification happens.
There is a subtle difference between verification and validation:
- Verification: A test of a system to prove that it meets all its specified requirements at a particular stage of its development, “am I building the product right?“
- Validation: An activity that ensures that an end product stakeholder’s true needs and expectations are met, “am I building the right product?“
Validation tends to be more a final test and more useful, while verification tend to be interim tests to check that things are on the right track.
Summary
Systems engineering is a discipline in itself and almost a must for serious space projects, therefore with its learning curve that uses time and resources. A slimmed down version can succesfully be applied to simpler cubesat (and similar) projects, with a smaller burden and learning curve. Using systems engineering principles to cubesat projects will not only improve the chances of success by detecting potential errors in development but also improve communication and effectiveness within the team as well as with external stakeholders.
At Blue Marble Space Systems we use these principles not only internally to be more agile and effective but also to “speak the same language” with partners.
