Posts Tagged ‘product development’

Systems Engineering In Medical Device Design – Production, Part 1

Sunday, February 24th, 2013
     Done any remodeling lately?  If you have, you’ve been faced with countless choices regarding design and materials.  Even a relatively simple decision such as putting in hardwood flooring requires many considerations.  What type of wood?  What grade?  How about the stain?  Should it be factory stained and sealed, or should the flooring be installed by single board, then stained and sealed in place?  Ultimately, your decision is based on your requirements with regards to cost, durability, and personal style.

     Now imagine the decision making process that is required to produce a medical device.  We’ve been discussing this complex process during our series on medical device design utilizing the systems engineering approach, a systemized approach to product development, design, and manufacture that is used within many manufacturing arenas.  Its objective is to relate the requirements for manufacture, regulatory compliance, sale, use, and maintenance of the product to specific design criteria for functionality, durability, and safety.  By doing so, the systems engineering approach ensures that the product meets or exceeds all requirements.

     Last time we wrapped up our discussion on the Development stage of systems engineering by discussing field testing of medical devices assembled during Preproduction.  Problems encountered during this phase result in a comprehensive review of the device design and instructions.  When all issues have been resolved, things move on to the manufacturing phase and full commercial production.

     During the Production stage, engineers make continual assessments of the manufacturing process and ongoing adjustments are made to the device design and manufacturing protocol as necessary, this due primarily to changing stakeholder requirements regarding cost reduction.  In the competitive marketplace, cost reduction is a never-ending quest to maintain profitability in view of changing economic and market conditions, and this must be done without compromising the quality, safety, and effectiveness of the device.

     For example, suppose a medical diagnostic imaging machine was designed to be fitted with a machined metal gear in one of its mechanisms.  The manufacturer specifies that a $10 decrease must be made in production costs so it can continue to be sold at an acceptable profit margin.  After reviewing the design, engineers discover that substitution of a molded plastic gear would reduce manufacturing cost per machine by $12.  This is a common scenario, as plastic parts are often substituted for metal to save on cost.

     Plastic versus metal?  How can that be an acceptable swap?  In many cases, it can be.  Mechanical stressors are analyzed, and if the plastic gears meet durability requirements as well as their metal counterpart, they are substituted.  During the Preproduction phase these plastic gears are used in both lab and field testing, where they are put through the rigors of real world use.  If they perform acceptably, they are made a permanent part of the device’s design and used in commercial production.

     Next time we’ll continue our look at the Production stage to discover another way that systems engineering can facilitate cost reduction to meet stakeholder requirements.

___________________________________________

medical device design

Forensic Engineering, Mom’s Way

Sunday, September 20th, 2009

     When you were a child, were you lucky enough to have someone who inspired you?  Someone who filled you with the wonder and passion needed to pursue a fulfilling career?  Was it a parent, a teacher, a friend?  For me, it was my mother.

      Mom grew up on a farm in west-central Wisconsin back in the 1930s.  The Depression was on, and she and her siblings learned how to be resourceful at a young age.  That’s how you survived in the days before rural electrification, high speed communication networks, interstate highways, big box stores, and many other things that we take for granted in the United States today. 

      When I was a kid back in the ’60s, my mom was the plumber, carpenter, mechanic, and general fix-it person of the family.  No, my father wasn’t dead or absent, he just wasn’t handy, nor did he desire to be.  Unlike many housewives, Mom didn’t call for professional help when the vacuum cleaner or washing machine was on the fritz.  Instead she learned how they ticked, determined what she had to do to get them working again, then got busy fixing them herself.  Whether it was a lack of money to pay a professional for their services or a genuine appreciation of the subject matter that motivated her, I don’t know.  I just know that Mom, whether she realized it or not, approached technical challenges in our home much like a systems engineer.  She had an eye for improving product design and used forensic engineering skills to get to the heart of her dead appliance’s problem.

      Mom’s lack of formal technical training didn’t hold back her fix-its, and the basement workbench in our home was similar to a product development laboratory.  As her apprentice on household repair projects, Mom would get me involved.  It didn’t take long before I, too, understood how the timer in her washing machine made valves open and close, how the motor in her sewing machine made the needle move, how the toaster turned on and off, and how to fix a clock that wasn’t keeping time. 

      The education that my mother gave me formed a real world technical foundation for my future studies of engineering in college.  Mom’s school gave me a practical understanding of the workings of machines and other devices that many of my classmates lacked.  And the desire to keep things hands-on has stayed with me through my career, where the sanitary conditions of an office environment were often supplemented by activities that would continue to get my hands dirty. 

      I still love to take things apart, problem solve, and innovate.  Thanks to Mom, I’m the engineer that I am today.  My writing skills I had to pick up elsewhere…

