- From: Magnus Feuer <mfeuer1@jaguarlandrover.com>
- Date: Tue, 11 Feb 2020 18:00:09 +0000
- To: Rudolf J Streif <rudolf.streif@ibeeto.com>, Ulf Bjorkengren <ulfbjorkengren@geotab.com>, "Schildt Sebastian (CR/AEX1)" <Sebastian.Schildt@de.bosch.com>
- CC: "public-automotive@w3.org" <public-automotive@w3.org>
- Message-ID: <DB7PR04MB46974C8A31F0AAD763916FBBF9180@DB7PR04MB4697.eurprd04.prod.outlook.com>
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. 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.
@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. The alternative is to have setter signals to actuate change, with which I see a number of problems:
1. 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.
2. 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.
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.
3. 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.
4. 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.
/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: Rudolf J Streif
Sent: Tuesday, February 11, 2020 08:27
To: Ulf Bjorkengren; Schildt Sebastian (CR/AEX1)
Cc: Magnus Feuer; public-automotive@w3.org
Subject: Re: Proposal for Remote Procedure Call extensions to VISS.
I am top posting since I would like to take a step back (and then a leap forward).
I think the discussion jumped too quickly from "what" to "how". The "what" being an agreement on RPC and their purpose within VSS and the "how" being the discussion about protocols etc.
What is the purpose of RPC within VSS? How is it intended to be used? Magnus made the example of opening a window. If that is the only purpose then what is the added value? The current VSS specification already calls for read and write access to signals. In this case RPC would only be a specific implementation mechanism to access a resource. The same can be achieved with REST. And there is not much beyond what is already in the specification.
I think RPC gets more interesting if there are more complex or compound operations to be carried out. Or it could be an abstraction. For example an RPC call could be secureVehicle(). It is a generic call and what the vehicle actually does would depend on the vehicle's implementation. Some vehicles might close all the windows, sun roofs, lock the doors, apply the parking brake, arm the alarm, send current position information, etc. Others might just do a subset.
Now RPC is so Nineties. Since vehicles are distributed compute environments and everybody is talking about the next generation of in-vehicle networking architecture shouldn't this effort be more forward looking and think of this in terms of a mircoservices architecture?
:rjs
On 2/11/20 2:18 AM, Ulf Bjorkengren wrote:
>> Or you introduce some “RPC” endpoints in the data model that expect some complex input data and specifying return values. My feeling is that the latter is too much.
I fully agree.
>> Maybe there is some middle ground, where one can define that there is an RPC mechanism (which means, transports need to have a support a generic query/response scheme that can do more than “writeInt()->Done()”), but not defining/modelling detailed RPC signaturess in VSS?
I think it is necessary to put proposals of this on the table to be able to say yes or no to the question.
The JLR proposal is one, which has the advantage that it does not require any modification of the standard (I believe?).
BR
Ulf
On Tue, Feb 11, 2020 at 10:26 AM Schildt Sebastian (CR/AEX1) <Sebastian.Schildt@de.bosch.com<mailto:Sebastian.Schildt@de.bosch.com>> wrote:
Hi,
so I feel the main issue here is one of scope for VISS:
We definitely can have HTTP, “Classic”-Websocket, WAMP, MQTT, etc. as “transports”, and the VISS specification might just reference them as optional parts such as “IF you want to do REST with VISS ; HERE is how we suggest you do it, in case of WAMP map it like this, for MQTT….” A little bit like convergence layers in Bundle Protocol.
But the question really is should the underlying data model understand the notion of RPCs? If an actor is just a node in the tree you can write to, and what will really happen is sort of hidden. Or you introduce some “RPC” endpoints in the data model that expect some complex input data and specifying return values. My feeling is that the latter is too much. (It might make VISS a feature monster….). Maybe there is some middle ground, where one can define that there is an RPC mechanism (which means, transports need to have a support a generic query/response scheme that can do more than “writeInt()->Done()”), but not defining/modelling detailed RPC signaturess in VSS?
Mit freundlichen Grüßen / Best regards
Sebastian Schildt
CR/AEX1
Tel. +49 711 811-15765 | Mobil +49 173 7124227
► Take a look at Bosch Research: www.bosch.com/research<http://www.bosch.com/research>
From: Ulf Bjorkengren <ulfbjorkengren@geotab.com<mailto:ulfbjorkengren@geotab.com>>
Sent: Dienstag, 11. Februar 2020 09:36
To: Magnus Feuer <mfeuer1@jaguarlandrover.com<mailto:mfeuer1@jaguarlandrover.com>>
Cc: public-automotive@w3.org<mailto:public-automotive@w3.org>
Subject: Re: Proposal for Remote Procedure Call extensions to VISS.
Thanks for the explanation.
I see this as a rather lightweight wrapper on top of VISS(/Gen2) that provides a different interface style. Which is fine with me, but I am doubtful in it being a formal part of the standard.
I also conclude that this is a different thing than WAMP that Gunnar mentioned.
BR
Ulf
On Mon, Feb 10, 2020 at 11:03 PM Magnus Feuer <mfeuer1@jaguarlandrover.com<mailto:mfeuer1@jaguarlandrover.com>> wrote:
I forgot the most important bit, the function call itself:
call_rpc("Vehicle.Cabin.Door.Row1.Left.Window.SetPosition", Position=50);
The argument (Position) can either be defined locally in the RPC definition, as per my previous email, or be a reference / anchor to a signal (tree) living somewhere else in the spec
/Magnus F.
-------------------
System Architect Manager
Jaguar Land Rover
Email: mfeuer1@jaguarlandrover.com<mailto:mfeuer1@jaguarlandrover.com>
Mobile: +1 949 294 7871
[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: Magnus Feuer <mfeuer1@jaguarlandrover.com<mailto:mfeuer1@jaguarlandrover.com>>
Sent: Monday, February 10, 2020 13:52
To: Ulf Bjorkengren <ulfbjorkengren@geotab.com<mailto:ulfbjorkengren@geotab.com>>
Cc: public-automotive@w3.org<mailto:public-automotive@w3.org> <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Subject: Re: Proposal for Remote Procedure Call extensions to VISS.
Ulf,
The idea is that the function name, and its arguments, live outside the VSS spec, driving our JLR principle of "RPC to actuate. Signal to sense". We are using a separate YAML file format for our service specifications.
That said, the idea of integrating function names into the VSS spec is probably worth exploring, although it may be too much feature packing into a single spec.
An RPC call in a VSS spec file would look something like:
# Signal to report window position
- Position:
datatype: uint8
type: sensor
min: 0
max: 100
unit: percent
description: Window position. 0 = Fully closed 100 = Fully opened.
# RPC to actuate window position
- SetPosition:
type: rpc
description: Move the window to a spcific position
arguments:
- TargetPosition:
datatype: uint8
min: 0
max: 100
unit: percent
description: The target position to move the window to. 0 = Fully closed 100 = Fully opened.
return:
- Result:
datatype: uint8
description: The result code (from a standard set of result codes)
- CurrentPosition:
datatype: uint8
min: 0
max: 100
unit: percent
description: The position of the window at the start of the window move
Complex arguments (structs and nested structs) would look much like a signal tree.
Thoughts?
/Magnus F.
-------------------
System Architect Manager
Jaguar Land Rover
Email: mfeuer1@jaguarlandrover.com<mailto:mfeuer1@jaguarlandrover.com>
Mobile: +1 949 294 7871
[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: Ulf Bjorkengren <ulfbjorkengren@geotab.com<mailto:ulfbjorkengren@geotab.com>>
Sent: Monday, February 10, 2020 02:20
To: Magnus Feuer <mfeuer1@jaguarlandrover.com<mailto:mfeuer1@jaguarlandrover.com>>
Cc: public-automotive@w3.org<mailto:public-automotive@w3.org> <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Subject: Re: Proposal for Remote Procedure Call extensions to VISS.
Hi,
I think this could be an interesting extension to the standard.
At the same time I see it as a "wrapper" on the standard, which I do not think should be part of the normative standard, possible a non-normative note or the like.
I have a few comments on what is presented on https://github.com/PDXostc/viss-rpc.
- In "subscribe" calls the path is explicitly used, while in "call" calls this is implicit in the "function" parameter (which must then by the receiving server be mapped to a path). This means every leaf node in the tree would have to have a unique function value.
- In the "call" example the "arguments" filed contain the format of provided data. This format is known already by the server from the VSS metadata of this node. Providing it in the call open for the problem of mismatch with the metadata in the tree.
I do not think that neither this nor WAMP, or any other pub-sub solution, should replace HTTP and/or WebSocket as transports, but rather complement them.
BR
Ulf
On Fri, Feb 7, 2020 at 12:45 AM Magnus Feuer <mfeuer1@jaguarlandrover.com<mailto:mfeuer1@jaguarlandrover.com>> wrote:
All,
We have been exploring an extended VISS protocol that allows for remote procedure calls to be invoked over the same websocket that today runs signal pub/sub.
Since we believe this extension may be of use to the wider community, we would like to explore the possibility of expanding the W3C standard accordingly.
The proposal, and a working sample implementation, can be found at:
https://github.com/PDXostc/viss-rpc
All is open sourced under MPLv2.
This is in no way a completed spec. Things such as nested arguments (structs) and callbacks missing, so questions, proposals, and criticism would be much appreciated.
If we come to an agreement that this is the right way forward I will make sure that JLR matures code and documentation as needed to integrate them into the W3C standard.
Regards,
/Magnus F.
-------------------
System Architect Manager
Jaguar Land Rover
Email: mfeuer1@jaguarlandrover.com<mailto:mfeuer1@jaguarlandrover.com>
Mobile: +1 949 294 7871
[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.
--
Ulf Bjorkengren
Geotab
Senior Connectivity Strategist | Ph. D.
Mobile
+45 53562142
Visit
www.geotab.com<https://www.geotab.com/>
--
Ulf Bjorkengren
Geotab
Senior Connectivity Strategist | Ph. D.
Mobile
+45 53562142
Visit
www.geotab.com<https://www.geotab.com/>
--
Ulf Bjorkengren
Geotab
Senior Connectivity Strategist | Ph. D.
Mobile +45 53562142
Visit www.geotab.com<https://www.geotab.com/>
--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700
Received on Tuesday, 11 February 2020 18:00:21 UTC