I've created the basics for the description of FMU's according to setlevel attributes branch/125-create-metadata-descirption-for-models-fmus. Overview of the variables: VARIABLES.md.

@raue @localhorst87 @PeLe987 Please look at the categorization into Format, Content, Quantity, Quality , and DataSource (these categories are predefined by the other ontologies). I've categorized them with my best guess. However, currently I think we don't need Quantity and probably not DataSource (move attribute model.specification to Content).
Do you have any opinions about that? Otherwise I will create a pull request.

Couldn't find 'Quantity' in VARIABLES.md. Eventhough some quantities (e.g. number of detected objects - if this is meant) wouldn't really hurt to have. But for that information about the object type (e.g. VRU) should also be given. For demo purposes I'd skip quantity, if it causes too much efforts,
'DataSource' seems to be desirable for me, since it provides the link to the full blown model description (i.e. specification).
Again, due to the remaining time, we should keep it small in case of any doubts.
BTW: warum nutzen wir hier eigentlich Englisch?

We use english since this is a public repository and everyone can follow the discussions ;) (at least this was my understanding).
Regarding Quantity, yes for the first attempt I did not sort any of the variables into this category. However, I can simply add some. Is the number of detected objects a common attribute of a simulation model (sensor, traffic participant, ...)? I would think this is more an attribute of the execution and the resulting OSITrace? It is currently modeled in a OSITrace file. Maybe the number of parameters could be an attribute for Quantity regarding a simulation model?
Regarding DataSource, if it is fine to map the specification to DataSource, we should keep it. I just thought maybe it is better to be located in Content. However, with DataSource it should be fine then.

ok, I considered this as more private, but we can stick to englisch ...
yes, I agree. My first thoughts were moving more in the direction of sensor data when it comes to quantity. But maybe somenthing, which goes into that direction from the model point of view could be the max. number of detections and objects a model can provide (this indeed are features from the real sensor ARS548 (max. detections = 800, max. objects = 50)).

Ok. I've added both attributes in simulation-model_shacl.ttl#L199 .Also available in Variables.md and the example. Is this fine for you? Then I create a pull request.