Flags for inactive properties

[mbencik]

Would it be a good idea to flag certain part of the messages as not used. The interesting problem that arises with all the properties that are covered by the OSI is size. Since certain simulations configurations do not need a lot of the properties those could be disabled by flags. That would be beneficial in order to reduce the amount of mandatory checks, copying and transportation of the messages.

[pmai]

Fields that are not filled do not consume resources for Google protobuf, so from the PoV of transportation and receiving I don't see any additional need for this. What might be beneficial in terms of performance would be a way for a sensor model (or other receiving end) to specify in advance what fields it intends to use, thus allowing the simulation/sender to not generate that content (which will, for some data, dwarf the performance needed to serialize it). However such an additional fine-grained auto-config mechanism will be complex, brittle, and thus only seems warranted if we run into performance limitations...

[mbencik]

The performance part is true, one should not expect more performance from protobuf. But this is actually not the problem.
There is a OSI validator witch is for validating scenarios. The app would need a flag to see witch parts of the scenario are intentionally disabled otherwise it gives errors.
The second problem is the enormous streams that can be created by the messages. For example there are situations where individual messages are 1,5 MB ( the messages are not even complete ). At 50 Hz this makes 75 MB/s +, some calculations have given streams over 200 MB/s. If this is recorded and then validated this creates issues. Because everybody will put all possible data into the messages to pass the validation.
Also the preferred way of handling such data amounts is recording and playback, same for validating.

[jdsika]

The KPI rules open the door to define a subset of OSI for a specific application. We should generalize this idea in the OSI working group at ASAM.