Skip to main content Skip to navigation
Hydrogen Properties for Energy Research (HYPER) Lab ME 316

ME 406 Lesson 2: Literature Reviews

There’s an old saying — “A week’s worth of time spent in the library can save a year’s worth of time in the laboratory.”

Of course today the time is usually spent on-line with Google instead of the library. Enter the quantity vs. quality debate. Do you want 5 highly relevant sources to your project with the chance that you miss an important one? Or 5 million potentially relevant sources to your project that you have to sift through to find the golden nuggets? The answer is probably the first.

So ask yourself, do you feel proficient at navigating the aggregated on-line knowledge of human existence? If the first thing that pops into your head is a cat video on youtube, you need to talk to a librarian. If you haven’t completed an extensive literature review in the past, you’re a rookie. Call in a pro to give you pointers before you waste everyone’s time. Talk to your librarian. Did you know that WSU has a dedicated Engineering Librarian, Chelsea Leachman? She was trained as an engineer and is married to one. She knows how you think. Talk to your librarian.

Contrary to popular belief, librarians are not out of style, only the antiquated stereotypes of them are. The amount of scientific information the world is generating is increasing at an exponential pace. Even with the new abilities to search this information for yourself, the learning curves are steep, and the expectations to have rigorously evaluated background literature are stringent. Suffice it to say, there has never been a more important time in history to have very, very good librarians on your side.

Let me be absolutely clear that the #1 problem I’ve noticed from our engineering students in the last five years is an inability to find the most relevant and credible information for their projects. Not math skills, not hands-on skills, not team skills, not communication, but simply doing a thorough review of what’s out there. The way Chelsea described it to me, “the students don’t understand their projects. So they don’t enter good keywords for searches. So they return irrelevant sources that they don’t read. So they never get to know their projects.” Ignorance is a vicious cycle — one that takes time, practice, and dedication to overcome.

You should consider double checking to make sure you have identified the following:

  1. Relevant testing standards nearly all of the experiments have a testing/operating standard that covers the general classification of machinery. These will often tell you how many data points to take, how many times you need to re-run a point, and what types of tests should be done.
  2. Relevant peer-reviewed journal publications. Although the standards may say what to do and how for the experiment, they may not give you the most recent and credible theoretical approaches for analyzing and correlating the data. You should quickly look through recent journal publications to see if recent research provides new theory for your experiment.
  3. Doctoral and Master’s theses. These are often golden finds as theses tend to describe everything in-detail from a novice viewpoint that’s empathetic to yours! You may even get a detailed operating procedure!
  4. Company product websites and manuals. Just like this site, they can be created by anyone, anywhere, and are not necessarily peer reviewed for credibility, but if highly relevant, are worth spending time on. Do you really know how that instrument works?

The primary focus of this class though are testing standards. Chelsea has grabbed many of the relevant standards for your projects and has a worksheet that breaks down and shows you how to use these testing standards. Note that there are even testing standards for data analysis and uncertainties.

Chapter 2: Literature Review

Now that Chelsea has shown you where to find and how to use the standards relevant to your project, you need to document them now, before you forget.

Literature reviews can be boring, especially to someone who is very familiar with the body of knowledge (a boss for example). So you need to stay efficient, credible, and work to try to teach us something interesting/relevant. While there isn’t a right or wrong way to structure this section of your report, good literature reviews tend to have the following elements:

  1. A quick narrative describing how the literature review is structured to maximize relevance to the need described in the introduction.
  2. An efficient history of the type/paradigm of the machine/widget/specimen you are testing. This historical view approach is often convenient as it naturally shows what has been done, in some kind of timeline, culminating in why the test is needed.
  3. The applicability of standards, what aspects of the experiment covered, and why or why not you are conforming to particular standards.
  4. Particularly relevant journal publications and industry manuals or websites that cover parts of your experiment.
  5. A summary that shows what is covered, and why you need to do theory and experiments to solve the original customer/client need from the intro.

Now for the specifics of actually using your sources and citing them appropriately. Here’s an example:

“Aerospace is an important industry.”

“Unmanned Aerial Systems are a rapidly growing sector of Aerospace (Teal Group 2012).”

“Unmanned Aerial Systems are predicted to be a $14 billion dollar industry by 2020 and Washington State will be the 2nd largest contributor (Teal Group 2012).”

