Events

[gunnarx]

I was asked to post my text on events.

General

• An event concept is defined in VSS, VSC, or similar model definition and actual events might also be named in an associated standard-catalog
• An event has a name/path identifier in the same way as VSS signals, or a namespace based "path" / name as in VSC.
• An event has a description, like VSS signals do.
• Semantics agreement: An event update indicates a "fire-and-forget" indication of that "something happened" (and is thereafter obsolete). Further details around how this is done is however a protocol/usage question.
• For data type/unit see later discussion.

Data Types and options

VSS style definition

First option defining events in VSS with a new leaf type event (in addition to attribute/actuator/signal). This is an extension of the (meta)model, or rules for definition. It may or may not also be included in the VSS (or other) standard catalog which adheres to the model.

Here we have two choices. All the general characteristics above are still assumed

1. Events carry no data. Only their name/identifier, and description is defined.

or

2. Events have essentially a boolean (only) data type. This is like 1. but with the interesting effect that the same event name could be used to indicate "this happened" (true) or "this has stopped happening" (false). Another way to look at it is "on" or "off".

• It could remove a lot of verbose duplication like: xyz_start_event and xyz_stop_event.
• Systems tools and protocols could be designed to make it simple. For example they might have the positive event "true" as default if nothing was specified.

2 a) All events are assumed to carry the boolean type (or be able to carry it -- see protocol default below). In this case, it's not required to specify this in the model or catalog because it is automatic because of the node type event. Choosing this is essentially a requirement to protocols that this type of semantic shall be available and transferred. The protocol could also default to "true" so in the normal case no additional info is needed. or 2 b) Only some events have this boolean, so it must be specified. One which does not claim this capability cannot specify the "on"/"off" data.

VSC style definition

Here is another option for the data type. This option fits poorly in VSS where each signal has only a single, simple data type, but would fit well inside the VSC model):

3. Events each have a signature and can carry any number of any argument types. In other words, they look almost identical to a method, with the difference that events have no return value, since they are fire-and-forget and not methods. In this case it looks kind of like a method definition:

   my_event(int counter, string some_info, ConfigurationStruct_t data)

(In terms of modeling, I would here suggest that it is just a subset of "method" and might rather use the same capabilities as the definition of a method? In fact, in Franca IDL thinking, this might be almost a deployment-model information that is added to the method definition).

Other notes

Worth discussing separately:

• If a VSS modeling approach is taken, and if there is a desire to include events into a "standard catalog", should events be described in the standard VSS tree (under existing branches) or separately?
• If option 3. is taken and "complex" events are defined in VSC, will the desire for "simple" events remain for users of VSS? (I think there are clearly scenarios where VSS/data could be adopted without adopting VSC)
• ... would that lead to defining two different concepts instead -- the simple data type one, and the "method signature" style?

[UlfBj]

I have now read this issue, and that did not lead to change of my gut feeling that this does not belong in the VSS data model, but should be defined somewhere else. In a protocol with a "subscription paradigm", like VISS, that provides a solution to the event handling. However, that fits well in a unicast environment, less so in a broadcast environment, which I believe VSC is meant to support. In such an environment I see the need for a predefined "event-space", but to define that in the VSS "signal-space" leads in my view to a "bloating" of respective space. This event space can very well be modelled using the VSS concepts, but I think it then should be a separate tree. Whether it then should reside on the VSS repo or the VSC repo is an open question.

[gunnarx]

I have now read this issue, and that did not lead to change of my gut feeling that this does not belong in the VSS data model, but should be defined somewhere else.

Let's talk about where. Only stating "not this" and "somewhere else" is not a solution.

In a protocol with a "subscription paradigm", like VISS, that provides a solution to the event handling.

Here I'm confused about if we are talking about the same thing when you say it's a "solution". It seems to imply that you do not need to define event objects, if you have the VISS protocol? Compare that VISS without VSS (model, catalog) wouldn't work. So the same situation here -- where are the actual events defined? Another purpose of this discussion and resulting documentation is to establish a clear agreement on what events mean -- what the intended behavior is.

