v1.0 - SEP Step 2 - Requirements Document

Added by Jeremy Wright about 12 years ago

I thought I'd get a discussion started on this. The three requirements that I've added are from the original wiki content, and I've tried to match them to the questions that they most likely fall under. Other questions will be pulled from the Initial Questions SEP document.

Q2. Who is this for?

  • Document the engine testing procedure from test stand setup, to running tests, and ending with stowing the test stand.

Q3. How will this be used?

  • Verify that we can measure the Estes motor performance data (thrust vs time for various motors as published here: http://estes.aptinet.com/images/page%2033.pdf)
  • Measure and record exhaust temperature of the Estes motors which means using a computer.

Replies (30)

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Jeremy Wright about 12 years ago

Here's my very rough draft of the requirements for the answered "Initial Questions". At this time there's an issue with question (4) that's still unresolved.

Answers to all questions can be found here

Q1. Why are we making this?

  • Must accommodate low power, commercially available amateur rocket motors sized A through E.
  • Must be mobile enough to enable live demonstrations as part of educational and outreach activities.

Q2. Who is this for?

  • Must be well documented so as to meet the needs of open source spaceflight designers who will design and build future test stands (at Mach 30 or elsewhere).
  • The documentation and procedures must be complete enough that Mach 30 operators, students and educators who want to bring rocket engineering into the classroom, and anyone else interested in how rockets are tested can learn how to use it.
  • The answer for Q2 above.

Q3. How will this be used?

  • Must be useful for the verification of Estes thrust vs time motor performance data .
  • Must be able to record exhaust temperature vs time of Estes motors and transport that data to a laptop computer.

Q5. What features does it need to have (later)?

  • I believe that requirements related to this question are beyond the scope of this document. However, future features are still useful as a guide to make sure that we don't design ourselves into a corner.

Q6. What are the legacy requirements?

  • Any desktop computer based control software should run on all three major PC platforms (MS Windows, Mac OS X, and Linux).
  • Must use standard connections to the computer running the control software (for example, USB, Ethernet, or similar connections).

Q7. Who's going to build this?

  • All design documentation must be open and complete enough so that ANYONE, without necessarily a technical education in rocketry, propulsion, or engineering, would be able to build and operate a Shepard test stand.

Q8. How many do we want to make?

  • The design must enable the completion of at least one operational test stand.
  • Whenever and wherever possible, considerations should be made so that this design can be used as a kit in the future.

Q9. What is the budget?

  • The cost of the first operational test stand must not exceed $200 excluding "consumables" and tools.

Q10. What is the timeline?

  • If at all possible, the test stand should be completed within 3 months of formal launch as an exercise of agile design.

Q11. What waste products will be produced by the manufacture and/or operation of this?

  • Disposal of the spent Estes motors should conform to all local, state, and federal guidelines.
  • Electronic waste items, including batteries and circuit boards, must also be disposed of according to all local, state, and federal guidelines.
  • If the frame of the test stand is damaged beyond repair during operation, proper disposal/recycling guidelines must be followed for the materials used in its construction.
  • Wherever possible, the design should make it as easy as possible to replace components which are consumable or relatively easy to damage.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by J. Simmons about 12 years ago

These are requirements are really coming along. I saw one part that looks like a typo to me. It is part of the answer to question 2.

  • The answer for Q2 above.

Jeremy, was this just a typo?

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Jeremy Wright about 12 years ago

I actually meant that I wanted to include the answer from the first post's Q2 in my own answers as-is. I modified the answers from Q3, which is why I didn't add an inclusion statement. I wondered at the time if I had made my intent clear enough, and obviously I hadn't. My goal was to create a comprehensive list of answers (minus Q4) in my second post.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by J. Simmons about 12 years ago

Gotcha. Plus it looks like more refinement happened while preparing the actual document for this material in the wiki.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Jeremy Wright about 12 years ago

That's correct. For the final edits that I made on the wiki I also did my best to incorporate what we had discussed in the Google+ hangout.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Greg Moran almost 12 years ago

Now that we have FINALLY come to an agreement on the safety guidelines, here's my first shot at creating a "strawman" (as J says) based on the Answer to question #4 (someone should go back and update the answer to question 4 where it references our safety guidelines https://opendesignengine.net/boards/4/topics/38).

Here are a few quick examples of how I interpret the safety requirements to be written.

Shepheard Test Stand Requirements (STSR):
  • STSR 10 - The design and operations of the Shepherd Test Stand (STS) shall be conducted in compliance with The National Association of Rocketry (NAR) Standards & Testing Committee Motor Testing Manual, Version 1.5, Effective Date: July 1, 2011, henceforth referred to as the NAR testing manual.
  • STSR 20 - In accordance with (IAW) NAR testing manual requirements specified in Section 8.5, the STS shall use a load cell calibrated with a NIST traceable weight standard.
  • STSR 30 - In accordance with (IAW) NAR testing manual requirements specified in Section 8.5, the STS shall use a data collection system where the least significant bit(LSB) has a value that is _ (less than 0.33% percent of the average thrust of the motor under test).

...

  • STSR xx - In accordance with (IAW) NAR testing manual requirements specified in Section 8.6, the STS shall measure the external casing temperature of the motor under test.

...

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Jeremy Wright almost 12 years ago

It seems like these example guidelines include quite a bit of text directly from the NAR testing manual. Are we bordering on having to get their permission to write our requirements this way?

RE: v1.0 - SEP Step 2 - Requirements Document - Added by J. Simmons almost 12 years ago

Jeremy Wright wrote:

It seems like these example guidelines include quite a bit of text directly from the NAR testing manual. Are we bordering on having to get their permission to write our requirements this way?

This is a good question. Looking over Greg's example requirements, I think we are ok because the parts that a lifted directly are the technical phrases ("measure external casing temperature") which there are limited ways to express (copyright is all about original expression of ideas, not the ideas themselves). And we are citing the source, so fair use comes into play. We may want to use quotes around the technical bits that are directly copied and include an end note to be on the safe side, but I think we are ok.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Jeremy Wright almost 12 years ago

STSR xx - In accordance with (IAW) NAR testing manual requirements specified in Section 8.6, the STS shall measure the external casing temperature of the motor under test.

I'm assuming that this is an example requirement for a future version of Shepard. Up to this point the only temperature measurement we've talked about has been exhaust. If I'm missing something please fill me in.

I've started a page for these requirements on the wiki. https://opendesignengine.net/projects/shepard-ts/wiki/Requirements_Document_v1_0

You'll notice the "Draft" marker at the top of the document, and this is still very much a living document that will change significantly over time. We can still discuss the changes that need to be made here, but I wanted to start capturing some of our more solidified requirements on the wiki.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Jeremy Wright almost 12 years ago

Here's where I see Greg's first 3 example requirements fitting into the requirements document . This doesn't count the quoting and footnoting to give the NAR proper credit (as suggested by J above).

STSR 10 - The design and operations of the Shepherd Test Stand (STS) shall be conducted in compliance with The National Association of Rocketry (NAR) Standards & Testing Committee Motor Testing Manual, Version 1.5, Effective Date: July 1, 2011, henceforth referred to as the NAR testing manual.

I would place this one under initial question 3 as-is, so the ID would become "STSR 3.1" and the other requirements associated with question 3 would be bumped down. See the requirements document above for an explanation of this numbering scheme.

STSR 20 - In accordance with (IAW) NAR testing manual requirements specified in Section 8.5, the STS shall use a load cell calibrated with an NIST traceable weight standard.

I would place this under question 3 as well, which would make it something like "STSR 3.4". The issue that I have with this requirement is one of potential cost. With a budget of $200, I'm wondering if an NIST traceable calibrated load cell will be too expensive. Should this requirement have a trap door clause so that if it causes the load cell to cost over a certain percentage of the project, the requirement no long applies?

STSR 30 - In accordance with (IAW) NAR testing manual requirements specified in Section 8.5, the STS shall use a data collection system where the least significant bit(LSB) has a value that is _ (less than 0.33% percent of the average thrust of the motor under test).

Again, under question 3 ("STSR 3.5"). Will the space that Greg left be filled in by finding 0.33% of the average thrust of an A size motor?

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Jeremy Wright almost 12 years ago

I've modified Greg's "STSR 20" and "STSR 30" examples and added them to the requirements document (STSR 4.6 and STSR 4.7).

The requirement to measure the casing temperature seems like more of a Shepard 2.0+ feature, so I'm thinking that needs to go under the "Version 2.0" or "Beyond Version 2.0" subsections in the requirements doc. All of the other items that I could find in the NAR motor testing manual seemed to be operational in nature. I'm going to go back through and rework the requirements document to match the language Greg has established in the examples, and then I'll take one last pass through the NAR testing manual looking for additional requirements. If I don't find any, and if there's no discussion on what's been done in the requirements document, I'll start working on the block diagram.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by J. Simmons almost 12 years ago

Jeremy,

I need to sit down and give one last detailed review, but on first pass these look great. I think this is a good adaptation of the process of answering the high level design questions into a requirements document. The one comment I do have is about the temperature measurement. I think I might have been the first one to suggest we measure the exhaust temperature based on a project I saw in a book I bought for Greg as a graduation gift. I mostly suggested this because I felt we should if at all possible include two channels of data collection in the test stand to ensure we had an architecture that supported multiple channels. Now that we have seen e NAR guidelines include case temperature, I would be in favor of making the exhaust temperature a future requirement and making the case temperature the second channel we collect data for in version 1.0.

I will sit down and do a full read through of the requirements document this weekend and post my questions, concerns, or approval by tomorrow.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by J. Simmons almost 12 years ago

Comments:

STSR 1.1 - I commented on the resources discussion that we may want to scope down the range of motors we support for this version to keep the motor mount simple. If we do decide to do that, we would need to adjust this requirement accordingly.

STSR 3.3 - I commented in another thread that I would support swapping out case temperature for exhaust temperature since the NAR testing procedure requires case temperature measurements. If we make this change, this is the requirement which would need to be updated to reflect that change.

STSR 4.4 - This is a duplicate of STSR 1.1 and is not needed.

STSR 4.5 - I would change the text to read "Keep an accurate timestamp for each data point collected during the test." This change eliminates the redundant mention of the motor characteristics to be measured.

Otherwise, I think this looks great. I think we are very close to locking the requirements in, and should be able to make the deadline in the proposed timeline.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Jeremy Wright almost 12 years ago

STSR 1.1 - I commented on the resources discussion that we may want to scope down the range of motors we support for this version to keep the motor mount simple. If we do decide to do that, we would need to adjust this requirement accordingly.

In the resources discussion you mentioned plugs/adapters to make D size motors work in an E size mount. Would it be possible to make plugs for the other size motors and run them all? How much would that complicate the build stage of the stand? It seems like a hackerspace could crank some out on a 3D printer. http://www.estesrockets.com/rockets/accessories/engine-mounting/302317-engine-adapters-standard-to-d

We would need to check to see if the Estes engine adapters will have to be modified in order to accommodate the casing temperature thermocouple.

STSR 3.3 - I commented in another thread that I would support swapping out case temperature for exhaust temperature since the NAR testing procedure requires case temperature measurements. If we make this change, this is the requirement which would need to be updated to reflect that change.

I also support this change. I'm hesitant to change it right now though since only two of us have weighed in on it (that I know of).

STSR 4.4 - This is a duplicate of STSR 1.1 and is not needed.

I deleted this and renumbered the rest of the requirements in that section.

STSR 4.5 - I would change the text to read "Keep an accurate timestamp for each data point collected during the test." This change eliminates the redundant mention of the motor characteristics to be measured.

Done.

Otherwise, I think this looks great. I think we are very close to locking the requirements in, and should be able to make the deadline in the proposed timeline.

Do you think any of the language needs to be changed to better match Greg's additions (STSR 4.5 and STSR 4.6), or is it fine the way it is?

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Jeremy Wright almost 12 years ago

I was looking through the NAR motor testing manual again and noticed 2 new potential requirements related to the thermocouple(s).

8.6.1 States that the thermocouple(s) must have a low thermal mass, and including the amplifier and readout system still be accurate to 10 degrees C. The thermal response also needs to be 5 seconds or less.

8.6.2 States that the thermocouples must make good contact with the motor casing in two places. The first is where the propellant and nozzle meet, and the second is 3/4 of the way down the motor casing as measured from the nozzle end.

Any thoughts?

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Jeremy Wright almost 12 years ago

I adjusted the language of the requirements wiki doc so that it more closely matches the NAR testing manual entries.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by J. Simmons almost 12 years ago

Jeremy Wright wrote:

STSR 1.1 - I commented on the resources discussion that we may want to scope down the range of motors we support for this version to keep the motor mount simple. If we do decide to do that, we would need to adjust this requirement accordingly.

In the resources discussion you mentioned plugs/adapters to make D size motors work in an E size mount. Would it be possible to make plugs for the other size motors and run them all? How much would that complicate the build stage of the stand? It seems like a hackerspace could crank some out on a 3D printer. http://www.estesrockets.com/rockets/accessories/engine-mounting/302317-engine-adapters-standard-to-d

We would need to check to see if the Estes engine adapters will have to be modified in order to accommodate the casing temperature thermocouple.

This is a great find. I'd be happy to leave the supported motor sizes at the stated "A-E" sizes and see if we can make something like this work. Then we can design the motor mount for D/E and if the adapters work we get all of the motor sizes, and if not, we still have a working test stand, just with a reduced set of motors it will work with. And for a version 1 design, that is far from a terrible outcome either way.

Do you think any of the language needs to be changed to better match Greg's additions (STSR 4.5 and STSR 4.6), or is it fine the way it is?

I am comfortable with this language (STSR 4.5 and STSR 4.6) the way it is, but let's make sure Greg is also comfortable with it, too.

I was looking through the NAR motor testing manual again and noticed 2 new potential requirements related to the thermocouple(s).

Nice catch. I think we need to add these if we switch the thermocouple from measuring thrust to measuring case temperature. Greg and Wilton, any thoughts on making this switch?

Finally, as far as I can tell, double checking the language for STSR 4.5 & 4.6, and deciding on which temperature we are going to measure look to be the last open issues on the requirements. Does that sound right?

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Greg Moran almost 12 years ago

Wow! Amazing job with translating the Q&A into requirements. I have 2 procedural thoughts.

1) There is a distinction between the Technical Requirements and the Project Requirements. If it's a technical requirement, you usually want to verify by testing (eg. Verify that the test stand can accommodate testing of Estes commercial motors A through E by actually running tests with each motor type). These technical requirements are usually traceable to a specific part of the system block diagram in the next ste p of the Systems Engineering process. That way you know you are designing the "right" system. Can we reorganize the Requirements wiki in this manner to separate the technical from the project requirements? I think it will make future design work much simpler to capture each requirement type separately. I'd recommend keeping the existing requirement numbering scheme, but simply reorganizing/reordering the list now.

