Subject: Re: [its] Article + TED talk

From: Alison Chaiken <[email-masked]>
Date: Mon, 5 Aug 2013 23:16:35 -0700

Roland Bless <[email-masked]> writes:
> BMW is using IP already in its on-board networks.

True, but BMW employees have been among those who object to IP for
some car intranet applications, as have some BWM contractors.
Ethernet AVB is the way to go in the longer term, but cars contain a
lot of legacy 8- and 16-bit microcontrollers that are inexpensive and
robust.   However, vendors of safety-critical systems like automakers
are not anxious to wholesale replace too many of these parts at one
go, and I don't blame them.

A lot of these MCUs expect CAN or SPI (serial peripheral interface)
signals.   Figuring out how to translate messages from Ethernet
packets to CAN messages or SPI signals in a real-time control system
is not so simple.    Prof. Max Ruggeri of Italy's Imamoter Institute
(CC'ed) has done some fine work on creating CAN-Ethernet gateways for
agricultural applications, which are commonly fully autonomous.   See,
for example, his paper "SAE J 1939 Over Real Time Ethernet: The Future
of Heavy Duty Vehicle Networks" (doi:10.4271/2012-01-1988).

>>> I don't think 5-10% savings are a good enough reason to not use IP.

I'm not sure the savings would be so meager when we consider
Ethernet-CAN or Ethernet-SPI translation.

I wrote:
>> Perhaps using a protocol other than IP will also have security benefits?
>>   The PKE model of DSRC, with its reserved safety channel and reserved
>> PSIDs, seems pretty appealing for safety applications.

Roland inquires:
> Security by obscurity? Sure, on the one hand IP knowledge and attack
> tools are more widely available, on the other hand the security
> mechanisms like IPsec/DTLS and so on are proven to work well.

I'm not sure why folks keep referring to proposed use of published
protocols as "security by obscurity."  Assuredly different
applications may benefit from different special-purpose protocols.
Segregating higher-priority communications about safety to separate
DSRC channels in 802.11p is not intended to to be obscure but to be
robust by design in a way that other 802.11 protocols are not.    I
used nmap today to figure out why I couldn't ssh in to my own system,
and find "pen tools" useful for debugging myself, but that doesn't
mean that I believe that my toaster should run IPV6.

It is regrettable indeed that SAE, ISO and (IIRC) ETSI protocols are
not available for free.   The difficulty of interchanging these freely
really hampers discussions like the present one.   Congrats to IETF
for staying open.

-- 
Alison Chaiken                           [email-masked]
650-279-5600                            http://{she-devel.com,
exerciseforthereader.org}
The intermediary between the head and the hands must be the heart.
-- Thea von Harbou

---

From: "m.ruggeri" <[email-masked]>
Date: Tue, 06 Aug 2013 12:05:42 +0200

Dear Alison, dear  Roland and friends.
I'm totally new in this group and I don't know all Your previous 
discussion. Sorry for that. I will try to expose my point of view, 
briefly, and if someone will have some question, I will try to answer in 
my best way.
I'm a CAN and automotive systems expert rather than an Ethernet and IP 
expert.

Really the discussion can be huge because of a lot of aspects and 
functionalities that we can consider or not.
Sure in the future we will manage a lot of automatic "in car" 
functionalities, and safety, security and real time aspects will be the 
major goals to be satisfied.

We tried to work on Ethernet just because of the bandwidth, the large 
amount of free software, components and systems, Ethernet is the 
preferred candidate to be a low cost network system in the future.
I can't forget the cost and the difficulties to start with my first CAN 
application in Magneti Marelli Company in Italy in the '90 connecting 
the car engine to an ABS/ASR system ..... :)
We suppose that a similar cost downsizing will happen for Ethernet; just 
have a look to the ARM/Cortex M4 today pricing ... You can buy a 2 
Ethernet 32 bit micro-controller for less than 1 $....

In the Agricultural machines and construction machines we have a lot of 
requirements for autonomous driving and autonomous working, right now. 
Sensors for virtual fencing, camera vision to recognize plants and 
humans, fleet and work sessions management systems running in real time 
with GPS and inertial platforms @ 100Hz are commonly used and the 
precision requested is less than 2 cm for autonomous driving.
Thus we need a lot of bandwidth, we need real-time, we need less CPU 
time to change protocol and we need safety and security, because of the 
responsibility for autonomous driving and to protect data .... then the 
natural solution is Ethernet and IP.