And of course it is likely that a pub/sub protocol will be applied to exchange the events. (I thought that was obvious and implied). Every client everywhere in the world does not want to be notified of every available event... so there's a kind of subscription going on. And of course VISS could/should support it too. But it seems that only if they are defined in the VSS way that it would be an obvious fit?

However, that fits well in a unicast environment, less so in a broadcast environment, which I believe VSC is meant to support.

First, as I see it, the "model" behind a VSC catalog, is essentially building a generic interface description language and must be applicable in all types of environments if it is going to have wide applicability. So it is not meant to be limited to one way of using. But to your specific point, a function call is most of the time done from one "caller" to one addressed entity. So the most common case sounds like unicast to me which seems like the opposite of what you wrote (unless your sentence can be read both ways?). It would help if you clarify here.

In such an environment I see the need for a predefined "event-space", but to define that in the VSS "signal-space" leads in my view to a "bloating" of respective space.

I don't know about "space" so much but it's definitely a matter of opinion how we like to split things into separate parts. But my opinion of the proposal is that in at least one alternative, the event is described kind of as a signal without a data type, so I don't think these things are so different as to suggest bloating. And in some of the alternatives the event is defined with one or several types. In fact the proposals are so diverse that I am struggling with your response to reject all of them at once, instead of helping with the comparison?

OK... so I am now thinking about why you wrote "in such an environment". Perhaps you mean there are cases where VSS is needed but events are not, and therefore they should not be forced together? If that's the point, I think that's a fair point to consider. But as we seem to agree, the pub/sub protocol side is still common betwen the two? I see more commonality than difference, honestly.

This event space can very well be modelled using the VSS concepts

Which is exactly what the proposal suggests! We don't seem to understand each other?

but I think it then should be a separate tree.

OK, well that was stated as an open question (twice).

The second sentence in the introduction: "It may or may not also be included in the VSS (or other) standard catalog which adheres to the model."

and towards the end:

"If a VSS modeling approach is taken, and if there is a desire to include events into a "standard catalog", should events be described in the standard VSS tree (under existing branches) or separately?"

Your response first seemed to reject the idea of including them in the (meta)model / rule set / or "VSS concepts" as you say. In the end it seems you are only talking about where to place the items in a tree, or a separate tree. To me that is a fairly trivial detail, which is why I left it as an open question. The first question is whether or not events can be described using an "event" type, and choosing one of the three options for the meaning and content of an event. We also have to remember to define concepts that work for the combination of data (and/or events) from a standard catalog like that defined by VSS, and other items that companies need to add (additional data, events). This is about agreeing on the concept, what I call "model" behind the data, meta-model or "rule set", in such a way that it becomes maximally useful.

On the topic of the tree however, one argument for handling this together in some sort of combined catalog is that the tree organization (the hierarchy of branches) might be useful to share between signals and events. If so, I think we should consider a way to make that easy instead of having to have a completely different hierarchy for events.

[UlfBj]

It seems to imply that you do not need to define event objects, if you have the VISS protocol?

In VISS the events are represented by "notification messages" that are asynchronously issued by the server when the trigger conditions are met. This is transparent to VSS, which do not have to know anything about these events.

Perhaps you mean there are cases where VSS is needed but events are not, and therefore they should not be forced together?

For VISS there is no need to define events in VSS. So for VISS, having events defined in VSS would be confusing, and could from that angle be seen as a bloating of VSS.

In the end it seems you are only talking about where to place the items in a tree, or a separate tree. To me that is a fairly trivial detail, which is why I left it as an open question.

I think that is a key point. Not only to have separate trees, but also to separate the metadata definitions. Parts that are relevant in both can be "shared", but if you are interested in just one of the domains you should not have to "filter out" what is not relevant to you.

This is about agreeing on the concept, what I call "model" behind the data, meta-model or "rule set", in such a way that it becomes maximally useful.

