FreeBSD and Robotics

[Ted Mittelstaedt]

> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Modulok
> Sent: Sunday, June 17, 2007 7:40 PM
> To: kzabbo at bellsouth.net
> Cc: questions at freebsd.org
> Subject: Re: FreeBSD and Robotics
> 
> 
> It's only as good as the drivers you write to control the robot. It
> also depends on just how critical your "critical situations" refers
> to.
> 
> In situations where human life is directly dependent upon the
> integrity of the system, a modular kernel design has traditionally
> been preferred over the monolithic kernel designs found in Windows,
> Linux, BSD. That isn't to say that FreeBSD is unstable, in fact it's
> very stable. However, in a situation where people die if the system
> fails, there are some questions as to the safety of the underlying
> designs of these kernels. The reason for this is, (in general), device
> drivers operate in the kernel's memory space and therefore have the
> potential to bring down the rest of the system, should they fail,
> (again, in general). In a modular kernel design, where everything is
> run in user-space, if a single driver goes berserk it is entirely
> insulated from the rest of the system.
> 
> Then there are embedded systems, which are regarded as more stable
> because the hardware they run on is identical from one system to the
> next and never changes. Contrast this to operating systems that must
> run on a wide range of consumer hardware; there is a statistically
> higher probability of mistakes, just due to the increased size of the
> codebase. (In practice this doesn't always work out though, as I've
> used some embedded systems that were embarrassingly unstable). The
> smaller codebase of embedded systems and modular kernels is typically
> easier to audit, as there is far less code. Where human life is
> directly dependent, the code must be audited by a third party.
> 

There's another issue and that is POST on standard PC hardware.  POST
takes too long.  For example the auto industry has agreed on a standard
time that a car engine computer must be fully operational, it is very
short, no more than something like 2 seconds or so.  Enough so that when
you turn the key and the engine starts cranking, that the engine computer
has completely booted and is running by the second crank.

That is why you probably will never see standard computer hardware used
in the operating room of a hospital to control patient life support, for
example.  If for example during an operation the computer controlling an
artificial heart suddenly dies, the staff simply unplugs the lines from
the computer and plug them into another computer which then is switched on
and within a second has come fully ready, and operating.  You could not
wait the 30-60 seconds that POST on a regular PC would take to complete.

By contrast, regular PC gear is used very much for stuff like image
analysis and non-critical gear in a hospital.  If the computer running a
CAT scanner were to die in the middle of a scan, no big deal, you
just replace it and restart the scan from the beginning.

Ted