Comments (6)
The reasoning when creating the struct concept was that signals can be seen as something similar to variables in many programming languages, and you cannot reuse/reference a variable when creating a struct or class. VSS signals also specifies if they are sensors/actuators/attributes, but that information does not make any sense inside a struct. Technically in vss-tools it would have been possibly to allow signals inside structs, as they contain the information needed.
When we introduced the structs we discussed hypothetically that the current CurrentLocation
signals possible should be removed and instead replaced with a single signal using a struct, but nothing has really happened there.
It could also be good to know that there have been other proposals to separate data representation from signals, like presented in a presentation from Ford on the links below.
https://wiki.covesa.global/display/WIK4/Data+Models+and+Ontologies
https://wiki.covesa.global/download/attachments/53510159/VSS%20Extensions%20and%20Ford%20Signal%20Ontology.pptx?version=2&modificationDate=1694797760649&api=v2
That would result in something like below, and with that approach it would be easy to reuse Vehicle. Longitude
for both individual signals as well as inside structs. But no active implementation ongoing in that area either.
CurrentLocation.Longitude:
property: Vehicle.Longitude
type: sensor
description: Current longitude of vehicle in WGS 84 geodetic coordinates, as measured at the position of GNSS receiver antenna.
Vehicle.Longitude:
datatype: double
type: property
min: -180
max: 180
unit: degrees
description: Longitude in WGS 84 geodetic coordinates.
The advantage would be that we only would need to specify min/max for longitude in a single location, compared to today when we have multiple.
from vehicle_signal_specification.
Cheers.
A facility for being able to reference already defined signals (or as in the case of the above suggestion properties
) would be very useful. The tree is simple and useful in a number of ways but it has been somewhat difficult to apply in many instances.
In our use-case(s) we have a number of complex objects that we foresee as needing to contain multiple signals, initially we were hoping we could use struct
types for this and represent these objects within our VSS model itself along with the signals contained in it. I think the way we'd now address this is to leave this representation issue outside VSS itself and use VSS only to validate that referenced signals are valid.
Is the working group interested in having the above type of initiative driven?
from vehicle_signal_specification.
Now I think that I understand your use-case - you want to aggregate/derive larger objects from other signals, which could be useful if you for instance want to have a struct containing vehicle speed, position and fuel-level or an identifier to be able to get/set/transmit those 3 signals in a single operation.
A possible solution to this could be to use a special field like vss-ref
to indicate which signal that provides values
Types.MyTransferStruct:
type: struct
description: Some data to be sent to backend.
Types.MyTransferStruct.Latitude:
type: property
datatype: float
vss-ref: Vehicle.CurrentLocation.Latitude
description: latitude.
Types.MyTransferStruct.MyTemperature:
type: property
datatype: int8
vss-ref: Vehicle.OutsideTemperature
description: longitude.
There have been some discussion on this long time ago, but then the conclusion was that it is something that should not be part of "core VSS" but rather something defined/used by downstream implementation projects.
We are always interested in new ideas on how to extend/improve VSS. If you have a rough idea we could reserve 10-15 minutes in an upcoming VSS meeting (Tuesdays 16.00 CET/CEST) for you to present the idea and for discussion.
from vehicle_signal_specification.
Thanks @erikbosch this idea with vss-ref
is helpful. With that it might be possible to include the "composed" complex objects into the tree itself instead of composing those outside the tree as part of serialisation process. Now to align the datatype
description
at the signal vs. struct definition levels...
Re: improvements/extensions my hope is that something like this will come out of our project for the community. WIP. Cheers.
from vehicle_signal_specification.
I think this issue origines from the fact that one tree hierarchy is not expressive enough. So, you might need to work around and increase the features of VSS
. However, I would like to point out again that any evolution of VSS into something bigger must include the adoption of an established language that natively supports cross references. This was the main message of the presentation I did at the last COVESA event.
One option (not the only one) is evolving VSS with GraphQL schema language. Check out the slides, they contain plenty of examples.
from vehicle_signal_specification.
MoM:
- open for more comments, please read through
from vehicle_signal_specification.
Related Issues (20)
- Enforce "style" for VSS standard catalog HOT 6
- Need for release-branches? HOT 11
- Ranges for Float and Double HOT 1
- Supported encoding for string values HOT 1
- Need for release tar-ball HOT 4
- Hydrofoil signals HOT 1
- Vehicle Error Codes HOT 2
- Representing signals in VSS tree HOT 2
- Inconsistent terminology - attributes, members, elements, meta data HOT 3
- typo in vspec v3.0 makes vss-tools 4.x fail HOT 2
- vehicle signal specification generated fidl is not recognized by commonapi. HOT 1
- Overlay childrens are not merged causing extensions_attributes missing HOT 3
- Mathematical Operation in Vspec HOT 5
- Separated signals for actual and target values? HOT 5
- Improve naming convention to distinguish instances from branches HOT 20
- Documentation generation framework (Learn) is deprecated HOT 1
- Allow instantiation of charging ports HOT 6
- Insurance relevant Parameters HOT 6
- Release prep for 5.0
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vehicle_signal_specification.