[SystemSafety] twitter thread of ex-employee on software development at tesla

[Peter Bernard Ladkin]

On 2018-08-24 21:43 , Robert P. Schaefer wrote:
> 
> There are a number of safety concerns identified here:
> 
> "A former Tesla employee, who worked on their IT infrastructure, is posting in a subforum of a
> subforum, a little-known place for funy computer forgotten by time. His NDA has expired."
I am not sure. There are a lot of acronyms flying around about firmware written in XXX that has to
talk to YYY over ZZZ and how it is installed over WWW. And the impression given that a lot of it is
on-the-fly, poorly thought through and poorly controlled.

I doubt it. Anyone who has ever tried to get a highly-distributed digital-tech-based system up and
running knows, that if you try to do it on-the-fly, the difficulties start with two components and
increase seemingly-exponentially as you add components. The interfaces have to be carefully
controlled, as does timing, and so on. It can't be done without moderately efficacious engineering
specifications. All that stuff must be in place otherwise the cars simply wouldn't work. And if the
specs are good enough, someone whose task is to implement them has the type of freedom exhibited in
the posts, because the necessities are already nailed in the specs. Of course there are going to be
weak points. For example, someone won't have thought through, say, the update protocols as
thoroughly as it turns out will be necessary, and that will need to be re-engineered on the go. The
tales of how can be quite interesting.

This is of necessity an ISO 26262 shop. How much attention US manufacturers pay to that I don't
know, but Tesla sells in Europe and if someone is injured or killed becuase of a phenomenon which
can be ascribed in part or whole to digital electronics then a civil court (and indeed a criminal
court in Germany and probably France) will be looking at conformance with applicable standards,
which for critical electronics/programmable electronics is ISO 26262. (Note; the writer apparently
doesn't like Bosch, but Bosch has some very good people who helped write ISO 26262.) If they didn't
conform to a high degree, the cars would likely be off the road in Europe at some point.

ISO 26262 isn't a panacea. It didn't stop the Miller-Valasek hack of Jeep critical control in 2015.
And I am not suggesting I know how efficacious it is because I don't. But there is a lot of
paperwork and formal checking involved (I don't know exactly how much, but for IEC 61508 SW there
are almost 60 pieces of individual documentation required). That documentation is also not a
panacea: for example, in IEC 61508 there is momentously inadequate handling of cybersecurity (and if
certain interests have their way, their might be even less, that is to say none, in Edition 3). I
have written about that in Chapter 13 of my Assurance Manifesto (unfortunately, our RVS-BI site is
current inaccessible, so I can't include the URLs). The relevant point here is that there must be
some development/documentation superstructure in place for at least formal conformance. This
structure, along with the difficulty of getting components to work with each other, is nowhere
hinted at in the posts, even though it must be constraining the processes being written about.

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
MoreInCommon
Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180825/5f7f79c8/attachment.sig>