How can I split a single large simulink model in to smaller unit?

I'm looking at splitting a very large model (say 30 MB of *.mdl file) in to smaller fragments to acheive the following:

 - Able to work individual subsystems across various geographies/teams
 - Able to reduce the effective time for auto-code generation (incremental build option) [The current single large model takes approx 1.5 hours to build and generate code if it doesn't halt due to memory error]

The following are the options considered for achieving the above:

1. Model Referencing [Keep the large subsystems in the model file as separate models and reference it through model referencing subsystem]

Pros: Supports Incremental build option which helps to reduce build time Allows splitting the model to smaller fragments Allows to fragment the model to enable working across various teams

Cons: Needs a script to maintain same settings for the parent model and the referenced model Doesn't allow the code of a referenced subsystems to be generated individually

2. Library referencing [Keep the large subsystems in the model file as separate individual libraries and reference it from the parent model as "atomic-inline" subsystems]

Pros: Allows to individually generate code of the referenced block alone Settings of the system remains the same as that of the parent model and hence easy to maintain Allows to fragment the model to enable working across various teams

Cons: Doesn't allow incremental build (no advantage in build time and needs more memory)

Has anybody tried any other means of achieving the same? Could you share any additional/better ideas for achieving the above?

Answer 1

[Ryan G]

It sounds like you already have a good grasp on the options available. Given the size of the model and your goals I would definitely go with model referencing. However, you could technically put the subsystems into a library and also reference those.

One thing I don't understand is the cons you mentioned.

First you mention a script to maintain settings. I believe this means you are utilizing configuration sets which I would consider a trivial addition to maintaining a model, however, why would the configurations of the individual models be changing at all?

Second, you should have no problem generating the code for the individual subsystems and model referencing should also allow code re-use for unchanged models. You could generate the code for the actual referenced .mdl file or you should be able to generate code for the component inside of the main model using a line like:

rtwbuild('mymainmodel/mymodelrefsubsysyem');

[Jeevan Thomas]

Thank you for your reply Ryan.

Reg usage of scripts: The reason I mentioned about usage of script is to maintain the same configuration settings for the parent model and the referenced model (except for the model referencing pane where the parent model may be set to "zero" reference/instances).

Reg building the model: As explained in query, I use a model which takes a long time to generate code and build. I run out of memory on issuing an "rtwbuild" command for the entire model. (Only option that I know to perform such a build is to use a 64-bit OS that allocates more memory for Matlab software, which I'm using as a separate build PC)

Instead of doing the above, I build component subsystems of the larger model in batches using a script so that I get individual code of the desired systems alone which I take it in to my IDE for build. (Before doing that, I ensure that all common/shared C-functions for lookups and common operations are available to the IDE/compiler from an earlier consolidated build so that I don't need select such files from the individual subsystem build folder again) This has become a standard across the team which about 40 people follow across various geographies in our development team.

But, if I understood it right, RTW-EC doesn't allow to build a referenced model (using model referencing subsystem) by locating it from the parent model using the command "rtwbuild('parentmodel/referencedmodel')" unlike in the case of library referencing. That's the reason why I've listed it as a disadvantage.

In the above case, the only option with me if I opt for model referencing is to open the constituent models one after the other and build individually.

FYI, the Software Version I use are: Matlab: R2008b (32-bit) OS: Windows 7 Professional (32-bit)

Please feel free to share any views.