[LINK] Who wrote the code that shocks us?

[Stephen Wilson]

Thanks Darrell

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 
verification.

FYI ...

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 
http://lockstep.com.au/blog/2011/02/23/programming-is-like-playwriti.html.  
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 
handlers.

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.

Cheers,

Steve Wilson
Lockstep
https://lockstep.com.au/blog/software-engineering





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.
>
> http://www.youtube.com/watch?v=5XDTQLa3NjE
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Darrell Burkey
> Web Transformation Project Team Leader
> UNIX Systems Administrator
> College of Asia & the Pacific
> Australian National University
> Ph: (02) 6125 4160