Other Big Constructors are trying to use Ethercat(TM), we are also 
evaluating Powerlink(TM) because of the OpenSafe(TM) Layer ..... but 
otday we don't have "the" solution. An ISO standard is not ready (but we 
are working on it for Agricultural Machines).

Anyway I have a stand alone toaster at home. I don't like complex 
systems if they are not necessary, but I think that Ethernet can be an 
opportunity for Automotive systems.
In fact we have to remember that CAN is not suitable for safety critical 
applications. Some Ethernet based protocol can be certified for safety.

In our research we just synthesized a protocol that is very similar to 
the Avionic ARINC-664 (AFDX) that was developed - I suppose - in Germany 
(as usual).

We just have some direct experience and we have some product running 
properly in a real network. I can send to You data related to some 
measurement in switched networks and in hub networks where CAN messages 
are sent using the Ethernet backbone, once packet in UDP datagrams, 
using a modified TCP/IP protocol in a similar way the ARINC 664 (AFDX) 
protocol suggests.

Please let me know if our work can be of some interest from Your side, 
no problem for us to open the doors to friends and share the whole 
knowledge and experience.

Kind regards

Massimiliano Ruggeri
----

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 09 Aug 2013 11:44:37 -0700

Massimiliano,

On Tue, 2013-08-06 at 12:05 +0200, m.ruggeri wrote:
> discussion. Sorry for that.

No apologies necessary.

>  I will try to expose my point of view, 

Some of my comments on your comments will be review, but since you're
new on the list ... the rest can flush my traffic (they do anyway).

> I'm a CAN and automotive systems expert rather than an Ethernet and IP 

While I'm no expert on CAN, what I see here is a very familiar argument.

CAN is, from what I do know, wholly for intra-vehicle communications.
Or, to put into internet-speak, it is not a routable network.  This
leads to two (very familiar) sides of the discussion:

Intra.  One side of the discussion says 'preserve the CAN investment'.
For those exceptional cases where we import or export the data, we'll
drop in a layer 7 gateway.

Inter.  The other side of the discussion is more of a 'do internet'
approach -- we overhaul the local data link to make it routable
(ethernet is one example of routable network).  This requires making the
end systems considerably smarter, so there's some NRE involved.  That
engineering and technology may be new to this particular industry, but
not to the internet at large.  

My personal background is as a communicator, certainly not as an
automobile engineer.  So my biases will be toward the Inter. approach
above; you've been warned.
> major goals to be satisfied.

Probably the last major item to get discussed is data security,
particularly data authenticity.  But it should be about the first.

In the Intra case, we assume that any data on the bus (CAN or otherwise)
came from some sensor in the automobile itself.  And since the bus is
standalone, there's no ability for some outsider to put data onto the
network, bogus or otherwise.  So by comprehensive control of the
population of end systems, we can meet the authenticity requirement.  

This assumption falls apart the moment you start importing data from
external.  Such as downloading CAP feeds to get weather reports.  The
security-by-isolation (usually tacit) assumption is no longer valid.  

There are, of course, several ways to deal with the authenticity
requirement.  One is to logically isolate, as in VPNs.  But that runs
counter to the desire to share the data ... you reach a point of
diminishing returns.  
    A better way is to assume that there will be liars among the data
feeds somewhere and the population of data feeds is such that you cannot
control them directly.  Deal with them by requiring positive
authentication OF THE DATA, that is require digital signatures.  
     This impacts several of your secondary arguments -- you will want
enough capacity to deal with the increased message sizes entailed by
adding a signature.  And the one-time engineering costs become a factor:
we have serviceable solutions in the internet environment, but you'd
have to replicate all these in a CAN one.  

> preferred candidate to be a low cost network system in the future.

As you probably gathered by now, I'm on board with this approach.  But
pay attention to high availability issues.  Single-threaded ethernet is
just like any other single-threaded comms system -- component break =
system fail.  We put backup brake systems in automobiles for a good
reason; we should do the same with the comms.  

(Routable networks shine here because they solve, by protocol design,
the reliable crossover problem.  A truck full of gateways will not).

> requirements for autonomous driving and autonomous working, right now. 

The takeaway from this use case (more ubiquitous in agriculture than on
the freeway) is that you have import and export of data.  

> are working on it for Agricultural Machines).

30 years ago, Society of Automotive Engineers -- SAE is a peer standards
body to IEEE -- was working on a ring network standard.  Technically it
was eclipsed by FDDI.  At the time it was too expensive to get traction
in the market.  But the advantage of both SAE Ring and FDDI was that
they solved the high availability problem quite elegantly.  
> opportunity for Automotive systems.

