Save, Link, and Delete Interfaces

Store Interfaces in a Data Dictionary

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 save interface 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.

The robot interfaces dictionary shown in the interface editor window. Below the dictionary are the interfaces named 'sensor data', 'GPS data', and 'coordinates'.

You can also add the interface definitions in the model to an existing data dictionary by selecting Link existing dictionary.

Use the interface importbutton 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 delete interface 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.

The 'sensor data' interface is selected. The confirm delete interface warning message says: Are you sure you want to delete interface: 'sensor data'? This will remove interface from all ports associated with that interface. This action cannot be undone. The default selection is No.

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 save interface 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.

Add Referenced Data Dictionaries

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 manage dictionary and references interface button, or by selecting Model Explorer from the tab in the Design section of the Modeling tab.

Model Explorer window with "Add" button on right

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.

Use Referenced Data Dictionaries for Projects with Multiple 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.

hierarchy diagram showing project with 3 models and 3 data dictionaries, 1 of which is referenced by the 2 others

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.

System Composer canvas showing the mSystem model

Interface Editor from the mSystem 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.

System Composer canvas showing the mSupplierA model

Interface Editor from the mSupplierA model

Related Topics