Repository navigation
Time-series data in SSP #61
Description
The possibility to store simulation stimuli (time-series data) in the SSP resources such that any SSP supporting integration tool can interpret the resource and invoke it for executing the simulation. In this context, the time-series data could represent some founding design requirements.
Activity
JochenKoehler commentedon Sep 16, 2022
Web meeting 2022-09-16
DagBruck commentedon Sep 16, 2022
The paper is "Proposal for a Standard Time Series File Format in HDF5" at https://ep.liu.se/ecp/076/050/ecp12076050.pdf.
chrbertsch commentedon Sep 16, 2022
Do you know the "Signal Tables" by @MartinOtter :
https://www.mdpi.com/2079-9292/11/18/2811
DagBruck commentedon Sep 26, 2022
Yes, that is a very useful paper. However, I did not see any explicit comparison of the performance and size requirements of the serialized SignalTable. As mentioned in the paper, the "trick" DSRES applies to signals of the type a=b or a=-b reduces the file size by up to 75%, which is significant.
MartinOtter commentedon Sep 26, 2022
As described in the paper and used in the SignalTables.jl prototype, "a=b" is utilized, but not "a=-b" (similar to FMI 3.0). The main reason was to simplify the description and the implementation. I did not yet made serious comparisons between SignalTables.jl and DSRES format, because it is some effort to have exactly the same (realistic) model in Modelica and in Julia/Modia/SignalTables.jl and store exactly the same variables. It would be possible to utilize "a=-b" as well by some additions to the current description and implementation.
trulede commentedon Oct 3, 2022
Could you do this using a Model (FMU) to represent the time series in the simulation?
Define your time series data as a Parameter (binary with MimeType according to the format), and then connect that to a Component (Model/FMU) which supports that MimeType format, for the purpose of introducing that data to the simulation.
As I read over the Binary Parameter specification, it does not seem possible to reference a resource file directly. It might be necessary to extend that to include a
sourceattribute, similar to Component source (anyURI). However, the annotation mechanism is available on a Parameter and would also suffice.Edit: With binary types increasing representing complex data sources (signals, buses etc.) it might be interesting to represent them as Components. With that, all the existing mechanisms of the SSP become available for creating the structural elements around that data source. There might be some overlap with the new FMI3 clocks, where the source of those clocks might be component of the Simulation environment, or some other (external) system, rather than an FMU.
DagBruck commentedon Oct 27, 2022
Another possibility regarding storage file formats is
recon, as described in https://ep.liu.se/ecp/096/113/ecp14096113.pdf.pmai commentedon Jun 13, 2024
F2F 2024-06-13: To be handled via the common CSV format and other approaches to be defined in FMI-LS-Ref and harmonized across the MA.
pmai commentedon Dec 10, 2025
WS 2025-12-10: Could be fully covered for the 2.1 release by ensuring support for fmi-ls-ref/ma-ls-experiment format support in a suitable form.