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

Feuer, Magnus mfeuer1 at jaguarlandrover.com
Thu Mar 17 18:48:23 EDT 2016


Ack.

Please tell me how we can help integrate this into AGL's effort.

/Magnus F.

-------------------

*Head System Architect - Open Source Projects**Jaguar Land Rover*

*Email*: mfeuer1 at jaguarlandrover.com
*Mobile*: +1 949 294 7871



Jaguar Land Rover North America, LLC
1419 NW 14th 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.

On Thu, Mar 17, 2016 at 3:28 PM, Walt Miner <wminer at linuxfoundation.org>
wrote:

> I created this issue in Jira to track this for AGL.
>
> https://jira.automotivelinux.org/browse/SPEC-154
>
>
> On Thu, Mar 17, 2016 at 7:07 AM, Stephane Desneux <
> stephane.desneux at iot.bzh> wrote:
>
>> Inlined (with some clean up for readability)
>>
>> On 16/03/16 22:44, Mies, Don wrote:
>> > Thank you to Stephane and Magnus.  I have some comments inline in the
>> following:
>> >
>> > On Wed, Mar 16, 2016 at 1:06 PM, Stephane Desneux
>> <stephane.desneux at iot.bzh
>> > <mailto:stephane.desneux at iot.bzh>> wrote:
>> >
>> >     Following Don's hints, I've found this documentation easily:
>> >     http://physics.nist.gov/cuu/Units/index.html
>> >     and this page in particular:
>> >     http://physics.nist.gov/cuu/Units/units.html
>> >
>> > These references are OK but I think they only define the SI units used
>> in
>> > Physics and Chemistry.  The references I had are:
>> >
>> >       SI Standards:  http://www.bipm.org/en/publications/si-brochure
>> >
>> >       NIST Standards:  http://www.nist.gov/pml/pubs/sp811
>> >
>> > Many of these references are overlapping so I don't think they conflict
>> at all.
>> > We should just decide which ones we want to use as our "standard" for
>> consistency.
>>
>> Exactly. Let's take the most complete one. And if some units are not
>> standardized, we can decide to express them as derived from base or
>> already
>> existing units. As you pointed for "non-units", we can also decide to
>> create
>> arbitrary pseudo-units for "boolean", "count", "ratio", ...
>> >
>> >     Having a table describing the units in a top section or separate
>> file can make
>> >     sense to check signals integrity.
>> >
>> >     The units list could be something as simple as this:
>> >     {
>> >        "m": {
>> >           "quantity": "length",
>> >           "name": "meter"
>> >        },
>> >        "s": {
>> >           "quantity": "time",
>> >           "name": "second"
>> >        },
>> >        "m/s": {
>> >           "quantity": "speed",
>> >           "name":"meter per second"
>> >        },
>> >        "Wb": {
>> >           "quantity": "magnetic flux",
>> >           "name": "weber"
>> >        }
>> >     ...
>> >     }
>> >
>> >
>> > I like the idea of having a separate file that describes the units.
>> This could
>> > be enhanced to also specify the conversion factors between units.  We
>> could have
>> > something like:
>> >
>> >   "m/s" :
>> >   {
>> >     "quantity" : "speed",
>> >     "name" : "meters per second",
>> >     "conversions" :
>> >     {
>> >       "kph" : ( 3600 / 1000 )
>> >       "mph" : 2.2369362921
>> >     }
>> >   }
>>
>> Yes. Please check my proposal for conversions below.
>>
>> > This file would be something that is defined by the group and included
>> by
>> > specific implementations.  The implementers could also add to the
>> definitions if
>> > they had a need to but modifying an existing value should be frowned
>> upon.
>>
>> Agreed.
>>
>> >     Some remarks:
>> >
>> >     * the main constraint is on the unit symbol (i.e "m", "s", "m/s"
>> ...) which must
>> >     be unique. It's self-expressed with symbols used as JSON object
>> keys. These
>> >     symbols can then be used as self-describing ids for units in signals
>> >     definitions. NB: the symbols are case sensitive and can be
>> displayed, as they
>> >     follow the SI/NIST official names.
>> >
>> >
>> > I agree.  The main unit definition name needs to be unique.
>>
>> OK
>>
>> >     * Without an extra constraint, multiple units may describe the same
>> quantity:
>> >     this means that we could have "m/s","km/h","kph" and "mph" to
>> express speed. Why
>> >     not ? But we have to choose.
>> >     IMHO this could be a problem at usage time as applications/daemons
>> would have to
>> >     check for units and make appropriate conversions: more errors could
>> be due to
>> >     no/bad conversions and so we'd need a conversion library everywhere.
>> >     So I'd vote for an extra constraint on the uniqueness of
>> "quantity": having a
>> >     single unit for a given quantity is probably better even if there
>> are
>> >     conversions to be done at signal source and at usage time. As a
>> consequence,
>> >     displayed/usage units would depend primarily on locale/region/user
>> settings and
>> >     wouldn't be used in signals. Also, to describe a quantity, it may
>> be better to
>> >     choose SI/NIST units and avoid exotic ones: for speed, we'd choose
>> "m/s", not
>> >     "kph" even if it's less meaningful for end users.
>> >
>> >
>> > I'm not sure that having multiple units that represent the same
>> quantity like
>> > "m/s", "kph", "mph", etc. is necessarily bad as long as we have a well
>> defined
>> > conversion factor for each one to our preferred internal unit.  This
>> might be
>> > necessary in cases such as a CAN speed sensor that gives the speed in
>> "kph" or a
>> > gauge that requires it's input in "mph".  If we agree to always use the
>> defined
>> > internal unit (like "m/s") then we can convert to/from any of the other
>> units
>> > that we have conversion factors for.
>>
>> Just a precision: I may be wrong but the units we're specifying in this
>> VSS file
>> are used for signals only, not for anything else ATM ? Assuming that we
>> defined
>> "m/s" as the unit for "speed", if we have a CAN sensor that sends input in
>> "kph", then we'll have to convert to "m/s" when receiving the CAN frame
>> then we
>> can emit a signal of "speed" in "m/s". When a subscriber receives this
>> signal,
>> if it has to work with "mph", it will convert the signal value from "m/s"
>> to
>> "mph" and we're done. The point is that speed signals should always be
>> expressed
>> the same way, whether we choose "m/s" or "kph" for the speed unit.
>>
>> If we allow multiple units for a given quantity, we may encounter some
>> problems
>> when defining a new speed unit which is not "known" yet by signal
>> subscribers.
>> You'll have to add some code in the subscriber to convert from the new
>> unit. And
>> if you don't add code, you won't be able to handle the signal values,
>> even if
>> you know how to handle the quantity. At least, if you only define one
>> unit per
>> quantity, there's no conversion dilemma: either the subscriber knows how
>> to
>> handle the quantity (with its known unit), or it doesn't.
>>
>> Having a constraint on signal units ("only one unit per quantity")
>> doesn't mean
>> that we couldn't define in the same file how to convert to other
>> equivalent
>> units, but this would be only for convenience.
>>
>> I'd propose something based on your previous proposal, with a few changes:
>> * to be consistent, we can give names to alternate units. the quantity is
>> implicit as it's the same as the main unit
>> * some conversions may need multiple factors. For example, between °C and
>> °F:
>> T(°F)=T(°C) * 1.8 + 32
>> * we should avoid formulas, as it would require some formula parsing to
>> be able
>> to use them in any condition (ex: C code that reads the json file using
>> json-c).
>> And BTW, JSON is strict: (3600/1000) is not a valid numeric value :\
>>
>> So we could have:
>> "°C": {
>>    "quantity":"temperature",
>>    "name":"degree celsius",
>>    "conversion": {
>>       "°F": {
>>          "name":"degree fahrenheit",
>>          "factors": [ 1.8 , 32 ]
>>       }
>>    }
>> },
>> "m/s" {
>>    "quantity" : "speed",
>>    "name" : "meters per second",
>>    "conversion": {
>>       "kph": {
>>          "name":"kilometer per hour",
>>          "factors": 3.6, # no need for an array if only one factor
>>       },
>>       "mph": {
>>          "name":"mile per hour",
>>          "factors": 2.2369362921
>>       }
>>    }
>> }
>>
>> Most conversions should be possible with this simple "two factors" model.
>>
>> For more complex conversions, I propose to put them out of scope:
>> * some conversions formula are not linear (not expressed as ax+b)
>> * some conversions factors are variant
>>
>> For example, a sensor could give speed with a "wheel rpm" unit (it counts
>> the
>> number of wheel revolutions per minute) but the wheel perimeter varies
>> depending
>> on time (tires state changes on a given car) and also varies from one car
>> to
>> another (wheel diameter varies). So we can't normalize any conversion
>> factors
>> from "m/s" or "kph": converting from/to this unit is out of the scope of
>> the VSS
>> specification because we probably want to keep things simple.
>>
>> So we should allow alternate units without specifying any conversion
>> factors:
>> {
>>    "m/s": {
>>        ...
>>       "conversion": {
>>          "wrpm": {
>>             "name": "wheel rpm"
>>          }
>>       }
>>    }
>> }
>> In this case, the emitter or subscribers have to take care of the
>> conversion by
>> themselves: VSS won't help.
>>
>> >     * some signals don't have any unit (ex: counts or ratios). So a
>> signal unit may
>> >     be a) optional or b) we should define a unit which means "no unit"
>> :)
>> >
>> >
>> > We could either not define a unit for something like this or define it
>> with some
>> > generic unit like "boolean" or "count".
>>
>> Yep, good idea. Seen before.
>>
>> >     * we could also document how a unit relates to others, with
>> something like:
>> >        "Wb": {
>> >           "quantity": "magnetic flux",
>> >           "name": "weber",
>> >           "alt": ["V.s","W.s.A-1","m2.kg.s-2.A-1"] # alternate
>> representations
>> >        }
>> >       BTW, this also means that the Weber is not a base unit.
>> >       Do we have use cases for this ?
>> >
>> >
>> > There are only 7 base units so almost everything that we will be
>> dealing with
>> > are derived units.
>>
>> Sure. But I don't think that specifying alternate representations like
>> the one I
>> proposed for Weber with the "alt" key is useful. I don't see any use case
>> for
>> that. I'd drop the "alt" key.
>>
>> >     * there's no need to define all possible units in advance. We could
>> first define
>> >     a base set of units. Then when adding new signals, the integrity
>> check procedure
>> >     could raise errors/warnings on undefined/unused units and drive the
>> author to
>> >     add/remove the appropriate ones to ensure integrity and efficiency.
>> >
>> >
>> > I agree.
>> OK.
>>
>> Thanks for contribs !
>>
>> Best regards,
>> Stéphane
>> _______________________________________________
>> automotive-discussions mailing list
>> automotive-discussions at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
>>
>
>
>
> --
> Walt Miner
> Engineering Project Manager
> The Linux Foundation
> mobile: +1.847.502.7087
> skype: vstarwalt
>
> Visit us at:
> automotive.linuxfoundation.org
> www.linuxfoundation.org
>
>
>
> _______________________________________________
> genivi-projects mailing list
> genivi-projects at lists.genivi.org
> https://lists.genivi.org/mailman/listinfo/genivi-projects
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genivi.org/pipermail/genivi-projects_lists.genivi.org/attachments/20160317/d9afaa94/attachment.html>


More information about the genivi-projects mailing list