In R2026b, you can get a high-level overview of design quality by using the new Model Design Dashboard. The dashboard assesses design size, complexity, requirements traceability, diagnostics, and reuse so that you can identify areas for improvement.
Use the Model Design Dashboard to:
Assess the size and composition of your design across Simulink®, Stateflow®, and MATLAB® code.
View complexity metrics, such as Halstead difficulty and cyclomatic complexity, and drill down to the Model Maintainability Dashboard for detailed architecture and decision path analysis.
Review requirements traceability, including implemented requirements, link types, and broken links.
Check recent compile results and code issues from the MATLAB Code Analyzer.
Identify opportunities for reuse through referenced models, linked libraries, subsystem references, and Clone Detector results.
To open the dashboard, on the Project tab, expand the Tools gallery, and select Model Design Dashboard. For more information, see Assess Model Design Using Model Design Dashboard.
Note
If you currently use the Metrics Dashboard to review MATLAB Code Analyzer warnings, Simulink diagnostics, and reuse metrics, consider using the new Model Design Dashboard instead. The Metrics Dashboard will be removed in a future release.
Starting in R2026b, you can create custom threshold sets by copying and modifying a shipping threshold set. Use custom thresholds to tailor compliance criteria to your project requirements. Custom threshold sets appear in the threshold settings in the top-left corner of the Model, SIL Code, and PIL Code Testing dashboards, alongside the shipping threshold sets. To apply your customized thresholds, select the threshold set.
Additionally, you can use custom thresholds with the metric engine API. For example, you
can get metric results classified according to a specific threshold set by using the ThresholdSetId argument in
getMetrics
function.
metricEngine = metric.Engine; metricID = "modeltesting.TestResultAnalysis[slcomp.TestStatusDistribution]"; results = getMetrics(metricEngine,metricID,ThresholdSetId="MyCustomizedThresholds")
For more information, see Adjust Dashboard Thresholds to Match Your Testing Criteria.
Starting in R2026b, 16 existing MAB checks display results in an updated, structured format in Model Advisor. This update improves how you review and interpret check results while preserving the existing check behavior and outcomes.
With this update, you can:
View check results in a structured format instead of a flat text-based layout.
See individual findings with consistent information, such as status and recommended action.
Navigate results more easily using the default Model Advisor result presentation.
The updated result format uses the standard Model Advisor result presentation for checks
authored with detailed result collections. For more information, see ModelAdvisor.ResultDetail and setCallbackFcn.
In the updated Model Advisor Report view, the check status appears as a horizontal summary bar.
In the updated Model Advisor Result Details view, check results appear in a table with columns for status, failing element, description, recommended action, justifications, and the check status appears as a horizontal summary bar.
The following table lists the MAB checks that use the updated result format in this release.
If you previously justified these checks, review the justifications after upgrading. The updated result format can affect how individual results are displayed.
In R2026a, you can detect compliance issues while modeling and resolve them by using the Model Guidance Dashboard. The dashboard displays edit-time violations in the model, gives visual indications of violations, and displays live model metrics.
For more information, see Model Guidance Dashboard.
Starting in R2026a, you can launch Model Slicer directly from the Breakpoints List when your Simulink model pauses at a breakpoint. This integration allows you to trace the signal values back to their sources so you can isolate the root cause of unexpected behavior in large models. A Simulink Check™ license is required to launch Model Slicer from the Breakpoints List.
In the Breakpoints List, Model Slicer:
Sets the starting point to the signal associated with the current breakpoint.
Updates the slice criteria to match the selected breakpoint when you add a new breakpoint or switch between existing breakpoints.
When model simulation hits a breakpoint, perform these steps to use Model Slicer from the Breakpoints List:
On the Debug tab, click Breakpoints List. The Breakpoints List opens at the bottom of the Simulink Editor.
In the Breakpoints List, click the Debug using Slicer button
to debug the signal. You can also:Add a starting point by clicking the Add Starting Point button
.View the upstream and downstream flow of the signals in the model using
button.
Click the Close Model Slicer button
to close the Model Slicer.
For more information, see Breakpoints List (Simulink) and Trace Faulty Signal Paths Using Model Slicer at Signal Breakpoints.
Starting in R2026a, you can open the Model Slicer from the context menu by right-clicking the Simulink model canvas, model, subsystems, blocks, or signals. For example, this image shows the differences between the Model Slicer context menus that open when you right-click a subsystem in R2025b and in R2026a.
To view the Model Slicer app section in the context menus, right-click the model canvas or subsystem, and select Model Slicer under Select Apps. The app opens and a Model Slicer app section appears in the context menu.
The Model Slicer context menu shows parameters with their corresponding icons for the model after you select Model Slicer app. The table shows the functionality in the context menu for model canvas, model, subsystems, blocks, or signals in R2026a that corresponds to options in the context menu in R2025b.
| R2025b | R2026a |
|---|---|
| Model Slicer > Slice component | Right-click the block or subsystem and select the Slice component button
 in the Model Slicer context menu. |
