Re: Proposal for Remote Procedure Call extensions to VISS.

Gunnar,

I do like FrancaIDL.

Our main, non-technical issue is that the Eclipse / Java plugin environment used for tooling is completely outside the tooling we (and, if I may speculate, others) use in their automated CI/CD tool chain.
That, eventually, leads to hiring and resource issues that I would rather avoid.

The upside of using a YAML-based service definition format, semantically equivalent to FrancaIDL, is the vast amount of skill, python libraries and tools available to process such files.

Looking for a path forward, do you know if there, in addition to the rudimentary python support out there today, are plans for FrancaIDL tooling that is easier to deploy in an automated / cloud environment?

/Magnus F.

-------------------
System Architect Manager
Jaguar Land Rover

Email: mfeuer1@jaguarlandrover.com<mailto:mfeuer1@jaguarlandrover.com>
Mobile: +1 949 294 7871

[https://ci3.googleusercontent.com/proxy/OfaGrHPlawsuQPtTYPlu2XkJRCrzJtHOGv2OSrFHsvJ6km-xYenAYwOsmmC-X18PrWn7LzA6AM--8oIU05Ifg6GD=s0-d-e1-ft#http://www.jaguarlandrover.com/email/jlr.jpg]

Jaguar Land Rover North America, LLC
1450 NW 18th Ave, Portland, OR 97209
-------------------
Business Details:
Jaguar Land Rover Limited
Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
Registered in England No: 1672070

This e-mail and any attachments contain confidential information for a specific individual and purpose.  The information is private and privileged and intended solely for the use of the individual to whom it is addressed.  If you are not the intended recipient, please e-mail us immediately.  We apologise for any inconvenience caused but you are hereby notified that any disclosure, copying or distribution or the taking of any action in reliance on the information contained herein is strictly prohibited.

This e-mail does not constitute an order for goods or services unless accompanied by an official purchase order.



________________________________
From: Gunnar Andersson <gandersson@genivi.org>
Sent: Tuesday, February 11, 2020 10:49
To: Magnus Feuer <mfeuer1@jaguarlandrover.com>
Cc: public-automotive@w3.org <public-automotive@w3.org>; Rudolf J Streif <rudolf.streif@ibeeto.com>; Ulf Bjorkengren <ulfbjorkengren@geotab.com>; Schildt Sebastian (CR/AEX1) <Sebastian.Schildt@de.bosch.com>
Subject: Re: Proposal for Remote Procedure Call extensions to VISS.

On Tue, 2020-02-11 at 18:00 +0000, Magnus Feuer wrote:
> Top posting as well.
>
> @Ulf -
> Our initial intent with the proposal was to extend VISS, in a
> backward compatible way, with RPC calls.
> It started of as a protocol that only shared the websocket with the
> pub/sub part, so that we don't have to run several endpoints for a
> single session.

> We then discussed merging signal semantics with RPCs, which seems to
> be a less than ideal solution. I believe that is where we are right
> now.

>
> I think the part forward for VISS, should we decide to expand that
> protocol while we figure out a long-term solution, would be to
> separate RPC calls from the existing pub/sub calls so that their only
> commonality is that they run over a single websocket.

WAMP = Pub/Sub + RPC.  I know I said it already :)
I forget if they run over one or more sockets, but I'd say complexity
largely disappear when this is already specified _and_ implemented.

> That leaves us with how we specify services (if we don't expand the
> VSS format). If there is interest I can check if we can release our
> internal YAML service catalog format as input to that conversation.

I hate if it seems like we just plug "our" preferred technologies
but GENIVI has been and remains consistent on this point.  I think it
is an important virtue that many in the industry appreciate - we have
found out over time how things like Franca, is adopted far beyond what
is really publicly known, but I think this is in part because of
staying firm and consistent.  We stick to recommendations as long as
there is not overwhelming reason to change, and thus create stability
for the industry, year after year.

The principle is simply this:

1) Signal/data semantics which use simple data types:
   --> Vehicle Signal Specification.

2) Complex datatypes and/or command-and-control interfaces:
   --> Franca IDL

