> It also is very sensitive to resistance, to the point that I actually had to construct ramps for my car to climb the 1-inch lip at the entrance to my garage, otherwise it would stop at that point and refuse to go further.
The pictures of the car in a article linked elsewhere in this discussion (https://www.ksl.com/?sid=39727592&nid=148&title=utah-man-say...) show that the windshield was smashed. I'm finding it challenging to reconcile your personal example with the images of the smashed windshield; in my own experience, it takes some effort to break laminated safety glass. I would think (perhaps wrongly) that it would take more effort to break safety glass than would be stopped by a 1in. step.
> but I don't think there's much room to discuss safety here.
I couldn't disagree more. I don't understand why it should be possible to disable any safety interlock (at least, that's how I'm interpreting the feature description) in a consumer product, especially persistently.
> I'm finding it challenging to reconcile your personal example with the images of the smashed windshield
Really? It seems fairly obvious to me. The sensors are in the front of the car, lower down. So anything on the ground in front of the car registers as an obstacle and the car stops. Such as a small step.
The front of this trailer (they keep referring to it as the back, but it's clearly the front) was too high off the ground to register as an obstacle. You'll note that the front of the car has plenty room - there's nothing blocking it - but the windscreen doesn't!
So it needs to be fixed; you could imagine a Tesla running into, say, a small truck with timber sticking out the back when the speed was low enough that the safe distance between vehicles was small. But it hardly seems life-threatening in any way.
The lip isn't detected by the sensors. The car stops on it when the tires hit it because of the physical obstacle it presents and the extra force needed to climb it.
It's weird, usually the car actually passed over the lip with the front tires, but then stopped when the rear tires got to it. The threshold for stopping must be very close to what it actually encounters there.
Someone on Youtube had what I thought was a clever solution: a piece of trim (looked like shoe molding) to bridge the 1" step. Cheap, and they claimed 100% effective.
This feature has me wondering what the SAE standards for automatic transmissions have to say on the matter, if anything?
I'm not familiar with them, nor do I have access, but I'm hoping someone here might be helpful on either aspect. Specifically, I'm wondering if the standards for automatic transmission controls recommend against having the Park setting do anything beyond activating the parking pawl and parking brake (when electronically controlled).
Experienced investors aren't going to invest much if the science isn't on a good foundation. Even if they would, that's a pretty expensive way to fund research: it's cheaper to fund it by grants or through revenue.
I would predict that it depends on where the money is coming from.
For VC firms that are experienced in the biomedical space, Theranos changes nothing because they were already suspicious of Theranos.
For firms that are inexperienced in the biomedical space, they have hopefully learned that growth cannot compensate for flaws in science or technology. If they continue to invest in biomedical, they will be much more careful in their DD; or perhaps they lose their appetite for biomedical and leave entirely.
I don't think things have changed for biomedical startups that are based on good science and technology and have an experienced team.
What would be wonderful is if the media learned a lesson from this mess. As I see it, they were a passenger in the Theranos hype machine.
"For firms that are inexperienced in the biomedical space, they have hopefully learned that growth cannot compensate for flaws in science or technology. If they continue to invest in biomedical, they will be much more careful in their DD; or perhaps they lose their appetite for biomedical and leave entirely."
Exactly, which will result in essentially a return to the status quo. The investors who understand the complexities and models of the various biomedical industries will continue to invest as they always have. The carpetbaggers will fold up their tents and move on. The result is less likely to be systemic taint or damage to biotech startups as a whole -- though this may happen in the short term -- and more likely to be a reduction in fly-by-night or sketchy biotech startups for lack of funding.
"I don't think things have changed for biomedical startups that are based on good science and technology and have an experienced team."
Yes. To paraphrase Buffett, the tide will go out, and we'll see who's been swimming naked -- but the people who've been wearing swimsuits will be just fine.
"What would be wonderful is if the media learned a lesson from this mess. As I see it, they were a passenger in the Theranos hype machine."
The media hype surrounding Theranos was truly spectacular to behold. One day, nobody's ever heard of this company that's been stealthily chugging along for nearly a decade and raising heroic amounts of capital. The next day, Holmes is on the cover of every business magazine, in full Steve Jobs attire and disposition. (I'm pretty sure one or two breathless headlines actually called her "The next Steve Jobs.") Soon she's headlining the lecture circuit and racking up more puff pieces and cover stories.
It's as if nobody took a critical eye to any of this hype, other than the WSJ. No doubt a confluence of factors was at play here: A desire to fill the "Great Tech Visionary" vibe left vacant by Steve Jobs's death. A desire to find the next great female role model. A desire to cover "hard tech," and not just the Nth food-delivery app of the week. And then there's just good old-fashioned me-tooism, which routinely plagues the business press: "Everyone else is covering this, so it must be a Thing, and now that it's a Thing, we have to cover it!"
I'd say that Theranos is so much of an outlier that it's failure won't really have a huge effect.
They weren't patenting nor licensing any exciting technology. They had no groundbreaking presentations of their technology. They had no experts in the field working at the company or on the board....
I mean, it's amazing they raised money to begin with
This article (by way of the WSJ) claims that Walgreens skipped their standard DD in partnering with Theranos, and that the deal overall was atypically structured.
Something seems a bit fishy. An uncorroborated source says WG skipped the due diligence part but in any event had they tried Theranos would have rebuffed their inquiries (because "secrecy") Could they not just compare and contrast results against known technologies, why rely on theranos's data at all?
Probably because they felt they didn't have the luxury of time on this one. They were probably worried that Rite Aid / CVS / other competitor would beat them to the punch, and figured that it was worth the risk to move quickly, at the time.
In terms of acceleration they're certainly impressive, but does any Tesla qualify as a supercar when other indices of performance are considered? They're pretty heavy for one, and while they wear it extremely well, a low CoG can only do so much.
Maybe Teslas aren't supercars, but they're instead super cars?
I don't think there's any simple answer to your specific questions based on what you've provided so far. I'm going to word vomit a bunch of stuff that might, with some Google/Wikipedia searches, help give you a better view (I hope!). I hope this is helpful.
So much depends on the stage of the development process you're in, what the goal is of this project (i.e., internal testing, research use only, human use), when you're going under design control, and what market/regulatory framework you're working under (FDA, CE, CFDA, etc.).
Your requirements documents are a good guide here. I personally separate them as Engineering Requirements Document (ERD), Software Requirements Document (SRD), and Market Requirements Document (MRD); your questions would touch all of these.
You've hinted that you are wanting a display and also wanting to do calculations; as others have suggested, good practice would be to separate this functionality. Your ERD/MRD should specify a minimum duration for projected parts availability. Dealing with part variations is a pain, but having to replace an end-of-life'd (EOL'd) part is worse. For your own personal sanity, you probably shouldn't be looking at consumer-level parts and instead look for more industrial-style parts (a weak example might be to use a BeagleCore instead of an RPi for an internal project). You'll need to be mindful of your environmental requirements too, if for example your design called for a sealed enclosure that could greatly impact the parts you could include in your design due to thermal management. Even when using consumer level stuff, say USB, you should look for the industrial/ruggedized versions (e.g., that will have retaining screws).
Touchscreens for medical devices are, in my experience, a mixed bag depending on the application. If you're using a good design, they can be easier to keep clean and disinfected vs. buttons. On the other hand, depending on the touch technology you use and the type of information you're displaying, the display may not look great (i.e., a 2D plot can look fine on a resistive touch panel, but video may look foggy). Depending on what your users are doing, you could have smudges of some sort of fluid (or boogers, or giblets) obscuring info on the display. Also, I think users expect a modern multitouch experience now and I personally haven't been thrilled with that style of interface on anything other than capacitive displays.
If you're using a contract manufacturer (CM), they are a great resource. You'll be dealing with them during design for manufacture (DFM), but it's a good idea to engage them early so that you can design for DFM (if that makes sense). I don't know what your expected volumes will be, but on things other than durable goods (like scalpels), "high volume" medical quantities are considered "low volume" for other areas and this will greatly influence your design. I also found it frustrating because you're limited to suppliers/distributors/CMs/whatever that will be satisfied with the lower volumes.
Handwavy answers are that your safety-critical stuff is going to be hard real-time and running an OS developed under an appropriate quality system (QMS) like vxWorks, Integrity, QNX, etc. I don't have experience with it, but there is also FreeRTOS with an SIL (safety integrity level) 3 SafeRTOS option that could be an interesting contender. The software you develop will also need to be developed under a QMS as a broader part of your software development lifecycle (SLDC) and greater product lifecycle management (PLM). There are guidelines to use software of unknown pedigree (SOUP) by bringing it under your QMS, but this can be undesirable depending on circumstances. Most commonly the software is developed under C or C++ with an appropriate coding, review, and testing standard; for a greenfield project I think that considering Ada/SPARK or Java (with the appropriate compiler/VM) could be smart.
For things outside of the safety-critical areas, you have greater options, and it might be largely sufficient to develop under a QMS. You're going to need to be very mindful of software licenses to make sure that they are aligned with your project's requirements. If you're set on Linux then Yocto would be worth exploring, but NetBSD would be my first consideration due to licensing. For your GUI, FLTK could be worth considering if it met your requirements. Even if your product is Class A, it's maybe helpful to keep the more stringent requirements for Class B/C products in mind, so that you can (when and if it makes sense) develop expertise and institutional knowledge for Class B/C products later on.
Finally, considering your questions and I say this in the kindest intentions, you should be participating in the process but not be signing the decisions. If your company doesn't have the expertise in house, it would be worthwhile to either bring someone on board or engage a consultant.
This advice reflects what I've seen in safety-critical field reading on all kinds of deployments. This plus other comments to use simplest microcontrollers with tiny RTOS or no OS using simplified software. Good advice and good alias.
Thanks and thanks. To further bloviate, Tcl is my not-so-secret weapon. I first used it when doing exploratory work with some embedded one-off instruments and it made an impression because those doohickies are still running strong to this day, well beyond the design goal. They had sensors that were communicating over a serial console: Tcl made interfacing quick and painless, and a control GUI in Tk practically built itself. It's robust and a known quantity (flaws and all). There's also some level of je ne sais quoi where, like Lisp, I don't feel like I will paint myself into a corner: need more performance? drop down to C. language is limiting? make a better DSL. So I guess I'm either a fan or delusional (likely, both).
I don't personally know of anyone in medical using it, but your comment about no OS does prod me to say that I have wondered if running Forth on bare metal for medical is viable and/or desirable on a greenfield project. I'm not saying I would do it, but I would happily cheer on someone else. (OP, don't do this, I'm delusional)
And OP, I really hope that my wall of text won't be discouraging in any way. Personally, I found that documentation is (a la Homer Simpson) the cause of, and solution to, all of life's problems in a regulated environment. If you master that, document honestly and eagerly, it's downhill from there and life will be good.
I never thought of Tcl to be used in safety- or security-critical systems. It's certainly simple and easy to use. We played with it for agent-oriented programming back in the day. Had serious, design-level issues for security and was harder to parse than some others (eg LISP's).
Rather than just a critique, I'm curious where and how you use it with what benefits it brings you? I could certainly see it in UI or untrusted parts. Maybe also during development in a way that auto-generates C or something that runs in production.
I only use it like you guessed (and what I think it's best/appropriate for): gluing things together, embedded scripting, and Tk on internal tools/gizmos and early prototypes. I wasn't clear earlier, sorry.
To be perfectly fair, on the decision matrix Tcl gets a helpful boost due to my own familiarity with it and playing nice with C; if a butterfly had flapped it's wings just a little bit differently or I was starting out today I would probably be using something else. Probably Java. Ada would be great, but the lack of ecosystem diversity makes me apprehensive.
Gotcha. Look into REBOL/RED while you're at it. RED is a REBOL clone/modification for system programming. They're LISP like advantages without the parenthesis and having small footprint. RED is already used in one OS project. I keep thinking of modifying it for system use. People keep telling me to check out Nim as it's like Pascal and Python combined with extra safety, macros, and C code generation.
So, there you have it: REBOL, RED, and Nim. Maybe Ivory language from Galois, too, but you need to know Haskell for that.
I remember playing around with REBOL a long time ago and it seemed useful and practical, but for reasons long forgotten I never used it. Maybe licensing? RED does look cool and I hadn't heard of it before, thanks for the tip.
Don't have any experience with Nim, but I share your interest for the same reasons. Haskell and I don't get along, maybe I'm too old and set in my ways?
Me too on Haskell. Mainly plan to try other two. Saw Little but didn't really get it past adoption. Then, your comment led me to the Why page which told me that was exactly the point. Along with programming in the large support. Funnier when I found out the boss wrote that.
I'd say it's not a good language to go with today for same reasons I'd say Tcl isn't. It's an interesting improvement especially to get better syntax with legacy compatibility with field-proven, TCL modules. And TK is still the shit for portable, easy-to-build GUI's. A TCL shop should definitely experiment with it and maybe incrementally upgrade their code. I think I'd be fine with a more typed, efficient, and fixed version of Tcl for some apps. Especially a command shell replacement or prototyping system.
Just not production unless it's non-critical like what you use it for. I don't even use it to glue to critical things as the glue is part of the TCB to a degree. Gotta find close-to-metal, abstract, typed, efficient, and macro'd stuff to replace it. At least we have contenders.
The author works for a custom embedded code shop, and I believe has been using it and its antecedents for years for his customers. He's on my short list of personal coding heroes.
I'm unclear on how Kuvée fits into the three-tier system [0]. Are they trying to supplement/replace the incumbent distributors, or are they in between the vineyards and distributors?
Amusingly, there's a large California company, Frank-Lin Distillers Products, which has found a way to use the three-tier system in a profitable way. Usually, there are distiller/bottlers, who make and bottle alcohol products, distributors, who operate warehouses and fleets of trucks, and retailers. This results in three levels of markup.
Frank-Lin buys ethanol in bulk, from industrial-scale distillers in the Midwest. The ethanol is delivered in tank cars to the railroad sidings at their plant in Fairfield. There, they take tap water, run it through a deionizing plant to remove dissolved solids, mix it with ethanol, add flavoring, bottle, and ship it out to retailers in their own trucks. Most of the bottom-shelf booze on the West Coast, and some of the expensive stuff (they used to make Skyy Vodka, until Campari bought out that brand) comes from their plant. They make over a thousand different bottled products, but admit that there are only about a hundred different recipes. There are still three tiers, but the markup on ethanol when you buy it by the trainload is very low.
They use a huge number of different bottles, with elaborate designs and labels. Their plant is conveniently located next to a Ball bottle manufacturing plant. They have automated bottling lines which can switch from one product and bottle to another without manual adjustments. This allows them to feed customer illusions about liquor while keeping the manufacturing costs low.
Frank-Lin is moving into wine production.They make "Maestri Chianti", which has decent scores from wine snobs. Same concept, just different bottles and flavoring. Who needs vineyards and wineries when you have an industrial plant and the right formulas? Now that's disruption.
