A lesser known feature in Dymola is the ability to simulate a model that has inputs and assign the inputs from signals stored in the dsu.txt file. This is a useful feature when replaying models used in hardware in the loop testing.
Simulating a model with unassigned inputs
If a model that has inputs is simulated, typically these inputs will be by default set to zero. However if there is a dsu.txt file, the model executable that is dymosim.exe, will look for the inputs in the dsu.txt file and use this if they are present (as in Figure 1).
Figure 1. Input and output files of dymosim.exe
In Figure 1 the input signals from dsu.txt are read by the dymosim.exe executable and results of the simulation are generated.
The format used in the dsu.txt file
The dsu.txt file has data stored as trajectories either in .mat format or in text format. Note that even when the data is stored as a .mat the input file is still called dsu.txt.
A simple example of how a dsu.txt file can be created in Dymola for testing purposes
A simple way to create the dsu.txt file is to simulate the model in a test rig and have outputs with the same names as the inputs to the model. For example in Figure 2. the test rig Suspensions.Autonomous.Experiments.ModelDevelopment.Combined was extended and the inputs of the vehicle model are attached to outputs of the same names.
Figure 2. Simulating test rig to generate trajectories to use as inputs
When the model in Figure 2 is simulated, the outputs are stored in the result file. Set the Simulation>Setup Interval length to suitably small value. Also store the results using double precision and only store the outputs in the result file by only selecting Outputs variables on the Simulation>Setup Output tab and select Double precision.
The .mat result file can now be duplicated and the name changes to dsu.txt and the model is simulated.
Simulating the model with dsu.txt inputs
So the output signals of the model in Figure 2 are used as the dsu.txt input signals of Figure 3.
Figure 3. The model that will be simulated in Dymola with the generated dsu.txt file
When Figure 3 is simulated, this will take the input signals from dsu.txt and the results should be similar to those obtained when simulating the model in Figure 2.
When input signals are not found in the dsu.txt file
However, in this case when the model in Figure 3 is simulated some of the inputs are not found as seen in the Simulation log below:
Log-file of program ./dymosim
(generated: Fri Dec 3 15:13:30 2021)dymosim started
… “DSU_Blog.RigidSuspensionsLinearTyres” simulating
… “dsin.txt” loading (dymosim input file)
… “dsu.txt” loading (input signals u)… Warning message from dymosim
Simulation log stating that the Brake[1], … signals could not be found
The following model input signals are not defined by the trajectory on
file “dsu.txt” and are assumed to be at their start-value during simulation:
Brake[1]
Brake[2]
Brake[3]
Brake[4]
The Simulation log above shows that dsu.txt is used to load the input signals; however, the Brake signals were not found. This is because in Figure 2 the Brake inputs were mislabelled as Brakes. This typo will have to be corrected in the model in Figure 2 and the model simulated to generate the correct dsu.txt file.
When would this feature typically be used?
The ability to simulate models like this is useful when debugging models that run as part of a Hardware in the Loop system. For example, you may want to step into the dymosim.exe to examine external C functions as described in the stepping through dymosim blog.
Obtaining the input signals in a HiL example
In this case, the model may be exported as an FMU and the inputs stored by selecting Store results in mat file as in Figure 4.
Figure 4. Exporting a FMU with a result file being generated
When the exported FMU is run, it will generate a result file which would contain the input signals and this file could be used to simulate the model in Dymola for debugging purposes. Unfortunately, generating a .mat file like this can cause the model to simulate too slowly for hardware in the loop systems; in this case input data would have to be stored using a different method (possibly by making use of UDP) and the dsu.txt file could be created manually using the trajectory functions described in the handling trajectory files blog.
Limitations
The simulation in Dymola will drift from the external simulation due to numerical differences; this is why it is recommended to store data using double precision.
Also when simulating a model as an FMU tunable parameters may be modified during the simulation; this is not possible in Dymola.
Using Claytex.FileReader as an alternative
An alternative is to use the Claytex.FileReader.FileReader block to load the result file and the ReadScalarSignal, ReadVectorSignal, ReadMatrixSignhal and ReadDiscreteScalarSignal blocks in this Claytex package to read the input trajectories from the result file as in Figure 5.
Figure 5. Claytex.FileReader.FileReader and ReadScalarSignal and ReadVectorSignal blocks used to read trajectories from result file
In Figure 5 the FileReader blocks are used to read the input trajectories from the result file generated in Figure 2. This method is appealing especially when it may be preferable to use some signals from a Dymola model rather than using recorded signals. For example it may be desirable to use some signals from a closed loop driver model.
Conclusions
A method to simulate models with given inputs is described; an appealing feature of this method is that the exact model can be simulated in Dymola. Also if only the input signals of the HiL system are stored, then this method could be used to get an idea of what the other signals in the model are and have the ability to step through the dymosim.exe source code which would not be possible in a HiL environment.
An alternative is to use the blocks in the Claytex.FileReader to read the input signals.
Written by: Garron Fish – Chief Engineer
Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion
