in Product Development | No comments

I Hate Wires

—- 8< ————- 8< ————- 8< ————- 8< ————- 8< ———

Does this conversation sound familiar?

KM: How’s the product design going?

EE: The PCB designs are done.

KM: How do the boards connect to the motor, heater, laser, each other, etc.?

EE: I put connectors on the board. We’ll wire them up.

KM: When will you do that?

EE: When the boards arrive.

I have learned not to be too subtle while having this conversation because others often don’t get that shiver of fear rattling down the back of their necks like I do. There are very few things more frustrating than spending a day or more in the lab wiring up a new system when missing your deadline is already imminent for other reasons.

Fortunately, I’ve found a very pleasant solution which I now brutally evangelize: avoid wires. I ‘m not pushing RF or IR: I mean wireless in the “less wires” sense. Even before a product is a twinkle in anyone’s eye I’m lobbying to remove wires. I know that’s maybe a bit unreasonable but if you don’t have lofty goals then you’re doomed to mediocrity.

So how do we do it? We use those very PCBs that required the wires in the first place. Instead of choosing connectors which must mate with wires, we choose board-to-board ones. Instead of making boring, rectangular PCBs, we make cool, odd-shaped ones that fit intimately with the other hardware bits. Connectors to the outside world are put on the same plain; controls, switches and indicators are chosen and located so they are board-mounted. Finally, we do all of this in a way that doesn’t make the Industrial Designers hate us.

I can picture the unbelievers in the room shaking their heads: “How can all of that be ‘simpler’ than just wiring things together with a good, old-fashioned wiring harnesses?” Well, the simple answer is that it’s not, but often only by a tiny little bit. Even wiring harnesses must be designed, wire lengths specified, connector housings and crimps chosen, BOMs built and procedures written. Of course this assumes that we’re going to document the wiring properly. We are, aren’t we?

If the effort is a wash, what’s the real advantage? Timeline. Back in the early stages of the detailed design of the product, the interconnection strategy can be worked out through collaboration between the electrical and mechanical engineers. The boards and mechanical parts are designed pretty early in the process and so the interconnection is too. This is in contrast to the week before the first prototype ships if you defer it all to a complex wiring harness.

Let’s not fool ourselves though, there will always be wires. How do we prevent even the small amount left from causing grief at the last moment? We design it as best we can up front. Wire lengths and routing can be estimated early during design; components can be chosen back then too. It all can then be built early, even subcontracted. When the boards are in and the initial power-up and debugging took longer than expected, you can at least take comfort in knowing that you won’t waste that day or two mucking around with crimpers and things when you should be tackling the deeper problems that you haven’t even discovered yet.

Let’s not leave it down to the wire.

—- 8< ————- 8< ————- 8< ————- 8< ————- 8< ———

 

in Product Development | No comments

Rapid Learning, Medical Device Development, and the Fine Art of Making Bread

Loaf of BreadA number of Rapid Learning Cycle techniques have been proposed in the last few decades. Acronyms like PDCA (Plan Do Check Act) or LAMDA (Look Ask Model Discuss Act) are meant to instill a structure to the design investigation process. To me the biggest emphasis I take from these ideologies is the need to understand the users, environment, and what the ‘real’ constraints are. The classic example I have heard is one involving a company developing a bread making machine that enlisted a master baker in order to show how bread needs to be stretched in order to produce the fluffy stuff we know and love – who knows how to knead bread today anyways!?

But I digress, the premise of taking time to plan and investigate early in a design process is key to delivering the right product to the marketplace. The scope of these investigations should include the entire value chain, from consumer packaging, disposables, reimbursement codes, the user’s state of mind, all the way to how the consumer disposes or services the device. By taking the time to investigate by looking and asking the right questions to experts early on in the design cycle – us engineers can then be thinking of these things early on in the product design cycle. Experience shows that this will provide the best value to the customer and help put the right product on the marketplace.

in Business, Industrial Design, Product Development | No comments

Prototyping and Its Relationship to Innovation in Medical Device Design

All products and services are eventually commoditized.  The only way to maintain leadership and profitability in a market is to innovate.  Innovation in and of itself is pointless unless it finds a useful and compelling application with a group of financially capable and willing end users.

