Simulink® allows you to create your own block libraries. If you create a block library, you can reuse the functionality of a block, subsystem, or Stateflow® atomic subchart in multiple models.
When you copy a library block to a Simulink model, the new block is called a reference block. You can create several instances of this library block in one or more models.
The reference block is linked to the library block using a library link. If you change a library block, any reference block that is linked to the library block is updated with those changes when you open or update the model that contains the reference block.
For more information about reference blocks and library links, see Custom Libraries (Simulink).
Library blocks themselves can have links to requirements. In addition, if a library block is a subsystem or atomic subchart, the objects inside the library blocks can have library links. You use the Requirements Management Interface (RMI) to create and manage requirements links in libraries and in models.
The following sections describe how to manage requirements links on and inside library blocks and reference blocks.
When you copy a library subsystem or masked block to a model, you can highlight, view and navigate requirements links on the library block and on objects inside the library block. However, those links are not associated with that model. The links are stored with the library, not with the model.
You cannot add, modify, or delete requirements links on the library block from the context of the reference block. If you disable the link from the reference block to the library block, you can modify requirements on objects that are inside library blocks just as you can for other block attributes when a library link has been disabled.
You use the RMI to manage requirements links on a reference block just like any other model object. You can view and navigate both local and library requirements on a reference block.
Locally created requirements links — Can be modified or deleted without changing the library block:
Manifold absolute pressure sensor
Mass airflow estimation
Requirements links on the library block — Cannot be modified or deleted from the context of the reference block:
If your library block is a subsystem or a Stateflow atomic subchart, you can create requirements links on objects inside the subsystem or subchart. If you disable the link from the reference block to the library, you can add, modify, or delete requirements links on objects inside a reference block. Once you have disabled the link, the RMI treats those links as locally created links.
After you make changes to requirements links on objects inside a reference block, you can resolve the link so that those changes are pushed to the library block. The next time you create an instance of that library block, the changes you made are copied to the new instance of the library block.
The workflow for creating a requirement link on an object inside a reference block is:
Within a library you have a subsystem S1. Drag S1 to a model, creating a new subsystem. This subsystem is the reference block.
Disable the library link between the reference block and the library block. Keep the library loaded while you disable the link to maintain RMI data. To disable the link, select the reference block, and in the Subsystem tab, click Disable Link.
Create a link from the object inside the reference block to the requirements document.
When linking to a requirement from inside a reference block, you can create links only in one direction: from the model to the requirements document. The RMI does not support inserting navigation objects into requirements documents for objects inside reference blocks.
Resolve the library link between the reference block and the library block:
Select the reference block.
In the Subsystem tab, click Restore Link.
In the Action column, click Push.
Click OK to resolve the link to the library block and push the newly added requirement to the object inside the library block.
When you resolve the library link between the library block and the subsystem, Simulink pushes the new requirement link to the library block S1. The following graphic shows the new link from inside the library block S1 to the requirement.
If you see a message that the library is locked, you must unlock the library before you can push the changes to the library block.
If you reuse library block S1, which now has an object with a requirement link, in another model, the new subsystem contains an object that links to that requirement.
If you have a requirement that links to a library block and you drag that library block to a model, the requirement does not link to the reference block; the requirement links only to the library block.
For example, consider the situation where you have established linking between a library block (B1 in the following graphic) and a requirement in both directions.
When you use library block B1 in a model, you can navigate from the reference block to the requirement. However, the link from the requirement still points only to library block B1, not to the reference block.
As discussed in the previous section, you can create requirements links on objects inside instances of library block after disabling library links. However, the RMI prohibits you from creating a link from the requirements document to such an object because that link would become invalid when you restored the library link.