Which sentence above reads as the most relevant and credible to you? I’m guessing the last. Notice how good sources give you specific numbers that can be traced back to the source. I’ve used them in my sentences to SHOW how big/important something is, rather than just to TELL the reader. Which sentence can be said by anyone? Which sentence makes you valuable as an employee?

How you list your sources is another consideration. You should always use the format that’s relevant to your company or journal that you will eventually submit the report to. If you are given the option, cite the article with the names of the authors/group producing the publication and year as I have above (Leachman 2016). This provides the readers a way to assess the credibility of the information immediately when they read it. Another way is to use a footnote and place the citation at the bottom of the page. Placing the sources at the very end of the report or presentation requires the reader to flip back and forth. It’s a pain! Have you ever been in a presentation where someone put the sources at the end, but flipped through the slide so quickly that nobody could read anything that was on it? If it’s worth citing, put the source where and when your readers need it.

 

ME 316 Lesson 10: Energy and Information Design Paradigms

Spatial and temporal spectrums are useful as a first step to breaking down systems, but quickly run into limits. Energy is likely a particularly useful spectrum to categorize our design alternatives within the context of this project. Consider how the Advanced Research Project Administration for Energy (ARPA-E) classifies energy conversion devices:

ARPA-E paradigm chart

Let’s take 15 minutes in our sub-teams and try to fill as many of the squares as possible with designs concepts for our sub-assemblies. An excel version of this is posted to the ME 316 slack thread. If you have an integration system like PLC, piping, or Box/container, try to think about how a design in each of these categories would change how you integrate with the sub-system.

This exercise gives us more possible design paradigms that we can populate our house of quality with from Lesson 7.

Information flows are yet another way we can breakdown the design. Information allows us to think about how many layers a sensing system (for example) may need to be resilient to hacking or terrorism. Some designs necessitate a high degree of parallel processes in order to quickly adapt to change.

For Friday you’ll need to work with your reporters to begin upload the following to your team’s page on the hydrogen.wsu.edu website:

  1. Your sub-assembly’s needs/motivation statement.
  2. The prior art/status quo for your sub-assembly.
  3. You Design specification, including a narrative to accompany your sub-assembly’s house of quality.
  4. A design ideation section describing the spectrum of possible designs for your sub-assembly.

We’ll start the process of down-selecting on Friday.

 

ME 316 Lesson 9: Design Paradigms (Spatial and Temporal)

With our design specification nailed down, we now begin the process of idea generation. Let’s start with a quick exercise:

Get out a sheet of paper and write down the first thing that comes to your mind when I tell you to think of:

  1. a color,
  2. a hand tool,
  3. a flower,
  4. a piece of furniture.

Let’s see how you did:

 

 

😉

 

 

Was your color blue or red?

Blue and Red

Was your tool a hammer or screwdriver?

Hammer and Screwdriver

Was your flower a rose or tulip?

Rose and Tulip

Was your piece of furniture a chair or couch?

Chair and Couch

Why is it that given a huge array of possible answer to these questions, I’m able to reliably predict the majority of the class responses (~66-80% of the time) with just two possible answers?

Our educational system primarily teaches conformity and reliability, i.e. algorithmic rule following towards a predictable outcome. Sir Ken Robinson’s TED talk, the most watched TED talk, hits this point home… along with Seth Godin’s TED talk and many others from leading educators and thought experts. Our western culture prides uniqueness, creativity, and original individual thought. The reality though is that our social behaviors and tools for aggregating knowledge (via Conway’s Law) have a HUGE effect on the products we produce.

To really start the process of idea generation so that we don’t simply mimic or conform to what is already out there, we really need to be aware of our mental ruts and employ system-level thought practices to break us into new thought paradigms or memes:

Paradigm

Meme

We first need to establish a spectrum or continuum of possibilities to place our specific design into context relative to other possible designs. The author of your textbook breaks down systems by Scale, Function, Structure, and Temporality. I’ve modified these to breakdown systems in four different (but interconnected) ways:

  1. Spatial
  2. Temporal
  3. Energy
  4. Information

Today we address the first two. Ray and Charles Eames are widely considered the greatest husband and wife design team in American History. While being primarily known for the design of furniture (including the examples above) they regularly undertook very diverse design challenges in their studios (now the homes of Facebook in California and Google in Chicago). In the early 1970’s IBM approached the duo with the need to help instill the importance of science and math in the minds of American youth (sound familiar?). The resulting film, Powers of Ten, made history. A writeup on the making of the film is here.

