I was recently in New York City for work. I stopped by to see a friend in the area. He said “I have something interesting to show you.” I was pretty excited because when Mark says “I have something interesting to show you.” you know it is going to be good. He’s a writer and his passion is finding strange and interesting things. My personal Indiana Jones. Many days he wakes up and just gives himself some adventure assignment and the goes searching for it.
The gage measurements are expected to be stable, meaning the gage should provide consistent readings. Some random variation due to random error is expected. However, gage measurements change with time or because the gage is damaged. The gage stability can be checked by measuring a known reference.
In this article, it is shown how to use control charts to assess gage stability.
If you recall I went on a slightly crazy adventure up to the edge of the article circle with my adventure buddy, my daughter Natalie, 11. We almost froze to death on a mountain just to see the Northern Lights (story here). But we also did something we both have always wanted to do and knew would be epic, a dog sled ride. The first thing I have to say about it is holy crap those dogs are fast. It felt like you could blow the doors off a snowmobile if you came across one.
I was recently giving a presentation for IEEE at MIT Lincoln Labs here in the Boston area. The topic was one of my favorites, my new playground, Use Case 7 ! The crowd loved the idea of expanding how we access use cases and came up with great examples. and experiences, of their own. They found many areas in their work where the Use Case 7 exercise may yield some interesting insight.
In February I did a hit and run trip to Fairbanks Alaska with my daughter, age 11, to try and see the Northern Lights. It was a long shot but I’ve done nuttier expeditions and she was game. It was actually her idea, and she knew who the right person was to ask for such a trip. She turned 11 in January. I asked her what she wanted for her birthday. I was ready for the “this or that electronic” request. Instead she said “I want to see the Northern Lights.” First thought was “Geez that’s a bit extravagant” but then my second thought was she’s 11 and this could have a great impact on her and what an interesting/cool thing to ask for. It might energize an interest in physics or natural photography, or cold weather clothing design. I also thought about how in a few years she may not want to do anything with me because I’ll be an “idiot who doesn’t get it.”
In the past five weeks I have been to Miami, Orlando, Cleveland, Chicago, Fairbanks Alaska, Fortuna Costa Rica. For one stint of that I went Fairbanks to Boston to Costa Rica in a 24 hr period. I walked into my home dropped the Alaska suitcase, grabbed the prepacked Cost Rica suitcase, slept for 6 hours ,and was back on a plane 13 hrs later. I think that qualifies as a HALT test considering the lowest temperature I experienced in Fairbanks (Arctic circle edge) was -30F on top of a mountain and then 85F in Costa Rica in the Rainforest.
So why did I do all of this? Because it’s me and it seemed fun.
Most of us rely on accurate measurements. If these measurements are unreliable, then our decisions could be based on false information. How can we have confidence in our measurements?
The purpose of a measurement system analysis is to determine if a gauge is fit for use. This means that we can rely upon the measurements to give us a true indication of the parameter being measured. Our decisions will not be affected by erroneous data. So how can we know the quality of our measurements?
Anyone who knows me knows I love modifying things. I always feel there is a better design. This is the goal of a reliability engineer at heart. I enjoy sports and I enjoy running. I do believe that we were born to run. If you look at the human body that is clearly what it was built for. Our big toe faces forward, which makes them no longer good for gripping things like branches. But it does make them great for landing a foot in forward motion. We have extremely long legs in proportion to our bodies compared to all other primates. We are slender which provide a great ratio of surface area to mass for cooling. The ability to sweat without hair is a great temperature control method as well. We are also the only mammal that can uncouple our breathing to our running pace because we are bipeds. This let’s us optimize our breathing for long distance.
Stay informed on the latest content added to the site, including: articles, podcasts, webinars, live events and assorted other reliability engineering professional development materials added each week.
Before you go on, please have a look at British comedian John Oliver’s video on infrastructure – https://www.youtube.com/watch?v=Wpzvaqypav8.
OK, if you are reading this and still haven’t watched the video … please go back and try again. You can do it.
If you haven’t watched the video by now, then I concede defeat. In short, the video is a humorous take on the state of US infrastructure. Particularly bridges. Bridges have been collapsing with alarming frequency in recent years. And after much political wrangling there is still no plan to pay for fixing crumbling columns, spans and struts. It is not as if the federal and state governments don’t know how bad things are (again … watch the video).
Oliver proposes a perhaps novel reason for all of this. [Read more…]
When something is working it is easy to just keep going forward. But how do you know things will keep chugging along? Is it worth stopping and asking “Why is this going well?”
I like lock picking “Lock Sport.” Of course I do. It’s a mechanical puzzle. It can also make you look like James Bond when someone forget’s their keys. I continue to challenge myself by getting progressively harder and harder locks. Throughout the years lock designs have come up with some great features to resist being picked. But there is still not one out there that is “pick proof”, so there is always a next level. I would say I am a mid-intermediate in the world of Lock Sport. So any lock that actually has good picking defenses can give me a good struggle.
I just returned from a great conference in Stuttgart called “Reliability Days.” I presented on some new concepts and techniques with regard to assessing and improving reliability culture in the product development process. Enjoy the presentation.
We all would like a clear path to achieve what we need. But we all know that it’s not the clear sections of the path where we spend most of our time. In product development many of these events we label as “obstacles” are in fact other individuals.
If these team members are noted as being strong enough to be considered an obstacle that means they have strength. This is a good quality in a team member. If we were to get ourselves headed in “generally” the same direction a lot of progress could be made very quickly.
There is no question that standardizing processes, techniques and best practices has contributed greatly to technological evolution. Just writing down or passing on what has worked well in the past helps anyone’s learning process. But there are many problems associated with this approach when blind obedience kills critical thinking.
The effectiveness of “Design for X” (DfX) methodology is often limited by the non-negotiable “freeze” gates in the product development process. Freezes become points of negotiation instead of directing scheduling and resource decisions. Design changes continue past “design freeze” commonly resulting in an inefficient multi-iterative process.
A design freeze is the wrong tool for the job. Design Freeze is a “Put your pencils down” methodology. This leaves no room for input to the decision to halt activity other than what was available when the freeze gate was set. Often a good deal of new information about the design and program has been created between the program creation and the freeze.
The “design freeze” principle is driven by the proposed benefit of increased efficiency through reduction of schedule creep. Both time and money can be lost as serial program phases are stalled due to incomplete predecessors. Common freeze gates are “Specification Freeze”, “Concept Freeze”, “Design Freeze”, and “Tooling Freeze.”
It is important to distinguish between internal freezes that are the result of dependencies, and external freezes like lead times that are imposed on the design process. Quality control norms like ISO 9000 require a freeze point for change control to distinguish between the design phase and change implementation afterwards. Certifications like UL and FDA are also often positioned post freeze.
There are phases to freezing. The program leadership will begin to express restrictions on changes as the freeze approaches. This may be called a “Chill” phase. It is marked by an increasing needed justification for design and process changes. As the actual freeze gate is approached it will take higher authority to approve activities that threaten the planned schedule.
I believe DFMEA’s offer an interesting structure to approaching how to take action based on risk that may apply here. All the risk that is captured in a Design Failure Mode Effects Analysis (DFMEA) is associated to risk to the product or the end user. The “Severity” score relates to event in the field, injury?, inconvenience?, loss of revenue? The “Occurrence” ranking correlates to either a speculated likelihood or a projected percentage of failure based on test or analysis. What about using that methodology of creating a quantifiable measurement of risk factors and applying it to decisions on program schedule and budget?
Previous to the introduction of the DFMEA method teams still accessed severity of failures and the likelihood of occurrence. This happened in informal conversation, special meetings or simply by the coffee pot. By acknowledging that this process of accessing risk through metrics, instead of informal discussion, then driving actions a new tool was created. The Failure Mode Effects Analysis not only ensures this process occurs in a program, it improves it. Efficiency is created due to the inclusion of a multi-disciplinary team in all portions of the analysis. Endless debate is truncated by quantitative analysis, resources are directed to areas of the product and program that will mitigate the most risk. Actions to address issues don’t “fall through the cracks” of the program because they are captured in a live document.
The program activities are impacted by design failures as well. A design issue that is identified in development now requires previously unplanned schedule, resource, or both to be mitigated. The impact to the program is discussed to select the most optimal solution. But just as previous to DFMEA it is typically done in an informal manner. Design failure driven program decisions occur with undetermined team members and the critical decision factors change. A method to guide this process is needed, the same as affect to the product decisions needed DFMEA.
I am developing a process called Program Risks Effects Analysis (FMPEA). This create a quantitative method to determine if the risk associated to a found reliability risk should be mitigated or addressed in a later stage. By including input from both the technical and business sides of the program a well informed estimation for risk to the program can be made. The decision is calculated, not estimated by individuals, and the risk calculation process is documented. It’s a DFMEA for the risk to the program of found and hypothetical design issues. I am looking forward to seeing it in action soon.