{"id":1770,"date":"2018-01-18T15:04:30","date_gmt":"2018-01-18T23:04:30","guid":{"rendered":"https:\/\/blogs.plm.automation.siemens.com\/t5\/Teamcenter-Blog\/Model-based-Product-Safety-amp-Reliability-forward-vs-backward\/ba-p\/460821"},"modified":"2026-03-26T08:50:27","modified_gmt":"2026-03-26T12:50:27","slug":"model-based-product-safety-reliability-forward-vs-backward-looking-design","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/teamcenter\/model-based-product-safety-reliability-forward-vs-backward-looking-design\/","title":{"rendered":"Model-based Product Safety & Reliability: forward vs backward looking design\u2026"},"content":{"rendered":"

No one seems to notice product safety & reliability until something goes wrong\u2026<\/em><\/strong><\/p>\n

Forward thinking\u00a0Product Safety & Reliability is about moving from isolated reliability and safety analysis processes (including disconnected FMEA tables, Fault trees, etc.) to integrated reliability models that can proactively influence product development towards safe\/reliabile\u00a0products.\u00a0\u00a0Which way are you facing?<\/p>\n

While working on one project, I was the designee to deliver bad product safety & reliability news in a project review\u2026 After the swearing was over, the program manager put it this way, \u201cthis is like driving a car looking thru the rear view mirror, I can see the problem after I\u2019ve run over it.\u00a0Why don\u2019t you give me something I can see it coming so I can avoid the problem\u201d. Since then I\u2019ve been looking for ways to implement forward-design thinking to predict product safety & reliability problems\/reduce risk vs. trying to fix them after we\u2019ve run over them (check previous blogs about how a connected product architecture is critical to forward looking design<\/a>)<\/p>\n

\"Driving
Items in the mirror are closer than they appear<\/figcaption><\/figure>\n

Systems Engineering\/Product Safety & Reliability engineers are in the business of reducing technical risk, avoiding future problems vs saving money (see different blog\/discussion about justifying systems engineering<\/a>); which is part of our problem since we lack evidence that we are as good as we say we are (see MIT\/NSF Research on \u201cNobody Ever Gets Credit for Fixing Problems that Never Happened\u201d <\/a>\u00a0for a good read on this topic).<\/p>\n

Yet, when visiting organizations with million(s) dollar mistakes, the people who made the mistakes are still there because you can\u2019t find the evidence that their decisions lead to the problem (It\u2019s like paper training a puppy, you\u2019ve got to catch them in the act)\u2014their decisions are separated by time & space from the consequence (i.e. engineering decision relativity).<\/p>\n

\"Don't
Credit: Gary Larson The Far Side<\/figcaption><\/figure>\n

The recent headlines of the emergency notification false alarm in Hawaii is a timely case in point, the connection to the person that hit the button was obvious<\/a>, but who designed a system to allow a single mis-button push to trigger the warning and another way-longer number of minutes to figure out how to retract it (see you don\u2019t know who that is either)?\u00a0 Apple and others have learned their lesson which is why it takes getting through a three (3) deep warning system before allowing you to clear\/reset your cell phone\u2014i.e. are your really, really, really sure?<\/p>\n

How come we keep repeating the same product safety & reliability problems\u2026 <\/em><\/strong><\/p>\n

If we accept that bad design\/architecture may produce bad results, let\u2019s at least learn from the experience and rather than look for scapegoats, lets at least put a connection between the problem and the root cause so we don\u2019t repeat the problem and maybe even feed it forward to the next project to design a more robust solution. I\u2019ve been keeping a \u2018problem resurface metric\u2019 by industry for some time\u2014how long does a problem once solved take to come back:<\/p>\n