Teamscale for Simulink and Stateflow
Teamscale analyzes MATLAB Simulink models and Stateflow charts directly, without requiring a MATLAB installation. You get guideline checks, structural metrics, clone detection, architecture analysis, and test coverage for your models in the same place as for your source code. This page explains how to set up a project for your models and how to work with them in Teamscale.
What Teamscale Offers for Model-Based Development
| Feature | What you get |
|---|---|
| Model viewer | Browse models, subsystems, library blocks, and Stateflow charts in Teamscale, with findings and metrics shown directly on the diagram. |
| Modeling guideline checks | More than 150 built-in checks for Simulink, Stateflow, and MATLAB code, mapped to the MathWorks Advisory Board (MAB) and High-Integrity Systems Modeling (HISM) guidelines. |
| Structural metrics | Block count, nesting depth, subsystems per model, Stateflow states, and more, each with configurable thresholds. |
| Model clone detection | Finds duplicated block structures across all models and shows them side by side. |
| Architecture analysis | Checks library dependencies between models against your intended architecture and shows the signals that flow along each dependency. |
| Model Advisor integration | Imports Simulink Model Advisor reports so that their results appear as Teamscale findings on your models. |
| Generated-code tracing | Maps findings and test coverage of generated code back to the Simulink blocks it was generated from. |
| Quality evolution | Track all of the above over time, per commit, per branch, and in merge requests, like for any other code in Teamscale. |
Supported Files
| File type | Extension | Language in Teamscale |
|---|---|---|
| Simulink models and libraries (SLX format) | .slx | Simulink and Stateflow |
| Simulink models (MDL format, including the text-based MDL format introduced in R2021b) | .mdl | Simulink and Stateflow |
| Simulink data dictionaries | .sldd | Simulink and Stateflow |
| MATLAB scripts, functions, and classes | .m | Matlab |
Stateflow charts and MATLAB Function blocks are part of the model files and need no extra configuration.
Setting up a Simulink Project
To analyze your models, follow these steps:
- Create an analysis profile and select
Simulink and StateflowunderLanguage & Tool Enablement. If your repository also contains MATLAB code (.mfiles), selectMatlabas well. - Create a project that uses this analysis profile and connect it to your version control system.
- In the connector's
Included file namesoption, make sure that all relevant files are included, for example,**.slx, **.mdl, **.sldd, **.m. Include libraries and data dictionaries even if you don't want findings for them. Teamscale needs them to resolve library blocks, bus definitions, and data types in your models. - Wait for the initial analysis to finish and open one of your models.
How to Improve Analysis Results for Simulink lists common pitfalls, such as configuring block types by their internal names.
Libraries Stored in Other Repositories
If your models use libraries from another repository, add that repository as a second connector to the same project. Teamscale resolves library blocks across all files in the project. If you don't want findings for these libraries, enable the expert option Source library connector on that connector. Teamscale then uses the libraries to analyze your models, but doesn't analyze or show the libraries themselves.
Adapting the Analysis to Your Modeling Standard
Most organizations follow a subset of the MAB guidelines, often with company-specific adaptations. To match Teamscale to your modeling standard:
- Open the Checks perspective and select the Guidelines view to see which MAB and HISM rules Teamscale checks.
- In your analysis profile, enable or disable individual checks and adjust their options, such as maximum name lengths, prohibited block types, or allowed numeric literals in Stateflow.
- Adjust the thresholds of the structural metrics to the size of your models.
- If you have an internal guideline document, create a custom guideline and map its rules to Teamscale checks. Use the language
SIMULINKin the guideline definition.
Browsing Models
Open the Metrics perspective and navigate to a model file (.slx or .mdl) in the file tree, just like you would for a source-code file. Teamscale shows the root level of the model.
At the top of the view, you see two breadcrumbs:
- The file path of the model in your repository.
- The path inside the model, starting at the model root. Click any part of this path to go back to that subsystem level.
You can also use the time-travel control to look at the model as it was at any earlier commit.
The model viewer reacts to clicks on blocks:
- Subsystems: Click a subsystem to open it.
- Library blocks and model references: Click the block to jump to the referenced library or model, directly at the referenced block. When you enter a library block this way, Teamscale shows data types for this specific usage of the library.
- Stateflow charts: Click a chart to open it. Click a state with a subchart to open the subchart.
Hover over a block to see its block type, or the block it references.
Finding Where a Model or Library Is Used
To find out which models use the current model or subsystem, open the code actions menu and select Show subsystem usages (keyboard shortcut D). The dialog shows two lists:
- Outgoing references: the libraries, referenced subsystems, referenced models, and data dictionaries the current model uses.
- Incoming references: all blocks in other models that reference the current model or subsystem.
Click an entry to navigate to the source or target block.
Showing Signal Data Types
Teamscale computes the data types of signals by propagating type information through your models, libraries, and data dictionaries. To show these types on the signal lines, select Show propagated types in the Display Options section of the right sidebar.
Viewing Data Dictionaries
When you open a data dictionary (.sldd), Teamscale shows its entries as a list of names and values. Findings on dictionary entries, such as unused data, appear next to the corresponding entry.
Findings and Metrics on Models
Findings appear as markers directly on the affected block, signal line, or annotation. Hover over a marker to see the finding messages, categories, and assessments. Findings that concern the model as a whole appear in a notice above the diagram. The right sidebar lists all findings in the current model and lets you filter them, just like for source code.
When you open a finding in the Findings perspective, the Model Code tab shows the model with the affected block highlighted. If the finding belongs to a guideline, the Guidelines tab shows the corresponding rule, for example, the MAB rule ID.
The Metrics section in the right sidebar shows the metric values of the current model, such as block count and nesting depth. In the treemap and in metric tables, Teamscale uses the number of blocks as the size of a model, in the same way it uses lines of code for source files.
Test Coverage on Models
If you use generated-code tracing and upload test coverage for the generated code, Teamscale shows the coverage on the model:
- In the right sidebar, set the coverage mode to Test Coverage.
- Teamscale colors each block by the coverage of the code generated from it: green for fully covered, yellow for partially covered, and red for not covered. Gray blocks have no executable code.
- Hover over a block to see its coverage and links to the generated code lines.
Stateflow charts aren't colored.
Comparing Model Clones
Teamscale finds duplicated block structures across your models and reports them as Simulink Clones findings. To compare a clone with its copies:
- Open the clone finding in the Findings perspective.
- Select the Siblings tab. It lists all other instances of the clone.
- Click Compare next to a sibling (keyboard shortcut
V).
The Model Compare view shows both subsystems side by side, with the cloned blocks highlighted.
To change the minimum size of reported clones, see Model Clone Detection.
Checking Model Dependencies against Your Architecture
Teamscale's architecture analysis supports Simulink. Each model is a component element, and each library link creates a dependency from the using model to the library. For MATLAB code, a call from one .m file to a function in another .m file creates a dependency.
When you specify an architecture, use model file names without extension as type names.
For Simulink, Teamscale also tells you which signals flow along a dependency:
- In the architecture editor, select a dependency and click Show signals in the policy properties.
- On an architecture violation finding, click Show Simulink Signals.
Both show the list of signals that flow from the source model into the target library, including signals that pass through buses, Goto and From blocks, and subsystem ports. Signals are available only for type-based architectures, not for file-based ones.
Typical Workflows
- Reviewing a model change: Open the merge request or commit in Teamscale to see which findings a model change introduced or removed. Click a finding to see the affected block highlighted in the model. See Performing a Code Review.
- Preparing a release: Use the Guideline Summary dashboard widget and the quality reports to show the guideline compliance of your models. See Creating a Quality Report.
- Cleaning up legacy models: Use the treemap in the Metrics perspective to find the largest and most deeply nested models, and look at model clones to find candidates for library blocks.
- Checking test completeness: Upload test coverage of your generated code to see which parts of the model are covered by tests. See Mapping from Generated Code to Simulink Models.