Since hydrogen is 74% of the known atomic mass in the universe it is the dominant atom at almost every scale in Powers of Ten. Although we could daydream a version of our system at every scale in Powers of Ten, only a few of the spatial and temporal scales are relevant to the design challenge at hand. Your task to post as a sub-assembly team to Slack for Wednesday is:

  1. Identify the appropriate space and time scale that your sub-system must operate in.
  2. How do these space and time scales control the design characteristics? i.e. Why must your design operate at a specific scale and what are the key limiters?
  3. Does your subsystem house of quality account for these limitations?
  4. Now a fun lesson in innovation, either increase or decrease the scale (think both spatially and temporally) to the point where your prior system no longer works. How would your system look or function at this new scale? Can this change lead to any insights on your current scale?

ME 316 Lesson 8: Technology Development (TRLs)

TechD

 

 

 

 

 

 

 

 

 

As engineers, one of the things we all need to be mindful of throughout the design and development process is our stage in technology development. It’s pretty obvious that every technology we have today is supported by a long chain of discoveries, tests, research, and development to get to the products we have in front of us. Insight into where our current efforts fit in that chain can be extremely helpful in a number of tasks:

  • Deciding on your goals for the project – What is a success and what is a failure? Early on in the process, an experiment that provides results counter to your expectations can be just as successful as getting the expected result. If you’re trying to make a product, however, a failure to achieve expected results can destroy any hopes to make it to market.
  • Knowing your audiences – You don’t want to be pitching your basic research to investors to try to start a company – it will never work! At the same time, the government is not going to fund a grant to help you move your finished product to market.
  • Communicating with your audiences – Having an effective descriptor for where in the development process you are working helps your audiences, whoever they may be, to connect to your goals and objectives. This becomes much easier if we define a standard set of descriptions for the development process.

NASA realized these points, and in the 1980s started developing a standardized system to describe their technical progress, called Technology Readiness Levels. These advance from the most basic research at TRL 1 to working products at TRL 9. This system has since been picked up by many government agencies, and is increasingly being used when issuing research grants. Industries, too, are now developing their own TRL guidelines. Each guideline is slightly different for each application, but share a very similar progression. Some examples of TRL users are listed below:

This last user in particular is important, as DOE is administering the contest! An example of a TRL system from John C. Mankins’ NASA TRL White Paper is given below:

“TRL 1

Basic principles observed and reported

This is the lowest “level” of technology maturation. At this level, scientific research begins to be translated into applied research and development. Examples might include studies of basic properties of materials (e.g., tensile strength as a function of temperature for a new fiber).

Cost to Achieve: Very Low ‘Unique’ Cost (investment cost is borne by scientific research programs)

TRL 2

Technology concept and/or application formulated

Once basic physical principles are observed, then at the next level of maturation, practical applications of those characteristics can be ‘invented’ or identified. For example, following the observation of high critical temperature (Htc) superconductivity, potential applications of the new material for thin film devices (e.g., SIS mixers) and in instrument systems (e.g., telescope sensors) can be defined. At this level, the application is still speculative: there is not experimental proof or detailed analysis to support the conjecture.

Cost to Achieve: Very Low ‘Unique’ Cost (investment cost is borne by scientific research programs)

TRL 3

Analytical and experimental critical function and/or characteristic proof-of-concept

At this step in the maturation process, active research and development (R&D) is initiated. This must include both analytical studies to set the technology into an appropriate context and laboratory-based studies to physically validate that the analytical predictions are correct. These studies and experiments should constitute “proof-of-concept” validation of the applications/concepts formulated at TRL 2. For example, a concept for High Energy Density Matter (HEDM) propulsion might depend on slush or super-cooled hydrogen as a propellant: TRL 3 might be attained when the concept-enabling phase/temperature/pressure for the fluid was achieved in a laboratory.

Cost to Achieve: Low ‘Unique’ Cost (technology specific)

TRL 4

Component and/or breadboard validation in laboratory environment

Following successful “proof-of-concept” work, basic technological elements must be integrated to establish that the “pieces” will work together to achieve concept-enabling levels of performance for a component and/or breadboard. This validation must devised to support the concept that was formulated earlier, and should also be consistent with the requirements of potential system applications. The validation is relatively “low-fidelity” compared to the eventual system: it could be composed of ad hoc discrete components in a laboratory. For example, a TRL 4 demonstration of a new ‘fuzzy logic’ approach to avionics might consist of testing the algorithms in a partially computer-based, partially bench-top component (e.g., fiber optic gyros) demonstration in a controls lab using simulated vehicle inputs.

