ARM, Single-Chip PC, or other architectures for audio stuff?

It's not life support. Also, you are never alone in that field. It will be reviewed ad nauseam, documented until the cows come home and agency submitted. This is why the sometimes encountered thinking that comment lines comprise "documentation" has to be pulled right away. Before the first line of code is being written a master SW document must be generated and almost completed. Just like it is with my hardware design. The module spec is #1, always. Same with aerospace designs.

Med tech is similar to flying. A pilot first maps out the flight path, files the IFR, gets weather forecasts and so on. Then he fires up the engines. Not the other way around.

I know folks who do medical in the PDX area. The modus operandi is to prototype an entire working system using typical commercial design rules. Then people write the specifications you're talking of from the working prototype. Then all the design files (that would never, ever pass FDA inspection) get backed up to a CD and wiped from the network.

Then the design team designs the whole thing again, from the written specifications.

The companies involved are all successful, so I guess it works.

I believe that is not legit. If something happens, an investigation occurs and they find trails of this (they always tend to find those), someone higher up might be in hot doodoo.

So how do they do clinical trials, or even animal trials?

As long as they don't get caught. I am also quite certain that this method is inefficient because you essentially do the project twice. One can still be successful with that if the market allows for very fat gross margins. But one has to ask, how much more successful could they be? How much moeny do they leave on the table by the inevitably longer time-to-market?

In all my cases we start with the specs, design towards them and keep a meticulous design history. The specs could change, for example based on animal trial results, but it's all nicely documented and nothing gets swept under the rug. The Federales might some day want to see that, and it has to go from conception of the idea to production ramp-up. They don't like to see a several-months long gap.

Y'know, it was presented to me as the safe way to do it -- you learn all about what really needs to be done by doing the initial turn, then you start over again with a clean slate to do it again while really knowing what you're doing.

I wasn't close enough to the process to know at what point they did the initial working prototype, but I know these guys and they're all meticulous and honest, they're certainly not "sweep it under the rug and hope" types.

But that doesn't necessarily mean it really is :-)

It's IMHO strange. Once the spec sheet is written we usually have a pretty good grasp of what needs to be done and then start to "peel the onion", layer by layer. It all gets documented. That way we can use that information "as is" later and build on it. Most of all we don't waste time building a whole big machine that then has to be thoroughly destroyed.

Well, if they make 100% sure than nothing, absolutely positively nothing, from that trial build ever makes it into the other phase it might be ok. I consider that risky.

Example: In a module spec you are supposed to not just explain how the XYZ wombombulator circuit works but also why you picked this particular architecture and what that decision was based upon. So one would occasionally write "We tried this, that and the other thing and the result were ..." .... *MEEEEP* ... thin ice, thin ice. Because if that wasn't documented or purged it can raise an auditor's eyebrow.

So every developer coming from non-med or non-safety has to be flashy-thinged before he may do medical things?

Doesn't sound reasonable.

Oliver

That sounds similar to reverse-engineering a product. One team (or separate company) does the product analysis and based on that, writes a functional specification. A completely different team then creates a new product based only on that specification.

Don't know what you mean with "flashy-thinged". Training? Yes, they do need to be trained in things such as design history, validation rules and so forth. Universities don't teach that, except maybe for the biomed engineers.

Well, we don't get to decide what's reasonable or not. In my line of work the FDA, FAA, UL and others do that.

No. I'm sure he meant "flashy-thinged" as in the "Men in Black" movies, where there's a device that goes "flash" and wipes your entire memory of the previous 'n' seconds of your life ('n' quite freely configurable).

And yes, it did come across as if people were somehow not allowed to remember anything about how things might be designed outside the med-safety field, for fear they might contaminate the medical device design with uncouth ideas.

The unsafe-prototype-first idea does seam like a rather good one at face value. If nothing else it could remove the terrible risk of going through all that massively expensive, agency-approved process, only to discover that some kink you would never discover until you have a prototype in hand, renders the whole thing unusable in actual operation.

I haven't seen that movie. We barely watch any modern movies, mostly older stuff. They were usually better :-)

It's perfectly ok to remember. I did that myself, brought a few ideas from Radar into the world of ultrasound. Nothing wrong with that.

I've never had that happen in over 25 years of medical device design. Same with other heavily regulated areas such as aerospace. We always design directly towards the spec and towards a releasable product, documenting the progress extensively.

Aside from wasting lots of time the risk with building an "off-the-books" first prototype is that you discover something in it that works remarkably well. So you keep it. Now the temptation is huge to just snip that section out of the schematic and copy it over into the "on-the-books" design. Or if purged you'd do it in your head because nobody can forget a beautifully working circuitry that fast.

