Engineering systems often share interface definitions across multiple components or subsystems.
Interfaces in System Composer™ can be stored either locally in a model or in a data dictionary, depending on the maturity of your system. By default, interfaces are stored within the architecture model and are not visible outside the model. If you are in the initial stages of building a system model, store interfaces locally to limit the number of files that need to be managed. However, if your model is mature to the point of leveraging componentization workflows like reference architectures and behaviors, storing interfaces in a data dictionary gives you the ability to share interface definitions across the model hierarchy.
Use the menu to save an interface to a new or existing data
dictionary. Create a new data dictionary by selecting Save to new
dictionary. Provide a dictionary name.
You can also add the interface definitions in the model to an existing data dictionary by selecting Link existing dictionary.
Use the button to import interface definitions from a Simulink® bus object, either from a MAT-file or the workspace.
Delete an interface from a dictionary using the button. If the interface is already being used by ports in
a currently open model, the software returns a warning message. The interface is then
removed from any ports in the open model that are associated with the interface. Note that
if an interface is deleted from a dictionary, upon opening another model that shares the
dictionary, a warning will be presented on startup if the deleted interface is used by ports
in that model. The Diagnostic Viewer offers an option to remove the deleted interface from
all ports that are still using it. You can also select ports individually and delete their
missing interfaces.
Note that a System Composer model and a data dictionary are separate artifacts. Thus, even when the data
dictionary is linked to the model, changes to the data dictionary (a
.sldd
file) must be saved separately from changes to the model (a
.slx
file). To save changes to a linked data dictionary, use the button and select
Save
dictionary
. Once a data dictionary is saved, other models can use its
interface definitions by linking to the data dictionary, thus allowing multiple models to
share the same interface definitions.
A data dictionary can reference one or more other data dictionaries. The interface
definitions in the referenced dictionaries are visible in the parent dictionary and can be
used by a model that is linked to the parent dictionary. To add a dictionary reference, open
the Model Explorer by clicking on the button, or by selecting Model Explorer
from the tab in the Design section of the Modeling
tab.
In the right side of the Model Explorer window, click Add, then select the file name of the data dictionary to add as a referenced dictionary. To remove a dictionary reference, highlight the referenced dictionary, then click Remove.
The Interface Editor shows all interfaces accessible to a model, grouped based on their
data dictionary files. In the following example, myDictionary.sldd
is the
data dictionary linked to the model, and otherDictionary.sldd
is a
referenced dictionary.
The model can use any of the interfaces listed. However, you cannot modify the contents of the referenced dictionaries from the model.
Note that referenced dictionaries can reference other data dictionaries. A model that links to a dictionary has access to all interface definitions in referenced dictionaries, including indirectly referenced dictionaries.
Referenced dictionaries may be useful when multiple models need to share some, but not all, interface definitions. For instance, Model A could link to Dictionary A, which contains interface definitions used only by Model A, and Model B could similarly link to Dictionary B. Both Dictionary A and Dictionary B could then reference Dictionary C, which contains interface definitions shared by both models, for example, to allow communication between the models.
A project may contain multiple models, and it may be useful for the models to share interface definitions that are relevant to data flows and other communications between models. At the same time, each model may have interface definitions that are relevant only to its internal operations. For example, different components of a system may be represented by different models, with different teams or different suppliers working on each model, with a system integrator working on the "top" model that incorporates the various components. Referenced data dictionaries provide a way for models to share some but not all interface definitions.
In such a multiple-team project, set up a "shared artifacts" data dictionary to store interface definitions that will be shared by different teams, then set up a data dictionary for each model within the project to store its own interface definitions. Each data dictionary can then add the shared data dictionary as a referenced data dictionary. Alternatively, if a model does not need its own interface definitions, that model can link directly to the shared data dictionary.
The above diagram depicts a project with three models. The model
mSystem.slx
represents a system integration model, and
mSupplierA.slx
and mSuppierB.slx
represent supplier
models. The data dictionary dShared.sldd
contains interface definitions
shared by all the models. The system integration model is linked to the data dictionary
dSystem.sldd
, and the Supplier A model is linked to the data dictionary
dSupplierA.sldd
; each data dictionary contains interface definitions
relevant to the corresponding model's internal workflow. The data dictionaries
dSystem.sldd
and dSupplierA.sldd
both reference the
shared dictionary dShared.sldd
. The Supplier B model, by contrast, is
linked directly to the shared dictionary dShared.sldd
. In this way, all
three models have access to the interface definitions in
dShared.sldd
.
The following diagrams show the system integration model mSystem
,
along with the Interface Editor. Interface definitions contained in the referenced
dictionary dShared
are associated with the ports used to communicate
between the models mSupplierA
and mSupplierB
and the
rest of the system integration model.
The following diagrams show the supplier model mSupplierA
, along with
the Interface Editor. Interface definitions contained in the referenced dictionary
dShared
are associated with the ports used to communicate externally,
while interface definitions in the private dictionary dSupplierA
are
associated with ports whose use is internal to the mSupplierA
model.