_________________________________________________________________

mom

You Can Make It, But They May Not Buy It

Sunday, August 9th, 2009

     When Thomas A. Edison was a young man in the late 1860s, he made the same mistake that many of today’s novice inventors make:  he concentrated all of his efforts on developing and patenting an invention without first doing a thorough market study to see if it had a good chance of being a commercial success.

     Edison’s first patented invention was a legislative vote recorder (US Patent No. 90,646).  The device was surprisingly innovative, enabling legislators to cast their votes in record time.  It made the entire voting process far more efficient than the system of roll call voting that was employed at the time.  Edison had no doubt that it would be a commercial success.  Who in their right mind wouldn’t want something that was efficient and saved time?

     Pumped full of optimism, Edison took the embodiment of his invention to Washington, D.C. to demonstrate it before a congressional committee.  He was shocked to find that no one on the committee was impressed with what he’d done.  And to add insult to injury, the Chairman of the committee could not resist saying, “If there is any invention on Earth that we don’t want down here, that is it.”  Swallowing his pride, Edison was forced to abandon his invention.

     If Edison had taken the time to study the market prior to proceeding with his invention, he would have discovered that it would be a foolish waste of time and money to pursue development of the vote recorder past the preliminary concept phase.  But the political process was not something he was familiar with, much less the slow pace of roll call voting that Congress employed.  He was unaware that this political maneuvering enabled politicians to easily filibuster bills and make deals behind the scenes in order to sway votes.  He would find out too late that his was a notion they did not care to support. 

     After his vote recorder demonstration crashed and burned, Edison vowed to only work on inventions that people actually wanted to buy.  He ultimately created the world’s first industrial research laboratory that pumped out thousands of inventions that made him a millionaire and created a technological legacy that remains with us today.

_________________________________________________________________

igloo

The Key To Successful Product Development

Sunday, July 12th, 2009
     We’ve all seen instances where someone was making something up as they were going along.  And the end result is usually not very good.      It’s no different in the product development process.  If an engineer designs a product without identifying all requirements, then the product may not meet the expectations of its end user.  Worse yet, it may pose a hazard during use and open up a world of potential liabilities.             There are three basic requirements for successful product development:  functionality, performance, and constraint.  A functional requirement specifies the necessary task, activity, or action that the product must be able to achieve.  A performance requirement specifies how well the product must perform under specific conditions.  A constraint requirement sets out the constraints under which the product must operate.  An example would be compliance with government regulations and industry standards. 

     In every successful product development project the goal is to create requirements that are well defined, well specified, and traceable, meaning each requirement should include the name of its originator and a space for their signature, indicating approval.  This eliminates any spinning-of-the-wheels due to misunderstandings, finger pointing, etc. 

     Well defined requirements are, of course, tied into specific design criteria and form the basis of a detailed design specification.  These criteria guide the way through all stages of the product’s development.  Each requirement should be listed, along with the rationale for its creation and a test method to verify that its objectives have been met. 

     Requirements are only good if they are achievable, verifiable, unambiguous, complete, expressed in terms of a need (not a solution), and consistent.

     Otherwise, what’s the point?

___________________________________________________________________

requirements2