Versions Compared

Old Version 78

changes.mady.by.user Paul Boyes

Saved on

compared with

New Version 79

changes.mady.by.user Melissa Morris

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Information Type

Values (per GM uServices)

Illustration #BMWFordGMVolvo CarsVSS Alignment / MappingAndroid Alignment / Mapping

Seat

Seat identity for 3 rows with 3 seats  per row, front to back

(looking towards front of vehicle from within the vehicle)

  • row1_left


row1_driver
or
row1_passenger
by region / config



  • Vehicle.Cabin.Seat.Row1.DriverSide
  • or Vehicle.Cabin.Seat.Row1.PassengerSide

Note: Driver seat typically has more functions than others. Typical ECUs are DriverSeatModule and PassengerSeat Module, that are picked up as is (SW content & interfaces) and moved from left to right of vehicle based on region)

Vehicle.Cabin.Seat.DriverPosition sets the DriverSide in VSS.  It is allows ['LEFT', 'MIDDLE', 'RIGHT'] .   

In uServices, it does not appear Driver Position or similar is spelled out.

Decision:  For Seating Capabilities, not how it is done internally to your organization, can we align around VSS Vehicle.Cabin.Seat?


Stupid Question Erik Jaegervall bear with me :  How does Vehicle.Cabin.SeatPosCount work with what is actually generated for vss.yaml (the instances) and/or how you use? 

For instance, in Cabin.vspec the default is 

SeatPosCount:
  datatype: uint8[]
  type: attribute
  default: [2, 3]

Based on the Seat branch definition:

Seat:
  type: branch
  instances:
    - Row[1,2]
    - ["DriverSide","Middle","PassengerSide"]


The following instances are generated per row:

Vehice.Cabin.Seat.Row1.DriverSide,

Vehice.Cabin.Seat.Row1.Middle,

Vehice.Cabin.Seat.Row1.PassengerSide


It is implied or just well known that in this case you just don't use Middle?  What if SeatPosition is [1,1] ... DriverSide and PassengerSide or the same?  What if it is your instances are ["DriverSide","Middle1","Middle2"PassengerSide"] and your SeatPosition is [3,4]?  

I guess it is implied, industry knowledge or incumbent on the implementor to spell it out? Right?

Comment from Erik Jaegervall 2024-12-18:

In general - how to indicate whether a VSS signal or a seat instance actually exists is up to the implementation. It might be based on that you do changes to your in VSS (for example with delete: true attribute to remove specific instances), or it may handle it dynamically, like no ECU provide values for specific seat). In the latter case, the VSS spec just shows "valid paths", it does not say whether a specific feature or seat actually exist.


The SeatPosCount signal is old. Once upon the time we actually had a numeric "pos" argument for seats, like Pos1, Pos2 and then you could possibly use it to know which seats that existed, but now it is more of guesswork.

There have been discussions if the instance-part should be removed from the VSS-spec and especially from the full dot-notated paths, as that is rather deployment information. That "core" VSS should specify that there can be multiple seats, and possibly that row/pos are attributes that seat can have, but specifying the actual instances is rather for the implementation. That would be a bit similar to the Android zone concept.





TBD
  • row1_center





  • Vehicle.Cabin.Seat.Row1.Middle

  • row1_right


row1_driver
or
row1_passenger
by region / config



  • Vehicle.Cabin.Seat.Row1.PassengerSide
  • or Vehicle.Cabin.Seat.Row1.DriverSide

  • row2_left





  • Vehicle.Cabin.Seat.Row2.DriverSide

  • row2_center





  • Vehicle.Cabin.Seat.Row2.Middle

  • row2_right





  • Vehicle.Cabin.Seat.Row2.PassengerSide

  • row3_left





  • Vehicle.Cabin.Seat.Row3.DriverSide

  • row3_center





  • Vehicle.Cabin.Seat.Row3.Middle

  • row3_right





  • Vehicle.Cabin.Seat.Row3.PassengerSide

...