Cost to Achieve: Low-to-moderate ‘Unique’ Cost (investment will be technology specific, but probably several factors greater than investment required for TRL 3)

TRL 5

Component and/or breadboard validation in relevant environment

At this, the fidelity of the component and/or breadboard being tested has to increase significantly. The basic technological elements must be integrated with reasonably realistic supporting elements so that the total applications (component-level, sub-system level, or system-level) can be tested in a ‘simulated’ or somewhat realistic environment. From one- to-several new technologies might be involved in the demonstration. For example, a new type of solar photovoltaic material promising higher efficiencies would at this level be used in an actual fabricated solar array ‘blanket’ that would be integrated with power supplies, supporting structure, etc., and tested in a thermal vacuum chamber with solar simulation capability.

Cost to Achieve: Moderate ‘Unique’ Cost (investment cost will be technology dependent, but likely to be several factors greater that cost to achieve TRL 4)

TRL 6

System/subsystem model or prototype demonstration in a relevant environment (ground or space)

A major step in the level of fidelity of the technology demonstration follows the completion of TRL 5. At TRL 6, a representative model or prototype system or system — which would go well beyond ad hoc, ‘patch-cord’ or discrete component level breadboarding — would be tested in a relevant environment. At this level, if the only ‘relevant environment’ is the environment of space, then the model/prototype must be demonstrated in space. Of course, the demonstration should be successful to represent a true TRL 6. Not all technologies will undergo a TRL 6 demonstration: at this point the maturation step is driven more by assuring management confidence than by R&D requirements. The demonstration might represent an actual system application, or it might only be similar to the planned application, but using the same technologies. At this level, several-to-many new technologies might be integrated into the demonstration. For example, a innovative approach to high temperature/low mass radiators, involving liquid droplets and composite materials, would be demonstrated to TRL 6 by actually flying a working, sub-scale (but scaleable) model of the system on a Space Shuttle or International Space Station ‘pallet’. In this example, the reason space is the ‘relevant’ environment is that microgravity plus vacuum plus thermal environment effects will dictate the success/failure of the system — and the only way to validate the technology is in space.

Cost to Achieve: Technology and demonstration specific; a fraction of TRL 7 if on ground; nearly the same if space is required

TRL 7

System prototype demonstration in a space environment

TRL 7 is a significant step beyond TRL 6, requiring an actual system prototype demonstration in a space environment. It has not always been implemented in the past. In this case, the prototype should be near or at the scale of the planned operational system and the demonstration must take place in space. The driving purposes for achieving this level of maturity are to assure system engineering and development management confidence (more than for purposes of technology R&D). Therefore, the demonstration must be of a prototype of that application. Not all technologies in all systems will go to this level. TRL 7 would normally only be performed in cases where the technology and/or subsystem application is mission critical and relatively high risk. Example: the Mars Pathfinder Rover is a TRL 7 technology demonstration for future Mars micro-rovers based on that system design. Example: X-vehicles are TRL 7, as are the demonstration projects planned in the New Millennium spacecraft program.

Cost to Achieve: Technology and demonstration specific, but a significant fraction of the cost of TRL 8 (investment = “Phase C/D to TFU” for demonstration system)

TRL 8

Actual system completed and “flight qualified” through test and demonstration (ground or space)

By definition, all technologies being applied in actual systems go through TRL 8. In almost all cases, this level is the end of true ‘system development’ for most technology elements. Example: this would include DDT&E through Theoretical First Unit (TFU) for a new reusable launch vehicle. This might include integration of new technology into an existing system. Example: loading and testing successfully a new control algorithm into the onboard computer on Hubble Space Telescope while in orbit.

Cost to Achieve: Mission specific; typically highest unique cost for a new technology (investment = “Phase C/D to TFU” for actual system)

TRL 9

Actual system “flight proven” through successful mission operations

By definition, all technologies being applied in actual systems go through TRL 9. In almost all cases, the end of last ‘bug fixing’ aspects of true ‘system development’. For example, small fixes/changes to address problems found following launch (through ‘30 days’ or some related date). This might include integration of new technology into an existing system (such operating a new artificial intelligence tool into operational mission control at JSC). This TRL does not include planned product improvement of ongoing or reusable systems. For example, a new engine for an existing RLV would not start at TRL 9: such ‘technology’ upgrades would start over at the appropriate level in the TRL system.

