I've done a few safety-critical embedded devices for medical equipment and an air traffic control system. We used Linux/C so we didn't kill people.
The combination of "medical device" and "touch-based user interface" started me twitching. Some things to bear in mind are (1) will the interface work if the users are wearing rubber gloves? (2) there could be a problem with an infectious agent transferring from a patient to a doctor's gloves to the screen then to another doctor and another patient.
At my workplace, we've tested capacitive touch panels with rubber gloves. Cleaning the device could be an issue, but is more general, since the same thing could happen with regular pushbuttons.
But I certainly defer to your expertise. These are the subtle issues that us non-medical guys overlook.
There are clearly a lot of people very informed people in this thread, and a lot of goofs who have never gone through the FDA validation process (or what seems to be any other validation process other than Heh My Node.js unit tests pass!) here. Some people are recommending RasPi and holy shit someone recommended JavaScript?! Who's going to be the one who tells lil' Tommy his grandma died because her dialysis machine confused === with == ahaha. Someone suggested LISP and Go? Holy fucking god. Good rule of thumb -- immediately disregard any advice of those advocating any platform that's advocated by the "hacker" or "maker community" unless those guys do embedded for a living and have graduate degrees (Nohl, Bunnie, Tarnovsky).
Like @Matthias247 said, QNX and GreenHill are easy to get up to speed from other RTOS, well documented, and arguably most importantly has name recognition so it'll be cheaper to get into hospitals, easier to get through the FDA certification process, and easier on your chequebook when you get your liability insurance. @viraptor offers good advice as to why RPi's are a dumb dumb dumb idea to base your product off of (who knows when they'll EOL their product?). Every component on your BOM should be from a reputable vendor who can tell you with the utmost confidence how long component X will be in production, the lead times typically seen, etc. @xzion did class B/C devices and mentioned EOL'ing so take his advice too. I'd even PM him and offer him a chunk of change to audit your unit before cert testing. (5k for someone to catch that EM your engineer didn't because his H-probe was oriented in the wrong direction is worth every cent). As a manager, I'd actually keep a resource on retainer who has taken an FDA embedded product to market as a consultant for my engineer to use as much as he wants, regardless of the cost (presuming my engineer hasn't done so himself, in which case, yay!). @analog31's definitely got good advice for his field but an FDA class C's requirements are entirely different from scientific equipment. Your $300k Keysight network analyser or $700k SEM might be okay to prototype against, but when my scope crashes a tech comes out and fixes it the next day- people don't die. When my Illumina sequencer fails, a post-doc might lose a week or two of work, bummer man, there goes his JAMA article, but no big folly. You can shop around a proof of concept for kit like that, (and likely have them take delivery of your rev 1 based on that same platform!) but I'd be very very concerned about EOL'ing anything on my BOM.
Make your BOM as jellybean friendly and as reliable as possible from the best vendors you could possibly afford. I strongly advocate ARM's for the following reasons.
1) IDE - Keil's MDK is basically the best IDE I've ever used (and I've used a lot). I can't even begin to delineate the functionality of it, just download the demo. It's better than having a bond-out chip and an in-circuit emulator with live debug. Really, it's crazy good and it's "free" (lacking some functionality) because ST subsidized it as a loss-leader (the first hit's always free...)
2) CMSIS-RTOS has a not-too-steep learning curve such that you could swap in any given engineer who's worked with on QNX4 and jump right in (for me, the learning curve was about as painless as Java 1.6 -> C#2 => ~2 weeks). Works on any M3 or higher (you aren't locked into any specific vendor), even licensed out with everything the IDE is reasonably priced as is the OS. So you don't run into the "Jane Street OCaml / Haskell shop hiring problem" of having a few pool of very very talented applicants, who are all in high demand as a result of their specific skillset. A good engineer won't have a problem.
3) Again, no specific vendor! If ST goes out of business (haha yeah right), NXP (a division of Philips) would definitely supply you with a same chip, with the same pin out, same package, same everything. Model everything on your BOM with a contingency in case lead times surge unexpectedly.
There are niche RTOS solutions out there (FreeRTOS works on ARM with a modicum of ST documentation. ST, Mentor, NXP, and all the other name-brands use it as the defacto standard if you're not going to go with a 'name-brand' RTOS.) eCos is probably the second pick with more of a hacker-community vibe to it, which, is probably good for getting that roto-copter's altitude up an extra few hundred feet but not really something you want your dialysis machine to be running on.
---
Here's an idea of what you're looking at (this is based on fed work from an engineering then from a bean-counter POV, but I've taken a Class B to market on the software side and it's got enough parallels that I feel this advice is pertinent).
Your cost breakdown is for first-product-to-market going to be 40% NRE for all the licensing, a board design engineer for your board layout (Cadence OrPCB / Altium 16 license), a software engineer with embedded experience (i.e., a good indicator is he's taken a lot of EE classes, or on the other end of the spectrum, has gone to the graduate level in theoretical computer science -- had great experiences with employees that fall into those categories) + Keil IDE or whatever, industrial engineer for your enclosures (Solidworks license) [you _might_ be able to bypass this step, but purchasing authorities ask "Can we change this font color" more often than "how efficient is it" - humans are significantly influenced by the aesthetics/how something interfaces with you. I'm guilty of this too, any industrial IP67 gear that feels chinsy, any relay that feels light, etc, I have a preformed biased against. (Aesthetics are a large part of Apple's value, along with exclusivity and status signalling; though, when I had my Macbook Air it felt like I could bend it in two, it's been on my desk for 3 years, and my daily driver is a Thinkpad I've neglected so much I'd have gone through 3 or 4 MBP's by now)
Legal and insurance will predictably be a fixed recurring (maybe 15%). Certification and re-spin costs can range from 5% to a lot more. Don't skimp on stupid things to save a few k here and there - pay a firm to do pre-EMI testing beforehand. Buy brand-name everything just as an insurance policy. $9 dollars extra for that precision thick-film resistor @ 10k vs $.13x10 might save you 8.70 a unit, but the engineering time it takes to find why your chip is clocking out spurious data but only once every 3 weeks at random times (oops, those resistors were 10% not 1%, which is normally fine except when you bring CE low for > x NS while doing Y, which heats up the bypass cap near Vcc increasing the ESR, and whoops, your cap's resistant factor is drawing an excess of current that shoulda went to Vcc! Again, Keil IDE helps so so much finding bugs like that.) Uh, yeah so, buy Nichicon and breathe easy. Use pre-certified industrial components that your competitors have already used if you can.
Office space can be finagled from other startups usually at pennies on the dollar. The commercial real estate market even in NYC is soft and I could get class-A space in midtown month-to-month at $3/sqft/mo (utils and furnished). I'd imagine SF is the only place where you'd have difficulty finding a reasonably priced space from someone who wants to let go of 800 or 1000 sqft. The rest is going to go to your marketing and/or sales team who will ultimately make or break you. Not for the faint of heart. If you don't have a mentor/family friend/guy on your board with existing contacts or know someone on the Cerner/EPIC/Meditech sales team with a big-fat Rolodex, you're going to be in for a tough, tough time. In government contracting (SBA, tiny contracts, fighting over the scraps really), we used to keep former decorated career military men on our board. They'd pocket 180k a year to literally fly down once every quarter and play golf while we got access to his Rolodex- medicine's the same.
Thanks for your input. (1) resistive screens and some capacitive screens can handle rubber gloves fine. (2) for our use-case (non-invasive blood sugar measurements) this is a non-issue, but out of curiosity: how is a touch screen different from a physical button (or the whole case) in this regard?
Have a look at panels on devices like ECG. Usually these don't even have real buttons exposed. A common approach here is to make the whole device as smooth as possible so there are no not-cleanable holes / ridges. For example displays will be actually behind transparent part of the case, not sticking out / in a hole. Same with buttons - all of the actual switches will be behind pillow-like buttons built into the case.
Edit: also when considering industry / medical devices, keep in mind that most touchscreen are not meant for the conditions these devices are in. You should be able to splash water / gel / oil / ... over it and just wipe it afterwards. They should also survive people who think they just need to press it harder if it responds slowly. Simple buttons (with extra protective cover) are more likely to survive this. Next time you're around in the hospital, check out how many of the button labels are completely worn down.
It should also be noted that a common practice in medical environments is to cover any control panels with a static-cling plastic sheet (usually light blue color, I imagine everyone is using the same brand) that can be quickly replaced between patients. So make your legends large and high-contrast.
There also used to be a website that ranked programming languages according to various parameters (which is faster, which is safer) by asking visitors pairwise comparisons (Which is faster - Matlab or C?). I was going to link it but can't find it unfortunately. Anyway I'm pretty sure C would come second-last in the safety ranking, right above assembly.
Comments
I've done a few safety-critical embedded devices for medical equipment and an air traffic control system. We used Linux/C so we didn't kill people.
The combination of "medical device" and "touch-based user interface" started me twitching. Some things to bear in mind are (1) will the interface work if the users are wearing rubber gloves? (2) there could be a problem with an infectious agent transferring from a patient to a doctor's gloves to the screen then to another doctor and another patient.
At my workplace, we've tested capacitive touch panels with rubber gloves. Cleaning the device could be an issue, but is more general, since the same thing could happen with regular pushbuttons.
But I certainly defer to your expertise. These are the subtle issues that us non-medical guys overlook.
There are clearly a lot of people very informed people in this thread, and a lot of goofs who have never gone through the FDA validation process (or what seems to be any other validation process other than Heh My Node.js unit tests pass!) here. Some people are recommending RasPi and holy shit someone recommended JavaScript?! Who's going to be the one who tells lil' Tommy his grandma died because her dialysis machine confused === with == ahaha. Someone suggested LISP and Go? Holy fucking god. Good rule of thumb -- immediately disregard any advice of those advocating any platform that's advocated by the "hacker" or "maker community" unless those guys do embedded for a living and have graduate degrees (Nohl, Bunnie, Tarnovsky).
Like @Matthias247 said, QNX and GreenHill are easy to get up to speed from other RTOS, well documented, and arguably most importantly has name recognition so it'll be cheaper to get into hospitals, easier to get through the FDA certification process, and easier on your chequebook when you get your liability insurance. @viraptor offers good advice as to why RPi's are a dumb dumb dumb idea to base your product off of (who knows when they'll EOL their product?). Every component on your BOM should be from a reputable vendor who can tell you with the utmost confidence how long component X will be in production, the lead times typically seen, etc. @xzion did class B/C devices and mentioned EOL'ing so take his advice too. I'd even PM him and offer him a chunk of change to audit your unit before cert testing. (5k for someone to catch that EM your engineer didn't because his H-probe was oriented in the wrong direction is worth every cent). As a manager, I'd actually keep a resource on retainer who has taken an FDA embedded product to market as a consultant for my engineer to use as much as he wants, regardless of the cost (presuming my engineer hasn't done so himself, in which case, yay!). @analog31's definitely got good advice for his field but an FDA class C's requirements are entirely different from scientific equipment. Your $300k Keysight network analyser or $700k SEM might be okay to prototype against, but when my scope crashes a tech comes out and fixes it the next day- people don't die. When my Illumina sequencer fails, a post-doc might lose a week or two of work, bummer man, there goes his JAMA article, but no big folly. You can shop around a proof of concept for kit like that, (and likely have them take delivery of your rev 1 based on that same platform!) but I'd be very very concerned about EOL'ing anything on my BOM.
Make your BOM as jellybean friendly and as reliable as possible from the best vendors you could possibly afford. I strongly advocate ARM's for the following reasons. 1) IDE - Keil's MDK is basically the best IDE I've ever used (and I've used a lot). I can't even begin to delineate the functionality of it, just download the demo. It's better than having a bond-out chip and an in-circuit emulator with live debug. Really, it's crazy good and it's "free" (lacking some functionality) because ST subsidized it as a loss-leader (the first hit's always free...) 2) CMSIS-RTOS has a not-too-steep learning curve such that you could swap in any given engineer who's worked with on QNX4 and jump right in (for me, the learning curve was about as painless as Java 1.6 -> C#2 => ~2 weeks). Works on any M3 or higher (you aren't locked into any specific vendor), even licensed out with everything the IDE is reasonably priced as is the OS. So you don't run into the "Jane Street OCaml / Haskell shop hiring problem" of having a few pool of very very talented applicants, who are all in high demand as a result of their specific skillset. A good engineer won't have a problem. 3) Again, no specific vendor! If ST goes out of business (haha yeah right), NXP (a division of Philips) would definitely supply you with a same chip, with the same pin out, same package, same everything. Model everything on your BOM with a contingency in case lead times surge unexpectedly.
There are niche RTOS solutions out there (FreeRTOS works on ARM with a modicum of ST documentation. ST, Mentor, NXP, and all the other name-brands use it as the defacto standard if you're not going to go with a 'name-brand' RTOS.) eCos is probably the second pick with more of a hacker-community vibe to it, which, is probably good for getting that roto-copter's altitude up an extra few hundred feet but not really something you want your dialysis machine to be running on.
---
Here's an idea of what you're looking at (this is based on fed work from an engineering then from a bean-counter POV, but I've taken a Class B to market on the software side and it's got enough parallels that I feel this advice is pertinent).
Your cost breakdown is for first-product-to-market going to be 40% NRE for all the licensing, a board design engineer for your board layout (Cadence OrPCB / Altium 16 license), a software engineer with embedded experience (i.e., a good indicator is he's taken a lot of EE classes, or on the other end of the spectrum, has gone to the graduate level in theoretical computer science -- had great experiences with employees that fall into those categories) + Keil IDE or whatever, industrial engineer for your enclosures (Solidworks license) [you _might_ be able to bypass this step, but purchasing authorities ask "Can we change this font color" more often than "how efficient is it" - humans are significantly influenced by the aesthetics/how something interfaces with you. I'm guilty of this too, any industrial IP67 gear that feels chinsy, any relay that feels light, etc, I have a preformed biased against. (Aesthetics are a large part of Apple's value, along with exclusivity and status signalling; though, when I had my Macbook Air it felt like I could bend it in two, it's been on my desk for 3 years, and my daily driver is a Thinkpad I've neglected so much I'd have gone through 3 or 4 MBP's by now)
Legal and insurance will predictably be a fixed recurring (maybe 15%). Certification and re-spin costs can range from 5% to a lot more. Don't skimp on stupid things to save a few k here and there - pay a firm to do pre-EMI testing beforehand. Buy brand-name everything just as an insurance policy. $9 dollars extra for that precision thick-film resistor @ 10k vs $.13x10 might save you 8.70 a unit, but the engineering time it takes to find why your chip is clocking out spurious data but only once every 3 weeks at random times (oops, those resistors were 10% not 1%, which is normally fine except when you bring CE low for > x NS while doing Y, which heats up the bypass cap near Vcc increasing the ESR, and whoops, your cap's resistant factor is drawing an excess of current that shoulda went to Vcc! Again, Keil IDE helps so so much finding bugs like that.) Uh, yeah so, buy Nichicon and breathe easy. Use pre-certified industrial components that your competitors have already used if you can.
Office space can be finagled from other startups usually at pennies on the dollar. The commercial real estate market even in NYC is soft and I could get class-A space in midtown month-to-month at $3/sqft/mo (utils and furnished). I'd imagine SF is the only place where you'd have difficulty finding a reasonably priced space from someone who wants to let go of 800 or 1000 sqft. The rest is going to go to your marketing and/or sales team who will ultimately make or break you. Not for the faint of heart. If you don't have a mentor/family friend/guy on your board with existing contacts or know someone on the Cerner/EPIC/Meditech sales team with a big-fat Rolodex, you're going to be in for a tough, tough time. In government contracting (SBA, tiny contracts, fighting over the scraps really), we used to keep former decorated career military men on our board. They'd pocket 180k a year to literally fly down once every quarter and play golf while we got access to his Rolodex- medicine's the same.
very sound advice, thank you!
Thanks for your input. (1) resistive screens and some capacitive screens can handle rubber gloves fine. (2) for our use-case (non-invasive blood sugar measurements) this is a non-issue, but out of curiosity: how is a touch screen different from a physical button (or the whole case) in this regard?
Have a look at panels on devices like ECG. Usually these don't even have real buttons exposed. A common approach here is to make the whole device as smooth as possible so there are no not-cleanable holes / ridges. For example displays will be actually behind transparent part of the case, not sticking out / in a hole. Same with buttons - all of the actual switches will be behind pillow-like buttons built into the case.
See http://g02.a.alicdn.com/kf/HTB1fNYoHVXXXXbkXFXXq6xXFXXXt/Fre...
Edit: also when considering industry / medical devices, keep in mind that most touchscreen are not meant for the conditions these devices are in. You should be able to splash water / gel / oil / ... over it and just wipe it afterwards. They should also survive people who think they just need to press it harder if it responds slowly. Simple buttons (with extra protective cover) are more likely to survive this. Next time you're around in the hospital, check out how many of the button labels are completely worn down.
It should also be noted that a common practice in medical environments is to cover any control panels with a static-cling plastic sheet (usually light blue color, I imagine everyone is using the same brand) that can be quickly replaced between patients. So make your legends large and high-contrast.
We used Linux/C so we didn't kill people.
I'm not sure that C the best language for life critical high level applications... it's far too easy to shoot yourself in the foot.
What alternative would you recommend?
Pretty much anything!! Java, C#, Rust, Go, OCaml, Lisp, ... even C++ would be a much better choice.
Check this out: http://tobyho.com/2008/03/30/how-safe-is-your-programming/
There also used to be a website that ranked programming languages according to various parameters (which is faster, which is safer) by asking visitors pairwise comparisons (Which is faster - Matlab or C?). I was going to link it but can't find it unfortunately. Anyway I'm pretty sure C would come second-last in the safety ranking, right above assembly.
Ada, frankly.