Pierre R. Mai

Some further thoughts based on our discussions: - There is no problem with the underspecification of the physical data type in e.g. DBC files: The FMU itself provides that mapping,...

To summarize my thoughts on the ways to map increasingly deeper levels of the interface to the bus, based on the current proposal: ## Level 1 The current proposed signal-based...

If I understand the proposal correctly, then the idea would be to have something like the nextEventTime mechanism for ME for (Hybrid-)CS: The FMU returns after each successfully completed DoStep...

Of course WASM can just be packaged as normal native binary FMUs that just embed the interpreter. However the point of WASM-based FMUs would be to establish a binary triple...

@andreas-junghanns to a first approximation it is (just another platform). However it would be the first platform that does not depend on an established OS C-based ABI, and a portable...

I agree with @KarlWernersson, this needs decoupling from order of variables, however this could be achieved through a proper setup call, and in this way could also be made optional...

Since the importer would be controlling the memory layout, I don't see how this kind of initial memory layout default would be of benefit to the importer? I could see...

Retarget to 3.1 as discussed in WebMeeting on 2019-01-29.

Core ideas for future (3.1) optional support (triggered by WebMeeting on 2019-01-29, just my currently feeling about those): - Provide shared memory data-exchange API as optional mode, that implementations that...

I'm a bit confused here: The content of VehicleAttributes is not intended to contain stuff that a sensor detects directly (e.g. driver id, etc.). All that data is intended to...