Cost to Achieve: Mission Specific; less than cost of TRL 8 (e.g., cost of launch plus 30 days of mission operations)”

Homework for Monday:

  1. Finish and polish your presentation for Jake (and the rest of the world!) to be given on Monday.
  2. Read the DOE TRL guide and try to get an understanding of where our development is taking place in the TRL system. Why might DOE be using this competition to advance TRLs?

ME 316 Lesson 7: Quality Function Deployment and Design Matrix Methods

Now that we’ve 1) interviewed our customers, 2) reviewed basic literature on the topic, 3) divided the project into sub-assemblies, and 4) began specifying desired traits and characteristic functions of the sub-assemblies, it’s time we merge everything together via tools called Design Structure Matrix (DSM) Methods. Professor Steven Eppinger has published a companion to your textbook on the topic. DSM’s are useful for spotting the connections and relationships in complex systems. Take for example the problem of assessing the Technology Readiness Level (TRL) for the Mars Curiosity Rover:

Architecture DSM Example

We used our intuition, post-its, and considerable time planning over the summer to accomplish this at the system level. As our design develops we will likely come back to these for system flow diagrams.

The most popular DSM is known as the House of Quality (HOQ). The seminal article in Western culture on the HOQ was written by John Hauser and Don Clausing in 1988. It’s worth the read. The HOQ is the centerpiece of Quality Function Deployment (QFD) that originated in a shipyard division of Mitsubishi in 1978. A handy flash tool explaining the HOQ is here. In essence, phase 1 of the HOQ is a neat design heuristic to ensure your method for assessing design performance matches the customer/client needs. Phase 2 then maps the engineering characteristics to use for assessing your specific sub-assembly alternatives, shown in the Figure below. Phases 3-4 then map the best sub-assembly to production process capabilities, which is beyond the scope of our class.

HOQ mapping to subs

Extensive use in industry and studies on the effectiveness of the HOQ over the years have shown that the method significantly improves inter-team communication, speed to delivery, and number of required design iterations. It’s safe to say that the HOQ is the leading design structure matrix method for engineers.

Based on this, consider the HOQ your team started to draft over the weekend. Does the global HOQ we drafted over the summer have adequate quality characteristics? Are you sure you can measure/quantify how effectively your potential designs will perform relative to the global system characteristics and customer requirements? Take 5 minutes to review and discuss the HOQ for your team’s sub-assembly, including changes that must be made and questions you need answered.

We’re approaching the time to develop a preliminary design specification. This design specification lays out the template that we’ll measure our overall design performance with and will guide us the rest of the semester. On Friday you’ll need to practice a 20 minute presentation discussing: 1) the client/customer need/background, 2) separate sub-functions/systems, 3) the needs, performance measures, and how you will assess them for your specific sub-assembly (overview of HOQ), and 4) how these connect to the global-system (overview of global HOQ). You will present a final version of this initial design specification for team-level grades and feedback in class on Monday. On Wednesday, you will post a web version of this presentation to the H2-Refuel team website. A Draft Presentation Grading Rubric for the presentation and post is here.

In order to prepare for this class-level activity, we need to break into our role-teams: 1) Builders, 2) Theorists, 3) Compliance, 4) Reporters, and 5) Liaisons. Take a moment to introduce yourselves and your sub-assemblies. Here are suggested problems for your role teams to address:

  1. Liaisons– You need to facilitate the presentations i.e. come up with a plan to practice and then deliver the presentations. Begin in a neat way. Setup each of the sub-assemblies to efficiently deliver their content, and wrap everything up leaving us feeling good and confident. Practice like you play. This should be clean, crisp, high-scoring, and professional.
  2. Reporters– You need to come up with a standard template for each of the teams to communicate their content with. If done well, this template will allow you to easily transfer the content to the H2-Refuel website. HINT: Customers tend not to understand the HOQ. So you need to consider your audience and what you need to communicate.
  3. Compliance– Addressing the design standards and competition requirements is essential to developing a complete HOQ. Make sure all of the sub-assemblies have identified and appropriately applied design standards.
  4. Theorists– Discuss how to link your sub-assembly HOQs to the global-system assembly HOQ so that we can efficiently track the influence of sub-assembly alterations to overall system-level performance. You can probably link separate spreadsheets within an Excel file. Also assess the adequacy of the current engineering characteristics in the global HOQ and make revisions.
  5. Builders– You pragmatic practitioners. Make sure we have a plan and can actually measure the metrics in the HOQs. We also need to connect all of you to Brian Karlberg and the TFRB build space. The shipping container is coming soon.