A large part of the "VSS concept" can very well be used in the "event domain", and sharing on that level I think is fine. But I think that the two domains should not be weaved together to the level of one shared tree. And the event metadata definitions should be clearly kept apart. One way to achieve that could be to create a new Github project for the event domain, that includes the VSS project, just as VSS includes VSS-tools.

[erikbosch]

If we start from the other direction, do we have any good candidate for an event to add to VSS? I have no objection to adding support for "event" if we see a real benefit of it, i.e. an example where subscribing to a boolean or integer sensor does not suffice, and the topic of the signal fit well into VSS.

[gunnarx]

In VISS the events are represented by "notification messages" that are asynchronously issued by the server when the trigger conditions are met. This is transparent to VSS, which do not have to know anything about these events

This is the point. I'm not talking about messages sent by a protocol that is defined to notify about something happening. An "event" per the definition proposed here is an object, like a VSS signal. It's all spelled out I think quite clearly in the text? Once you have those named things defined, it is true that protocols (like VISS) might have a logic to distribute a notification of an event happening.

Think about it this way. Let's say I instead said that the VSS needs "signals" and you seem to reply with -- we don't need signals, because the VISS protocol has messages that will transfer the data for you.

The next answer to Erik, might clarify a little bit further.

[gunnarx]

There are several options described in the proposal so it's hard to generalize for all of them. But looking at the simplest most obvious meaning of an event - it is something indicating "this thing happened" with no further information. The "thing that happened" could be anything, but it is named and it has a meaning. It is not the same as a VSS signal notification. The thing would be basically any happening except the happening "VSS signal X changed value".

The purpose of defining it is to give it a name and meaning. And that is separate from how it is transferred. Actually, in reality, it is only partly separate. Consider, also for the VSS data definition, we have certain assumptions of behavior built in that we expect protocols to follow. Protocols can differ in detail but there is a built in expectations that the protocols transfer a value for the VSS items, and that the value has the data type specified by VSS, etc. Similarly, events would expect certain behavior, but the details of a protocol might differ slightly in format.

One such behavior, as described, is that an event is likely to be a "fire and forget" operation in typical transfer protocols.

an example where subscribing to a boolean or integer sensor does not suffice

If the situation you want to notice is really is about a measured value changing (to any value without any particular conditions) then the logical modeling is to have a VSS signal for that sensor, and to notify on signal value change. (Unless for some particular situation you were fully convinced that you really do not want to ever transfer the actual signal value, but only the information that it had changed -- hypothetical example maybe? Or for privacy purposes maybe? )

So an integer signal is not the situation that is to be covered. In short, Events are not VSS signals with an integer type.

Let's look at boolean next. Let's say that instead of the event "Software Download has completed" you define a VSS signal with a boolean data type: Name: SWDLIsComplete - datatype: boolean

You can then notify when this value changes (with VISS or similar protocol)

There are a few differences:

• An event, is an "edge trigger" thing, i.e. it is only transferred when it happens.
• A signal (as we have defined it in VSS, and other systems might use the word observable Property or Attribute) is something you can do "getValue()" on at any time. This is not the case for an event. For an event, "getValue()" should make no sense, because it does not keep its value. It "happens" once, and then disappears.

• I think you are asking, could we instead model all events with a boolean typed VSS "sensor" signal? Maybe... Leaving aside the fact that "sensor" often might not make sense for some internal happening (whic is true for other VSS signals) here is a behavior difference, because:

System A Situation : boolean "signal"

Let's say System A comes to a point where it sets Situation to true. A VISS-like protocol with subscription would notify clients that Situation changed to true.

But when is the Situation variable set to false?
Should we require a particular client to do this? Which one? They only want to know about the event that it becomes "true" when that thing happens. They do not care about a persistent value.

Perhaps we require System A to handle events like this: When the situation happens, change the signal value to true, and then immediately to false again. Would this send out two event notifications?