| Model Slicer > Refine for dead logic | Right-click the block or subsystem and select the Refine for dead logic
button  in the Model Slicer context menu. |
| Model Slicer > Add as Starting Point | Right-click the block or subsystem and select the Add to Current Slice as
button in the Model Slicer context menu. |
| Model Slicer > Add as Exclusion Point | Right-click the block or subsystem and select the Add as Exclusion Point
button  in the Model Slicer context menu. |
| Model Slicer > Enable editing | Right-click the model canvas and select the Enable editing button
 in the Model Slicer context menu. |
| Model Slicer > Resume slicing | Right-click the canvas and select the Resume slicing button
 in the Model Slicer context menu. |
| Model Slicer > Constraint | Right-click the block and select the Constraint button
 in the Model Slicer context menu. |
To view a tooltip that explains what action you can take by clicking a button, hover over the button icon.
To remove the Model Slicer app section from the context menu, hover over the Model Slicer app icon and click Close App. For more information on the changes in the context menu, see Simulink Context Menu.
Starting in R2026a, you can open the Model Advisor from the context menu by right-clicking the Simulink model canvas, model, subsystems, blocks, or signals. For example, this image shows the differences between the Model Advisor context menus that open when you right-click a subsystem in R2025b and in R2026a.
To view the Model Advisor apps section in the context menus, right-click the model canvas or subsystem, and select Model Advisor under Select Apps. The app opens and a Model Advisor app section appears in the context menu.
The table summarizes the actions in the context menu in R2026a for adding or modifying exclusions that correspond to actions the context menu in R2025b when you right-click the subsystem or block:
| R2025b | R2026a |
|---|---|
| Select Model Advisor > Model Advisor Exclusion Editor | Click the block or subsystem and select Open Model Advisor Exclusion Editor
button  in the Model Advisor section of the context
menu. |
| Select Model Advisor > Exclude all blocks of type blockType > All checks | Click the block and select Exclude > All Blocks of This Type > All checks in the Model Advisor section of the context menu. |
| Select Model Advisor > Exclude all blocks of type blockType > Select checks | Click the block and select Exclude > All Blocks of This Type > Select checks in the Model Advisor section of the context menu. |
| Select Model Advisor > Exclude block only > All checks | Click the block and select Exclude > This Block Only > All checks in the Model Advisor section of the context menu. |
| Click the block and select Model Advisor > Exclude block only > Select checks | Click the block and select Exclude > This Block Only > Select checks in the Model Advisor section of the context menu. |
You can also open the Model Guidance Dashboard introduced in R2026a from the Model Advisor
section of the context menu. To open it, right-click the model canvas, subsystem, or block and
select the Open Model Guidance Dashboard button 
.
To remove the Model Advisor section from the context menu, hover over on the app icon and click Close App. For more information on the changes in the context menu, see Simulink Context Menu.
To access Clone Detector app options in the new Context Menu design, point to Select Apps and click the Clone Detector
button 
. A new menu section containing options related to the Clone
Detector app appears in the menu.
The Model Transformer app has been removed from Simulink context menu. For more information about the new context menu, see New Simulink context menus prioritize frequently used functionality.
This image shows the appearance of the context menu in R2025b and in R2026a.
Starting in R2026a, these Clone Detector app options are available in Simulink context menu:
To exclude a subsystem from clone detection analysis, select Exclude subsystem from clone detection button
.To open Clone Detection Exclusion Editor, select Exclusion editor button
.
Starting in R2026a, the Hide requirements metrics option has been removed from the dashboard project. In previous releases, if you do not perform requirements-based testing and want to hide non-compliant requirement metrics, you can hide the Test Analysis section of the Model Testing Dashboard by selecting Hide requirements metrics.
Now, you can hide the compliance overlays for requirements metrics by selecting No Threshold or Testing without Requirements in the threshold settings in the top-left corner of the dashboard.
In R2025a, you can assess the status and quality of the models in your project by using the Project Model Testing dashboard. The dashboard summarizes the model testing, coverage, and requirements traceability across the units in your project.
For more information, see Summarize Status of Model Testing for Project and Project Model Testing Metrics.
In R2025a, you can use the Traceability tab in the Dashboard window to manage artifact traceability for your project and to open new trace views for your project. The new trace view toolbar allows you to search for specific artifacts and navigate large projects with complex hierarchies by using the Cluster layout. You can view the direct traceability connections for specific artifacts in the new Artifact Neighbors panel. For more information, see Explore Traceability Information Using Trace Views.
Additionally, the digital thread can now analyze:
Code Analyzer configuration files
Requirement justifications
System Composer allocation sets
System Composer profile XML files
For more information on how the digital thread traces relationships between artifacts, see Monitor Artifact Traceability and Detect Outdated Results with Digital Thread.
Starting in R2025a, you can identify tests that do not count as component tests, such as tests on libraries, subsystem references, and virtual subsystems, by using the new Independent widget in the Model Testing Dashboard. Previously, the dashboard only showed these types of tests under the Others folder in the Artifacts panel.
Independent tests can execute independently of the component and can behave differently depending on the conditions specified in the test harness. Therefore, these tests do not definitively indicate the quality of component testing and do not contribute to the other metric results in the Model Testing Dashboard. You can view the component tests and independent tests by using the new Component and Independent widgets in the Test Breakdown section of the Model Testing Dashboard. For more information, see Component Tests and Independent Tests.
Additionally, you can also programmatically identify the functional requirements implemented in the component. For more information, see Component Requirements.
The Justification widget of Model Advisor check violations now includes these changes to its user-interface elements.
| Previous UI Element | New UI Element | Description of Functionality |
|---|---|---|
| Add Justification | Apply | No change in functionality. Use this button to justify a model advisor check violation. |
| Edit |  icon. | No change in functionality. Use the
icon to edit the rationale for justification. After editing, click the  icon to save your edits. |
| Delete |  icon. | No change in functionality. Use the icon to delete a justification and set the justified violation back to the error or warning status. |
For more information, see Justify Model Advisor Violations from Check Analysis.
If your Simulink Test test files, test cases, and test iterations use external files as inputs, you can now view those external file dependencies by using the Tests and Results trace view in the Model Testing Dashboard or Model Design Dashboard. The Tests and Results trace view shows external files like coverage filters, baseline files, parameter override sets, and configuration setting overrides.
For information, see Explore Traceability Information Using Trace Views.
In R2024b, you can view the units and components in your project by using the Units and Components trace view in the Model Testing Dashboard or Model Design Dashboard.
Previously, the Project panel in the Dashboard window listed the units in the project, organized by the components that referenced them. Now, the Project panel shows a flat list of the compatible artifacts for the current dashboard and the Units and Components trace view shows the relationship between the units and components in your project.
For more information, see Explore Traceability Information Using Trace Views.
With the support package, you can now:
Create formal assessments to evaluate the compliance of task inputs and outputs against specific standards that you define in a
padv.Assessmentobject. Starting in R2024a, when you point to the task status, the assessments show the specific objectives associated with the failures, warnings, and passing results that you see in the Details column. For more information, see Assess Quality of Task Results.
Add instructions to your tasks by specifying a Markdown file or binary file in the
Instructionproperty. Starting in R2024a, when you click the task information icon
, the rendered instruction text appears in
Process Advisor.Add custom tools to your tasks by using a
padv.TaskToolobject. Starting in R2024a, you can use those task tools to open custom App Designer oruifigureapps directly in Process Advisor or evaluate specific MATLAB commands.Represent manual tasks that you perform outside the build system as a part of your process by using the
TaskTypename-value argument. For more information, see Create Custom Tasks.Run your Process Advisor process as part of a MATLAB build by using the new task
padv.buildtool.tasks.RunProcessTaskin your build file.Use the task property
PredecessorTaskto directly specify a predecessor task for the built-in taskspadv.builtin.task.AnalyzeModelCode,padv.builtin.task.MergeTestResults, andpadv.builtin.task.RunCodeInspection. By default, these tasks expect outputs from upstream tasks with specific names. Previously, if you renamed an upstream task, you needed to reconfigure the input queries of these built-in tasks to find and get the outputs from your renamed task. Now, you can specify thePredecessorTaskproperty instead.Execute the built-in tasks
padv.builtin.task.GenerateRequirementsReport,padv.builtin.task.GenerateSDDReport, andpadv.builtin.task.GenerateSimulinkWebViewin parallel. Previously, if you tried to run these tasks in parallel, these tasks generated an error due to the MATLAB Connector server running on non-default ports.Enable or disable pipeline caching for a generated pipeline by using the
EnablePipelineCachingproperty in the pipeline generator options for your CI platform.
Note that by default, the web views that you generate by using
padv.builtin.task.GenerateSimulinkWebView
no longer include the optional views for model
requirements and coverage data. To include those views, specify the new task properties
IncludeRequirements and IncludeCoverage as
true.
To download and install the support package, see CI/CD Automation for Simulink Check. For more information, see Continuous Integration.
With the support package, you can now:
Create a checklist of tasks that users can mark as complete by using a checkbox. For more information, see Create User Tasks.
Customize how Process Advisor opens artifacts from the I/O column by overriding the
openArtifactmethod of a task. For more information, see Optional Customizations for Opening Task Artifacts.Use additional build options
ContinueOnFailureandSkipfor the built-in taskpadv.builtin.task.RunBuildTool.Manage data dictionary caching across multiple MATLAB sessions by using the new utilities
padv.util.DictionaryCacheandpadv.util.initSessionDataDictionaryCache.View skipped and disabled tasks, along with their dependent tasks, in a list of
skippedtasks at the end of the build log.
To download and install the support package, see CI/CD Automation for Simulink Check. For more information, see Continuous Integration.
In R2024a, you can use the new back-to-back testing metrics in the SIL and PIL Code Testing dashboards to assess translation validation for your generated code. These metrics compare the normal mode and software-in-the-loop (SIL) or processor-in-the-loop (PIL) mode test runs, which test the equivalence between your model and generated code. The dashboards show the back-to-back test status and a breakdown of the statuses for each test in the software unit. For more information, see View Status of Code Testing Activities for Software Units in Project.
Alternatively, you can collect the metrics programmatically by using the metric.Engine API. The back-to-back testing metrics include:
| Metric ID | Metric Information |
|---|---|
slcomp.sil.B2BTestStatus | Back-to-Back Test Status for Normal and SIL Mode |
slcomp.sil.B2BTestStatusDistribution | Back-to-Back Test Status Distribution for Normal and SIL Mode |
slcomp.pil.B2BTestStatus | Back-to-Back Test Status for Normal and PIL Mode |
slcomp.pil.B2BTestStatusDistribution | Back-to-Back Test Status Distribution for Normal and PIL Mode |
To view the comparison results that the metrics use to determine the status of
back-to-back testing, you can use the new function metric.loadB2BResults.
For more information, see Evaluate Status of Back-to-Back Testing for Software Units.
In R2024a, you can measure the size and complexity of the Simulink models, Stateflow charts, and MATLAB code in your project using the Halstead difficulty metrics. These metrics can help you monitor code quality, identify complex areas in the design, and address software maintainability concerns. You can view the metric results in the Halstead Difficulty widget and Halstead Difficulty Breakdown section in the dashboard.
Alternatively, you can collect the metrics programmatically by using the metric.Engine API. For information on the Halstead difficulty metrics, see Halstead Difficulty Breakdown.
In R2024a, you can analyze artifacts and their relationships more efficiently by using the digital thread to cache traceability information in the artifacts themselves. You can enable caching from the Digital Thread Settings dialog box.
When you open a Model Design or Model Testing Dashboard, the dashboard now shows an informational banner where you can open the Digital Thread Settings dialog box by clicking View Digital Thread Settings.
In the Digital Thread Settings dialog box, under User Settings > Trace Information, select Cache trace information to enable caching.
Alternatively, you can view the Digital Thread Settings dialog box for a project by clicking Options in the dashboard toolstrip and clicking Digital Thread Settings. For more information about the digital thread, see Monitor Artifact Traceability and Detect Outdated Results with Digital Thread.
In R2024a, when you open a Model Design or Model Testing Dashboard for the first time in a project, the dashboard requires that you enable artifact tracing, even if you previously enabled artifact tracing for the project. When you open a dashboard, click Enable and Continue to automatically select the artifact tracing setting Track tool outputs in the Digital Thread Settings dialog box.
The artifact tracing setting allows the digital thread to generate trace information for output artifacts by allowing the digital thread to use callbacks in other MathWorks tools.
Previously, the setting was in the project settings, in the Manage Project Startup and Shutdown dialog box, under the name Track tool outputs to detect outdated results. That setting and its previous value have been removed. Use the Track tool outputs setting instead.
For more information about the digital thread, see Monitor Artifact Traceability and Detect Outdated Results with Digital Thread.
In R2023b, the Metric Details section in the Model Testing, SIL Code Testing, and PIL Code Testing Dashboards has a new Status column that shows whether the metric results for individual artifacts are compliant or noncompliant with the metric thresholds. Previously, you could only see the overall status in the overlay icon for a widget. Now, when you click a widget in the dashboard, you can view threshold violations for individual artifacts directly in the Metric Details section.
For example, if you click the Requirements with Tests widget in the Model Testing Dashboard, the Metric Details section shows a Status column with the threshold compliance status for each artifact.
For an example, see Fix Requirements-Based Testing Issues.
The support package CI/CD Automation for Simulink Check now supports R2023a.
In R2023a, you can analyze artifacts in referenced projects and view artifact warnings and errors in the Project Analysis Issues pane.
To download and install the support package, see CI/CD Automation for Simulink Check.
Assess the status and quality of your code testing by using the metric results in the SIL Code Testing dashboard and PIL Code Testing dashboard. The metrics measure different aspects of code testing completeness for software-in-the-loop (SIL) and processor-in-the-loop (PIL) tests. The metrics are based on industry-recognized standards such as ISO 26262 and DO-178C.
Use the dashboards to view the:
Compliance status of SIL and PIL test results and coverage
Detailed test status breakdowns
Comparisons to relevant model testing results and coverage
Based on the metric results, you can identify and fix failing test results, gaps in coverage, and anomalies between model and code testing results. The dashboard widgets show a summary of the testing metric data for a software unit. To explore the data in more detail, click an individual widget. A table lists the artifacts in the unit and their results for the metric. The table provides hyperlinks to open each artifact so that you can view details about the artifact and address testing quality issues. For more information, see View Status of Code Testing Activities for Software Units in Project and Identify and Troubleshoot Gaps in Code Testing Results and Coverage.
You can also collect the metrics programmatically by using the same metric API as the Model Testing Dashboard. For more information, see metric.Engine.
Viewing the metric results data and details in the dashboard requires a Simulink Check license. To collect results for a metric, you must have the licenses required to edit the associated artifacts, such as Simulink Test and Simulink Coverage™. For more information on the metrics and the required licenses, see Code Testing Metrics.
In R2023a, the dashboards provide additional and improved trace views that help you visually explore traceability information in a project. A trace view is an interactive diagram that shows a certain preset of traceability information for artifacts in a project. The trace views provide a detailed, tree-like structure of project artifacts and show trace relationships, individual artifact information, and a hierarchical view of trace relationships between the artifacts in the selected unit or component.
Previously, you could only see the traceability path from a specific artifact to its unit or component when you right-clicked the artifact and clicked View trace to dashboard.
Now, there are three different types of trace views for units and components:
Design Dependency — Shows the library blocks, data dictionaries, model references, and MATLAB files that trace to the unit or component
Requirement to Design — Shows the functional requirements that trace to the unit or component
Tests and Results — Shows the test cases and test results that trace to the unit or component
For more information, see Explore Traceability Information for Units and Components.
In R2023a, the dashboards can analyze artifacts in referenced projects. The dashboards automatically analyze artifacts across project references and trace artifacts from a referenced project to the current project.
The Project panel now shows units and components in the current project and in referenced projects. Artifacts from referenced projects appear in the Artifacts panel for the relevant unit or component that they trace to in the project. The dashboard includes these referenced project artifacts in the metric results.
To see the name and path of the project that contains an artifact, point to the artifact and view the tooltip.
You can also see artifacts from referenced projects in a trace view. For more information, see Explore Traceability Information for Units and Components.
In R2023a, you can use the Artifact Issues tab to identify and fix artifact issues in your project and troubleshoot warnings and errors. Artifact issues no longer appear in the Diagnostics panel. The issues now appear in the Artifact Issues tab and persist between MATLAB sessions.
To view artifact issues in the current project, open the Artifact Issues tab by clicking the Artifact Issues button in the dashboard toolstrip. In the Artifact Issues tab, a table displays detailed information about each artifact issue in the project.
Alternatively, you can use the new function getArtifactIssues on a metric
engine object to return a list of the artifact issues the dashboard detects in the
project.
For more information, see View Artifact Issues in Project and getArtifactIssues.
In R2023a, the Model Testing Dashboard shows integer overflow coverage, Int. Overflow, in the Model Coverage section of the dashboard.
You can also programmatically collect integer overflow coverage with the metric ID
slcomp.mt.CoverageBreakdown. The metric value returns a structure
array with a field OverflowSaturation for the integer overflow coverage.
For
example:
metric_engine = metric.Engine; execute(metric_engine,"slcomp.mt.CoverageBreakdown"); res = getMetrics(metric_engine,"slcomp.mt.CoverageBreakdown"); overflowCoverage = res(1).Value.OverflowSaturation
overflowCoverage =
struct with fields:
Achieved: 100
Justified: 0
Missed: 0
AchievedOrJustified: 100For more information, see Model Coverage Breakdown.
Previously, if a test case included multiple iterations, the dashboard and metric results reflected the status of the whole test case and did not show individual iteration results. In R2023a, the dashboards and metrics can show the results for individual tests. A test can be either:
A test iteration
A test case without iterations
For example, if the Untested widget in the Model Testing Dashboard shows 6 untested unit tests, these tests can be:
6 untested test iterations
6 untested test cases without iterations
A combination of test iterations and test cases without iterations
In the Artifacts panel, in the Tests and Test Result folders, the dashboard now shows test iterations in the test file hierarchy.
Additionally, in the Metric Details, you can point to an artifact to view a tooltip with the:
Location of the artifact in the project hierarchy
Artifact type
Project name
Project path
Artifact path relative to the project root
For an example, see Explore Status and Quality of Testing Activities Using Model Testing Dashboard.
In R2023a, the Model Advisor is updated to support the new JMAAB 6.0 modeling guidelines. While a new folder containing JMAAB 6.0 checks is added in the Model Advisor, MAB 5.0 and JMAAB 5.1 checks continue to be available as before.
The JMAAB 6.0 checks are derived from the JMAAB v6.0 modeling guidelines composed by the Japan MATLAB® Automotive Advisory Board.
This table lists the new JMAAB 6.0 checks.
| Model Advisor Check | Check ID |
|---|---|
mathworks.jmaab_v6.jc_0900 | |
mathworks.jmaab_v6.jc_0901 | |
mathworks.jmaab_v6.jc_0902 | |
Check for prohibited overlapping or intersecting blocks and signal lines | mathworks.jmaab_v6.jc_0903 |
Check for prohibited overlapping of states and transition lines in Stateflow charts | mathworks.jmaab_v6.jc_0904 |
mathworks.jmaab_v6.jc_0905 | |
mathworks.jmaab_v6.jc_0906 | |
mathworks.jmaab_v6.jc_0907 | |
| Check description of execution statements | mathworks.jmaab_v6.mp_0007 |
| Check for spaces between function or variable names and left parenthesis symbol | mathworks.jmaab_v6.mp_0008 |
mathworks.jmaab_v6.mp_0010 | |
mathworks.jmaab_v6.mp_0011 | |
mathworks.jmaab_v6.mp_0022 | |
mathworks.jmaab_v6.mp_0023 | |
mathworks.jmaab_v6.mp_0032 | |
mathworks.jmaab_v6.mp_0034 | |
mathworks.jmaab_v6.mp_0040 | |
mathworks.jmaab_v6.mp_0046 | |
mathworks.jmaab_v6.mp_0047 | |
mathworks.jmaab_v6.ar_0002 | |
| Check signal line connections | mathworks.jmaab_v6.db_0032 |
| Check position of signal labels | mathworks.jmaab_v6.db_0097 |
| Check definition of Stateflow data | mathworks.jmaab_v6.db_0125 |
| Check for MATLAB expressions in Stateflow charts | mathworks.jmaab_v6.db_0127 |
mathworks.jmaab_v6.db_0129 | |
mathworks.jmaab_v6.jc_0232 | |
Check usage of floating-point expressions in Stateflow charts | mathworks.jmaab_v6.jc_0481 |
mathworks.jmaab_v6.jc_0627 | |
mathworks.jmaab_v6.jc_0630 | |
mathworks.jmaab_v6.jc_0644 | |
mathworks.jmaab_v6.jc_0651 | |
mathworks.jmaab_v6.jc_0753 | |
mathworks.jmaab_v6.jc_0770 | |
Check for usage of events and broadcasting events in Stateflow charts | mathworks.jmaab_v6.jm_0012 |
mathworks.jmaab_v6.na_0011 | |
mathworks.jmaab_v6.na_0020 |
The remaining checks are included as part of JMAAB 6.0, with no change to the check behavior.
In R2022b, you can assess the size, architecture, and complexity of your design by using the metric data in the new Model Maintainability Dashboard. The metrics measure different aspects of model maintainability from model design artifacts like Simulink models, Stateflow charts, and MATLAB code. The model maintainability metrics help you determine if parts of a design are too complex and need to be refactored. A less complex design is easier to read, maintain, and test.
Use the Model Maintainability Dashboard to collect and explore maintainability metric data. The dashboard displays metric results related to the component structure, interface ports and signals, design cyclomatic complexity, and software architecture. For an example of how to use the Model Maintainability Dashboard, see Monitor the Complexity of Your Design Using the Model Maintainability Dashboard.
You can also collect the metrics programmatically by using the functions associated with
the metric.Engine
object. This is the same metric API used to programmatically collect metrics for the
Model Testing Dashboard. When you use it to programmatically
collect metrics for the Model Maintainability Dashboard, specify the
Dashboard argument as "ModelMaintainability". For
more information, see Collect Model Maintainability Metrics Programmatically.
Previously, in the Model Testing Dashboard, you used the Artifacts panel both to select which unit to open the dashboard for and to explore the artifacts that traced to the units and components in the project.
In R2022b, the dashboard selection and artifact exploration are in separate panels:
The Project panel shows the architecture of the software units and components in the current project. The dashboard displays metric results for the unit or component you select in the Project panel. If a dashboard is not available for a specific unit or component, the name of the unit or component appears dimmed.
The Artifacts panel shows the Functional Requirements, Design, Tests, and Test Results folders, which contain the artifacts the dashboard traced to the current unit or component selected in the Project panel. For example, the Design folder for a unit might show the data dictionary, model, and subsystem references associated with the unit.
For more information, see Monitor the Complexity of Your Design Using the Model Maintainability Dashboard and Explore Status and Quality of Testing Activities Using Model Testing Dashboard.
In R2022b, identify the types of tests that contribute to your overall achieved coverage in the Model Testing Dashboard. The dashboard identifies the percentage of the overall achieved coverage coming from requirements-based tests or unit-boundary tests, including execution, decision, condition, and modified condition / decision coverage. Requirements-based tests link to at least one requirement. Unit-boundary tests test the whole unit, not just lower-level subsystems.
Industry-recognized software development standards recommend using requirements-based, unit-boundary tests to confirm the completeness of coverage. Verify the tests that contribute to your overall achieved coverage with the dashboard metric data. In the Model Testing Dashboard, in the Simulation Test Result Analysis section, there is a new subsection, Achieved Coverage Ratio, with two new widgets: Requirements-Based Tests and Unit-Boundary Tests.
Additionally, you can use the functions associated with the metric.Engine
object to programmatically collect the achieved coverage ratio metrics.
For more information on the new metrics for overall achieved coverage from requirements-based and unit-based tests, see:
For more information, see Monitor Low-Level Test Results in the Model Testing Dashboard.
The Model Advisor user interface now includes simplified toolstrip with new features.
Filter Checks - Filters the checks based on their respective result statuses, such as
Failed,Passed,Justified.Justify - Justify the violations. Justifications allow you to add a rationale for violations observed during Model Advisor analysis. For more information, see Justify Violated Blocks from the Model Advisor Check Analysis.
Fix - Fixes the violations by setting the violated parameter values to recommended values.
Reports - Export Model Advisor analysis reports in HTML, PDF, and DOCX formats.
Manage Configurations - Create, load, restore, and associate configurations in simple workflows.
This table describes the changes to the menu items in the Model Advisor:
| Previous UI Element | New UI Element | Description of the Change |
|---|---|---|
| Run Selected Checks | Run Checks | No change in functionality. Use this button to run selected checks. |
| Settings > (options) | Open > (options) | Some older options are no longer available. Use this button to open or customize Model Advisor Configuration Editor. |
| Generate Report… | Report > (options) | No change in functionality. Use this button to generate the Model Advisor analysis report in HTML format. Use the drop-down option to selectPDF or WORD. |
| Configure Hidden input parameters | Configure input parameters in Model Advisor Configuration Editor | Configure hidden input parameters was
a hyperlink in the check window. In R2022a, you can now click the
Configure input parameters in Model Advisor Configuration
Editor icon ( ). |
| Edit > Send Check IDs to Workspace | Right-click on any check, and select Send Check IDs to Workspace. | Use this option to send check IDs to workspace. |
| Edit > Send Instance IDs to Workspace | Right-click on any check, and select Send Instance IDs to Workspace. | Use this option to send instance IDs to workspace. |
This table describes the navigation options removed from Model Advisor:
| Navigation Options Removed |
|---|
| Settings > Treat as referenced model |
| Settings > Preferences |
| Edit > Reset |
| Switch to Model Advisor Dashboard |
| Run Checks in Background |
| Highlighting check results |
| Highlight exclusion results |
| Highlighting |
For more information, see Run Model Advisor Checks and Review Results.
Model Advisor analysis now have new statuses to better understand the check results. This table describes the existing and new check statuses:
Check Result Status | Icon | Description | |
|---|---|---|---|
|
| Model does not have any violations for the given check or checks. | |
|
| Check has identified severe violations. | |
|
| Check has identified violations. | |
|
| Check violations are justified. | |
|
| Check not selected for Model Advisor analysis. | |
|
| Check analysis is incomplete or check execution has resulted in exceptions. | |
For more information, see Run Model Advisor Checks and Review Results.
In R2021b, you can now use overlays in the Model Testing Dashboard to see if your testing artifacts comply with standard requirements-based testing practices. The overlays show if the metric results for a widget are compliant, non-compliant, or generate a warning that the metric results should be reviewed. Results are compliant if they show full traceability, test completion, or model coverage.
To see the overlays for a compliance category, select the category in the Overlays section of the dashboard toolstrip. The overlay appears on the widgets that have results in that category and the top right of the dashboard shows the number of widgets in each compliance category.
To see the compliance thresholds for a metric, point to the overlay icon in the widget.
You can hide the overlay status icons by deselecting the overlays in the toolstrip.
For more information on the compliance thresholds for each metric, see Model Testing Metrics.
In R2021b, the Model Testing Dashboard organizes the models in a new hierarchy, with component models at the top of the hierarchy and unit models at the bottom of the hierarchy. The new hierarchy helps you to locate the models that require unit testing so you can assess their testing quality using the dashboard. The Model Testing Dashboard provides metric results for only the unit models.
By default, the Model Testing Dashboard defines models in two ways:
Models that do not reference other models are units.
Models that reference one or more models are components.
Alternatively, you can specify a model as a unit or a component by using labels in your project.
In the example below, the Artifacts pane shows that the component
model db_Controller references the unit models
db_ControlMode, db_DriverSwRequest,
and db_TargetSpeedThrottle.
Expand a unit to see the artifacts that trace to it, organized by artifact type. For more information, see Categorize Models in a Hierarchy as Components or Units.
Additionally, if you collect metric results programmatically, the metric.Result object
has the new property CollectionScope, which describes the unit
for which you collect metric results.
In R2021b, you can use the Model Testing Dashboard to trace test results in a PDF report, ZIP report, or DOCX report created by Simulink Test. A test results report appears in the Test Results section of the Artifacts panel of the dashboard under the model that it traces to.
To trace a report file in the Artifacts panel, you must open the dashboard for the project before generating the report.
Additionally, you can generate an MLDATX file of the test results before opening a project in the dashboard for the first time, then trace and do metric analysis on the test results.
For more information on the traceability of testing artifacts, see Explore Status and Quality of Testing Activities Using the Model Testing Dashboard.
In R2021b, you can view a summary of the requirements-based testing artifacts in each unit of the model testing metrics report.
After you generate a report, each unit in the report contains a table with a summary of the artifacts in that unit. The table is in the first subsection of each unit in the report. Use the summary to quickly gauge the size and structure of each unit in the report.
To generate a model testing metrics report, click Report in the
Model Testing Dashboard or use the generateReport function. For an example of how to collect metrics
programmatically and generate a report, see Collect Metrics on Model Testing Artifacts Programmatically.
In R2021b, you can generate a requirements-based testing report from the toolstrip of the
Model Testing Dashboard. Previously, to create a report, you
needed to use the generateReport function. In the Model Testing Dashboard, collect results,
then click the Report button.
In the Create Metric Result Report dialog box, specify the file format and location for the report and click Create.
From R2021b, you can find exact clones beyond the boundaries of a subsystem programmatically or by using the Clone Detector app. Prior to R2021b, you could identify subsystem clones only, that is subsystems with identical region of blocks. Matching regions of blocks that were not in the subsystem were not recognized as clones.
To enable finding clones outside subsystem boundaries, in the Clone Detector tab, click Settings, then select Detect Clones Across Model.
To programmatically find clones outside subsystem boundaries, create an object of the
Simulink.CloneDetection.Settings class, set the
DetectClonesAcrossModel property to true, then pass this object to
the Simulink.CloneDetection.findClones function to identify
clones.
cloneDetectionSettings = Simulink.CloneDetection.Settings(); cloneDetectionSettings.DetectClonesAcrossModel = 1; cloneDetectionSettings.MinimumRegionSize = 2; cloneDetectionSettings.MinimumCloneGroupSize = 2; cloneResults = Simulink.CloneDetection.findClones(cloneDetectionSettings);
For more information, see Find Clones Anywhere in a Model.
In R2021b, you can use the Model Transformer tool to replace multiple Interpolation Using Prelookup blocks that have same input signals connected from the outputs of Prelookup blocks into a single Interpolation Using Prelookup block. Reducing the number of Interpolation Using Prelookup blocks in a model reduces the number of variable assignments in the code, which improves the efficiency of the generated code. You can use the Model Transformer app or programmatic commands to refactor the model.
To optimize the model in the Model Transformer, select Common source interpolation transform.
To programmatically run this check, use these MATLAB commands:
| Syntax | Action |
|---|---|
Simulink.ModelTransform.CommonSourceInterpolation.identifyCandidates | Identify eligible Interpolation Using Prelookup blocks to transform. |
Simulink.ModelTransform.CommonSourceInterpolation.refactorModel | Replace Interpolation Using Prelookup blocks n-D blocks. |
For more information, see Improve Code Efficiency by Merging Multiple Interpolation Using Prelookup Blocks.
In R2021b, the edit-time check diagnostics window now includes a Fix button you can use to address block constraint violations.
To enable the edit-time checking, in the Modeling tab, select Model Advisor > Edit-Time Checks.
For more information, see Define Model Advisor Checks for Supported and Unsupported Blocks and Parameters