ME 316 Lesson 6: Form follows function

Today is Louis Henry Sullivan’s birthday. Sullivan’s wiki-page lists him as a famous American Architect widely considered the “Father of the Skyscraper.” In an 1896 essay Sullivan wrote:

Whether it be the sweeping eagle in his flight, or the open apple-blossom, the toiling workhorse, the blithe swan, the branching oak, the winding stream at its base, the drifting clouds, over all the coursing sun, form ever follows function, and this is the law. Where function does not change form does not change. The granite rocks, the ever-brooding hills, remain for ages;the lightning lives, comes into shape, and dies in a twinkling.

Sullivan’s famous statement, form follows function, has defined engineering design for over a century. In many ways this is an early incarnation of the Constructal Law, i.e. the Design Law of thermodynamics that I alluded to earlier. Said plainly, you should not envision the form of your design until you fully understand how the design must function. To understand how the design must function you must fully understand: 1) what is flowing in the system, 2) the necessary steps required to accomplish this flow, and 3) how your customers will assess and quantify the performance of your design. Hopefully all 3 coalesce. We know our system is flowing hydrogen, have started the process of identified key sub-systems required to accomplish this flow, and are beginning to consider how our customers will assess design performance.

Last class each of the teams created conceptual system diagrams for the entire fueling station concept. The votes are in and the vortex tube team’s diagram was a landslide winner. What’s fascinating is that almost everyone, more or less, had similar essential steps in the process, but almost all of the the diagrams are organized differently. The PLC and Sensor team’s diagram is particularly interesting and shows that their head’s are in the right place. Only minor re-alignment of the initial team sub-assemblies will be required to conform to this new diagram.

Let’s take our sub-system diagrams one step further by drawing a diagram with the essential steps required for our specific sub-systems.

Now that you’ve presented and discussed. How does this spatial diagram relate to the MUSTS and SHOULDS that you drafted before class? Now take the time to merge the two. It really is an interesting point of Conway’s Law when you see how these two very different approaches to organizing information about a design’s function can lead to differing results. The reality is that our design won’t be set in stone until it has to be. It’s a highly iterative process.

One of the factors that will influence the design that we need to begin thinking about is how our customers will assess performance. We’re taking an interesting approach to our customers with this design. Ag Energy Solutions is our local client with very similar needs to the H2-Refuel competition at the national level. The H2-Refuel competition has devised a very rigorous scoring criterion to assess design performance for the competition. That takes care of a major, and difficult, part of the design process for us. Our task is to develop a system for determining how our design quantitatively addresses the performance criterion. Anybody can simply say one design is better than another. Engineers our valuable because we quantify why a design is superior.

The leading tool for quantifying the performance for complex systems is the House of Quality (HOQ). A free house of quality template is available here. Here’s an unlocked Turn Table HOQ.

We’ve already mapped the competition criterion into a Global HOQ for H2 Refuel. Over the weekend your task is to draft an initial HOQ for your sub-assembly and upload to your team’s Slack thread before class on Tuesday. We’ll begin integrating these sub-assembly HOQ’s into the Global HOQ on Wednesday.

 

ME 316 Lesson 5: Defining What a Design MUST and SHOULD do

For those of you curious, Jake was lucky enough to be in Florida watching the MUOS-4 launch this morning and won’t be back until Friday. This is a great example of a complex system like the one we will be designing (and uses liquid hydrogen too!).

Now that you have seen the competition requirements, talked with our customers/clients, and had a chance to read relevant literature on your specific topic, you should have a pretty good understanding of what is required and some of the specific challenges we will have to rise to meet. It’s time to start talking systems design!

No engineer, regardless of how talented or experienced, will come up with the winning design in one go. Did you think ULA designed the perfect rocket to launch MUOS-4 in their first go at it? No! As we’ve discussed, there is no algorithm you can follow to get the perfect design. Engineering systems is a iterative, heuristic process – the more iterations or potential solutions you can run through, the better your design becomes. Today, we’ll run through several iterations of the whole system, and by the end of class everyone should have a good idea of the full system design we’re moving forward with.