Zoruishi, in Japan, builds things like teapots that are end systems
connected to the internet.  The use case here is that one can check up
on your parents -- use of the teapot is 1) communicated to whoever and
2) a reliable indicator that your folks are OK.

> the Avionic ARINC-664 (AFDX) that was developed - I suppose - in Germany 

ARINC data buses have historically been non-routable, like CAN.  Both
aircraft and military manufacturing use a lot of Mil-1550 bus for
intra-vehicle comms.  Examples of the Intra case above.  None are very
good as soon as you start importing or exporting data. 
> using a modified TCP/IP protocol in a similar way the ARINC 664 (AFDX) 

What modifications did you make?  Why did you feel you needed them?  
     This is also not new but the features of TCP and IP are all there
for a reason and if you monkey with them you're likely to stub your
comms interoperability toe.  (I observed very expensive cases of this in
satellite comms networks.)  The worst of the exercises are those that
place some QoS control requirement before session reliability in the
priority list -- that's always a shortsighted and BAAAAAD tradeoff.  

> knowledge and experience.

The mail group is rather amorphous; there is no 'your side'.  
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Aug 2013 14:51:25 +0200

Hello Massimiliano,

Thanks for the email.  The perspective from agricultural vehicles is
surprisingly similar to that of other vehicles.  The autonomous driving
is one striking such similarity, in the use of tight localization
systems (and the first time I hear of 100Hz GPS sampling!).

I will not be wrong to guess that more automated vehicles are on the
fields and construction sites than on the roads these days.

Le 06/08/2013 12:05, m.ruggeri a écrit :
[...]
> measurement in switched networks and in hub networks where CAN
> messages are sent using the Ethernet backbone, once packet in UDP
> datagrams, using a modified TCP/IP protocol in a similar way the
> ARINC 664 (AFDX) protocol suggests.

I wonder whether this kind of communication from device to CAN to
Ethernet across the Internet and up to some IP server is considered in
agricultural/construction vehicles.  And what are the UDP and TCP/IP
modifications?

This communication scenario is often referred to as "V2I" for Vehicle to
Infrastructure.

Recently, a draft was submitted draft-liu-its-mobility-00.txt which
describes some mobility considerations (Mobile IP and DNS interactions)
for this V2I scenario.

> Please let me know if our work can be of some interest from Your
> side, no problem for us to open the doors to friends and share the
> whole knowledge and experience.

Well, let us discuss further, and see whether V2I scenarios for
agricultural/construction vehicles could be described in an Internet Draft.

Alex

>
> Kind regards
>
> Massimiliano Ruggeri ----
>
>
>> Ethernet AVB is the way to go in the longer term, but cars contain
>> a lot of legacy 8- and 16-bit microcontrollers that are
>> inexpensive and robust.   However, vendors of safety-critical
>> systems like automakers are not anxious to wholesale replace too
>> many of these parts at one go, and I don't blame them.
>>
>> packets to CAN messages or SPI signals in a real-time control
>> system is not so simple.    Prof. Max Ruggeri of Italy's Imamoter
>> Institute (CC'ed) has done some fine work on creating CAN-Ethernet
>> gateways for agricultural applications, which are commonly fully
>> autonomous.   See, for example, his paper "SAE J 1939 Over Real
>> Time Ethernet: The Future of Heavy Duty Vehicle Networks"
>> (doi:10.4271/2012-01-1988).
>>
>>>> Perhaps using a protocol other than IP will also have security
>>>> benefits? The PKE model of DSRC, with its reserved safety
>>>> channel and reserved PSIDs, seems pretty appealing for safety
>>>> applications.
>> Roland inquires:
>>> Security by obscurity? Sure, on the one hand IP knowledge and
>>> attack tools are more widely available, on the other hand the
>>> security mechanisms like IPsec/DTLS and so on are proven to work
>>> well.
>>  Segregating higher-priority communications about safety to
>> separate DSRC channels in 802.11p is not intended to to be obscure
>> but to be robust by design in a way that other 802.11 protocols
>> are not.    I used nmap today to figure out why I couldn't ssh in
>> to my own system, and find "pen tools" useful for debugging myself,
>> but that doesn't mean that I believe that my toaster should run
>> IPV6.
>>
>> It is regrettable indeed that SAE, ISO and (IIRC) ETSI protocols
>> are not available for free.   The difficulty of interchanging
>> these freely really hampers discussions like the present one.
>> Congrats to IETF for staying open.
>>
>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>