Model Type Traffic Participant

[ClemensLinnhoff]

Describe the problem

In the model types documentation, multiple inputs and outputs for traffic participant models are defined. Can the ego vehicle also be modeled as a traffic participant? If yes, I am wondering, why SensorData is not mentioned as a possible input, since the ego vehicle has to react to sensor input.

Furthermore, I stumbled across this sentence in the documentation:

Traffic participant models may internally use environmental effect models, sensor models, or logical models as part of a modeled autonomous vehicle.

This sounds like traffic participant models are kind of wrappers of other FMUs. Is this correct? Is there any distinction between models than only contain for example behavior planning and pure vehicle dynamics models?

Currently, if someone says he has a traffic participant model, it is unclear to me, what it models, what it contains and what the interfaces are.

[ClemensLinnhoff]

Furthermore, a model type for a traffic simulation tool is missing. For example, I would like to package a scenario player like esmini as an OSMP FMU to use it in a co-simulation. I currently did this with just a SensorView output (see current esmini master branch). Now I would enable this FMU for closed loop simulation and add a TrafficUpdate input. However, neither of these two configuration align with a model type defined in the OSMP configuration.

I propose to add a "traffic simulation" model type for SensorView output and optional TrafficUpdate input.

For the problem stated above, I would like to start a discussion on maybe splitting up the current traffic participant definition into more closely defined types.

What do you think @jdsika @pmai @localhorst87 @PhRosenberger ?

[pmai]

The TrafficParticipant model type is defined to be the whole traffic participant, i.e. from SensorView to TrafficUpdate, whether it is simple (e.g. stupid surrounding traffic following fixed trajectories) or complex (e.g. autonomous vehicles). Hence the sentence pointing out that such a model could include sensor models, etc. Whether those models are included as FMUs in the overall FMU or in other ways is outside of the scope of OSMP (or FMI for that matter), as it is an implementation detail.

From the point of view of the simulation environment, this is an opaque interface, i.e. it does not and should not care about its contents. The user might care, and hence the documentation or meta-data of the model should supply this information; but from the point of view of the simulation it does not matter.

When building up a more complex traffic participant using OSI model types, only the front-end models are defined model types, e.g. Sensor models. There is nowadays a standardized MotionRequest interface between something that determines the motion (e.g. an AD function) and something that executes it (i.e. a physical model including actuators and actuator control), but no corresponding model types (yet), since the architecture of how to split those functionalities tends to vary quite a lot. Especially for actual implementations where the interfaces and architecture will be highly OEM/Tier1 dependent.

That does not mean that future definitions of such types does not make sense for e.g. research purposes, which is why the Other Models group is working in this direction (see also #101 which needs some love). However they are just additions and not replacements for TrafficParticipants, since again for the most part an environment simulation does not and should not care about the internal interfaces of the TP.

So for e.g. specifying an ALKS function, one would specify an FMU with one or more SensorData inputs and either a MotionRequest output (if the actual physics of motion is handled outside of the ALKS function), or a TrafficUpdate output. If this is then combined with one or more Sensor models, and/or a SensorFusion model (SensorData->SensorData), and any physics model, it would contain the functionality of a whole TrafficParticipant. The integration can be handled by integrating the individual FMUs into one FMU, or - if the simulation environment supports SSP - by providing a connected up SSP system that contains the FMUs.

To the question of a Traffic Simulation model type: One could do this, however since the number of outputs and inputs needs to vary depending on the number of Traffic Participants, and FMI does not offer dynamic interfaces, the utility of this model type is kind of restricted, hence the lack of demand for such a definition right now (the major reasons for model types are ease of exchange and integration, which this model type would likely not improve). But of course one can define such FMUs and connecting them up should work in most FMI-capable tools, whether or not OSMP provides such a model type - it does already provide such interface types.

[jdsika]

Could we make a note in the next version of OSMP that has a meaning like "OSMP allows to define their model types like e.g. the traffic participant model as SSP systems consisting of multiple FMUs and to publish the interface and model defintions of the OSI compliant sub systems"?

[ClemensLinnhoff]

Thank you @pmai for the extensive explanation. So as I understand it, the model types are defined from the point of view of a simulation tool. So there are various possibilities to use OSMP aside from these defined types, as long as the input and output messages are defined, right? The question is, if we should define more types, just to give these possibilities a name and people can talk more easily about it. E.g. a model with SensorData in and TrafficUpdate out. Or a model with TrafficUpdate in and SensorView out, etc.

[nocll]

Hi @pmai I would also be interested to have a model type with:

• Input: SensorData
• Output: TrafficUpdate

This would enable a quite natural architecture:

• [Environment simulator] --SensorView--> [Sensor Model] --SensorData--> [Logical Model] --SensorData--> [This New Model] --TrafficUpdate--> [Environemnt simulator] --> ...

As you explained, maybe this potential new model type should not be called "Traffic participant".

But perhaps could be either, (a) an acceptable interface for a "Logical Model", or (b) have some other new name (Motion control model, maybe?)