Initial System Designs:

  • Compressor Team:IMG_20150902_132907223
  • Container Team:ContainerSys1
  • H2 Purification Team:PurificationSys1
  • H2 Source Team:SourceSys1
  • H2 Storage Team:StorageSys1
  • Heat Exchanger and Piping Team:HXSys1
  • PLC and Sensors Team:project flow -team plc
  • User Interface Team:UISys1
  • Vacuum Chamber Team:VacSys1
  • Vortex Tube Team:VTubeSys1
  • Summer Guests Team:SummerFlow

Now that you’ve each presented a potential design, we’ll look at how to make toast. Keep this in mind as we take a few minutes to iterate to the next design!

Revised System Designs:

  • Compressor Team:
  • Container Team:ContainerSys2
  • H2 Purification Team:PurificationSys2
  • H2 Source Team:SourceSys2
  • H2 Storage Team:StorageSys2
  • Heat Exchanger and Piping Team:20150902_135704
  • PLC and Sensors Team:PLCSys2
  • User Interface Team:UISys2
  • Vacuum Chamber Team:IMG_20150902_135701
  • Vortex Tube Team:VTubeSys2

 

Vote on the winning revised design, and by sending me a Slack direct message with your top two designs.

By Friday you need to:

  1. Send your TA a direct message in Slack with the names of the teams with your top two favorite system designs. I’ll post the top designs to the announcements.
  2. Start your subsystem process flow and create an editable document that will allow you to continuously update and refine your design. I would recommend using Dia Diagram, but feel free to use Visio, Word, PowerPoint, or whatever system your team is comfortable with. Upload this to OneDrive, so everyone on your team can access.
  3. Once your subsystem process flow is complete, you should have a pretty good idea of your subsystem’s requirements. Make a list of everything your subsystem NEEDS to do, and a list of everything your subsystem SHOULD do. Upload this to OneDrive as well.

 

 

ME 316 Lesson 4: Literature Reviews

There’s an old saying — “A week’s worth of time spent in the library can save a year’s worth of time in the laboratory.”

Of course today the time is usually spent on-line with Google instead of the library. Enter the quantity vs. quality debate. Do you want 5 highly relevant sources to your project with the chance that you miss an important one? Or 5 million potentially relevant sources to your project that you have to sift through to find the golden nuggets? The answer is probably the first which means you need to talk to a librarian.

Contrary to popular belief, librarians are not out of style, only the antiquated stereotypes of them are. The amount of scientific information the world is generating is increasing at an exponential pace. Even with the new abilities to search this information for yourself, the learning curves are steep, and the expectations to have rigorously evaluated background literature are stringent. Suffice it to say, there has never been a more important time in history to have very, very good librarians on your side.

I hope you learned the importance of assessing the relevance and credibility of an information source from your engineering librarian, Chelsea Leachman. Chelsea is familiar with this particular project and has placed relevant engineering standards on reserve in the library to assist you. Your Design Information Audit worksheet was a great start to sorting the relevant information for your project. In addition to having this completed and updated regularly in your Slack sub-assembly, you should consider double checking to make sure you have identified the following:

  1. Relevant design standards pertaining to your sub-assembly. For example SAE J2601 mandates hydrogen fueling rates to prevent bursting of fuel tanks. Is there a standard for designing hydrogen-safe shipping containers? What about fuel-system user interfaces? Hydrogen safe compressors?
  2. Relevant peer-reviewed journal publications. The majority of hydrogen research in liquefaction systems was conducted in the 1960’s-early 1980’s. There likely is no standard for designing liquid hydrogen purification, heat exchange, vortex tubes, and other systems but there are journal publications that discuss these topics. You’ll often learn what not to do by reading these.
  3. Doctoral and Master’s theses and Dissertations. These are excellent sources to begin a major design project with because they include extensive literature reviews and explanations/justifications of why certain approaches should be considered that are often removed from regular journal publications in the interest of space.
  4. General websites. Just like this site, they can be created by anyone, anywhere, and are not necessarily peer reviewed for credibility.

I have saved considerable information over the years on cryogenic hydrogen and will share some of these with you after you’ve first looked for yourself. It’s essential that I not bias your initial searches as it limits the classes ability to find something new that could solve some of our current problems.

Washington State University