Difference between a Simulink library and a model reference

What are (If there are) the differen开发者_如何学JAVAces between a Simulink library and a model reference. There's advantadges in using either of them in different situations?

The main purpose of libraries and model reference are the same: facilitate the reuse of simulink models. When you work with libraries, simulink "imports" the content of the referenced models in to the main model. Sometimes, this leads to the developer dealing with gigantic models (more than 50k blocks), which can be time consuming. When you are designing a library, the lib file cannot be run. You have to "instantiate" it in the main model. On the other side, model reference deals with separated models. They are put together when you press the simulate button, but during the design time, you deal with completely separated models. With model reference, you can also select acceleration methods (it basically compiles the model) and this can't be done with libraries.

Adding some more to danielmsd's answer:

• Configuration Management: Model references can be put easily into version control and developers can work independently from each other. A library is one file, so the blocks cannot be versioned individually and developers cannot work in parallel.
• You can protect model references.
• Code Generation: Incremental build is only possible with model referencing.

BUT: Model referencing has quite a few limitations, so check them out carefully before picking this option. See Model Referencing Limitations.

From a system design perspective model references should be used for components of your system. That is the different parts your system is made from. Libraries should be used as utilities. That is reuable blocks that are used through out your design.

For example a robot control system includes components: navigation, control, path_plannen etc. These are components and should be implemented with model references. In that case they are developed as independent models and can be tested independently.

Inside the components you could need utility blocks such as low_pass_fileter, error_state_handler and check_input_range, they are libraries.

Advantages of mdl ref: - Code generation: Model references allow partial builds when using the coder product. Assuming you have a really large model with 100k blocks and it takes 20 minutes to build, splitting it up in model references will reduce the build time since only the changed model will need to rebuild.

• Model update: only changed model references are updated "CTRL+D" therefore this helps when having really large models.

• Simulation: In simulations mdl refs are generated as dlls which makes your simulations much faster (the effect is much bigger than the difference between normal and accellerator mode)

Disadvantages pains: - In general Mdl referencing is somehow a pain to use due to limitations

• There is no possibility to pass a Simulink.parameter.object which has a tree structure. (When using type:BusObject only the value property has a structure, the other properties don't)

• When a subsystem has a bus signal as input, a mdl ref needs a bus object to specify the input interface, and the library block doesen't. (Even if its quite ugly to use unspecified bus inputs in a lib block). (Note that busobject are always global in the base workspace... risk of naming collisions)