Use of the formal systems engineering process

Added by Greg Moran over 12 years ago

So that everyone is on the same page, this area discusses the process by which we will design, build and operate the Shepard test stand. According to a rigorous application of systems engineering methodology the steps of the process should include:
  1. requirements definition
  2. functional architecture development
  3. physical architecture development
  4. preliminary design
  5. detailed design
  6. procurement/manufacture
  7. assembly
  8. integration
  9. testing
  10. disposal

At this early stage of the project all effort should be made to AVOID making assumptions that are not given in the problem statement. IF assumptions are made they should be documented appropriately. Similarly, any mention of the technical solution should be avoided so as to not bias the end product. Let's step back from jumping into the parts discussion and technical solution for a bit so that we can finish the appropriate level of planning (believe me, I know this is VERY difficult for most engineers).


Replies (12)

RE: Use of the formal systems engineering process - Added by Ben Barnett over 12 years ago

OK. As you can see from my intro, I am generally disorganized. Around here the only part of my brain that is highly organized is in my wife's head :-)

I am probably worse than useless in steps 1 & 2. I may be able to contribute to step 3, but may not be useful until step 4. I will step back and watch what happens.

Ben

RE: Use of the formal systems engineering process - Added by J. Simmons over 12 years ago

Greg,

You and I started chatting about some of this briefly last night. After some reflection, I think there is one other level above the process to capture: the project values (which will mostly fall out of Mach 30's values). Just to note for posterity, I believe the role values play in an engineering process is to inform us as designers about how to make decisions when it comes to issues where more than one technical solution meets the requirements or when we are discussing processes.

Here are my proposed values for the project (in no particular order, yet):

  • Open Source - All of our work will be licensed openly, and where possible, we should favor components that are openly licensed over those that are closed. I believe there can be an exception for commodity components such as capacitors, resistors, wire, etc. One metric of how well we support this value will be if other people are able to build and use copies of the Shepard test stand from our documentation.
  • Mature Technology - I think this value points us to using existing sub-systems when possible, and using standard techniques in our designs when we must invent something. Doing so should support at least two of the values in FIST (fast and simple).
  • FIST
    • Fast - Let's face it, this project is not all that complicated compared to some things we could be working on. So, we want to make sure we do not spend too much time deliberating and loose build time. At the budget we have set, even a failure (that is being unable to record thrust and/or temperature profiles) will teach us lessons about the technology we chose. In support of this value, the proposed time budget is 3 months (starting basically now).
    • Inexpensive - We are limiting ourselves to $200 to focus our efforts on affordable solutions. This will hopefully support our value of open source, making it an affordable project for others to build.
    • Simple - This value promotes elegant designs and processes. Here is where I think the rubber meets the road in terms of applying the system engineering processes to the project. Could we for instance, define the requirements, and then have a melded step of architecture design and conceptual design? We would still come out with a kind of block diagram for the system before developing more detailed designs. I might also consider working in a more "test early, test often, then draw up the detailed design" approach instead of doing a full detailed design up front (kind of like what Armadillo Aerospace does in their development). And I think we will need to remember to apply this value to operations as well.
    • Tiny - This is Dan's kind of catch all FIST value. It is reminder to be light weight in all things, not just time, cost, and design/process.

One final reminder, this project is very early on in our development of testing capability. It is as much an experiment as a development program, answering questions like:

  • Can we use the Arduino for data acquisition? If so, where and when? If not, what about it is insufficient?
  • How well does this website work for collaborating on physical projects?
  • Are projects at this scale interesting to the open source hardware and open source spaceflight communities?
  • What lessons do we need to learn before we build larger test stands?

RE: Use of the formal systems engineering process - Added by J. Simmons about 12 years ago

We dropped this thread online, but have discussed it in person some since the last post. I think one of the conclusions we came to was to look at Amanda Wozniak's presentation at the Open Hardware Summit for guidance on a suitably scaled process for kite level projects.

RE: Use of the formal systems engineering process - Added by Jeremy Wright about 12 years ago

The following is what I got out of Amanda Wozniak's presentation and slides on the open source engineering process. Please correct me on anything that I've gotten wrong. The "SEP item" entries refer to Greg's post at the beginning of this topic.

1. Ask Important Questions
  • Includes SEP item "requirements definition"
  • Why are we making this?
  • Who is this for?
  • How will this be used?
  • What features does it need to have (now)?
  • What features does it need to have (later)?
  • What are the legacy requirements?
  • Who's going to build this?
  • How many do we want to make?
  • What is the budget?
  • What is the timeline?
2. Design, and Record Your Rationale
  • Includes SEP items "functional architecture development", "physical architecture development", "preliminary design", and "detailed design".
  • Group required features into a block diagram.
  • Perform the bulk of the design steps.
    Example block diagram:
3. Hold a Review
  • Does the proposed design meet the requirements?
4. Make One and Test It
  • Includes SEP items "procurement/manufacture", "assembly", "integration", and "testing".

5. Does it Work, and Did You Address the Questions (Requirements)?

I'm not sure where the "disposal" step of the SEP fits in.

Some of the end product documentation she mentioned is as follows.
  • Project Introduction Including Goals and an Overview
  • System Block Diagram
  • Block By Block Breakdown
  • Function
  • Layout Block
  • Schematic Block
  • Part Selection
  • Performance Metrics
  • Discussion of Essential Features/Trade-Offs
  • Software/Firmware Summary
  • Typical Application
  • User's Quick-Start Guide
  • Eratta
Two Other things that caught my attention.
  1. Continuously keep your CAD library and BOM up-to-date.
  2. For every part on the BOM:
    • List multiple vendors.
    • List part function.
    • List critical specifications.

RE: Use of the formal systems engineering process - Added by J. Simmons about 12 years ago

That is a great summary. I think we would do well to try this process out. I think step 1 ("Ask important questions") would make a good hangout topic. If we do that in the next couple of weeks, I think it would help get you up to speed on the thought process to date and help get the ball rolling.

To answer your question about the SEP "disposal" step, at some point you will be finished with a piece of hardware (be it a jet fighter, a space shuttle, or a small test stand) and good Systems Engineering dictates you address what you will do with the hardware in question at the end of its life. This is particularly important for projects which contain hazardous materials where the disposal cost could be a significant factor in the overall program cost.

RE: Use of the formal systems engineering process - Added by Jeremy Wright about 12 years ago

Would you be interested in also having a topic on it on the forum until then? Or would it be better to wait?

RE: Use of the formal systems engineering process - Added by J. Simmons about 12 years ago

In the interest of keeping things moving, and of making our work as open as possible, a topic on the forum would be a good start. And I think we should take the full results of the discussion (over forum and over hangout) and document it on the wiki, following the format of the questions.

RE: Use of the formal systems engineering process - Added by Jeremy Wright about 12 years ago

To answer your question about the SEP "disposal" step, at some point you will be finished with a piece of hardware (be it a jet fighter, a space shuttle, or a small test stand) and good Systems Engineering dictates you address what you will do with the hardware in question at the end of its life. This is particularly important for projects which contain hazardous materials where the disposal cost could be a significant factor in the overall program cost.

Sorry, I didn't explain my confusion about the "disposal" step very well. It's helpful to have it defined, but what I'm actually having trouble figuring out is where disposal fits into Amanda Wozniak's SEP. Do you just integrate it into the "Make One and Test It" step, or is it more of a consideration that influences the entire engineering process? You mentioned how it can influence the budget as well, so it seems like it would span multiple steps from planning through execution. Does that make sense, or am I making this more complicated than it has to be?

RE: Use of the formal systems engineering process - Added by Greg Moran about 12 years ago

Jeremy,
That's a great observation WRT the disposal step of the formal SEP not making it into Amanda's Wosniak presentation. You are correct in stating that the disposal aspect should influence the entire process. The placeholder at the very end of the list simply serves as a reminder that we have to plan to "clean up after ourselves" since it would be cumbersome to document it as parts of all the other steps. A good example: a later versions of the test stand project may include fuels that would have special handling/processing/disposal guidelines. It should be important to consider this special requirement while designing the test stand so that clean-up of the equipment and environment can be eased.

RE: Use of the formal systems engineering process - Added by Jeremy Wright about 12 years ago

You are correct in stating that the disposal aspect should influence the entire process. The placeholder at the very end of the list simply serves as a reminder that we have to plan to "clean up after ourselves" since it would be cumbersome to document it as parts of all the other steps.

So would it be fair to say that for our purposes, step 1 of Wozniak's SEP should include a question like "What waste products will be produced by the manufacture and/or operation of this?"

That way it's captured from the start in your requirements and you're forced to keep it in mind throughout the entire process.

RE: Use of the formal systems engineering process - Added by Jeremy Wright about 12 years ago

Another thing that just occurred to me is the question of when do we freeze a step of the SEP? For instance, do we freeze step 1 of the SEP when we start manufacturing and then move all new questions/requirements to the next version? Because of the nature of ODE I would think that people will post their thoughts on steps in the SEP that are already "finished". That makes their input no less valid, but it's difficult (and many times impractical) to integrate someone's new input into a design that's already being manufactured.

RE: Use of the formal systems engineering process - Added by J. Simmons about 12 years ago

Jeremy Wright wrote:

You are correct in stating that the disposal aspect should influence the entire process. The placeholder at the very end of the list simply serves as a reminder that we have to plan to "clean up after ourselves" since it would be cumbersome to document it as parts of all the other steps.

So would it be fair to say that for our purposes, step 1 of Wozniak's SEP should include a question like "What waste products will be produced by the manufacture and/or operation of this?"

That way it's captured from the start in your requirements and you're forced to keep it in mind throughout the entire process.

That sounds like a good idea to me.

Another thing that just occurred to me is the question of when do we freeze a step of the SEP? For instance, do we freeze step 1 of the SEP when we start manufacturing and then move all new questions/requirements to the next version? Because of the nature of ODE I would think that people will post their thoughts on steps in the SEP that are already "finished". That makes their input no less valid, but it's difficult (and many times impractical) to integrate someone's new input into a design that's already being manufactured.

Yeah, that is indeed a challenge of open development (in software or hardware). And I think something along the lines of what your comment expresses is what usually happens in software (though it is worth doing some research to confirm). I imagine as we move to each new step in the design process we have to gel (that is mostly freeze) our work from the previous step until we go through another design iteration. I say gel, because if someone catches a significant technical error (for example the fins of this rocket are going to fall off because of an error in the prediction of their failure) then I think we would want to be flexible enough to respond to the comments. But if the comment is more of a "gee, you could get a little bit of improvement if you just went back and made this change that requires weeks of work to accomodate", then I think we want to wait to incorporate that comment.

(1-12/12)