[SystemSafety] UK principles for security of driverless cars [No Classification]

Matthew Squair mattsquair at gmail.com
Wed Aug 9 13:24:31 CEST 2017


I said it was simple, not easy, the difficulty is of course exactly because
of the points that you enumerate. I'd also suggest that all that will
change the first successful hive attack on a vehicle fleet.

On 9 August 2017 at 3:31:06 pm, Peter Bernard Ladkin (ladkin at causalis.com)
wrote:

> On 2017-08-09 02:12 , Matthew Squair wrote:
>
> My experience is that if you give a principles document to an engineer for
> whom it is not their
> ‘bread and butter’ it will be used to prop open the door.
>
>
> Yes, I suppose that's why MIT finds it has to teach them
>
> https://ocw.mit.edu/courses/materials-science-and-engineering/3-003-principles-of-engineering-practice-spring-2010/index.htm
>
> There’s also a simple solution that I think everyone is studiously
> overlooking, and that’s to
> legislate that you can’t connect a car’s critical systems to the internet.
>
>
> It is not simple, and it is not a solution. People are actively working on
> intervehicle
> communication systems and have been for a decade and a half at least (I
> was introduced to Daimler's
> work at SAFECOMP in 2004). The main idea then seemed to be negotiation at
> points of traffic
> conflict. Another idea was sharing traffic movement information, but that
> seems to be done already,
> and differently.
>
> If you think you need intervehicle communication for control purposes, you
> are networked. If you are
> networked, then you have the choice. Do you use TCP/IP, or something else
> proprietary and solid,
> such as Kevin designed? For companies concerned about beating the
> competition to market, that is a
> no-brainer. TCP/IP development tools and kit is available all over the
> place for you to pick up and
> have a working network in a trice. The reason that doesn't happen in the
> design of commercial air
> transport is that competition is attenuated and there are two regulators
> who insist you do
> everything right, and who have the power to interpret "right".
>
> Now, if you have been using TCP/IP for years in your road-vehicle R&D for
> the above reason, you're
> not going to throw away all that developed E/E/PE kit and say "now we'll
> do it differently before
> putting it in our car". You've been testing that kit on real roads; it
> makes no commercial sense to
> start again from scratch.
>
> There are general due-diligence legal constraints on car manufacturers, as
> with any other
> manufacturer, but lawmakers=politicians are a long way from being able to
> tell car manufacturers
> what network technology they should be using. Nevertheless there are some
> directives setting
> constraints. EU Directive 2010/40/EU on "intelligent" road transport
> systems contains a clause
> saying such systems shall be interoperable and based on open standards
> (clause 11). So bye-bye to
> proprietary network technology. If you want to spend the money to develop
> such technology because
> you don't like TCP/IP, you're then going to have to give it away. (To read
> the Directive, easiest is
> to go to http://eur-lex.europa.eu and put in a search for the label of
> the Directive. You can then
> read it in whatever EU language you want. The URLs are otherwise
> horrendous.)
>
> BTW, we all know about the Chrysler/Jeep hack (after Daimler divorced),
> and now after Def Con a
> bunch of new Tesla hacks. Has anyone heard of a Mercedes or BMW
> control-system hack? Why not?
>
> PBL
>
> Prof. Peter Bernard Ladkin, Bielefeld, Germany
> MoreInCommon
> Je suis Charlie
> Tel+msg +49 (0)521 880 7319 <+49%20521%20880%207319> www.rvs-bi.de
>
>
>
>
>
> ------------------------------
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20170809/d63188ab/attachment.html>


More information about the systemsafety mailing list