All in all, the difference may seem small, but there is a semantic (behavior) difference between the concepts, where one is keeping state, i.e. keeping track of a value continuously, and the other is only a notification and then nothing is remembered.

This is why it might be useful to have the concept defined. Somewhere.

[gunnarx]

@UlfBj

For VISS there is no need to define events in VSS

Maybe you are still mixing it up with Notification messages here, or you are using VISS as the starting point. I look at it from the opposite direction. If we have a need to define Events, I see little reason why VISS should not support them? Maybe you see VSS as only a tool that allows VISS to transfer data, and I more see VISS as a tool to transfer VSS data?

[gunnarx]

@UlfBj

I think that is a key point. Not only to have separate trees, but also to separate the metadata definitions. Parts that are relevant in both can be "shared", but if you are interested in just one of the domains you should not have to "filter out" what is not relevant to you.

When I speak about how we can "model" things, I think the "standard catalog" comes secondary. It's still an important question I agree, but I start with the capabilities in describing data. VSS is not only about the standardized catalog, but also about having a tool that companies can use for all possible data (close to it), standard, internal, proprietary, etc. And in combination with VSC it is about having all the tools to model a complete system behavior (close to it).

At the moment you could say we have two different main models, the VSS and the VSC (but there might be some other variation also, from other parts of the industry). I disagree that from the modeling side we cannot work towards aligning this. I'd like to avoid a description of one "metamodel" for signals (observable properties), another one for services, and a third for events, if they are closely related.

Sure, events could be defined in VSC, but they are much more similar to "signals" that it seems worthwhile to discuss the VSS option at least. In particular since we know that VSC wants to refer to VSS signals already.

if you are interested in just one of the domains you should not have to "filter out" what is not relevant to you.

There are tradeoffs to be made here. No situation is ideal.

[SebastianSchildt]

I think I get the general idea, what you mean with "event" here.

Considering VSS the question really would be, do we have a - significantly compelling - use case/problem now where we need it?

Another point to keep in mind: Current VSS can used fine in systems not supporting any "event" or asynchronous paradigms (think REST, or Websocket VISS without subscribe), the concept of "event" would not be a perfect fit for this kind of systems.

So for me the situation looks like this: This would "extend" VSS expressibility (and thus make it a little less "simple") I am not generally opposed to this, but we should have a solid need/use case, and not design/build something that will only be sued by one example datapoint.

[gunnarx]

@UlfBj

A large part of the "VSS concept" can very well be used in the "event domain", and sharing on that level I think is fine. But I think that the two domains should not be weaved together to the level of one shared tree. And the event metadata definitions should be clearly kept apart.

This seems doable and ultimately what I expected we would do. I'm looking first to get feedback on what/how Events could be.

Also, there would not be a lot of metadata - as we can see in the original description, events are things that either have no data type at all (Maybe only the description: label), or, possibly they have a datatype of boolean (which is either implied and not mentioned at all, or using the exact same datatype: label). So I so far see no other metadata at all, other than adding one more type: attribute/actuator/sensor/event

One way to achieve that could be to create a new Github project for the event domain, that includes the VSS project, just as VSS includes VSS-tools.

Something like that, perhaps, yes. I actually think we might need to do even more, in general, to separate (meta)model from standard catalog, in terms of project naming and so on. There's a bigger picture building and it is worthwhile to start describing that in more clear terms that everyone can understand.

[gunnarx]

Please note also that it is a question for the VSC (@magnusfeuer note) whether it really needs the VSC-style events that I described last (that can carry advanced data with the event). It is in the current proposal for VSC, but I personally think it might be better to see them as just a special variant of a method call. That variation of Event only fits well in VSC, not in VSS.

And if adopted in VSC, it would seem that the pressure to have it in VSS is less. But I think we consider if it might be useful anyway, as something available independent of the VSC, and I do see the "simple" events as a very natural extension of the VSS model. To Sebastian's point, I would envision that there are some systems that only need VSS signals, but there might be others that need only VSC (without referring to VSS signals), VSC+signals, or VSS+events, or all of them... etc.

