First stab at vehicle signal specification.

Feuer, Magnus mfeuer1 at
Thu Mar 17 18:52:15 EDT 2016


tl;dr: JSON may not be a good choice. How about a simple proprietary flat
file structure?

/Magnus F.

On Wed, Mar 16, 2016 at 10:00 AM, Streif, Rudolf <
rstreif at> wrote:
> [...] It feels a little clunky to me. [...] Nevertheless, I would urge to
> get it right the first time and not to change it later.

I am, too, starting to feel uncomfortable about bastardized JSON. See


> = "body.door.0.left"
> body.door.0.left.description = "Driver door"
> body.door.0.left.alias = "body.door.driver"
> How about:

--- root.vspec ----

  type: branch
  description: "Left front door"

  type: branch
  description: "Right front door"

#include "door.vspec", "body.door.front.left"
#include "door.vspec", "body.door.front.right"

--- door.vspec ---

  type: string
  enum: "locked","unlocked"
  description: "Is door locked or not"

  type: Uint8
  min: 0
  max: 100
  description: "Window position. 0 = all up 100 = all down."

We can easily generate a nested JSON file from the above.


> The better wording would probably consistency rather than standardization.
> The potentially growing tree and the QA required are concerns that I think
> need to be addressed by a clean structure that can easily be verified with,
> preferably standard, tooling. That is one of my concerns with the proposed
> hybrid file format.



> If you define the aliases outside the structure they can easily be handled
> by include files.
So you would have a vehicle_abc.vspec file for a specific model/year, which
would have the following content (given the file format proposed above):

#include root.vspec

body.door.driver alias body.door.front.left

That would work.

If somebody wants to pick up on that I would be happy to setup a PDXostc
>> repo to host it. That said, I would like to keep that project outside VSS
>> to limit scope creep.
> That would mean one repo referencing another. I don't think that would
> work well. But keeping aliases, if we really want them, in a separate
> directory eventually in separate branches could accomplish separation and
> proximity.
> Agree.

> :rjs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the genivi-projects mailing list