When testing your prototypes or sub systems of your satellite it is important to record what you did and what happened during the experiments. During the prototyping stage you will identify design flaws and issues during the tests. Sometimes the issues may not just be the design itself, it can also be the processes and testing methods which are also important to log. Once you identify the problems you can then work on developing solutions that will enable you to move from prototype to a flight model.

To help you with your prototyping you can download a free lessons learned document (link) which will be explained below:

The lessons learned document has the following sections:

• Part/Subassembly
• Action
• Issue/Findings
• Potential causes
• Root cause
• Lessons learned
• Date
• Continue, stop, finalised

Part/Subassembly

What are you testing? This can be parts in a satellite or even the subassemblies such as radio or ADCS system. You can have a document that just focusses on one subcomponent.

Action

List out what action you carried out, this can be powering up your magnetorquers or folding up your solar panel array to test the mechanism. Always record everything you do such as assembly setting the part up, the testing phase and resetting the system again as you may spot flaws in your design throughout these phases. Assembly is important because you may have had issues with fits or the mechanism not fitting properly, and you had to make minor changes by drilling holes or sawing features off. If you forget to record these issues you could end up repeating them as you didn’t make the changes.

Issue/Findings

Highlight the issues you found also treat this like an FMEA where you give each issue its own row as sometimes where you are testing something you will experience multiple problems. Also, sometimes you won’t experience any issues and things go well but you noticed something unexpected which could be it performed better than you anticipated. For you can hear your reaction wheels vibrate.

Potential causes

For each issue you want to brainstorm all the possible causes to an issue for example there were tolerancing issues in your reaction wheel where it wasn’t balanced, poor machining quality, poor fit tolerances in the motor shaft.

Root cause

After identifying potential causes to the issues you are experiencing, you can then find the root cause by carrying out an Ishikawa/fishbone analysis. Finding the root cause will help you find the solution to solve the issue.

You can also look to find the root cause to any findings that cause no problems to fully understand your design or to find areas of improvement.

Lessons learned

The lessons learned section focusses on how things can be improved or things that should be avoided in future to improve the performance or make the subsystem meet requirements. This can be design or testing method. You can leave this blank if no further action is required.

It is useful to reference the potential root causes you are going to test out in the future here.

Date

When the test was carried out.

Continue, stop, finalised

This is where you decide whether you should continue, or the issue is solved. The reasons for deciding to continue, stop or finalised are as follows:

• Continue: You have identified the root cause to the issue so you want to find out if your solution will work. Another reason could be you made a discovery in your system during an experiment and want to investigate it further.
• Stop: Whatever you are doing is leading to nowhere and doesn’t impact on the performance of your satellite or one of it’s subsystems. This can also be that you are going to scrap a component or function completely in your satellite.This is important to record also as the learning experience can be used in future projects or missions.
• Finalised: You have carried out an experiment and the system meets your mission requirements therefor no further work is required.