Modifying Simscape Initial Conditions

We receive a simscape plant model together with a .mat file containing the initial conditions.

We want to place that simscape model into a subsystem, connect it to a controller model, and save the combined model as a different model name.

The Initial Conditions variable is a structure array with .signals.blockName and .signals.stateName fields containing the full path of the simscape blocks. For example

>> disp(InitialConditions.signals(10).blockName)

Architecture_Delivery2/C11/Bulk Heater

and

>> disp(MissionProfile_InitialConditions.signals(10).stateName)

Architecture_Delivery2.C11.Bulk_Heater.BH_3_.p_I

All well and good - I've written a simple function to strrep() from the original model/path names to the new model/path names. This works most of the time. However occasionally I see a stateName like this:

>> disp(InitialConditions.signals(2).stateName)

Architecture_Delivery2.Simulink_PS_Converter14.outputFiltered_3445558726_0

and when I save the model, the numbers at the end can change (sometimes, not always). This means that the model fails to initialise as it can't find the correct stateName.

Unable to load the specified initial state for model 'Combined_Plant_Controller'. BlockName/BlockPath of the element at index 2 in the initial state is invalid

Note that this error is incorrect - it's not the Block Name/Path that's incorrect but the State Name/Path.

So, my questions are;

1. Why do some blocks have seemingly random numbers appended to the stateName and others don't?
2. Is there a way to programmatically examine a model to find out what number has been given to a block's stateName so that I can update the initial conditions variable correctly?

Answer 1

[David John]

1. Internal states, i.e., states that are introduced by Simscape as part of the compilation process, may have a number following the name in order to ensure uniqueness of the state names. These are "secondary variables" and usually it shouldn't be necessary to set the values on those states explicitly (although maybe not always).
2. In the "Model Settings", you should be able to go to "Data Import/Export" and select "Final states" and "Save final operating point". Then, after running the model, you can look at xFinal.loggedStates.stateName to get all of the state names that Simulink sees.

[Christopher Slack]

Thanks. That was also the conclusion I came to.

It means there has to be a two step process; run the new model once to get the list of simscape states, then translate all the values from the old-model states to the new states doing some clever regexrep stuff where the uniqe id numbers differ.

The argument about uniqueness is a bit strange though, as the simscape state name is prepended with the block path.name so they're guaranteed to be unique as you can't have two blocks with the same name at the same level of heirarchy in a model.

At the moment, I've only seen this unique-id being added to PS-Convertor blocks, so it's not all that critical.