[agl-discussions] First stab at vehicle signal specification.

Feuer, Magnus mfeuer1 at jaguarlandrover.com
Tue Mar 15 19:55:53 EDT 2016


On Tue, Mar 15, 2016 at 2:26 PM, Mies, Don <dmies at jaguarlandrover.com>

> I have a couple of comments to make on this discussion.  The first is
> concerning internationalization.  I think we need to decide if we want to
> handle internationalization at all.  I've worked with a company that
> supported their software in multiple languages and it was a huge
> undertaking whenever a new release was due.  Do we want to support all of
> the foreign translations for each release?  That being said, Mr. Streif's
> example only shows internationalization of one field.  The description,
> name, etc. are still in English so we'd need a way to internationalize all
> of the relevant fields.  From my experience with internationalization, it
> is much easier to deal with separate documents for each language
> translation as these documents are typically sent to a language expert in
> each supported language.  It would unnecessarily clutter up all of the
> documents to have the translations embedded in each record definition.
I would agree with this. The purpose of VSS is to provide projects with a
common naming nomenclature with basic attributes. It was not really meant
to have data extracted for UI presentation.
That said, should there be a need for i18n, I would propose specifying a
second format that refers to signals in VSS:

   "signal": "drivetrain.transmission.speed",
   "i18n": { "en.us": "speed", "en.uk": "speed", "de.de":
"Geschwindigkeit", "fr.fr": "Vitesse" },

This is similar to the vehicle signal deployment file Rudi and I talked
about in a fork of this thread.

The strategy of externalizing all extensions to their own spec files allows
us to keep the core VSS file clean, thus avoiding forcing its users to
process information that they do not need.

My second question concerns "units".  Just specifying the units for a value
> is not enough to uniquely qualify that value.  For instance, the unit
> "gallon" means significantly different things in U.S. units vs. British
> units.  So in order to define the actual unit being used, the unit system
> must also be defined somewhere (probably in the header that contains other
> global information).  The two most common unit systems are the
> "International System of Units - SI", and the "U.S. Customary" (Used mostly
> in English speaking countries).  That being said, maybe we should adopt a
> "standard" for the units definitions.  NIST (National Institute for
> Standards and Technology) has adopted a units standard that is based on the
> global "SI" units and defines the names, abbreviations, symbols, and
> conversion factors for all of the base units and derived units.  The
> definition and standardization of units is an entire Engineering discipline
> all by itself and we certainly don't want to get into that business.
What I would really like here is an official list of SI/NIST units,
including abbreviations (c, kph, mbar, etc)  that we can refer to from the

> *Don Mies*
> Systems Architect - Open Source Projects
> Open Source Technology Center
> *Email*: dmies at jaguarlandrover.com <mfeuer at jaguarlandrover.com>
> *M*: +1 601-953-3397
> Jaguar Land Rover North America, LLC
> 1419 NW 14th Ave, Portland, OR 97209
> Jaguar USA <http://www.JaguarUSA.com/index.html>  |  Land Rover USA
> <http://www.LandRoverUSA.com/us/en/lr>
> -------------------
> 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.
> /Magnus F.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genivi.org/pipermail/genivi-projects_lists.genivi.org/attachments/20160315/d0ca309c/attachment.html>

More information about the genivi-projects mailing list