(And... honestly I'm still thinking the logical long term way to name these modelling methodologies is with a common name. In other words, we might some kind of merge of VSS and VSC (metamodels) into a one. I guess it is more of a naming thing, and it should not mean that you cannot use only part of the capabilities, when that is all you need.)

[gunnarx]

Having considered all of this let me restate my preference (at the moment, always open to be convinced).

1) Include the simplest type of events (with no data type) into VSS modeling capability (aka rules, metamodel, ...) We can separately decide on if there are any that should go into the standard "VSS catalog" or not.

2) Document a recommendation that if a system needs "SituationHappened" and "SituationStoppedHappening" then this ought to be modeled instead using a signal with boolean data type, and notification on that signal. I withdraw the "event with boolean" variation. A boolean VSS signal is not 100% identical, and it would mean the possibility to do a get-value() on the signal state at any time, which is not valid for an event. But I think it is is close enough to cover the design need. And for a case where it isn't (in other words the behavioral difference between signal and event is required) then both event objects can be separately defined.

3) The VSC should keep some capability to have the advanced event definition, but not using the name Event (which should be reserved for the VSS style event). It could be named "Callback" instead of event, because a callback-function is essentially the intention of these. The callback (previously) event has two main differences compared to a method. One is that it is a method with no return value (which is just a special case of method), and the second is that it implies the direction this is travelling (from service-server "back" to client). However I would recommend that we have a larger discussion about how and if the VSC language shall really indicate in which direction a method call happens. Let's deal with that in a VSC focused discussion.

[erikbosch]

I can see the theoretical need, my previous comment was more to discuss if we foresee any practical use that we think would be valuable to add to VSS in the near future. Like if we e.g. would see a value in an event like Vehicle.Animal that shall be sent immediately when the vehicle detect an animal in the proximity of the vehicle. If we have a hands-on practical example it is easier to argue whether e.g. an integer counter signal instead would be an alternative or not.

[danielwilms]

• need of example and an idea how to use it
• has to apply to core tools
• connection to/impact on VSC

[erikbosch]

I am doing some cleanup closing all issues created 2021 or earlier where there have been no activity 2023 or later. If you still consider this issue relevant feel free to reopen it add and add a comment on how you would like to see progress on this one.

[MandavaRajesh]

Hello, We are new to COVESA forum and recently we were introduced to the VSS specification, we are thinking an event would be good addition to the core vss. After going through the closed issues, we found this thread #273 that goes with our views of visualizing an event in vss.

Our argument with an example, if there is a CollisionOccured or HarshBrake event an event should be sent out and the datatype the event holds is open for discussion. We would like to reopen the discussion on this topic and also open for contributing for this addition.

[UlfBj]

Events should be introduced at the interface definition, not in the data model. In VISS it is realized by the subscription mechanism.

if there is a CollisionOccured or HarshBrake event an event should be sent out

To whom should it be sent out, there is no notion of clients in VSS, while in VISS a client can subscribe to these events.

[skarlsson]

Does it not make some sense to declare events in the data model independently to declare that there is indeed something "subscribable" together with what datatype to expect? We can of course declare this in a similar way in a separate yaml file using same datatypes as vss - but it would be nice to extend standard tools to support the definition even if there are no events defined in the standard. The idea is that an event is a separate thing compare to a boolean sensor going to "true". also an event is by definition not pollable.

[erikbosch]