2) I've been taught to make each technical requirement verifiable. That means that there should be some metric or process by which we can confirm that the requirement has been met. Usually this means taking ALL ambiguity out of the requirement language. Requirement STSR 4.6 and 6.1 are absolutely correct in this sense, but there are a few others that I am concerned about not having enough definition yet (eg. What do you mean by "easily set up and torn down" or "easily packaged for shipment" or "accurate time stamp for each data point"). When do we know that we've met these requirements? I think being more specific here would be appropriate.

Do you want me to take a shot at reorganizing and adding definition? Jeremy, you've make an awesome list here and I absolutely think we are on the right track for conducting Open Source Systems Engineering processes! These comments are really about the more sophisticated (read: Nit picky) aspects of Requirements Definition, so please understand that you've done a great job with the process so far. Congratz!

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Jeremy Wright almost 12 years ago

Do you want me to take a shot at reorganizing and adding definition?

I think that will be faster than the process of me making changes and then asking if that's what you had in mind (especially with a deadline a few days away). Making the requirements more verifiable is a smart move. Like you said, otherwise how do you know when you've met a requirement?

This is a great find. I'd be happy to leave the supported motor sizes at the stated "A-E" sizes and see if we can make something like this work. Then we can design the motor mount for D/E and if the adapters work we get all of the motor sizes, and if not, we still have a working test stand, just with a reduced set of motors it will work with. And for a version 1 design, that is far from a terrible outcome either way.

