Developing a set of requirements before you dive into CAD is not only good practice but necessary as you can’t determine whether your design will meet your needs if you haven’t defined them. Poor or vague requirements are also useless as they can make things difficult to define if your design is acceptable for solving the issue you have.
I have been defining the requirements for the Claymore 6p POD based on the QB50, pocketqube mechanical interface requirements, NASA GEVS and various ESA standards for materials and testing. Since there isn’t a pocketqube standard for testing I have been contacting various launch providers for qualification and the QB50 standards. While these defined standards have helped me there are some requirements I have had to define myself which can be difficult especially if you have to justify them.
When designing a system I have recently started to visualise how it will operate within it’s environment. I would develop an operations sequence where I would record each step of it’s procedures. I find it easier to produce rough sketches or diagrams of each step as it makes it easier for me to see what is going on in each scene. Then for each step I would identify what requirements the system will need to meet in order to be able to carry out a task. In addition I would also identify the key functions of the system which would allow it to meet those requirements.
For example I am designing an Earth observation pocketqube satellite and since I am a Motherwell fan I want to have my PQ taking pictures of the hallowed turf of Fir Park.
| Figure 1 Fir Park https://public.fotki.com/kerki/united-kingdome–ir-1/sco-motherwell-fir.html) |
The sequence of my PQ taking photos of the stadium can be as follows:
STEP 1: PQ leaves CLAYMORE POD
Requirements:My PQ (Green) leaves the POD along with another PQ’s.
- Must be able to separate itself from other PQ to avoid collisions
- Must have a delay of 30 seconds from deploying its mechanisms (antenna, wings etc) to avoid collisions.
Functions:
- Has it’s microswitches in the facing the door and other PQ to act as a separation spring.
- Has pre-programmed delay after the microswitches are decompressed.
STEP 2: Mechanisms actuate
Mechanisms must maintain position after release.Requirements:
- Mechanism release must not damage satellite.
Functions:
- Hinges have latch to hold mechanisms in place
- Mechanisms have dampeners to slow down the actuation.
Danger:
- Mechanism release causes PQ to tumble.
STEP 3: PQ detumbles and orientate itself
Requirements:
- Must have active ADCS system to detumble within 2 minutes.
- Must be able to identify its position around the Earth.
Functions:
- Has active ADCS with magnetorquers and reaction wheels to slow down spin.
- Has sun sensors, star tracker and can link up with the ground station to obtain co-ordinates?
STEP 4: PQ orientates its camera towards Motherwell as it is approaching Scotland.
Figure 2 Scotland from Space – Picture by Jeff Williams of NASA
Requirements:
- Must have pointing accuracy of 3 degrees.
- Must be able to point to a target on command
- Must be able to identify its position around the Earth.
- Must produce clear images of target.
Functions:
- Has calibrated reaction wheels for XYZ axis rotation.
- Has sun sensors, star tracker and can link up with the ground station to obtain co-ordinates.
- Can receive new commands and software updates from groundstation.
- Has high resolution camera.
STEP 5: PQ sends me the photo
Must be able to store data in case it doesn’t have line of sight with the ground station
Requirements:
- Must be able to downlink data at high rate.
- Must be able to identify its position around the Earth.
Functions:
- Has memory storage (SD card).
- Has antenna can downlink data.
- Has sun sensors, star tracker and can link up with the ground station to obtain co-ordinates.
- Can receive new commands and software updates from ground station.
There are some steps I would have missed out but I just wanted to make a very basic sequence of deploying from my POD and taking images of a target and down linking the data. It’s also good to have values to requirements instead of the vague ones I put in. You will notice some functions and requirements will carried over to other steps which may happen in your scenarios.
It’s really useful to map out every sequence (if possible) of your systems life time (installation, operation, disassembly, disposal etc) as these will help generate more useful requirements. This may be time consuming but the more time you spend at the early stages of developing a new system (whether it’s a deployer, pocketqube or other product) as it’s easier to fix things early on instead of trying to solve it when you are trying to ship it out. Also if you can map out how the system will carry out it’s tasks it will provide you a better understanding of the problem. This will lead to better designs and help you avoid the costly mistakes that will be time consuming and stressful to solve. In addition if you going to be faced with reviews this process can also assist you in justifying any requirements you have defined.
Follow me on twitter (@Spaceca27508118) to keep up to date on the developments of my Claymore pocketqube deployer.
wyrmengineering.com 