¶ Introduction
¶ Purpose, Objective and Scope
This document is separated in to two sections, the test specification and the test procedure.
The test specification section defines the purpose of the test, the test approach, the item under test, test sequence, test facility, pass/fail criteria, required documentation, participants and test schedule.
The test report section gives directions for conducting a test activity in terms of description, resources, constraints and provides detailed step‐by‐step instructions for conducting test activities with the selected test facility and set‐up.
This document serves as a mid-semester review for the on-going semester project. It aims to define tests to meet some requirements set upon the acoustic levitator payload.
¶ Test Documentation
There are 3 main types of types of documents which relate to testing activities.
¶ AI&T
- High level overiew of testing activities
- Highlights dependancies in between types of tests
- Tracks the status of each type of test
- Document should be prepared as early as possible after PDR
¶ TSP
-
Test specification section explains:
- What part/assembly is being tested during each test.
- What characteristic is being tested.
- Brief description as to how the test is goind to be conducted.
- Explains the Pass/Fail criteria for each step.
- Explains when the test is due to happen and who will be involved in the test.
-
Document should be prepared after the baseline AI&T and ~1 month before the actual test.
-
Test procedure serves as a detailed plan for each individual test, it contains (among other things):
- A list of tools and instrument needed for the test.
- A description of the test location and condition.
- A step by step procedure of what needs to be done before, during and after the test.
-
Document should be prepared after the test specification and at least ~1 week before the actual test.
¶ TR
- The test report contains:
- The "as run procedure", meaning the procedure as planned ~1 week before the test with all of the comments and modiciations which were done the day of the test.
- The results of the test and all of the test data (or at least a link to the test data).
- If applicable, the analysis of the test data.
- The conclusion.
- The baseline document should be prepared the day of the test and the final version should be ready ~1 week after the test
¶ Definitions and Abbreviations
- ABV : Abbreviations
- ALE : Acoustic Levitation Experiment
- Standby mode : refering to the state machine design, mode during which the payload is ON but no experiment is being carried out yet (ie during rocket's horizontal assembly)
- Transition mode : (state machine) mode where the lifting of the rocket to a vertical position has been detected and the particle is lifted into it's final position using phase differences, after which active mode is on.
- Active mode : (state machine) mode when the experiment is actively ON, recording and logging with camera and sensors begins (particle is levitating)
¶ Applicable and Reference Documents
¶ Requirements to be verified
- 2024_C_SE_PL_ACOUSTIC_LEVITATION_EXPERIMENT_16 Autonomy
The payload power source shall have an autonomy of at least [8] hours (with the payload possibly running on 'standby mode' for most of that time).
- 2024_C_SE_PL_ACOUSTIC_LEVITATION_EXPERIMENT_10 Structure load case
The payload structure shall protect the experiment from radial accelerations of at least [3]g's. - 2024_C_SE_PL_ACOUSTIC_LEVITATION_EXPERIMENT_18 Experiment acceleration resistance
The payload experiment shall function when subjected to vertical accelerations of at least [8]g's. - 2024_C_SE_PL_ACOUSTIC_LEVITATION_EXPERIMENT_19 Experiment acceleration resistance
The payload experiment shall function when subjected to radial accelerations of at least [3]g's.
- 2024_C_SE_PL_ACOUSTIC_LEVITATION_EXPERIMENT_03 Data collection
The payload shall store and log all collected data on its own avionics. - 2024_C_SE_PL_ACOUSTIC_LEVITATION_EXPERIMENT_20 Experiment recording
The payload should include a small camera that can record the experiment. - 2024_C_SE_PL_ACOUSTIC_LEVITATION_EXPERIMENT_23 Experiment start
The experiment shall start with the rocket in a vertical position.
¶ Test Specification
¶ Open issue, Assumption and Constraint
Testing 2024_C_SE_PL_ACOUSTIC_LEVITATION_EXPERIMENT_9 (vertical structural resistance to accelerations up to 60g) is deemed un-testable with current means.
¶ Test Description
3 tests will be conducted to verify the requirements announced in the previous section. The payload design iteration under testing is still considered a prototype.
- Testing Objectives: verify experiment's correct starting procedure and state machine (software)
- Testing Methods: the payload will be placed horizontally to simulate the insertion into nose cone, then will be tilted to a vertical position at various rates to simulate the rocket being put in launch position by rail
- Test Environment: non-vital
- Test Data and Scenarios: Live accelerations log by the accelerometer combined with visual confirmation of successful levitation or fall.
- Testing Objectives: verify autonomy requirement of 8 hours.
- Testing Methods: the payload will be turned ON until battery depletion
- Test Environment: non-vital
- Test Data and Scenarios: During the test, a script will periodically log timestamps to then determine at what time power outtage happened. Scenario will be [5h of standby mode --> "transition mode" -> "active mode" until depletion], which should be an extreme scenario where the payload's state is "active mode" for over 3 hours.
- Testing Objectives: verify payload's resistance to accelerations
- Testing Methods: the payload will be axially and vertically shaken to reach desired 8 and 3 g limits (respectively)
- Test Environment: non-vital
- Test Data and Scenarios: Accelerations logged by the accelerometer. The scenario is the extreme case (up to requirement level)
¶ Test Sequence
Experiment start test must be conducted and payload must passed it before moving on to the Autonomy test, though Acceleration test is not constrained by the others.
¶ Pass/Fail Criteria
- PASS: particle lift during "transition mode" is clearly observed, stabilization in middle trapping node is clearly observed, correct recording and logging with camera and sensors is verified. State transitions happen when expected.
- FAIL: there is any deviation from the state machine's intended transitions.
- PASS: after 5 hours of "standby mode" and a "transition mode", payload exceeds 3 hours of "active mode" before depletion (lower bound of 99% CI is over 8 hours, computed over multiple tests to form sample).
- FAIL: 99% CI does not guarantee autonomy of over 8 hours in this worst case scenario (lower bound is under 8 hours).
- PASS: particle is still trapped in acoustic node and structure is intact after reaching required limit accelerations (8g axially, 3g radially).
- FAIL: particle escapes node for any accelerations equal or under 8g axially / 3g radially, or structure failure.
¶ Test Organisation
- Tests are conducted by Alexei Ermochkine.
- Time constraints: tests will be conducted once new sphere components are printed, ordered supersonic transducers are received and combined with spheres + power solution is received (by Nov 18th)
¶ Test Procedure
¶ Item Under Test
| Sub-System | Part Name/ID | Type of Part | Version ID |
|---|---|---|---|
| Payload | ALE | Prototype |
¶ Test Set-up
No set-up in particular required.
¶ Test Equipment Checklist
| Packed ? | Equipment | Packed in | Packed by |
|---|---|---|---|
| Laptop with VNC viewer | my bag  |
Alexei |
¶ Test Instrumentation Description
Since the only sensor data used will be from the accelerometer that's considered part of the payload, no external instrumentation is required for the 3 tests.
¶ Test Location and Conditions
Irrelevant.
¶ Participants
| Responsible for: | Name |
|---|---|
| Equipment Checklist, Data Gathering | Alexei |
| Safety | Alexei |
| Documenting/Reporting | Alexei |
| Preparing the test on-site | Alexei |
| Preparing the test on-site | Alexei |
¶ Test Safety
REMOVE THIS TEXT
SECTION DESCRIPTION TBD: Saftey concerns shall be tracked similarly to the risk assessment and mitigation. (Test Safety Assessment tables can be done on other application as long as a link/image is provided in this document).
REMOVE THIS TEXT
| Safety Concern | Probability | Impact | Severity | Mitigation | Post-Mitigation Probability | Post-Mitigation Impact | Post-Mitigation Severity | Corresponding Action Item | Action if safety Concern still occurs |
|---|---|---|---|---|---|---|---|---|---|
¶ Tasks and Step-by-Step Procedure
| Done ? | Task | Time |
|---|---|---|
| arm payload in horizontal position | - | |
| wait 5 minutes | - | |
| rotate payload to vertical | - | |
| wait 5 minutes | - |
| Done ? | Task | Time |
|---|---|---|
| arm payload in vertical position | - | |
| wait until battery depletion (8-10 hours) | - | |
| connect raspberry pi to power source and verify logs | - | |
| repeat n-times (sample size) | - |
| Done ? | Task | Time |
|---|---|---|
| arm payload with special script to print in live and log sensor values for acceleration | - | |
| shake payload along axial/radial directions to reach desired acceleration values | - |
¶ .
And then for each of your tasks (or at least the most complicated onces) you would have a step by step procedure, for example folding the parachute could be:
| Done ? | Step | Tool |
|---|---|---|
| Fold each gore in half and stack them until you have a triangular stack of gores | - | |
| Put the parachute on the ground and remove all of the air | - | |
| Measure out the right length to fold the parachute (using the deployment bag) | - | |
| Fold in Z until the parachute is a rectangular stack | - | |
| Remove all of the air | - | |
| Roll the parachute as tight as possible from side to side (the lines should be on a side, not at the top or the bottom) | - | |
| CHECK | - | |
| Place the shock cord which attaches the deployment bag to parachute in the bag first | - | |
| Place the parachute in the deployment bag | - | |
| Place the cords and cables in the parachute bag in the shape of a bird's nest | - | |
| CHECK | - |
Tracking the time each step took will help you to better plan your future tests (You do not HAVE to track the time it took for each step).
Feel free to make the checklist on another application as long as links/images are included in this document.
REMOVE THIS TEXT
¶ Before Test
¶ Tasks
| Done ? | Task | Time | Operator |
|---|---|---|---|
¶ Step-by-step procedure
| Done ? | Step | Tool |
|---|---|---|
| - | ||
| - | ||
| - |
¶ During Test
¶ Tasks
| Done ? | Task | Time | Operator |
|---|---|---|---|
¶ Step-by-step procedure
| Done ? | Step | Tool |
|---|---|---|
| - | ||
| - | ||
| - |
¶ After Test
¶ Tasks
| Done ? | Task | Time | Operator |
|---|---|---|---|
¶ Step-by-step procedure
| Done ? | Step | Tool |
|---|---|---|
| - | ||
| - | ||
| - |