I do like the idea of designing the stand in that top down manner (D/E and using adapters for the rest). I'd like to see the stand cover the full range of motors if possible to make it useful to the largest group of people.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by J. Simmons almost 12 years ago

Ditto on wanting to support all size of motors, and ultimately, I think the test stand will cover all sizes. I was just commenting above that if we run out of time/money/etc on this iteration, getting D/E covered is a pretty good start and we can always take another swing at the motor mount in later version(s) to address this issue if needed.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by J. Simmons almost 12 years ago

Greg, I think this re-org was a good idea. I made some formatting changes just to make the document more parallel in physical layout. I also filled in the questions Greg had (mostly around data collection and thermal measurements), and added one or two more small things (like file formats for data collected).

Per discussion above, I have gone ahead and switched the temperature measurement to the case temperature (I needed to assume this to address some of Greg's performance questions). Obviously, this is non-binding until we all agree to the change.

One more thought for later, it looks like certain questions are tending to generate technical requirements vs project requirements. I wonder if we can reorganize the order of the initial questions to more easily break out the final requirements. We don't have to answer this now, it is just an observation to discuss when we have had some time to reflect on the requirements generation process.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by J. Simmons almost 12 years ago

One more formatting thing... do we need the "(IAW)" references through out the requirements? Or can we add that to the glossary (or maybe just drop this acronym)?

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Jeremy Wright almost 12 years ago

The requirements look good to me. It sounds like we won't be able to gel them for awhile yet, but I think the consensus is that we should be able to move on to the block diagram.

Here are a few notes about the doc.

1. I'm not sure 45 minutes will be enough time for one person to set up, but I don't have anything to back that up so I'd say 45 minutes is good until proven otherwise.

2. I would have no problem moving "IAW" to the glossary or just dropping it. The way it's being used now I don't think it's adding to the doc's clarity.

3. I added a few footnote references back in that looked like they got lost in the reordering process.

4. I made a couple of grammar corrections including a sic.

5. Do we need to add a definition for "consumables" to the glossary? Most people reading the requirements in the future aren't going to know what that term means.

6. I noticed that the draft date had been taken off of the top of the document. Are we not going to keep draft, gelled, and frozen dates on the docs?

RE: v1.0 - SEP Step 2 - Requirements Document - Added by J. Simmons almost 12 years ago

Jeremy Wright wrote:

The requirements look good to me. It sounds like we won't be able to gel them for awhile yet, but I think the consensus is that we should be able to move on to the block diagram.

Ditto. Though, I would still like to hear from Wilton and Greg on the change from measuring exhaust temp to case temp.

Here are a few notes about the doc.

1. I'm not sure 45 minutes will be enough time for one person to set up, but I don't have anything to back that up so I'd say 45 minutes is good until proven otherwise.

Based on setup and tear down time of model rocket launches, I think this is a pretty good first estimate. I would not want to consider the STS a failure if we needed more time though.

2. I would have no problem moving "IAW" to the glossary or just dropping it. The way it's being used now I don't think it's adding to the doc's clarity.

I'll see of I can find some time to work on this change today or tomorrow.

3. I added a few footnote references back in that looked like they got lost in the reordering process.

4. I made a couple of grammar corrections including a sic.

Thanks and thanks!

5. Do we need to add a definition for "consumables" to the glossary? Most people reading the requirements in the future aren't going to know what that term means.

It wouldn't hurt (I am a fan of adding clarity, both for other users and for ourselves in 2 months time).

6. I noticed that the draft date had been taken off of the top of the document. Are we not going to keep draft, gelled, and frozen dates on the docs?

I removed the date stamp because I realized it was redundant information. The wiki system tracks the date, time, and user for each revision to the document, and it does so better than we do (we have to remember to manually update the date when we make "major revisions"). So, I think we do not want to keep "drafted" dates. I do think we need to keep gelled and frozen dates, but instead of just including the dates for these versions, I think we should also include the version number from the page history and link to it (here is an example url: https://opendesignengine.net/projects/shepard-ts/wiki/Requirements_Document_v1_0?version=34), that way users can jump straight to the version of the text that was gelled or frozen.

RE: v1.0 - SEP Step 2 - Requirements Document - Added by Jeremy Wright almost 12 years ago

2. I would have no problem moving "IAW" to the glossary or just dropping it. The way it's being used now I don't think it's adding to the doc's clarity.

I'll see of I can find some time to work on this change today or tomorrow.

I made the change IAW what we've been discussing. I'm not sure if it's what everyone will want though.

5. Do we need to add a definition for "consumables" to the glossary? Most people reading the requirements in the future aren't going to know what that term means.

It wouldn't hurt (I am a fan of adding clarity, both for other users and for ourselves in 2 months time).

Done.

I think we should also include the version number from the page history and link to it (here is an example url: https://opendesignengine.net/projects/shepard-ts/wiki/Requirements_Document_v1_0?version=34), that way users can jump straight to the version of the text that was gelled or frozen.

If you look at the bottom of the initial questions doc you'll see I've done this. There's the gelled date with a version designation at the end. That designation is also a link to the version of the page that was gelled.

1 2 Next » (1-25/30)