- From: Winzell, Peter <peter.winzell@volvocars.com>
- Date: Wed, 2 Sep 2020 17:49:26 +0000
- To: "ted@w3.org" <ted@w3.org>, Ulf Bjorkengren <ulfbjorkengren@geotab.com>
- CC: Gunnar Andersson <gandersson@genivi.org>, public-automotive <public-automotive@w3.org>, Jay Hum <jay@autonomic.ai>
Ok got it I misunderstood. I am involved in a data collection project where we currently "push" data using MQTT as transport. The Gen2 implementation in this case would be solely cloud based on top of that data - not interfacing directly with the vehicle(is this something that a developer needs to be concerned with, yes maybe in the context of real-time properties or maybe not). So, that confirms somewhat what MagnusF is saying. It is more practical to push data as Magnus mentioned "(vehicle not running or otherwise offline/out of cell network reception, security concerns), ".
Another discussion is where and when the gen2 implementation could be used in-vehicle. For Volvo having Android as current infotainment platform it does not make much sense to have a gen2 implementation for infotainment-based apps, since Android have APIS to access vehicle signals that cover many use cases. Having said, that there are other nodes in the vehicle network where the gen2 could potentially being used, as we have done in the past (VISS).
Br
Peter Winzell
On 9/2/20, 10:05 AM, "Ted Guild" <ted@w3.org> wrote:
Peter,
Gen2 is pull (HTTP GET and subscribe over web socket requests) and
while there may be schemes to initiate a pull and then redirect to in
this case cloud client and in effect be a push, we aren't proposing
that yet.
We are not limiting where Gen2 can be used nor how. Main uses
discussed:
-In-vehicle Gen2 instance for apps running on same vm, other vm in-
vehicle or trusted paired devices (eg smartphone) on a local network.
-Gen2 instance running on cloud with already off-boarded data so client
apps can run indirectly from vehicle.
-In-vehicle Gen2 that will accept connections from outside world,
likely firewalled to OEM cloud servers only. Is this sufficient for
off-boarding more substantive amounts of telematics data, perhaps but
cloud servers will need to poll (repeatedly check if vehicle is online)
and then make its pull requests (GET, subscribe. POST is a push to
vehicle from cloud but initiated by client - cloud server)
Magnus indicated what I have heard to be a common practice for reasons
given (vehicle not running or otherwise offline/out of cell network
reception, security concerns), that offboarding data from vehicle to
cloud is usually pushed from vehicle.
It would be good to confirm what other OEM in this group are doing as
well as Geotab and Autonomic. How does the information flow?
On Wed, 2020-09-02 at 16:27 +0000, Winzell, Peter wrote:
> So, yes, we will likely be using our own cloud servers for now. I do
> not, however, believe that the current gen2 should be tailored for
> pull vs push since this is likely to limit use cases. This is my
> personal opinion of course, I will have a discussion internally to
> get a broader understanding.
>
> Br
> Peter W
>
> On 9/2/20, 8:38 AM, "Ted Guild" <ted@w3.org> wrote:
>
> It may well not be an absolute truth but those are rather strong
> influencers. MagnusF affirmed that is why they are why they push
> to
> cloud instead of pull from.
>
> Say you're managing several million vehicles. Do you want to poll
> them
> frequently wondering if they are on/running and online (within
> cell
> reception)? Those will often go unanswered. Even if pull (Gen2
> requests) is permitted it likely would only be from OEM cloud
> servers
> and not independent garage, fleet managers' servers. Those
> connections
> can timeout from tunnels, parking garages etc and would want to
> be able
> to buffer regardless of push/pull.
>
> Discussed in brief during GENIVI CCS call. I agree with Ulf we
> are open
> to Gen2 being used however OEM or other implementers prefer.
>
> Off-boarding in CCS scope diagram:
>
>
> https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=44859735&preview=/40402952/47711462/communication-architecture-draft-CCS.pdf
>
> As mentioned, there are perhaps some things such as supporting
> binary
> or other format output to subscriptions in Gen2 that would
> benefit both
> push and pull provided we keep both in mind.
>
> On Tue, 2020-09-01 at 21:35 +0200, Ulf Bjorkengren wrote:
> > >> For a variety of reasons (security, connectivity, car being
> off),
> > data being off-boarded from vehicle to the cloud will be
> pushed, not
> > pulled.
> > I don't see this being an absolute truth. I think the concerns
> > mentioned can be mitigated, thus enabling the pull scenario.
> > I guess it is the OEMs that ultimately makes this call, so I
> hope to
> > hear their view on it.
> > BR
> > Ulf
> >
> >
> > On Tue, Sep 1, 2020, 21:10 Ted Guild <ted@w3.org> wrote:
> > > On Tue, 2020-09-01 at 11:28 -0400, Ted Guild wrote:
> > > > We can/should also explore alternate formats Gunnar
> suggested
> > > >
> > > > https://en.wikipedia.org/wiki/Apache_Avro
> > > > https://en.wikipedia.org/wiki/Protocol_Buffers
> > > >
> > > > As these messages being transmitted are fairly small to
> begin
> > > with
> > > > and
> > > > in-vehicle use case will have extremely low latency, I also
> want
> > > to
> > > > try
> > > > to understand how/where this would be more useful as
> > > > encoding/compressing and decoding will cost time and
> depending on
> > > > method non-negligible cpu. If the client app is just
> sampling to
> > > > offboard and won't unpack (decode), then we probably should
> look
> > > at
> > > > Extended Vehicle and other solutions being used for off-
> boarding
> > > in
> > > > addition to formats. What problem[s] are we trying to solve
> here?
> > >
> > > We confirmed on the call today the primary use case is for
> off
> > > boarding
> > > data.
> > >
> > > For a variety of reasons (security, connectivity, car being
> off),
> > > data
> > > being off-boarded from vehicle to the cloud will be pushed,
> not
> > > pulled.
> > >
> > > Gen2 server instance can reside either in-vehicle or on a
> server in
> > > the
> > > cloud.
> > >
> > > For in-vehicle client apps that will be residing on the
> vehicle or
> > > nearby (local network) trusted devices, compression is not
> needed.
> > > Cloud servers will not be permitted to connect to Gen2 (ports
> not
> > > open)
> > > on a vehicle to make pull requests. Gen2 supports clients
> making
> > > pulls,
> > > HTTP GET and subscribe on Web Socket, it cannot initiate a
> push to
> > > server in the cloud.
> > >
> > > Gen2 supporting alternate, including binary, formats besides
> JSON
> > > for
> > > more efficient local storage until it can send buffered data
> off
> > > the
> > > vehicle would help with 'every byte counts' when sending data
> off
> > > the
> > > vehicle.
> > >
> > > VSS in protobuf format can make a ton of sense, perhaps with
> some
> > > further optimization along lines of what Ulf and Sanjeev have
> been
> > > working on.
> > >
> > > Gen2 server residing in the cloud, exposing data already off-
> > > boarded
> > > can respond to pull requests from client apps running
> elsewhere in
> > > the
> > > cloud. Compression makes sense there.
> > >
> > > If someone has a different architecture in mind where
> vehicle<-
> > > >cloud
> > > connections differ fundamentally or we can translate a pull
> to push
> > > by
> > > redirecting and caching/buffering data, I would like to hear
> it.
> > >
> --
> Ted Guild <ted@w3.org>
> W3C Automotive Lead
> https://www.w3.org/auto
>
>
--
Ted Guild <ted@w3.org>
W3C Automotive Lead
https://www.w3.org/auto
Received on Wednesday, 2 September 2020 17:49:42 UTC