RE: Vehicle Signal Specification

Looks good!

One thing that comes to mind when dealing with all these signals is a mechanism to query if a certain signal or set of signals is/are available. I guess that it could be handled in an error reply through our subsuscribe/get apis. Question is if we need something else/more ?

I will start looking at our current spec next week and see how things match up.




Br
Peter Winzell
From: Streif, Rudolf [mailto:rstreif@jaguarlandrover.com]
Sent: Thursday, May 19, 2016 1:16 AM
To: public-automotive
Cc: Magnus Feuer
Subject: Vehicle Signal Specification

Colleagues:

We have been discussion the Vehicle Signal Specification (VSS) as the basis for the data structure for our new web services approach to provide access to vehicle data and allow control of various vehicle functions from a managed runtime, web runtime, and/or web browser:

[Inline image 1]
(The slide is from a deck I presented at the Future Connected Cars Conference in Santa Clara last week.)

We have now published the first iteration of the VSS on GitHub [1] for review and commenting. The specification is modeled after actual signals from CAN bus databases used by JLR. The current iteration contains about 180 signals which we expect will grow to about 500 signals with the coming iterations.

You can easily see that because of the sheer number of signals and controls, a dynamic approach for the API based on services and JSON data structures makes very much sense.

The hierarchical approach with signal paths also naturally lends to grouping of signals which is important for subscription.

For example a door has multiple signals:
·  body.door.0.left.locked
·  body.door.0.left.open
·  body.door.0.left.child_lock
·  body.door.0.left.window_position
·  body.door.0.left.curtain_position
You can now group signals using wildcards:
·  body.door.0.left.*       (all signals of the left door of the first row)
·  body.door.0.*            (all signals of all doors of the first row)
·  body.door.*              (all signals for all doors)
·  body.*                   (all body signals)
And equally using "in between" wildcards:
·  body.door.0.*.open       (open status of all doors in the first row)
·  body.door.*.left.open    (open status of all doors on the left side of the vehicle)
·  body.door.*.*.open       (open status of all doors on all sides of the vehicle)
·  body.*.*.*.open          (open status of anything that provides it e.g. doors, hood, trunk, moon roof, filler cap, ...)

We invite your feedback and consideration.

Best regards,
:rjs

[1] https://github.com/GENIVI/vehicle_signal_specification



--
Rudolf J Streif
System Architect - Open Source Initiative
Open Source Technology Centre

M: +1.619.631.5383
Email:  rstreif@jaguarlandrover.com<mailto:rstreif@jaguarlandrover.com>

[http://www.jaguarlandrover.com/email/jlr.jpg]
UK: G/26/2 G02 Building 523, Engineering Centre, Gaydon, Warwick, CV35 ORR
US: 1419 NW 14th Ave, Portland, OR 97209
jaguar.com<http://jaguar.com> | landrover.com<http://landrover.com>
-------------------
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.