First stab at vehicle signal specification.

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


Inlined.

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 jaguarlandrover.com> 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
below.

[...]

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

--- root.vspec ----

body.door.front.left
  type: branch
  description: "Left front door"

body.door.front.right
  type: branch
  description: "Right front door"

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

--- door.vspec ---

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

window_position
  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.
>

Agree.

[...]

> 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: <http://lists.genivi.org/pipermail/genivi-projects_lists.genivi.org/attachments/20160317/b7010b39/attachment.html>


More information about the genivi-projects mailing list