[LINK] Who wrote the code that shocks us?
swilson at lockstep.com.au
Fri Mar 9 11:59:55 EST 2012
I've been working my way slowly through Sandler's presentation and her
paper "Killed by code".
What's really stark on first viewing is the culture change. Sandler had
an incredibly hard and very off-putting time getting any defib company
to explain their software. But when we started in this field, every
single person in the company -- and many of our doctors -- would have
been able to answer the question "What software does this defib run
on?" The answer was "ours". And moreover, the FDA were highly aware of
software quality issues. The whole medical device industry was still on
edge from the notorious Therac 25 episode, a watershed in software
In 1990 Telectronics (a tragic legend of Australian technology) released
the world's first software controlled implantable defib, the model
4210. The computing technology was severely restricted by several
factors: ultra low power consumption, and a limited number of
microprocessor vendors that would warrant their chips for use in medical
devices. The 4210 defib used a semi-customised 8 bit microcontroller
based on the 6502, and a 32 KB byte-organised SRAM chip that held the
entire executable. It clocked at 128kHz. The software had to be
efficient not only to
We wrote mostly in C, with some assembly coding for the kernel and some
performance sensitive routines. The kernel was of our own design,
multi-tasking, with hard real time performance requirements (in
particular, for obvious reasons the system had to respond within spec to
heart beat interrupts!) We also wrote the C compiler, to avoid the
problems that Marghanita has talked about.
The 4210's software was 40,000 lines of C, developed by a team of 5-6
over several years; the total effort was 25 enegineer-years. Some of
the testing and pre-release validation is described in my blog post
The final code inspection involved a team of five working five-to-six
hour days for two months, reading aloud and understanding every single
line. When occasion called for checking assembly instructions,
sometimes we took turns with pencil and paper pretending to be the
accumulators, the index registers, the program counter and so on. No
stone was left unturned.
The final walkthrough was quite a personnel challenge. One of the
senior engineers (a genius who wrote the kernel and compiler) lobbied
for inspecting the whole executable because he didn't want to rely on
the correctness of the compiler -- but that would have taken six
months. So we compromised by walking through only the assembly code for
the critical modules, like the tachycardia detector and the interrupt
We amassed several thousand implant-years of experience with the 4210
before it was superceded. After release, we found two or three minor
bugs, which we fixed with software upgrades. None would have caused a
misfire, neither false positive or false negative.
Yes, for the upgrade we could write into the RAM over a proprietary
telemetry protocol. In fact the main reason for the one major software
upgrade in the field was to add error correction because after hundreds
of device-years we noticed higher than expected bit flips from natural
background radiation. That's a helluva story in itself. It was
observed that had the code been in ROM, we couldn't have changed it but
we wouldn't have had to change it for bit flips either.
Anyway, some of the morals of the story:
- Software then was cool and topical, and the whole company knew how to
talk about it. The real experts -- the dozen or so people in Sydney
directly involved in the development -- were all well known worldwide by
the executives, the sales reps, the field clinical engineers, and
regulatory affairs. And we got lots of questions (in contrast to Karen
Sandler's experience where all the caridologists and company people said
nobosy ever asked about the code).
- Everything about the software was controlled by the company: the
operating system, the chip platform, the compiler, the telemetry protocol.
- We had a team of people that knew the code like the backs of their
hands. Better in fact. It was reliable and, in hingsight,
impregnable. Not that we worried about malware back in 1987-1990.
So the sorts of issues that Karen Sandler is raising now, two decades
on, are astonishing on so many levels. Why FFS would anyone decide to
write life support software on someone else's platform? Why FFS would
they use wifi or Bluetooth for telemetry? And if the medical device
companies cut corners in software develeopment, one wonder what
Westinghouse is doing with their cruise missile controllers.
On 9/03/2012 9:21 AM, Darrell Burkey wrote:
> On 09/03/12, *Stephen Wilson * <swilson at lockstep.com.au> wrote:
>> I called myself a software engineer for 10 years or so. I worked on real
>> time control software for implantable defibrillators. Ultra high
>> reliability code, and now when I read with disbelief about malware
>> getting into implantable defibs (because they run on Windows or
>> somesuch) I realie we wrote high security code at the same time. But
>> that's a story for another day ...
> One of the keynote speakers at LinuxConf 2012, Gnome Executive
> Director Karen Sandler, gave a fascinating talk about her quest to
> find out what software was operating her implanted defibrillator and
> if she had any rights regarding access to it. She made some very
> interesting points that really made me think about all the software we
> depend on.
> Darrell Burkey
> Web Transformation Project Team Leader
> UNIX Systems Administrator
> College of Asia & the Pacific
> Australian National University
> Ph: (02) 6125 4160
More information about the Link