This being the case, innovation is the key element in determining whether a company will grow and thrive in the future.  The best way to encourage a stream of meaningful innovation within a business is to create a culture of frequent and rapid prototyping – in both products and services.

As a product development consultant, I’ve watched many companies over the last 25 years struggle to implement some form of innovation agenda.  A few seemed to ‘get it’ early on, while others came to grips with the need to innovate only after the brutal assault of margin eroding competition hit their once protected local market. Nowhere is this more evident than in the medical device development industry.

As I think about this all, a few questions and lessons come to mind.

Why is prototyping the equivalent of a good insurance policy?

  • Prototyping reveals hidden assumptions.  It makes the implicit, explicit.
  • Prototyping decreases risk by exposing and purging bad ideas.
  • Frequent prototyping increases the likelihood that new and interesting options will open up.

What chokes off the benefits of prototyping?

  • Early prototyping should have loosely defined objectives and outcomes.  Being too specific early in the process greatly reduces the opportunity for the unexpected…..and its benefits.

Who are the innovators and who makes the prototypes?

  • Prototyping is essentially a democratic exercise in that it breaks down internal barriers, invites broad participation and provokes an informed critique of ideas, all highly desirable outcomes in the early stages of medical device design.
  • Designers and others with the skill to make the intangible tangible may be the ones who can interpret, sketch, fabricate and/or sculpt a concept, but idea creation and review should be open to a broad spectrum of stakeholders.  It should not be limited to formal ‘product developers’.

How should prototypes be made?

  • Early prototypes shouldn’t be highly finished models created by craftsmen, rather they should be quick mockups, just sufficient to communicate a preliminary concept.
  • Common and easily accessible materials and methods of construction should be used to create mockups.  Materials that are accessible, quickly understood and fashioned by non-technical participants are usually the best choice.

What are the benefits of prototyping?

  • Prototyping gives tangible expression to abstract thought.  It’s a process that naturally fits with the way people think and work through their ideas.
  • Separately prototyping a multitude of small, discrete components of an overall assembly increases the likelihood of overall system level ‘fit’.
  • Prototyping is counterintuitive at first, in that it appears to delay ‘time to market’, but in the end it serves to reduce overall development time.
  • Prototyping improves quality and ‘end user’ acceptance by allowing for the testing of ‘use models’ and customer assumptions.
  • Prototyping gives opportunity to, and helps manage the alignment of product development activities with an organizations overall business strategy.
  • Prototyping builds a company’s brand by ensuring that the final product does in fact deliver on a corporation’s promises.

If prototyping is a prerequisite to innovation, and a culture of innovation is fundamental to future business success, then it makes sense to learn more about how this activity can be introduced into and managed within your company.  If you want to learn more, send me a note and we’ll arrange a time to chat.

 

in Regulatory | No comments

FDA Pilot Program for ISO 13485 Certified Medical Device Manufacturers

On Jun 5, 2012 the FDA is officially launching ISO 13485 Voluntary Audit Submissions Pilot Program that will allow ISO 13485 certified companies to submit ISO 13485 audit reports from previous 2 years, copy of current ISO 13485 certificate, FDA registration number, company contact information and ISO 13485 auditor information. If the submission is accepted by the FDA, i.e. the compliance status can be established, the manufacturer will be removed from annual FDA inspection list. Inspections conducted ‘for cause’ as well as ‘follow up’ and PMA inspections would not be affected. FDA is still debating how many years in a row this process could be used by a particular manufacturer.

This is great news for manufacturers that are subjected to both ISO 13485 and FDA 21 CFT part 820 inspections; the burden of the inspections will be significantly reduced.

For more information please see FDA guideline as well as Emergo Group blogs on the subject.

in Engineering, Product Development | No comments

Don’t Interrupt Me!

An interrupt is a software routine which is executed whenever a specified hardware event occurs. They are often used in real-time microcontroller based subsystems of medical devices to ensure that the data associated with an event is processed in a timely manner. Typically the microcontroller has many event sources such as UARTs, ADCs, SPI ports, digital IO, etc. Often handling of all of these events using separate interrupts can lead to a bunch of problems.