I reopened this issue as the discussion has restarted, and added it as a possible topic for next VSS meeting (May 28th, https://wiki.covesa.global/display/WIK4/VSS+Meeting+Topics+and+Meeting+Notes)

Technically it would be no problem to add yet another type event in VSS-syntax in addition to sensor, attribute and actuator. Potentiality one would like to have events without data, like supporting datatype: none. Then how to handle/receive those events would be a question for downstream implementations (like VISS, VISSR, Kuksa), like if they shall give an error if you try to do a get on an event.

Adding support for events to the syntax is one thing, but if so we should better discuss how existing tooling/converters should handle them. My view is that as acceptance criteria for adding the syntax at least the generic output formats Yaml, JSON and CSV should be able to handle it, and others should not crash but may give a warning and ignore events. Adding events to the standard catalog would as I see it be a follow-up topic, where one need to look at individual proposals.

[UlfBj]

Introducing the semantics of events in a data model is in my view not the right way to go.

[erikbosch]

Events should be introduced at the interface definition, not in the data model. In VISS it is realized by the subscription mechanism.

if there is a CollisionOccured or HarshBrake event an event should be sent out

To whom should it be sent out, there is no notion of clients in VSS, while in VISS a client can subscribe to these events.

My view is that VSS in itself (if at all, that is to be discussed) should just define the existence and semantic meaning of an event, like

Vehicle.RodentInVehicle
  type: event
  datatype: none
  description: One or more mammals of the order Rodentia has been observed in the vehicle.

Then, how that event actually should be used would then not be in the scope of VSS. I.e. VSS does not need to specify if this is this is something sent out by the vehicle, or something potentially sent to the vehicle by some external monitoring system so that the vehicle can take countermeasures. In a fleet monitoring system the event distributed would likely have additional metadata like VIN or registration number of the vehicle so that the fleet operator knows which vehicle that is concerned.

I.e. the interface definition may define if this vehicle provides this event or if it requires/consumes this event, but the actual definition of the event fits quite well to VSS I think.

[erikbosch]

MoM:

• Erik gave quick background to the issue
• Svante, Scania, we have done a PoC, found events misisng
• S: Would supergood to have it in the model, we have stream processing. We miss events. We could do PR, Rajesh did investigation
• Ted: This is close to our ideas of named functions.
• Daniel: I agree of a way of representing events, but not as a new type. But we could handle it as observing properties. Like when speed is over threshold, subscribe to a boolean signal.
• Ulf: Should be added at interface level, If RodentInVehicle is a boolean sensor, you can subscribe to change but also poll
• Svante: If we now it is an event, then we can instrument/decorate with things like rate
• Adnan: Events are often usecase tailored. Like "vehicle locked" or not. We take VSS, and import it into IDL, like taking VSS to Protobuf and creating events.
• Erik: There are other solutions, but what is the reason not to support events. I do not see that big difference between "events" and sensor/actuator
• Adnan: But you can create events from sensors7actuators
• Daniel: You can specify a boolean datapoint in VSS and use it as an event
• Adnan: Should we work on a proposal or blog post on how we can handle events
• Svante: If VSS does not want events, we use our "workaround". We like the concept of events
• Adnan: Could you possibly share a bit more on the problem, and we could show solutions
• Svante: We want business-case-specific events, when those events happen we send other data.
• Adnan: I can prepare some content on how we handle this type of event
• Sivashankar: Would be very helpful. How do we differentiate between different definitions.
• Adnan: Req on VISS to inform/sync on which model is used.
• Sivashanakar: Rate is important aspect for API
• Stephen: Data Architect Group looks on rules to operate on data model
• Daniel: VSS define datapoints, not constraints
• Sivashankar: What/Where to generate/specify frequency
• Ulf: Commercial vehicle BoF is proposing frequencies for various signals
• Erik: COVESA could define "profiles" on terms/attributes to use to define things like frequency (but should not define specific frequency)
• Ted: envisioning using APIs, using overlays to specify collection campaigns

[UlfBj]

An alternative solution to introducing an "event" node type would be to introduce an "event" datatype. This datatype would be limited to the values zero and one [0,1], and when changed from zero to one it would be restricted to keep the value one for maximum X milliseconds. This datatype would only be allowed to be used by sensor nodes. This design would announce just as clearly the "event nature" as having an event node type, but it would not have to introduce atrocities like datatype:none.