That's it!

I really want to voice my objection to creating further overlap and
to keep making every single incompatible technology choice subsume
the same features of every other technology choice, to just create an
even bigger fragmentation mess.

There's already a little overlap, because unlike VSS, Franca IDL is a
complete modeling language for interfaces and therefore a superset.
Franca has Attributes (aka properties) that are observable (aka
pub/sub).  The simplicity of VSS is its power and I really think it
should be protected rather than grow into a generic modeling language.

But some of the overlap turns out useful.  I have in other projects
shown that translation between VSS and Franca Attributes is straight
forward, and this in fact gives us access to create, a SOME/IP service
that exposes signals as defined by VSS (by going via Franca), among
other protocols.  The scaffolding code for this is generated by tools
that already exist today.

Together the ecosystem of tools around these two things, data server
and (micro)services through RPC, create the potential to design just
about anything you need.

The only possible third category I might add is a more streaming/data-
flow type protocol, which I believe should be seen as another category,
compared to on-demand polling, RPC, and pub/sub.  We are keeping a
track open for that need as well, in the Cloud-and-Connected Services
analysis of what future data-driven architectures should look like.

So I'm fully with you on all of the conclusions you have drawn
(as are others to be honest, when we discuss design with other OEM
architects!).  The combination of a data-driven _plus_ API/RPC/services
driven design is what enables a full system design.  These are
excellent, complementary tools.

> @Rudi -
> I agree with that we should focus on the what, or rather the why. As
> I said previously, we internally run RPCs to actuate state change in
> the vehicle and signals to report status.

Exactly, I was almost about to repeat your words in response to Rudi.
I find it natural and a good approach.

Of course it's *possible* for some designs to choose
another behavior, such as:
   Write/Set the value of the VSS signal "*.Door.Window.Position"
means the same thing as "Move the window to this position".

It should not be the primary recommendation for sure, I much prefer
like you actuating by an explicit command API, but it is really not for
us to say.  We should first create the possibilities and tools here,
with perhaps some best-practice guidance.

> The alternative is to have setter signals to actuate change, with
> which I see a number of problems:
>
> Return values
> Defining return values is non-trivial using pub/sub since you will
> end up with transaction signals and other context-specific, short-
> lived data that really is outside the scope of pub/sub.

Yeah, it's not only non-trivial.  If you need a return value, and I
would imagine you do if it is used to indicate success/failure, then
clearly it would be crazy to put this in a "side channel" (another
signal).  Race-conditions, complexity... I just can't see it work
reliably.

>
> Contracting
> Defining a call contract is easier to do when you have a well-defined
> parameters and return values with legal intervals and assert
> conditions. This allows us to write validation systems for call
> sequences at a higher abstraction level than is possible with
> pub/sub.

+1

> Signals are more nebulous since there may be multiple recipients that
> act on them, and there are no real boundaries of when signals can or
> cannot be transmitted.

Precisely, signals are (generally speaking, again not enforcing limits)
a one publisher - multiple subscribers model.


> Complex call sequences
> Once we start seeing A --(call)--> B --(call)--> C --(return)--> B --
> (return)--> A, it will be almost impossible to trace those calls
> using only pub/sub-only .
> Implementing a transaction ID (or rather a transaction ID stack to
> track the call flow) is fairly easy using RPCs, but not really a
> thing you want to do using signals.

+1  You are now just letting your engineering brain run wild with what
how this could /possibly/ be implemented (i.e. misused).  This is
inventive, but it is crazyness - even more than creating new VISS
extensions ;-)

> Type management
> RPC specification languages usually allow you to declare (nested
> structs) and other self-contained data types that can be atomically
> transmitted as an argument or return value to an RPC.
> While this is possible using pub/sub as well, the natural boundaries
> and distinctiveness of a typedef cannot be reproduced in a signal
> tree.
>
> I would love to hear dissenting opinions on the list above since I
> believe there are more things to explore here.

As much as I would like to, I find it impossible to dissent, on most of
what you said here. ;-)

- Gunnar