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

Walt Miner wminer at linuxfoundation.org
Thu Mar 17 18:28:52 EDT 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genivi.org/pipermail/genivi-projects_lists.genivi.org/attachments/20160317/2eeffd4b/attachment.html>


More information about the genivi-projects mailing list