Many interrupts may inject large, unpredictable latencies in the processing of other code. Each hardware system has a minimum rate that it must be serviced for it to continue working properly but when a number of event sources fire close together, there may not be sufficient time to service them. Bugs associated with the interactions of multiple interrupts often occur infrequently making bug hunting difficult. Debugging with a scope can be difficult: triggering is challenging and the data tends to jump around wildly even under normal circumstances. It’s difficult to analyze all the ways that may lead to problems. Finally, determining the true execution time of an interrupt is difficult, either by analysis or measurement.

So what can we do? Most event sources can be analysed ahead of time to determine their minimum required servicing rate under worst case conditions. Instead of having a separate interrupt for each event source, we can have one, timer-based interrupt running at a rate chosen so that all event sources can be processed. The rest of your code – which is usually slow-to-execute stuff like display routines or big calculations – can happen in your mainline loop.

This one-interrupt system is totally deterministic. Each event source is polled at the same time in the cycle. When you scope, the servicing code is rock steady on the trace. It’s relatively easy to tell if some of the servicing code is taking too long for its allotted time because the next cycle of the interrupt will be late. You’ll see this easily on the scope and it is also readily tested and flagged within the firmware. It’s even possible to cycle-count every possible path through the assembly or disassembly to analytically determine absolutely if there is enough time.

One thing you have to watch out for even with this strategy is that there is enough time to execute your mainline code as well. I find that a good rule of thumb is to aim for the microcontroller to spend about half of its time running interrupts and half on the mainline code. Additionally, that mainline code must loop sufficiently quickly under all circumstances so that each of its constituent routines gets the airtime it requires. For example, you can’t send a whole page of text off to your LCD and still expect your PID code to perform as expected.

That’s not to say that the one-interrupt strategy is foolproof or is suitable for all circumstances. I would say though, if you find you have to use more than one interrupt, make sure you think very carefully about all the circumstances where they might run back to back and whether that leaves them enough time so they don’t miss out on the next event.

I have used this one-interrupt architecture in every firmware project I have ever worked on and found every time that I’ve been able to squeeze just about every last drop of goodness from my microcontroller and debugging has been straight forward.

in Industrial Design, Product Development, Regulatory, Uncategorized | No comments

Risk Management as a Design Tool in Medical Device Development

How do we define the quality of a medical device? What attributes cause us to come to the conclusion that a device is a “quality product”? The safety of the device, if mentioned at all, usually follows fit and finish, reliability and performance in the list of attributes we think of in connection with quality. The expectation that the device be safe for both the care giver and the patient is generally assumed as a requirement and expected as part of good engineering practice. Consequently the formal processes of risk management are often overlooked or left until late in the development process.

The tools for risk management and reliability engineering are very similar. The basic analysis tool is the Failure Mode Effects Analysis (FMEA). Just as it sounds, FMEA involves analyzing the various possible failure modes to determine which have an effect on the safety of the patient or caregiver. Once these failure modes are identified, mitigations are developed to eliminate or reduce the effects to an acceptable or justifiable level. If the risk is severe it is valuable to perform a Fault Tree Analysis (FTA) where all of the combinations of actions and events that can create the failure mode are documented in a flowchart. FTA is a tool originally created for improving reliability by identifying possible failure paths and redundancies. Used properly, both tools can greatly increase the safety and reliability of the design.

ISO 14971 is the standard for risk management in the development of medical devices. Annex E of the standard includes a list of typical hazards which can be used as classes of failure modes. The obvious ones are electrical, mechanical, biological and functional. Additionally use error is included, surprisingly, one of the most common types of failures. More patients are injured by the incorrect use of a medical device than the failure of the device itself. Anyone who has used more than one microwave, cell phone or computer application knows that not all user interfaces are created equally. Confusing controls and bad ergonomics should not survive the design process.

Risk management isn’t just a burdensome regulatory process it is good engineering practice. Good design is a term which can generate hours of discussion but at minimum it should result in a safe as well as an effective device.

*This blog post was written by Rob Keur, QA Manager at StarFish Medical