It's not about uncouth ideas. The issue is documentation. Agencies may want to know how you arrived at this grandiose idea of the XYZ wombombulator. Now, all the trials and errors had happened in the "off-the-books" design where all notes have been incinerated in the corporate wood stove. And Leroy who had designed this section is no longer with the company. He is on a six-months trek in Nepal. So you can't even call him but the agency folks will waltz in next week for the big audit.

I am not making this up. I have seen stuff like this happen and it was not pretty. One large company (a competitor of ours) even got shut down by an agency after they found this sort of disarray.

(commerially designed prototype as spec basis "is not legit")

of course. I have to admit that I like the German verb "blitzdingsen" more.

Exactly. And optimisations can be done in a efficient environment. The method described by Tim sounds reasonable.

Oliver

I think you would like it (sequel of 3), quality entertainment allright.

I am mostly digging out British stuff - mainly from this century, they seem to be inexhaustible when it comes to producing good films, series, miniseries.

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

------------------------------------------------------

I can only advise anyone who plans to work in a regulated field to stick to the law. It is explained in plain non-legalese language in this presentation, someone has marked it up with notes but it's still readable:

Sheet 11 shows that the design history documention must start at conception and not at some point thereafter. It has been like that since the 90's. Violations of these rules, such as faking a later conception date, can lead to project shutdown or worse.

I've never liked SciFi much. I know that's kind of unusual for an engineer but at least I did see some episodes of Spaceship Enterprise as a kid, so I know what a tricorder is :-)

BTW, nice photo work. I really like the take-off of a bird here, that requires almost millisecond precision to capture it and I've never been that lucky:

I don't think there was any implicationg of faking. The descirption I saw was build a prototype using methods unsuitable for a production article (that's normal for prototypes). Then use the prototype to develop the specification for the production article. Then the prototype design gets taken out of the process (archived, not "disappeared" or anything like that) and the production article is developed under the rigorous processes required for such things.

Maybe in the historical embedded device world involving 8-bit microcontrollers with a few K of code, it's possible to write a substantially complete spec without first actually building and testing anything. With complex software, "build one to throw away" has been accepted wisdom since the 1960's. I think the phrase came from "The Mythical Man-month", a classic on software engineering by Fred Brooks.

I don't understand the objection to the prototyping process. If I hear that some super-safe airplane was developed using formal software verification, wind tunnel tests, x-raying every weld, yada yada, that's great, that's what they're supposed to do. That before the formal process started, the design was first conceptualized by hacking out a plywood mockup in the back lot doesn't seem especially bothersome, and if anything it seems reassuring, as long as the final result implemented all the necessary checks and tests. Can someone explain the issue?

"Taken out of the process" is not legit, per FDA rules. Not as long as any part of the design is later used to derive a next phase or has to do with the conception phase. But hey, it's not me who invented the rules. I just have to live by them. Always had to.

That does not really work in medical or aerospace. I also try not to do that on other projects.

Ok, I'll try: Prototyping is ok and I do it all the time. Provided it is all documented and properly archived, building up a design history repository. Meaning that when the guys have their meeting around the crumpled heap after their plywood mockup hit the big pine tree the findings get recorded. It is very easy to draw a conclusion, act upon it, have success with it and then forget to record the conclusion.

The other risk is that things can get papered over when a schedule crunch happens. Nobody takes the time to document or maybe it's inconvenient for other reasons. A perfect example is the new Bay Bridge in California where they even did that way into the production phase. We now have a super expensive and massive structural piece with serious flaws in it.

The classic case of how it can go wrong when using parts of a previous design (in this case software of a real product) without thorough documentation is the Therac 25 radiation therapy system that ended up maiming and killing patients:

That case might have triggered the FDA to institute the rules I've tried to describe.

Snfd06c00.pdf

Y'know, it's a very high horse you're riding, but it's total BS.

When was the last time you wrote down Maxwell's equations on a board and derived and derived and derived, and came up with a pacemaker? It's just not done! You always start from some previous work.

But why stop at Maxwell? Write down your own equations, if you don't want to build on previuos work!

Not my rules, it's those from agencies. I know (well, knew ...) a large company where many people must have thought this is all baloney. It was shut down by the Federales. They didn't ride into town on horseback though like in the olden days :-)

Of course they don't go to those extremes. What they want to avoid is design decisions based on something that worked once but nobody really knows the details anymore. "Oh, wait, I've got a well working subroutine somewhere on a CD". That's how accidents such as Therac 25 have happened. They used poorly documented older software routines from the past and nobody knew or remembered that they were only supposed to be used if the system had hardware interlocks. Which the old system had but the new one that went into production didn't. People died because of that.

From well documented and design-reviewed previous work. Else, no.