MATLAB SIMULINK VERIFICATION AND VALIDATION - S User`s guide

Add to my manuals
674 Pages

advertisement

MATLAB SIMULINK VERIFICATION AND VALIDATION - S User`s guide | Manualzz

Simulink

®

Verification and Validation™

User's Guide

R 2015a

How to Contact MathWorks

Latest news:

Sales and services:

User community:

Technical support:

Phone:

www.mathworks.com

www.mathworks.com/sales_and_services www.mathworks.com/matlabcentral www.mathworks.com/support/contact_us

508-647-7000

The MathWorks, Inc.

3 Apple Hill Drive

Natick, MA 01760-2098

Simulink ® Verification and Validation™ User's Guide

© COPYRIGHT 2004–2015 by The MathWorks, Inc.

The software described in this document is furnished under a license agreement. The software may be used or copied only under the terms of the license agreement. No part of this manual may be photocopied or reproduced in any form without prior written consent from The MathWorks, Inc.

FEDERAL ACQUISITION: This provision applies to all acquisitions of the Program and Documentation by, for, or through the federal government of the United States. By accepting delivery of the Program or Documentation, the government hereby agrees that this software or documentation qualifies as commercial computer software or commercial computer software documentation as such terms are used or defined in FAR 12.212, DFARS Part 227.72, and DFARS 252.227-7014. Accordingly, the terms and conditions of this Agreement and only those rights specified in this Agreement, shall pertain to and govern the use, modification, reproduction, release, performance, display, and disclosure of the Program and Documentation by the federal government (or other entity acquiring for or through the federal government) and shall supersede any conflicting contractual terms or conditions. If this License fails to meet the government's needs or is inconsistent in any respect with federal procurement law, the government agrees to return the Program and Documentation, unused, to The MathWorks, Inc.

Trademarks

MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See www.mathworks.com/trademarks

for a list of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective holders.

Patents

MathWorks products are protected by one or more U.S. patents. Please see www.mathworks.com/patents

for more information.

Revision History

June 2004

October 2004

March 2005

April 2005

First printing

Online only

Online only

Second printing

September 2005 Online only

March 2006 Online only

September 2006 Online only

March 2007 Online only

September 2007 Online only

March 2008

October 2008

Online only

Online only

March 2009 Online only

September 2009 Online only

March 2010 Online only

September 2010 Online only

April 2011 Online only

September 2011 Online only

March 2012 Online only

September 2012 Online only

March 2013 Online only

September 2013 Online only

March 2014

October 2014

March 2015

Online only

Online only

Online only

New for Version 1.0 (Release 14)

Revised for Version 1.0.1 (Release 14SP1)

Revised for Version 1.0.2 (Release 14SP2)

Revised for Version 1.1 (Web release)

Revised for Version 1.1.1 (Release 14SP3)

Revised for Version 1.1.2 (Release 2006a)

Revised for Version 2.0 (Release 2006b)

Revised for Version 2.1 (Release 2007a)

Revised for Version 2.2 (Release 2007b)

Revised for Version 2.3 (Release 2008a)

Revised for Version 2.4 (Release 2008b)

Revised for Version 2.5 (Release 2009a)

Revised for Version 2.6 (Release 2009b)

Revised for Version 2.7 (Release 2010a)

Revised for Version 3.0 (Release 2010b)

Revised for Version 3.1 (Release 2011a)

Revised for Version 3.2 (Release 2011b)

Revised for Version 3.3 (Release 2012a)

Revised for Version 3.4 (Release 2012b)

Revised for Version 3.5 (Release 2013a)

Revised for Version 3.6 (Release 2013b)

Revised for Version 3.7 (Release 2014a)

Revised for Version 3.8 (Release 2014b)

Revised for Version 3.9 (Release 2015a)

Contents

Getting Started

1

Simulink Verification and Validation Product Description .

1-2

Key Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-2

System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-3

Operating System Requirements . . . . . . . . . . . . . . . . . . . . . .

1-3

Product Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-3

Requirements Traceability

Links Between Models and Requirements

2

Overview of the Requirements Management Interface

(RMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Requirements Traceability Links . . . . . . . . . . . . . . . . . .

Requirements Link Storage . . . . . . . . . . . . . . . . . . . . . . .

Supported Requirements Document Types . . . . . . . . . .

Supported Model Objects for Requirements Linking . .

Selection-Based Linking . . . . . . . . . . . . . . . . . . . . . . . . .

2-6

2-9

2-10

2-3

2-4

2-5

v

vi Contents

Link to Requirements Document Using Selection-Based

Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-11

Configure RMI for IBM Rational DOORS or Microsoft

ActiveX Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-12

Requirements Traceability Link Editor . . . . . . . . . . . .

Manage Requirements Traceability Links Using Link

Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Requirements Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-13

2-13

2-15

Document Index Tab . . . . . . . . . . . . . . . . . . . . . . . . . .

2-15

Requirements Settings . . . . . . . . . . . . . . . . . . . . . . . . . .

Selection Linking Tab . . . . . . . . . . . . . . . . . . . . . . . . .

2-16

2-16

Link Model Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Link Objects in the Same Model . . . . . . . . . . . . . . . . .

2-18

2-18

Link Objects in Different Models . . . . . . . . . . . . . . . . .

2-18

Link from External Applications . . . . . . . . . . . . . . . . . .

2-20

Link Multiple Model Objects to a Requirements

Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-21

Link Multiple Model Objects to a Requirement Document

Using a Simulink DocBlock . . . . . . . . . . . . . . . . . . .

2-24

Link to Requirements in Microsoft Word Documents .

Create Bookmarks in a Microsoft Word Requirements

Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Open the Example Model and Associated Requirements

Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Create a Link from a Model Object to a Microsoft Word

Requirements Document . . . . . . . . . . . . . . . . . . . . .

Link to Requirements in IBM Rational DOORS

Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-26

2-26

2-28

2-28

Link to Requirements in Microsoft Excel Workbooks .

Navigate from a Model Object to Requirements in a

Microsoft Excel Workbook . . . . . . . . . . . . . . . . . . . .

Create Requirements Links to the Workbook . . . . . . .

Link Multiple Model Objects to a Microsoft Excel

Workbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-32

2-34

2-34

2-34

2-35

Change Requirements Links . . . . . . . . . . . . . . . . . . . .

Link to Requirements in MuPAD Notebooks . . . . . . . .

Create Requirements Traceability Report for Model .

2-36

2-39

2-42

Link to Requirements Modeled in Simulink . . . . . . . .

2-44

Requirements Linking with Simulink Annotations . . .

2-53

Link Signal Builder Blocks to Requirements

Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-54

Link Signal Builder Blocks to Model Objects . . . . . . . .

2-56

Link Requirements to Simulink Data Dictionary

Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-58

3

How Is Requirements Link Information Stored?

External Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Guidelines for External Storage of Requirements

Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Specify Storage for Requirements Links . . . . . . . . . . . .

Save Requirements Links in External Storage . . . . . . .

Load Requirements Links from External Storage . . . . .

Move Internally Stored Requirements Links to External

Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Move Externally Stored Requirements Links to the

Model File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-2

3-7

3-8

3-3

3-4

3-5

3-6

vii

viii Contents

Reviewing Requirements

4

Highlight Model Objects with Requirements . . . . . . . . .

Highlight Model Objects with Requirements Using Model

Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Highlight Model Objects with Requirements Using Model

Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-2

4-2

4-3

Navigate to Requirements from Model . . . . . . . . . . . . . .

Navigate from Model Object . . . . . . . . . . . . . . . . . . . . .

4-5

4-5

Navigate from System Requirements Block . . . . . . . . . .

4-5

Customize Requirements Traceability Report for

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Create Default Requirements Report . . . . . . . . . . . . . .

Report for Requirements in Model Blocks . . . . . . . . . .

Customize Requirements Report . . . . . . . . . . . . . . . . .

4-7

4-7

4-15

4-17

Generate Requirements Reports Using Simulink . . . . .

4-22

Filter Requirements with User Tags . . . . . . . . . . . . . . .

4-25

User Tags and Requirements Filtering . . . . . . . . . . . .

Apply a User Tag to a Requirement . . . . . . . . . . . . . .

Filter, Highlight, and Report with User Tags . . . . . . .

Apply User Tags During Selection-Based Linking . . . .

Configure Requirements Filtering . . . . . . . . . . . . . . . .

4-25

4-25

4-27

4-29

4-31

Create Requirements Traceability Report for Simulink

Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-33

View Requirements Details for a Selected Block . . . . .

4-34

Requirements Details Workflow . . . . . . . . . . . . . . . . .

4-34

Requirements Details Limitations . . . . . . . . . . . . . . . .

4-34

Requirements Links Maintenance

5

Validation of Requirements Links . . . . . . . . . . . . . . . . . .

5-2

When to Check Links in a Requirements Document . . .

5-2

How the rmi Function Checks a Requirements

Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5-3

Validate Requirements Links in a Model . . . . . . . . . . . .

5-4

Check Requirements Links with the Model Advisor . . . .

5-4

Fix Invalid Requirements Links Detected by the Model

Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5-7

Validate Requirements Links in a Requirements

Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Check Links in a Requirements Document . . . . . . . . .

When Multiple Objects Have Links to the Same

5-11

5-11

Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5-12

Fix Invalid Links in a Requirements Document . . . . . .

5-13

Document Path Storage . . . . . . . . . . . . . . . . . . . . . . . . .

Relative (Partial) Path Example . . . . . . . . . . . . . . . . .

5-15

5-15

Relative (No) Path Example . . . . . . . . . . . . . . . . . . . .

5-15

Absolute Path Example . . . . . . . . . . . . . . . . . . . . . . . .

5-16

Delete Requirements Links from Simulink Objects . .

5-17

Delete a Single Link from a Simulink Object . . . . . . . .

5-17

Delete All Links from a Simulink Object . . . . . . . . . . .

5-17

Delete All Links from Multiple Simulink Objects . . . . .

5-18

Requirements Links for Library Blocks and Reference

Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5-19

Introduction to Library Blocks and Reference Blocks . .

5-19

Library Blocks and Requirements . . . . . . . . . . . . . . . .

Copy Library Blocks with Requirements . . . . . . . . . . .

5-19

5-20

Manage Requirements on Reference Blocks . . . . . . . . .

5-20

Manage Requirements Inside Reference Blocks . . . . . .

5-21

Links from Requirements to Library Blocks . . . . . . . .

5-24

IBM Rational DOORS Surrogate Module

Synchronization

6

Synchronization with DOORS Surrogate Modules . . . .

6-2

ix

x Contents

Advantages of Synchronizing Your Model with a

Surrogate Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-4

Synchronize a Simulink Model to Create a Surrogate

Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-5

Create Links Between Surrogate Module and Formal

Module in a DOORS Database . . . . . . . . . . . . . . . . . . .

6-7

Customize DOORS Synchronization . . . . . . . . . . . . . . . .

DOORS Synchronization Settings . . . . . . . . . . . . . . . . .

Resynchronize a Model with a Different Surrogate

Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Customize the Level of Detail in Synchronization . . . .

Resynchronize to Include All Simulink Objects . . . . . .

Resynchronize DOORS Surrogate Module to Reflect

Model Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-15

Navigate with the Surrogate Module . . . . . . . . . . . . . .

Navigate Between Requirements and the Surrogate

Module in the DOORS Database . . . . . . . . . . . . . . .

Navigate Between DOORS Requirements and the

6-17

6-17

Simulink Module via the Surrogate Module . . . . . . .

6-18

6-8

6-8

6-10

6-11

6-12

Navigation from Requirements Documents

7

IBM Rational DOORS . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Why Add Navigation Objects to DOORS Requirements?

Configure Requirements Management Interface for

DOORS Software . . . . . . . . . . . . . . . . . . . . . . . . . . .

Enable Linking from DOORS Databases to Simulink

Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Insert Navigation Objects into DOORS Requirements . .

Customize DOORS Navigation Objects . . . . . . . . . . . . .

7-2

7-2

7-2

7-4

7-5

7-7

Navigate Between DOORS Requirement and Model

Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7-8

Diagnose and Fix DXL Errors . . . . . . . . . . . . . . . . . . . .

7-9

Microsoft Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Why Add Navigation Objects to Microsoft Office

7-10

Requirements? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7-10

Enable Linking from Microsoft Office Documents to

Simulink Objects . . . . . . . . . . . . . . . . . . . . . . . . . . .

7-10

Insert Navigation Objects in Microsoft Office

Requirements Documents . . . . . . . . . . . . . . . . . . . .

Customize Microsoft Office Navigation Objects . . . . . .

7-11

7-12

Navigate Between Microsoft Word Requirement and

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7-13

Navigate with Objects Created Using ActiveX in Microsoft

Office 2007 and 2010 . . . . . . . . . . . . . . . . . . . . . . . .

7-14

MATLAB Code Traceability

8

Link Between MATLAB Code Lines and Requirements

Information in External Documents . . . . . . . . . . . . . .

Create Link Using Context Menu Shortcuts . . . . . . . . .

Create Link Using Link Editor . . . . . . . . . . . . . . . . . . .

Enable or Disable Highlighting of Traceability Links for

MATLAB Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Enable Traceability Highlighting of MATLAB Code . . .

Disable Traceability Highlighting of MATLAB Code . . .

8-2

8-2

8-2

8-4

8-4

8-4

Remove Traceability Links from MATLAB Code Lines .

8-5

Delete Links to Requirements from MATLAB Code

Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Delete Link Targets in MATLAB Code Lines . . . . . . . .

8-5

8-5

Traceability for MATLAB Code Lines . . . . . . . . . . . . . . .

Traceability Link Targets . . . . . . . . . . . . . . . . . . . . . . .

Storage of Traceability Links . . . . . . . . . . . . . . . . . . . .

Limitations of MATLAB Code Traceability . . . . . . . . . .

8-6

8-6

8-6

8-7

Associate Traceability Information with MATLAB Code

Lines in Simulink . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8-8

xi

xii Contents

Custom Types of Requirements Documents

9

Why Create a Custom Link Type? . . . . . . . . . . . . . . . . . .

9-2

Implement Custom Link Types . . . . . . . . . . . . . . . . . . . .

9-3

Custom Link Type Functions . . . . . . . . . . . . . . . . . . . . . .

9-4

Links and Link Types . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Link Type Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9-5

9-6

Custom Link Type Registration . . . . . . . . . . . . . . . . . . .

9-10

Create a Custom Requirements Link Type . . . . . . . . . .

9-11

Create a Document Index . . . . . . . . . . . . . . . . . . . . . .

9-17

Custom Link Type Synchronization . . . . . . . . . . . . . . .

9-19

Navigate to Simulink Objects from External

Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Provide Unique Object Identifiers . . . . . . . . . . . . . . . .

Use the rmiobjnavigate Function . . . . . . . . . . . . . . . .

Determine the Navigation Command . . . . . . . . . . . . .

Use the ActiveX Navigation Control . . . . . . . . . . . . . .

9-20

9-20

9-20

9-20

9-21

Typical Code Sequence for Establishing Navigation

Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9-21

10

Requirements Information in Generated Code

How Requirements Information Is Included in

Generated Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Generate Code for Models with Requirements Links .

10-2

10-4

Model Component Testing

Overview of Component Verification

11

Component Verification . . . . . . . . . . . . . . . . . . . . . . . . .

Component Verification Approaches . . . . . . . . . . . . . .

Simulink Verification and Validation Tools for Component

Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11-2

11-2

11-2

Basic Approach to Component Verification . . . . . . . . .

Workflow for Component Verification . . . . . . . . . . . . .

Verify a Component Independently of the Container

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Verify a Model Block in the Context of the Container

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11-4

11-4

11-6

11-7

Functions for Component Verification . . . . . . . . . . . . .

11-8

Verifying Generated Code for a Component

12

Verify Generated Code for a Component . . . . . . . . . . .

12-2

About the Example Model . . . . . . . . . . . . . . . . . . . . . .

12-2

Prepare the Component for Verification . . . . . . . . . . .

Create and Log Test Cases . . . . . . . . . . . . . . . . . . . . .

Merge Test Case Data . . . . . . . . . . . . . . . . . . . . . . . . .

12-7

Record Coverage for Component . . . . . . . . . . . . . . . . .

Execute Component in Simulation Mode . . . . . . . . . . .

Execute Component in Software-in-the-Loop (SIL)

Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12-4

12-6

12-7

12-8

12-9

xiii

Signal Monitoring with Model Verification Blocks

Using Model Verification Blocks

13

Model Verification Blocks and the Verification

Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13-2

Use Check Static Lower Bound Block to Check for Out-

of-Bounds Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13-3

Linear System Modeling Blocks in Simulink Control

Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13-6

Constructing Simulation Tests Using the

Verification Manager

14

What Is the Verification Manager? . . . . . . . . . . . . . . . .

14-2

Construct Simulation Tests Using the Verification

Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14-3

View Model Verification Blocks . . . . . . . . . . . . . . . . . .

Enable and Disable Model Verification Blocks in a

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Enable and Disable Model Verification Blocks in a

14-3

14-9

Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Use Check Static Lower Bound Block to Check for Out-of-

Bounds Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Link Test Cases to Requirements Documents Using the

14-12

14-16

Verification Manager . . . . . . . . . . . . . . . . . . . . . . .

14-19

xiv Contents

Model Coverage Analysis

Model Coverage Definition

15

Model Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15-2

Types of Model Coverage . . . . . . . . . . . . . . . . . . . . . . . .

Cyclomatic Complexity . . . . . . . . . . . . . . . . . . . . . . . .

15-3

15-3

Condition Coverage (CC) . . . . . . . . . . . . . . . . . . . . . . .

15-4

Decision Coverage (DC) . . . . . . . . . . . . . . . . . . . . . . . .

15-4

Lookup Table Coverage . . . . . . . . . . . . . . . . . . . . . . . .

Modified Condition/Decision Coverage (MCDC) . . . . . .

15-4

15-5

Relational Boundary Coverage . . . . . . . . . . . . . . . . . .

15-6

Saturate on Integer Overflow Coverage . . . . . . . . . . . .

15-8

Signal Range Coverage . . . . . . . . . . . . . . . . . . . . . . . .

15-8

Signal Size Coverage . . . . . . . . . . . . . . . . . . . . . . . . . .

15-9

Simulink Design Verifier Coverage . . . . . . . . . . . . . . .

15-9

Simulink Optimizations and Model Coverage . . . . . .

Inline parameters . . . . . . . . . . . . . . . . . . . . . . . . . . .

Block reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conditional input branch execution . . . . . . . . . . . . . .

15-11

15-11

15-11

15-12

Model Objects That Receive Model Coverage

16

Model Objects That Receive Coverage . . . . . . . . . . . . .

Abs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Bias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Combinatorial Logic . . . . . . . . . . . . . . . . . . . . . . . . . .

Compare to Constant . . . . . . . . . . . . . . . . . . . . . . . . .

Compare to Zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Data Type Conversion . . . . . . . . . . . . . . . . . . . . . . . .

Dead Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Direct Lookup Table (n-D) . . . . . . . . . . . . . . . . . . . . .

16-11

Discrete Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16-11

16-2

16-7

16-8

16-8

16-9

16-9

16-10

16-10

xv

xvi Contents

Discrete FIR Filter . . . . . . . . . . . . . . . . . . . . . . . . . .

Discrete-Time Integrator . . . . . . . . . . . . . . . . . . . . . .

Discrete Transfer Fcn . . . . . . . . . . . . . . . . . . . . . . . .

Dot Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Enabled Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . .

Enabled and Triggered Subsystem . . . . . . . . . . . . . .

Fcn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

For Iterator, For Iterator Subsystem . . . . . . . . . . . . .

16-11

16-11

16-12

16-13

16-13

16-13

16-14

16-15

Gain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

If, If Action Subsystem . . . . . . . . . . . . . . . . . . . . . . .

16-15

16-16

Interpolation Using Prelookup . . . . . . . . . . . . . . . . . .

16-16

Library-Linked Objects . . . . . . . . . . . . . . . . . . . . . . .

16-17

16-17

16-18

16-18

Logical Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-D Lookup Table . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-D Lookup Table . . . . . . . . . . . . . . . . . . . . . . . . . . .

n-D Lookup Table . . . . . . . . . . . . . . . . . . . . . . . . . . .

16-19

Math Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16-20

MATLAB Function . . . . . . . . . . . . . . . . . . . . . . . . . .

MinMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16-20

16-20

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16-20

Multiport Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16-21

16-21

16-22

16-22

PID Controller, PID Controller (2 DOF) . . . . . . . . . .

Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Proof Assumption . . . . . . . . . . . . . . . . . . . . . . . . . . .

Proof Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Rate Limiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16-22

16-23

Relational Operator . . . . . . . . . . . . . . . . . . . . . . . . . .

16-23

Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C/C++ S-Function . . . . . . . . . . . . . . . . . . . . . . . . . . .

Saturation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Saturation Dynamic . . . . . . . . . . . . . . . . . . . . . . . . .

16-24

16-25

16-26

16-26

Simulink Design Verifier Functions in MATLAB Function

Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Sqrt, Signed Sqrt, Reciprocal Sqrt . . . . . . . . . . . . . . .

16-27

16-27

Sum, Add, Subtract, Sum of Elements . . . . . . . . . . . .

16-27

Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SwitchCase, SwitchCase Action Subsystem . . . . . . . .

Test Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16-27

16-28

Test Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16-28

16-29

Triggered Models . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16-29

Triggered Subsystem . . . . . . . . . . . . . . . . . . . . . . . . .

Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Unary Minus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Weighted Sample Time Math . . . . . . . . . . . . . . . . . .

16-30

16-31

16-31

16-31

While Iterator, While Iterator Subsystem . . . . . . . . .

Model Objects That Do Not Receive Coverage . . . . . .

16-31

16-33

Setting Model Coverage Options

17

Specify Model Coverage Options . . . . . . . . . . . . . . . . . .

Coverage Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Results Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Reporting Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17-2

17-2

17-6

17-8

Options Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17-12

Filter Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17-14

Cumulative Coverage Data . . . . . . . . . . . . . . . . . . . . . .

17-17

Coverage Collection During Simulation

18

Model Coverage Collection Workflow . . . . . . . . . . . . . .

Create and Run Test Cases . . . . . . . . . . . . . . . . . . . . . .

18-2

18-3

View Coverage Results in a Model . . . . . . . . . . . . . . . .

18-4

Overview of Model Coverage Highlighting . . . . . . . . . .

18-4

Enable Coverage Highlighting . . . . . . . . . . . . . . . . . . .

18-5

View Results in Coverage Display Window . . . . . . . . .

18-8

Model Coverage for Multiple Instances of a Referenced

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

About Coverage for Model Blocks . . . . . . . . . . . . . . .

Record Coverage for Multiple Instances of a Referenced

18-10

18-10

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18-10

Model Coverage for MATLAB Functions . . . . . . . . . .

About Model Coverage for MATLAB Functions . . . . .

Types of Model Coverage for MATLAB Functions . . .

18-20

18-20

18-20

xvii

xviii Contents

How to Collect Coverage for MATLAB Functions . . . .

18-22

Examples: Model Coverage for MATLAB Functions . .

18-23

Model Coverage for C and C++ S-Functions . . . . . . . .

Make S-Function Compatible with Model Coverage . .

Generate Coverage Report for S-Function . . . . . . . . .

View Coverage Results for C/C++ Code in S-Function

Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18-37

18-37

18-38

18-41

Model Coverage for Stateflow Charts . . . . . . . . . . . . .

How Model Coverage Reports Work for Stateflow

Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Specify Coverage Report Settings . . . . . . . . . . . . . . .

Cyclomatic Complexity . . . . . . . . . . . . . . . . . . . . . . .

Decision Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . .

Condition Coverage . . . . . . . . . . . . . . . . . . . . . . . . . .

MCDC Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Relational Boundary Coverage . . . . . . . . . . . . . . . . .

Simulink Design Verifier Coverage . . . . . . . . . . . . . .

Model Coverage Reports for Stateflow Charts . . . . . .

Model Coverage for Stateflow State Transition Tables

Model Coverage for Stateflow Atomic Subcharts . . . .

Model Coverage for Stateflow Truth Tables . . . . . . . .

Colored Stateflow Chart Coverage Display . . . . . . . .

18-45

18-45

18-46

18-46

18-47

18-50

18-51

18-51

18-51

18-53

18-62

18-63

18-66

18-71

Results Review

19

Types of Coverage Reports . . . . . . . . . . . . . . . . . . . . . . .

19-2

Model Summary Report . . . . . . . . . . . . . . . . . . . . . . .

Model Reference Coverage Report . . . . . . . . . . . . . . . .

External MATLAB File Coverage Report . . . . . . . . . . .

19-5

Subsystem Coverage Report . . . . . . . . . . . . . . . . . . . .

Code Coverage Report . . . . . . . . . . . . . . . . . . . . . . . .

19-3

19-4

19-9

19-11

Top-Level Model Coverage Report . . . . . . . . . . . . . . .

Coverage Summary . . . . . . . . . . . . . . . . . . . . . . . . . .

Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Cyclomatic Complexity . . . . . . . . . . . . . . . . . . . . . . .

19-12

19-12

19-14

19-22

Decisions Analyzed . . . . . . . . . . . . . . . . . . . . . . . . . .

Conditions Analyzed . . . . . . . . . . . . . . . . . . . . . . . . .

MCDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Cumulative Coverage . . . . . . . . . . . . . . . . . . . . . . . .

Relational Boundary . . . . . . . . . . . . . . . . . . . . . . . . .

Saturate on Integer Overflow Analysis . . . . . . . . . . .

19-24

19-25

19-26

19-27

N-Dimensional Lookup Table . . . . . . . . . . . . . . . . . .

19-30

Block Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19-36

Signal Range Analysis . . . . . . . . . . . . . . . . . . . . . . . .

19-42

Signal Size Coverage for Variable-Dimension Signals

Simulink Design Verifier Coverage . . . . . . . . . . . . . .

19-37

19-41

19-44

19-45

Export Model Coverage Web View . . . . . . . . . . . . . . . .

19-47

Excluding Model Objects From Coverage

20

Coverage Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20-2

What Is Coverage Filtering? . . . . . . . . . . . . . . . . . . . .

When to Use Coverage Filtering . . . . . . . . . . . . . . . . .

20-2

20-2

Coverage Filter Rules and Files . . . . . . . . . . . . . . . . . .

What Is a Coverage Filter Rule? . . . . . . . . . . . . . . . . .

What Is a Coverage Filter File? . . . . . . . . . . . . . . . . .

20-3

20-3

20-3

Model Objects to Filter from Coverage . . . . . . . . . . . . .

20-4

Create, Edit, and View Coverage Filter Rules . . . . . . .

Create and Edit Coverage Filter Rules . . . . . . . . . . . .

20-5

20-5

Save Coverage Filter to File . . . . . . . . . . . . . . . . . . . .

20-8

Attach Coverage Filter File to Model . . . . . . . . . . . . . .

20-8

View Coverage Filter Rules in Your Model . . . . . . . . .

Remove Coverage Filter Rules . . . . . . . . . . . . . . . . . .

20-8

20-9

Coverage Filter Viewer . . . . . . . . . . . . . . . . . . . . . . . . .

20-10

Filter Model Objects to Refine Coverage Results . . . .

20-12

About the Example Model . . . . . . . . . . . . . . . . . . . . .

Simulate Example Model and Review Coverage . . . . .

20-12

Filter a Stateflow Transition . . . . . . . . . . . . . . . . . . .

20-12

20-13

xix

Filter a Stateflow Event . . . . . . . . . . . . . . . . . . . . . .

20-15

Filter Library Reference Blocks . . . . . . . . . . . . . . . . .

20-19

Filter a Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . .

Filter a Specific Block . . . . . . . . . . . . . . . . . . . . . . . .

20-20

20-21

Automating Model Coverage Tasks

21

Commands for Automating Model Coverage Tasks . . .

Create Tests with cvtest . . . . . . . . . . . . . . . . . . . . . . . . .

21-2

21-3

Run Tests with cvsim . . . . . . . . . . . . . . . . . . . . . . . . . . .

21-5

Retrieve Coverage Details from Results . . . . . . . . . . . .

21-7

Obtain Cumulative Coverage for Reusable Subsystems

and Stateflow® Constructs . . . . . . . . . . . . . . . . . . . . .

Create HTML Reports with cvhtml . . . . . . . . . . . . . . .

Save Test Runs to File with cvsave . . . . . . . . . . . . . . .

Load Stored Coverage Test Results with cvload . . . .

cvload Special Considerations . . . . . . . . . . . . . . . . . .

Use Coverage Commands in a Script . . . . . . . . . . . . .

21-8

21-11

21-12

21-13

21-13

21-14

Checking Systems with the Model Advisor

Checking Systems Interactively

22

Check Model and Subsystems . . . . . . . . . . . . . . . . . . . .

22-2

xx Contents

Limit Model Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22-3

What Is a Model Advisor Exclusion? . . . . . . . . . . . . . .

22-3

Model Advisor Exclusion Files . . . . . . . . . . . . . . . . . . .

22-3

Create Model Advisor Exclusions . . . . . . . . . . . . . . . .

Review Model Advisor Exclusions . . . . . . . . . . . . . . . .

Manage Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . .

22-4

22-6

22-7

Limit Model Checks By Excluding Gain and Outport

Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Model Checks for DO-178C/DO-331 Standard

Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22-11

22-16

Model Checks for IEC 61508, ISO 26262, and EN 50128

Standard Compliance . . . . . . . . . . . . . . . . . . . . . . . .

Model Checks for MathWorks Automotive Advisory

Board (MAAB) Guideline Compliance . . . . . . . . . . .

Model Checks for Requirements Links . . . . . . . . . . . .

22-20

22-23

22-28

Check Systems Programmatically

23

Checking Systems Programmatically . . . . . . . . . . . . . .

23-2

Finding Check IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23-3

Create a Function for Checking Multiple Systems . . .

23-4

Check Multiple Systems in Parallel . . . . . . . . . . . . . . .

Create a Function for Checking Multiple Systems in

Parallel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23-6

23-7

Archive and View Results . . . . . . . . . . . . . . . . . . . . . . . .

23-9

Archive Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23-9

View Results in Command Window . . . . . . . . . . . . . . .

23-9

View Results in Model Advisor Command-Line Summary

Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23-10

xxi

View Results in Model Advisor GUI . . . . . . . . . . . . .

View Model Advisor Report . . . . . . . . . . . . . . . . . . . .

23-11

23-12

Archive and View Model Advisor Run Results . . . . . .

23-13

Customizing the Model Advisor

Overview of Customizing the Model Advisor

24

Model Advisor Customization . . . . . . . . . . . . . . . . . . . .

Requirements for Customizing the Model Advisor . . . .

24-2

24-2

Create Model Advisor Checks

25

Create Model Advisor Checks Workflow . . . . . . . . . . . .

25-2

Customization File Overview . . . . . . . . . . . . . . . . . . . . .

25-3

Quick Start Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .

25-6

Add Customized Check to By Product Folder . . . . . . . .

25-6

Create Customized Pass/Fail Check . . . . . . . . . . . . . .

Create Customized Pass/Fail Check with Fix Action .

25-7

25-11

Create Check for Model Configuration Parameters .

Create Data File for Diagnostics Pane Configuration

25-16

Parameter Check . . . . . . . . . . . . . . . . . . . . . . . . . .

25-17

Create Check for Diagnostics Pane Model Configuration

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Data File for Configuration Parameter Check . . . . . .

25-19

25-22

Register Checks and Process Callbacks . . . . . . . . . . .

Create sl_customization Function . . . . . . . . . . . . . . .

25-27

25-27

xxii Contents

Register Checks and Process Callbacks . . . . . . . . . . .

Define Startup and Post-Execution Actions Using Process

Callback Functions . . . . . . . . . . . . . . . . . . . . . . . .

25-27

25-28

Define Custom Checks . . . . . . . . . . . . . . . . . . . . . . . . .

About Custom Checks . . . . . . . . . . . . . . . . . . . . . . . .

Contents of Check Definitions . . . . . . . . . . . . . . . . . .

Display and Enable Checks . . . . . . . . . . . . . . . . . . . .

25-30

25-30

25-30

25-32

Define Where Custom Checks Appear . . . . . . . . . . . .

25-33

Check Definition Function . . . . . . . . . . . . . . . . . . . . .

25-34

Define Check Input Parameters . . . . . . . . . . . . . . . .

25-34

Define Model Advisor Result Explorer Views . . . . . . .

25-35

Define Check Actions . . . . . . . . . . . . . . . . . . . . . . . .

25-36

Create Callback Functions and Results . . . . . . . . . . .

About Callback Functions . . . . . . . . . . . . . . . . . . . . .

Common Utilities for Authoring Checks . . . . . . . . . .

Simple Check Callback Function . . . . . . . . . . . . . . . .

25-37

25-37

25-37

25-38

Detailed Check Callback Function . . . . . . . . . . . . . . .

25-39

Check Callback Function with Hyperlinked Results .

Action Callback Function . . . . . . . . . . . . . . . . . . . . .

Format Model Advisor Results . . . . . . . . . . . . . . . . .

25-40

25-43

25-44

Exclude Blocks From Custom Checks . . . . . . . . . . . . .

25-49

Model Advisor Code Examples . . . . . . . . . . . . . . . . . . .

25-52

Register Custom Checks and Process Callbacks . . . . .

25-52

Process Callback Function . . . . . . . . . . . . . . . . . . . . .

25-52

Input Parameter Definition . . . . . . . . . . . . . . . . . . . .

List View Definition . . . . . . . . . . . . . . . . . . . . . . . . .

Action Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Informational Check Callback Function . . . . . . . . . .

Basic Check with Pass/Fail Status . . . . . . . . . . . . . .

Check With Subchecks and Actions . . . . . . . . . . . . . .

Action Callback Function . . . . . . . . . . . . . . . . . . . . .

25-53

25-54

25-55

25-56

25-58

25-60

25-62

xxiii

xxiv Contents

Create Custom Configurations by Organizing

Checks and Folders

26

Create Custom Configurations . . . . . . . . . . . . . . . . . . . .

26-2

Create Configurations by Organizing Checks and

Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26-3

Create Procedural-Based Configurations . . . . . . . . . . .

26-4

Organize Checks and Folders Using the Model Advisor

Configuration Editor . . . . . . . . . . . . . . . . . . . . . . . . . .

26-5

Overview of the Model Advisor Configuration Editor . .

Start the Model Advisor Configuration Editor . . . . . . .

26-5

26-9

Organize Checks and Folders Using the Model Advisor

Configuration Editor . . . . . . . . . . . . . . . . . . . . . . .

26-10

Organize Customization File Checks and Folders . . .

26-12

Customization File Overview . . . . . . . . . . . . . . . . . . .

26-12

Register Tasks and Folders . . . . . . . . . . . . . . . . . . . .

Define Custom Tasks . . . . . . . . . . . . . . . . . . . . . . . .

26-13

26-14

Define Custom Folders . . . . . . . . . . . . . . . . . . . . . . .

26-16

Customization Example . . . . . . . . . . . . . . . . . . . . . . .

26-17

Verify and Use Custom Configurations . . . . . . . . . . . .

26-18

Update the Environment to Include Your sl_customization

File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Verify Custom Configurations . . . . . . . . . . . . . . . . . .

26-18

26-18

Model Advisor Code Examples . . . . . . . . . . . . . . . . . . .

26-20

Register Custom Tasks and Folders . . . . . . . . . . . . .

Task Definition Function . . . . . . . . . . . . . . . . . . . . . .

26-20

Group Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26-20

26-21

Create Procedural-Based Model Advisor

Configurations

27

Create Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

What Is a Procedure? . . . . . . . . . . . . . . . . . . . . . . . . .

Create Procedures Using the Procedures API . . . . . . .

Define Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Create a Procedural-Based Configuration . . . . . . . . . .

27-2

27-2

27-2

27-2

27-5

Deploy Custom Configurations

28

Overview of Deploying Custom Configurations . . . . . .

28-2

About Deploying Custom Configurations . . . . . . . . . . .

28-2

Deploying Custom Configurations Workflow . . . . . . . .

28-2

How to Deploy Custom Configurations . . . . . . . . . . . . .

28-3

Manually Load and Set the Default Configuration . . .

Automatically Load and Set the Default

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28-4

28-5

xxv

Getting Started

• “Simulink Verification and Validation Product Description” on page 1-2

• “System Requirements” on page 1-3

1

1

Getting Started

Simulink Verification and Validation Product Description

Verify models and generated code

Simulink Verification and Validation automates requirements tracing, modeling standards compliance checking, and model coverage analysis.

You can create detailed requirements traceability reports, author your own modeling style checks, and develop check configurations to share with engineering teams.

Requirements documentation can be linked to models, test cases, and generated code.

You can generate harness models for testing model components and code, and use model coverage analysis to ensure that models have been thoroughly tested.

Simulink Verification and Validation provides modeling standards checks for the

DO-178, ISO 26262, IEC 61508 and related industry standards.

Key Features

• Compliance checking for MAAB style guidelines and high-integrity system design guidelines (DO-178, ISO 26262, IEC-61508, and related industry standards)

• Model Advisor Configuration Editor, including custom check authoring

• Requirements Management Interface for traceability of model objects, code, and tests to requirements documents

• Automatic test-harness generation for subsystems

• Component testing via simulation, software-in-the-loop (SIL), and processor-in-theloop (PIL)

• Programmable scripting interface for automating compliance checking, requirements traceability analysis, and component testing

1-2

System Requirements

System Requirements

In this section...

“Operating System Requirements” on page 1-3

“Product Requirements” on page 1-3

Operating System Requirements

The Simulink Verification and Validation software works with the following operating systems:

• Microsoft ® Windows ® XP, Windows Vista™, and Windows 7

• UNIX ® systems (Requirements linking to HTML and TXT documents only)

Product Requirements

The Simulink Verification and Validation software requires the following MathWorks ® products:

• MATLAB ®

• Simulink

If you want to use the Requirements Management Interface with Stateflow product:

® charts, the Simulink Verification and Validation software requires the following MathWorks

• Stateflow

The Requirements Management Interface in the Simulink Verification and Validation software allows you to associate requirements with Simulink models and Stateflow charts. The software supports the following applications for documenting requirements:

• Microsoft Word 2003 or later

• Microsoft Excel ® 2003 or later

• IBM ® Rational ® DOORS ® 6.0 or later

• Adobe ® PDF

1-3

Requirements Traceability

2

Links Between Models and

Requirements

• “Overview of the Requirements Management Interface (RMI)” on page 2-3

• “Requirements Traceability Links” on page 2-4

• “Requirements Link Storage” on page 2-5

• “Supported Requirements Document Types” on page 2-6

• “Supported Model Objects for Requirements Linking” on page 2-9

• “Selection-Based Linking” on page 2-10

• “Link to Requirements Document Using Selection-Based Linking” on page 2-11

• “Configure RMI for IBM Rational DOORS or Microsoft ActiveX Navigation” on page

2-12

• “Requirements Traceability Link Editor” on page 2-13

• “Requirements Settings” on page 2-16

• “Link Model Objects” on page 2-18

• “Link from External Applications” on page 2-20

• “Link Multiple Model Objects to a Requirements Document” on page 2-21

• “Link to Requirements in Microsoft Word Documents” on page 2-26

• “Link to Requirements in IBM Rational DOORS Databases” on page 2-32

• “Link to Requirements in Microsoft Excel Workbooks” on page 2-34

• “Link to Requirements in MuPAD Notebooks” on page 2-39

• “Create Requirements Traceability Report for Model” on page 2-42

• “Link to Requirements Modeled in Simulink” on page 2-44

• “Requirements Linking with Simulink Annotations” on page 2-53

• “Link Signal Builder Blocks to Requirements Documents” on page 2-54

• “Link Signal Builder Blocks to Model Objects” on page 2-56

2

Links Between Models and Requirements

• “Link Requirements to Simulink Data Dictionary Entries” on page 2-58

2-2

Overview of the Requirements Management Interface (RMI)

Overview of the Requirements Management Interface (RMI)

If you want to link Simulink and Stateflow objects to requirements, including external documents, verification objects, or tests, use the RMI to:

• Associate Simulink and Stateflow objects with requirements.

• Create links between Simulink and Stateflow model objects.

• Navigate from a Simulink or Stateflow object to requirements.

• Navigate from an embedded link in a requirements document to the corresponding

Simulink or Stateflow object.

• Review requirements links in your model using highlighting and tags that you define.

• Create reports for your Simulink model that show which objects link to which requirements.

2-3

2

Links Between Models and Requirements

Requirements Traceability Links

When you want to navigate from a Simulink model or from a region of MATLAB code to a location inside a requirements document, you can add requirements traceability links to the model or code.

Requirements traceability links have the following attributes:

• A description of up to 255 characters.

• A requirements document path name, such as a Microsoft Word file or a module in an IBM Rational DOORS database. (The RMI supports several built-in document formats. You can also register custom types of requirements documents. See

“Supported Requirements Document Types” on page 2-6.)

• A designated location inside the requirements document, such as:

• Bookmark

• Anchor

• ID

• Page number

• Line number

• Cell range

• Link target

• Tags that you define

2-4

Requirements Link Storage

Requirements Link Storage

When you create links from a model to external requirements, by default, the

Requirements Management Interface (RMI) stores the information about the links internally in the model file. When links are stored with the model, each time you change requirements links, the time stamp and version number of the model changes.

If you do not want to modify your model when creating or modifying requirements links, use external storage for requirements links. External storage is a mechanism for saving information about linked requirements in a file that is separate from the model file. The

RMI saves information about the requirements links in a file that, by default, is named

model_name.req

and is saved in the same folder as the model.

When you use external storage for requirements links, no changes are made to the model file when you modify the requirements links.

For more information on external storage of requirements links data, see “External

Storage” and “Guidelines for External Storage of Requirements Links”.

2-5

2

Links Between Models and Requirements

Supported Requirements Document Types

The Requirements Management Interface (RMI) supports linking with external documents of the types listed in the table below. For each supported requirements document type, the table lists the options for requirements locations within the document.

If you would like to implement linking with a requirements document of a type that is not listed in the table below, you can register a custom requirements document type with the RMI. For more information, see “Create a Custom Requirements Link Type”.

Requirements

Document Type

Microsoft Word

2003 or later

Microsoft Excel

2003 or later

Location Options

• Named item — A bookmark name. The RMI links to the location of that bookmark in the document. The most stable location identifier because the link is maintained when the target content is modified or moved.

• Search text — A search string. The RMI links to the first occurrence of that string in the document. This search is not case sensitive.

• Page/item number — A page number. The RMI links to the top of the specified page.

• Named item — A named range of cells. The RMI links to that named item in the workbook. The most stable location identifier because the link is maintained when the target content is modified or moved.

• Search text — A search string. The RMI links to the first occurrence of that string in the workbook. This search is not case sensitive.

• Sheet range — A cell location in a workbook:

• Cell number (A1, C13)

• Range of cells (C5:D7)

• Range of cells on another worksheet (Sheet1!A1:B4)

The RMI links to that cell or cells.

2-6

Supported Requirements Document Types

Requirements

Document Type

IBM Rational

DOORS

MuPAD

Simulink

DocBlock block

(RTF format only)

Text

HTML

Location Options

Page/item number

Named item

— The unique numeric ID of the target

DOORS object. The RMI links to that object.

— The name of a link target in a MuPAD notebook.

Create links to the RTF file associated with the DocBlock block to a

Microsoft Word file:

• Search text — A search string. The RMI links to the first occurrence of that string in the document. This search is not case sensitive.

• Named item — A bookmark name. The RMI links to the location of that bookmark in the document.

• Page/item number — A page number. The RMI links to the top of that page.

• Search text — A search string. The RMI links to the first occurrence of that string within the document. This search is not case sensitive.

• Line number — A line number. The RMI links to the beginning of that line.

You can link only to a named anchor.

For example, in your HTML requirements document, if you define the anchor

<A NAME=valve_timing> ...contents... </A> in the Location field, enter valve_timing or, from the document index, choose the anchor name.

Select the Document Index tab in the “Requirements Traceability

Link Editor” to see available anchors in an HTML file.

2-7

2

Links Between Models and Requirements

Requirements

Document Type

Location Options

Web browser URL The RMI can link to a URL location. In the Document field, type the URL string. When you click the link, the document opens in a

Web browser:

PDF

• Named item — An anchor name. The RMI links to that location on the Web page at that URL.

• Named item — A bookmark name. The RMI links to the location of that bookmark in the document. Not fully supported, depends on the platform and bookmark type.

• Page/item number — A page number. The RMI links to the top of that page.

Note: The RMI cannot create a document index of bookmarks in

PDF files.

2-8

Supported Model Objects for Requirements Linking

Supported Model Objects for Requirements Linking

You can associate requirements links between the following types of Simulink model objects:

• Simulink block diagrams and subsystems

• Simulink blocks and annotations

• Simulink data dictionary entries

• Signal Builder signal groups

• Stateflow charts, subcharts, states, transitions, and boxes

• Stateflow functions

• Lines of MATLAB code

• Simulink Test™ test manager test cases

2-9

2

Links Between Models and Requirements

Selection-Based Linking

You can use selection-based linking to create links from a model object to another model object or to an object in a requirements document. Selection-based linking is the easiest way to create requirements links from a model to an external document.

For examples of selection-based linking, see “Link to Requirements Document Using

Selection-Based Linking” on page 2-11 and “Link Multiple Model Objects to a

Requirements Document” on page 2-21.

2-10

Link to Requirements Document Using Selection-Based Linking

Link to Requirements Document Using Selection-Based Linking

To create a link from a model to a requirements document, using selection-based linking:

1 In the requirements document, select text or objects to link to.

2 Right-click the model object. Select Requirements Traceability and then the option that corresponds to one of the types for which selection-based linking is available:

Link to Selection in MATLAB

Link to Selection in Word

Link to Selection in Excel

Link to Selection in DOORS

Select for Linking with Simulink

2-11

2

Links Between Models and Requirements

Configure RMI for IBM Rational DOORS or Microsoft ActiveX

Navigation

To use the features of the Requirements Management Interface (RMI), you must communicate with external software products such as Microsoft Office and IBM Rational

DOORS.

Initial configuration steps are required to setup the RMI if you need to:

• Use the RMI with DOORS applications (PC only).

• Use ActiveX ® controls for navigation from Microsoft Office documents to Simulink models. You might need to register ActiveX controls when you work with existing requirements documents (PC only).

You can setup the initial configuration for both cases by running this command: rmi setup

If you do not have DOORS installed on your system, the rmi setup command does not install the DOORS API.

If the rmi setup command fails to detect a DOORS installation on your system, and you know that the DOORS software is installed, enter the following command: rmi setup doors

This command prompts you to enter the path to your DOORS installation, and then installs the required files.

2-12

Requirements Traceability Link Editor

Requirements Traceability Link Editor

In this section...

“Manage Requirements Traceability Links Using Link Editor” on page 2-13

“Requirements Tab” on page 2-15

“Document Index Tab” on page 2-15

Manage Requirements Traceability Links Using Link Editor

You can create, edit, and delete requirements traceability links using the Link Editor. To open the Link Editor:

• in the Simulink Editor, right-click on a model object that has a requirements traceability link. From the context menu, select Requirements Traceability >

Open Link Editor.

• in the MATLAB Editor, right-click inside a region of code that has a requirements traceability link. From the context menu, select Requirements Traceability >

Open Link Editor.

The Link Editor opens, as shown below.

2-13

2

Links Between Models and Requirements

2-14

In the Link Editor, you can:

• Create requirements links from one or more Simulink model objects or MATLAB code lines.

• Customize information about requirements links, including specifying user tags to filter requirements highlighting and reporting.

• Delete existing requirements links.

• Modify the stored order of requirements to control the order of labels in context menus for linked objects.

Requirements Traceability Link Editor

Requirements Tab

On the Requirements tab, you specify detailed information about the link, including:

• Description of the requirement (up to 255 words). If you create a link using the document index, unless a description already exists, the name of the index location becomes the description for the link .

• Path name to the requirements document.

• Document type (Microsoft Word, Microsoft Excel, IBM Rational DOORS, MuPAD,

HTML, text file, etc.).

• Location of the requirement (search text, named location, or page or item number).

• User-specified tag or keyword.

Document Index Tab

The Document Index tab is available only if you have specified a file in the Document field on the Requirements tab that supports indexing. On the Document Index tab, the RMI generates a list of locations in the specified requirements document for the following types of requirements documents:

• Microsoft Word

• IBM Rational DOORS

• HTML files

• MuPAD

Note: The RMI cannot create document indexes for PDF files.

From the document index, select the desired requirement from the document index and click OK. Unless a description already exists, the name of the index location becomes the description for the link.

If you make any changes to your requirements document, to load any newly created locations into the document index, you must click Refresh. During a MATLAB session, the RMI does not reload the document index unless you click the Refresh button.

2-15

2

Links Between Models and Requirements

Requirements Settings

You can manage your RMI preferences in the Requirements Settings dialog box.

These settings are global and not associated with any particular model. To open the Requirements Settings dialog box, from the Simulink Editor, select Analysis >

Requirements Traceability > Settings. In this dialog box, you can select the:

Storage tab to set the default way in which the RMI stores requirements links in a model. For storage information, see “Specify Storage for Requirements Links”.

Selection Linking tab to set the options for linking to the active selection in a supported document. For setting information, see “Selection Linking Tab”.

Filters tab to set the options for filtering requirements in a model. For filtering information, see “Configure Requirements Filtering”.

Report tab to customize the requirements report without using the Report

Generator. For setting information, see “Customize Requirements Report Using the

RMI Settings”.

Selection Linking Tab

In the Requirements Settings dialog box, on the Selection Linking tab, are the following options for linking to the active selection in a supported document. To open the

Requirements Settings dialog box, select Analysis > Requirements Traceability >

Settings.

Options Description

For linking to the active selection within an external document:

Enabled applications

Document file reference

Enable selection-based linking shortcuts to

Microsoft Word, Microsoft Excel, or DOORS applications.

Select type of file reference. For information on what settings to use, see

“Document Path Storage” on page 5-15.

Apply this user tag to new links Enter text to attach to the links you create.

For more information about user tags, see

“Filter Requirements with User Tags” on page 4-25

When creating selection-based links:

2-16

Requirements Settings

Options

Modify destination for bi-directional linking

Store absolute path to model file

Use custom bitmap for navigation controls in documents

Use ActiveX buttons in Word and

Excel (backward compatibility)

Description

Creates links both to and from selected link destination.

Select type of file reference. For

information, see “Document Path Storage” on page 5-15.

Select and browse for your bitmap. You can use your own bitmap file to control the appearance of navigation links in your document.

Select to use legacy ActiveX controls to create links in Microsoft Word and

Microsoft Excel applications. By default, if not selected, you create URL-based links.

2-17

2

Links Between Models and Requirements

Link Model Objects

In this section...

“Link Objects in the Same Model” on page 2-18

“Link Objects in Different Models” on page 2-18

Link Objects in the Same Model

You can create a requirements link from one model object to another model object:

1 Right-click the link destination model object and select Requirements

Traceability > Select for Linking with Simulink.

2 Right-click the link source model object and select Requirements Traceability >

Add Link to Selected Object.

3 Right-click the link source model object again and select Requirements

Traceability. The new link appears at the top of the Requirements Traceability submenu.

Link Objects in Different Models

You can create links between objects in related models. This example shows how to link model objects in slvnvdemo_powerwindow_controller and slvnvdemo_powerwindow

.

1

Open the slvnvdemo_powerwindow_controller and slvnvdemo_powerwindow models.

2 In the slvnvdemo_powerwindow model window, doubleclick the power_window_control_system subsystem. The power_window_control_system

subsystem opens.

3

In the slvnvdemo_powerwindow/power_window_control_system subsystem window, right-click the control subsystem. Select Requirements Traceability >

Select for Linking with Simulink.

4 In the slvnvdemo_powerwindow_controller model window, right-click the control

subsystem. Select Requirements Traceability > Add Link to Selected

Object.

2-18

Link Model Objects

5 Right-click the slvnvdemo_powerwindow_controller/control subsystem and select Requirements Traceability. The new RMI link appears at the top of the

Requirements Traceability submenu.

6 To verify that the links were created, in the slvnvdemo_powerwindow_controller

model window, select Analysis >

Requirements Traceability > Highlight Model.

The blocks with requirements links are highlighted.

7

Close the slvnvdemo_powerwindow_controller and slvnvdemo_powerwindow models.

2-19

2

Links Between Models and Requirements

Link from External Applications

You can navigate to Simulink objects or MATLAB code with requirements using the internal MATLAB HTTP server.

To get the URL for an object in your model, right-click the object and select

Requirements Traceability > Copy URL to Clipboard. Note that if your model stores requirements traceability data internally, when you select Requirements

Traceability > Copy URL to Clipboard, the Requirements Management Interface

(RMI) creates a unique identifier in the model file. To enable navigation with the URL that you copied, resave your model. To use URLs that do not require changes to your model, configure your model for external storage of requirements traceability data. For more information, see “Move Internally Stored Requirements Links to External Storage”.

To get the URL for a line or lines of MATLAB code, in the MATLAB Editor, select the region of code you want to link to and right-click. From the context menu, select

Requirements Traceability > Copy Link to Clipboard.

You can then paste the URL into an external application and use it to navigate back to the corresponding object in your model.

To enable navigation with these links, the internal MATLAB HTTP server must be activated on your local host. Selecting Requirements Traceability > Copy URL

to Clipboard activates the internal HTTP server. You can also enter the command rmi('httpLink')

at the MATLAB command prompt to activate the internal HTTP server.

2-20

Link Multiple Model Objects to a Requirements Document

Link Multiple Model Objects to a Requirements Document

You can link multiple Simulink and Stateflow objects to a requirement. The workflow is:

1 In the requirements document, select the requirement.

2 In the Simulink Editor or Stateflow Editor, select the objects to link to the selected requirement. You can select multiple objects by holding down the Shift key while you click each object that you want to select. Note that you can only select multiple objects in the same diagram.

3 Right-click one of the selected objects to open the context menu and hover over

Requirements Traceability.

4

Select one of the selection-based linking options:

Link to Selection in MATLAB

Link to Selection in Word

2-21

2

Links Between Models and Requirements

Link to Selection in Excel

Link to Selection in DOORS

5 You can also add and edit links for multiple objects using the Requirements

Traceability Link Editor. To open the Link Editor, in the Requirements

Traceability context menu, select Add Links to All.

2-22

Link Multiple Model Objects to a Requirements Document

2-23

2

Links Between Models and Requirements

2-24

Link Multiple Model Objects to a Requirement Document Using a Simulink

DocBlock

This example shows how to link multiple model objects to a requirement document using a DocBlock.

You can minimize the number of links to the external requirements document by using a DocBlock in the model. You can insert aDocBlock at the top level of the model and link your external requirements document to it. Then you can link the DocBlock to all objects in the model that are relevant to the requirement in the external document.

1 Open the example model: slvnvdemo_fuelsys_officereq

2

Open a requirements document associated with that model: rmi('view','slvnvdemo_fuelsys_officereq',1);

3 Insert a Simulink DocBlock into the model.

4 Right-click DocBlock and select Mask Parameters. The Block Parameters:

DocBlock dialog box opens.

5

In the Block Parameters: DocBlock dialog box Document type drop-down list, select

RTF

.

6 Click Apply or OK to create the link.

7 In slvnvdemo_FuelSys_DesignDescription.docx, find and select the section titled 2.2 Determination of pumping efficiency.

8

In the slvnvdemo_fuelsys_officereq model window, right-click the DocBlock and select Requirements Traceability > Link to Selection in Word.

The RMI inserts a bookmark at that location in the requirements document.

9 In the slvnvdemo_fuelsys_officereq model window, right-click the DocBlock and select Requirements Traceability > Select for Linking with Simulink.

10

In the slvnvdemo_fuelsys_officereq/fuel rate controller subsystem window, select the control logic chart and the Airflow calculation subsystems. Use the shift key to select both.

11 Right-click the Airflow calculation subsystem and select Requirements

Traceability > Add Link to Selected Object.

12 In the slvnvdemo_fuelsys_officereq model window, select DocBlock, rightclick, and select Requirements Traceability.

Link Multiple Model Objects to a Requirements Document

The link to the new requirements are on the top menu option.

13 To verify that the links were created, select Analysis > Requirements

Traceability > Highlight Model.

The DocBlock, control logic chart, and Airflow calculation subsystem are highlighted.

14 Close the slvnvdemo_fuelsys_officereq model and the slvnvdemo_FuelSys_DesignDescription.docx

requirements document.

2-25

2

Links Between Models and Requirements

Link to Requirements in Microsoft Word Documents

In this section...

“Create Bookmarks in a Microsoft Word Requirements Document” on page 2-26

“Open the Example Model and Associated Requirements Document” on page 2-28

“Create a Link from a Model Object to a Microsoft Word Requirements Document” on page 2-28

Create Bookmarks in a Microsoft Word Requirements Document

You can create bookmarks in your Microsoft Word requirements documents to identify the requirements that you want to link to. When you create the links, you specify that the RMI must link to an existing bookmark, rather than create a new bookmark.

This approach offers advantages to creating new bookmarks:

• You can give the bookmarks meaningful names that represent the content of the requirement.

• When the RMI creates the links, it does not modify your requirements document.

Note: When you link to an existing bookmark, navigating the link highlights the entire range of the existing bookmark. Therefore, when you create a bookmark for requirement linking, make sure to select only the document information relevant to your requirement.

If you have a requirements document containing bookmarks, follow these steps to create requirements links from your Simulink model to the bookmarks:

1 Open your model.

2 Open your Microsoft Word requirements document that contains bookmarks that identify requirements.

3

Right-click a block in the model that you want to link to a requirement and select

Requirements Traceability > Open Link Editor

The Requirements Traceability Link Editor opens.

4 Click New.

5

Click Browse and navigate to the Microsoft Word requirements document that has bookmarks.

2-26

Link to Requirements in Microsoft Word Documents

6 Open the document. The RMI populates the Document and Document type fields.

7

Click the Document Index tab of the Link Editor.

The Document Index tab lists all bookmarks in the requirements document, as well as all section headings (text that you have styled as Heading 1, Heading 2, and so on).

The document index lists the bookmarks in alphabetical order, not in order of location within the document.

2-27

2

Links Between Models and Requirements

2-28

8 Select the bookmark that you want to link the block to and click OK.

The RMI creates a link from the block to the location of the bookmark in the requirements document without modifying the document itself.

Open the Example Model and Associated Requirements Document

This example describes how to create links from objects in a Simulink model to selected requirements text in a Microsoft Word document.

Navigate from the model to the requirements document:

1

Open the example model: slvnvdemo_fuelsys_officereq

2 Open a requirements document associated with that model: rmi('view','slvnvdemo_fuelsys_officereq',1);

Keep the example model and the requirements document open.

Create a Link from a Model Object to a Microsoft Word Requirements

Document

Create a link from the Airflow calculation subsystem in the slvnvdemo_fuelsys_officereq

model to selected text in the requirements document:

1

In slvnvdemo_FuelSys_DesignDescription.docx, find the section titled 2.2

Determination of pumping efficiency.

2 Select the header text.

3 Open the example model: slvnvdemo_fuelsys_officereq

4 Select Analysis > Requirements Traceability > Settings. The Requirements

Settings dialog box opens.

5

On the Selection Linking tab of the Requirements Settings dialog box:

• Set the Document file reference option to path relative to model folder

.

Link to Requirements in Microsoft Word Documents

• Enable Modify destination for bi-directional linking.

When you select this option, every time you create a selection-based link from a model object to a requirement, the RMI inserts navigation objects at the designated location.

For more information about the settings, see “Requirements Settings” on page 2-16.

6

Double-click the fuel rate controller subsystem to open it.

7 Open the Airflow calculation subsystem.

8

Right-click the Pumping Constant block and select Requirements Traceability >

Link to Selection in Word.

The RMI inserts a bookmark at that location in the requirements document and assigns it a generic name, in this case, Simulink_requirement_item_7.

9 To verify that the link was created, select Analysis > Requirements Traceability

> Highlight Model.

The Pumping Constant block, and other blocks with requirements links, are highlighted.

10 To navigate to the link, right-click the Pumping Constant block and select

Requirements Traceability > 1. “Determination of pumping efficiency”.

The section 2.2 Determination of pumping efficiency is displayed, selected in the requirements document.

Keep the example model and the requirements document open.

View Link Details

To view the details of the link that you just created, right-click the Pumping Constant block and select Requirements Traceability > Open Link Editor.

The Requirements Traceability Link Editor opens.

2-29

2

Links Between Models and Requirements

2-30

This dialog box contains the following information for the link you just created:

• Description of the link, which for selection-based links, matches the text of the selected requirements document, in this case Determination of pumping efficiency

.

• Name of the requirements document, in this case slvnvdemo_FuelSys_DesignDescription.docx

.

• Document type, in this case, Microsoft Word.

Link to Requirements in Microsoft Word Documents

• The type and identifier of the location in the requirements document. With selectionbased linking for Microsoft Word requirements documents, the RMI creates a bookmark in the requirements document. For this link, the RMI created a bookmark named Simulink_requirement_item_7.

If you do not want the RMI to modify the Microsoft Word requirements document when it creates links, create bookmarks in your Microsoft Word file, as described in

“Create Bookmarks in a Microsoft Word Requirements Document” on page 2-26.

• User tag, a user-defined keyword. This link does not have a user tag.

Note:

For more information about user tags, see “Filter Requirements with User

Tags” on page 4-25

2-31

2

Links Between Models and Requirements

Link to Requirements in IBM Rational DOORS Databases

This example shows how to create links from objects in a Simulink model to requirements in an IBM Rational DOORS database.

1 Open a DOORS formal module.

2 Click to select one of the requirement objects.

3 Open the example model: sldemo_fuelsys

4

Open the fuel_rate_control subsystem.

5 Right-click the airflow_calc subsystem and select Requirements Traceability >

Link to Selection in DOORS.

6

To confirm the requirement link, right-click the airflow_calc subsystem and select

Requirements Traceability. In the submenu, the top item is the heading text for the DOORS requirement object.

2-32

Link to Requirements in IBM Rational DOORS Databases

If you navigate to a DOORS requirement, the DOORS module opens in read only mode. If you want to modify the DOORS module, open the module using DOORS software.

Note: To view an example of using the RMI with an IBM Rational DOORS database, run the Managing Requirements for Fault-Tolerant Fuel Control System (IBM Rational

DOORS) example at the MATLAB command prompt.

2-33

2

Links Between Models and Requirements

Link to Requirements in Microsoft Excel Workbooks

In this section...

“Navigate from a Model Object to Requirements in a Microsoft Excel Workbook” on page

2-34

“Create Requirements Links to the Workbook” on page 2-34

“Link Multiple Model Objects to a Microsoft Excel Workbook” on page 2-35

“Change Requirements Links” on page 2-36

Navigate from a Model Object to Requirements in a Microsoft Excel

Workbook

1

Open the example model: slvnvdemo_fuelsys_officereq

2

Select Analysis > Requirements Traceability > Highlight Model to highlight the model objects with requirements.

3 Right-click the Test inputs Signal Builder block and select Requirements

Traceability > 1. “Normal mode of operation”.

The slvnvdemo_FuelSys_TestScenarios.xlsx file opens, with the associated cell highlighted.

Keep the example model and Microsoft Excel requirements document open.

For information about creating requirements links in Signal Builder blocks, see “Link

Signal Builder Blocks to Requirements Documents” on page 2-54.

Create Requirements Links to the Workbook

1 At the top level of the slvnvdemo_fuelsys_officereq model, right-click the speed sensor block and select Requirements Traceability > Open Link Editor.

The Requirements Traceability Link Editor opens.

2

To create a requirements link, click New.

3 In the Description field, enter:

Speed sensor failure

2-34

Link to Requirements in Microsoft Excel Workbooks

You will link the speed sensor block to the Speed Sensor Failure information in the Microsoft Excel requirements document.

4 When you browse and select a requirements document, the RMI stores the document path as specified by the Document file reference option on the Requirements

Settings dialog box, Selection Linking tab.

For information about which setting to use for your working environment, see

“Document Path Storage” on page 5-15.

5 At the Document field, click Browse to locate and open the slvnvdemo_FuelSys_TestScenarios.xlsx

file.

The Document Type field information changes to Microsoft Excel.

6 In the workbook, the Speed sensor failure information is in cells B22:E22. For the Location (Type/Identifier) field, select Sheet range and in the second field, enter B22:E22. (The cell range letters are not case sensitive.)

7 Click Apply or OK to create the link.

8 To confirm that you created the link, right-click the speed sensor block and select

Requirements Traceability > 1. “Speed sensor failure”.

The workbook opens, with cells B22:E22 highlighted.

Keep the example model and Microsoft Excel requirements document open.

Link Multiple Model Objects to a Microsoft Excel Workbook

You can use the same technique to link multiple Simulink and Stateflow objects to a requirement in a Microsoft Excel workbook. The workflow is:

1

In the model window, select the objects to link to a requirement.

2 Right-click one of the selected objects and select Requirements Traceability >

Open Link Editor.

3 When you browse and select a requirements document, the RMI stores the document path as specified by the Document file reference option on the Requirements

Settings dialog box, Selection Linking tab.

For information about which setting to use for your working environment, see

“Document Path Storage” on page 5-15.

2-35

2

Links Between Models and Requirements

4 Use the Link Editor to specify information about the Microsoft Excel requirements document, the requirement, and the link.

5

Click Apply or OK to create the link.

Change Requirements Links

1 In the slvnvdemo_fuelsys_officereq model, right-click the MAP sensor block and select Requirements Traceability > Open Link Editor.

The Requirements Traceability Link Editor opens displaying the information about the requirements link.

2-36

Link to Requirements in Microsoft Excel Workbooks

2

In the Description field, enter:

MAP sensor test scenario

The User tag field contains the tag test. User tags filter requirements for highlighting and reporting.

2-37

2

Links Between Models and Requirements

Note:

For more information about user tags, see “Filter Requirements with User

Tags” on page 4-25.

3 Click Apply or OK to save the change.

Keep the example model open.

2-38

Link to Requirements in MuPAD Notebooks

Link to Requirements in MuPAD Notebooks

This example shows how to create a link from a Simulink model to a MuPAD notebook.

You use a model that simulates a nonlinear second-order system with the van der Pol equation.

Before beginning this example, create a MuPAD notebook with one or more link targets.

This example uses a MuPAD notebook that includes information about solving the van der Pol equation symbolically and numerically.

Note: You must have the Symbolic Math Toolbox™ installed on your system to open a

MuPAD notebook. For information about creating or opening MuPAD notebooks, see

“Create MuPAD Notebooks” and “Open MuPAD Notebooks”.

1 Open an example model for the van der Pol equation: vdp

2 Right-click a blank area of the model and select Requirements Traceability at

This Level > Open Link Editor.

You are adding the requirement to the model itself, not to a specific block in the model.

3

Click New.

4 In the Document type drop-down list, select MuPAD Notebook.

5 When you browse and select a requirements document, the RMI stores the document path as specified by the Document file reference option on the Requirements

Settings dialog box, Selection Linking tab.

For information about which setting to use for your working environment, see

“Document Path Storage” on page 5-15.

6 Click Browse to navigate to the notebook that you want to use.

Use a notebook that has link targets in it.

7 Make sure that the MuPAD notebook is in a saved state. Any link targets created since the last save do not appear in the RMI document index.

8 To list the link targets, in the Requirements Traceability Link Editor, click the

Document Index tab.

2-39

2

Links Between Models and Requirements

This figure shows two link targets.

2-40

Note: These link targets are in a MuPAD notebook that was created for this example. The Document Index tab displays only link targets that you have created in your MuPAD notebook.

9 Select a link target name and click Apply.

Link to Requirements in MuPAD Notebooks

The Requirements tab reopens, displaying the details of the newly created link.

Unless you have previously entered a description, the link target name appears in the Description field.

10 To confirm that you created the link, right-click a blank area of the model and select

Requirement. The new link is at the top of the submenu.

2-41

2

Links Between Models and Requirements

Create Requirements Traceability Report for Model

To create the default requirements report for a Simulink model:

1 Open the example model: slvnvdemo_fuelsys_officereq

2 Make sure that your current working folder is writable.

3

In the Simulink Editor, select Analysis > Requirements Traceability >

Generate Report.

If your model is large and has many requirements links, it takes a few minutes to create the report.

A Web browser window opens with the contents of the report. The following graphic shows the Table of Contents for the slvnvdemo_fuelsys_officereq model.

2-42

Create Requirements Traceability Report for Model

A typical requirements report includes:

• Table of contents

• List of tables

• Per-subsystem sections that include:

• Tables that list objects with requirements and include links to associated requirements documents

• Graphic images of objects with requirements

• Lists of objects with no requirements

• MATLAB code lines with requirements in MATLAB Function blocks

For detailed information about requirements reports, see “Customize Requirements

Traceability Report for Model” on page 4-7.

2-43

2

Links Between Models and Requirements

Link to Requirements Modeled in Simulink

You can use Simulink to model your design requirements. For example, you can use verification blocks to specify desired system properties and model the design requirements. The Requirements Management Interface (RMI) allows you to create navigation links between the requirements modeled in Simulink, the associated Simulink objects, and related test cases. This example shows how to use the RMI to create and view links to requirements modeled in Simulink.

Open Example Model

Open the Power Window Controller model by typing the command: open_system( 'slvnvdemo_powerwindowController' );

Loading RMI data from ...eqs\slvnvdemo_powerwindowRequirements.req

2-44

Link to Requirements Modeled in Simulink

Verification Subsystems for Power Window Controller Model

Open the verification model, 'Power Window Controller Temporal Property

Specification'. This model specifies properties and requirements of the slvnvdemo_powerwindowController

model.

Consider the following design requirements for the controller:

1

Requirement 1 (Obstacle Response) - Whenever an obstacle is detected, the controller shall give the down command for one second. This requirement is modeled in Verification Subsystem2.

2-45

2

Links Between Models and Requirements

2 Requirement 2 (Autodown feature) - If the driver presses the down button for less than 1 second, the controller keeps issuing the down command until the end has been reached, or the driver presses the up button. This requirement is modeled in

Verification Subsystem3

See Design Verifier Temporal Properties example for more details.

open_system( 'slvnvdemo_powerwindow_vs' );

2-46

Link to Requirements Modeled in Simulink

2-47

2

Links Between Models and Requirements

Create RMI Link to a Simulink Object

Create an RMI link from Verification Subsystem2 to the emergencyDown state in the slvnvdemo_powerwindowController

model.

1 Open slvnvdemo_powerwindowController model.

2

Right-click on emergencyDown state and select Requirements > Select for

linking with Simulink.

3 Right-click on Verification Subsystem2 and select Requirements > Add link to

selected object.

4 Right-click the Verification Subsystem2. The new RMI link appears at the top of

Requirements submenu.

5 Close slvnvdemo_powerwindowController model.

6 Right-click on Verification Subsystem2. Navigate the new link at the top of the

Requirements submenu. Model opens and emergencyDown state is highlighted.

Link Simultaneously to Multiple Simulink Objects

You can link to a multiple selection of Simulink objects. Use the Shift key to select all the following objects as in figure below.

• iniDriverDown

• autoDriverDown

• after(5,tick) transition out of iniDriverDown

• [driver[1]] transition to autoDriverDown

2-48

Link to Requirements Modeled in Simulink

1 Right-click on this group of objects, select Requirements > Select for linking

with Simulink. Be careful to not lose the selections when you right-click.

2 Right-click on Verification Subsystem3 and select Requirements > Link to 4

selected objects.

Link to a Group of Simulink Objects

1 Right-click on NAND block in Global Assumptions and select Requirements >

Select for linking with Simulink.

2 Drag the mouse across endstop and obstacle inputs in slvnvdemo_powerwindowController

to select both inputs.

3 Right-click on this group of objects and select Add link to selected object. Be careful to not lose the selection.

4 Click on the background of slvnvdemo_powerwindowController to clear the group selection.

2-49

2

Links Between Models and Requirements

5 Right-click each input and select Requirements to display new links. Click the new link, confirm that NAND is highlighted.

Create Links for Navigation in Both Directions

To create links for navigation in both directions:

1 Open Requirements Settings dialog box.

2 Select the Selection Linking tab.

3

Enable Modify destination for bi-directional linking.

Now, when you create a link from one Simulink object to another, a corresponding

"return" link is also created.

2-50

Link to Requirements Modeled in Simulink

Highlight and Report RMI Links Between Simulink Objects

Create RMI links to Simulink objects in the same way as links to external documents:

1 In the slvnvdemo_powerwindow_vs model window, select Analysis >

Requirements > Highlight Model to highlight all RMI links in the model, including links to Simulink objects.

2

In the slvnvdemo_powerwindow_vs model window, select Analysis >

Requirements > Generate Report.

3 In the generated report, click a hyperlink in any requirements table. This navigates to the corresponding object in Simulink diagram.

2-51

2

Links Between Models and Requirements

2-52

Cleanup

Close all open models. Do not save changes.

close_system( 'slvnvdemo_powerwindowController' , 0); close_system( 'slvnvdemo_powerwindow_vs' , 0);

Requirements Linking with Simulink Annotations

Requirements Linking with Simulink Annotations

You can create requirements links to and from Simulink.Annotation objects using the Requirements Management Interface (RMI). Annotations are free-floating text boxes that you can place inside a Simulink model. For more information, see “Annotations” in the Simulink documentation. You can use RMI linking to associate annotations with other Simulink objects or external requirements documents. Note that requirements linking for annotations is not supported in Stateflow.

Requirements linking for Simulink annotations is enabled only if you configure your model to store requirements data externally. To specify external storage of requirements data for a model, in the Requirements Settings dialog box under Storage > Default

storage location for requirements links data, select Store externally (in a

separate *.req file). If you have an existing model that contains internally stored requirements links, you must convert the model to store requirements data externally before you can use requirements linking for annotations in the model. To switch the model from internal to external RMI storage, move all existing requirements links in it to an external .req file by selecting Analysis > Requirements Traceability > Move

to File. For more information on requirements links storage, see “Specify Storage for

Requirements Links”.

Note: If you later change your model to store requirements links internally as described in “Move Externally Stored Requirements Links to the Model File”, or if you save the model in a version of MATLAB prior to R2012b, annotation requirements links are either discarded or attached to a corresponding parent diagram.

Annotations are context-specific. Unlike copying other Simulink objects, copying an annotation does not copy its associated requirements links. Requirements links from annotations do not appear in generated code, but requirements links to annotations from other Simulink objects do appear.

2-53

2

Links Between Models and Requirements

Link Signal Builder Blocks to Requirements Documents

You can create links from a signal group in a Signal Builder block to a requirements document:

1

Open the model: sf_car

2

In the sf_car model window, double-click the User Inputs block.

The Signal Builder dialog box opens, displaying four groups of signals. The Passing

Maneuver signal group is the current active group. The RMI associates any requirements links that you add to the current active signal group.

3 At the far-right end of the toolbar, click the Show verification settings button .

(You might need to expand the Signal Builder dialog box for this button to become visible.)

A Requirements pane opens on the right-hand side of the Signal Builder dialog box.

2-54

4

Place your cursor in the window, right-click, and select Open Link Editor.

The Requirements Traceability Link Editor opens.

5 Click New. In the Description field, enter User input requirements.

6 When you browse and select a requirements document, the RMI stores the document path as specified by the Document file reference option on the Requirements

Settings dialog box, Selection Linking tab.

For information about which setting to use for your working environment, see

“Document Path Storage” on page 5-15.

7 Browse to a requirements document and click Open.

8 In the Location drop-down list, select Search text to link to specified text in the document.

Link Signal Builder Blocks to Requirements Documents

9 Next to the Location drop-down list, enter User Input Requirements.

10 Click Apply to create the link.

11 To verify that the RMI created the link, in the Simulink Editor, select the User

Inputs block, right-click, and select Requirements Traceability.

The link to the new requirement is the option at the top of the submenu.

12 Save the sf_car_linking model.

Note: Links that you create in this way associate requirements information with individual signal groups, not with the entire Signal Builder block.

In this example, switch to a different active group in the drop-down list to link a requirement to another signal group.

2-55

2

Links Between Models and Requirements

Link Signal Builder Blocks to Model Objects

This example shows how to create links from a signal group in a Signal Builder block to a model object:

1 Open the sf_car model.

2

Open the sf_car/shift_logic chart.

3 Right-click upshifting and select Requirements Traceability > Select for

Linking with Simulink.

4 In the sf_car model window, double-click the User Inputs block.

The Signal Builder dialog box opens, displaying four groups of signals. The Passing

Maneuver signal group is the current active group. The RMI associates any requirements links that you add to the current active signal group.

5

In the Signal Builder dialog box, click the Gradual Acceleration tab.

6 At the far-right end of the toolbar, click the Show verification settings button .

(You might need to expand the Signal Builder dialog box for this button to become visible.)

A Requirements pane opens on the right-hand side of the Signal Builder dialog box.

2-56

7 Place your cursor in the window, right-click, and select Open Link Editor.

The Requirements Traceability Link Editor opens.

8 Click New. In the Description field, enter Upshifting.

9

In the Document type field, select Simulink. Click Use current. The software fills in the field with the Location: (Type/Identifier) information for upshifting.

Link Signal Builder Blocks to Model Objects

10

Click Apply to create the link.

11

In the model window, select the User Inputs block, right-click, and select

Requirements Traceability.

The link to the new requirement is the option at the top of the submenu.

12

To verify that the links were created, in the sf_car model window, select Analysis

> Requirements Traceability > Highlight Model.

The blocks with requirements links are highlighted.

Note: Links that you create in this way associate requirements information with individual signal groups, not with the entire Signal Builder block.

13 Close the sf_car model.

2-57

2

Links Between Models and Requirements

Link Requirements to Simulink Data Dictionary Entries

You can create requirements traceability links for entries in Simulink data dictionaries.

The process is similar to linking for other model objects. In the Model Explorer, rightclick a data dictionary entry, select Requirements Traceability, and choose one of the selection-based linking options. You can also use the Link Editor.

This example demonstrates linking to a data dictionary entry.

1 Enter sldemo_fuelsys_dd_controller at the command line to open sldemo_fuelsys_dd_controller

.

2

Open the linked data dictionary by clicking the data dictionary badge in the bottom left corner of the model.

3 In the Model Hierarchy pane of the Model Explorer, select Design Data in the sldemo_fuelsys_dd_controller

data dictionary.

4

You will link the PumpCon parameter to the Pumping Constant lookup table in the model.

2-58

Link Requirements to Simulink Data Dictionary Entries

5 Open the airflow_calc subsystem and select the Pumping Constant lookup table.

6 In the Model Explorer, right-click the PumpCon parameter and select Requirements

Traceability > Link to Selection in Simulink.

The two objects are linked.

7

Check the link. Right-click the PumpCon parameter and select Requirements

Traceability, then select the navigation shortcut at the top of the Requirements

Traceability submenu. Simulink highlights the lookup table.

2-59

3

How Is Requirements Link Information

Stored?

• “External Storage” on page 3-2

• “Guidelines for External Storage of Requirements Links” on page 3-3

• “Specify Storage for Requirements Links” on page 3-4

• “Save Requirements Links in External Storage” on page 3-5

• “Load Requirements Links from External Storage” on page 3-6

• “Move Internally Stored Requirements Links to External Storage” on page 3-7

• “Move Externally Stored Requirements Links to the Model File” on page 3-8

3

How Is Requirements Link Information Stored?

External Storage

The first time you create links to requirements in a Simulink model, the RMI uses your designated storage preference. When you reopen the model, the RMI loads the internally stored links, or the links from the external file, as long as the file exists with the same name and location as when you last saved the links.

The RMI allows you to save your links file as a different name or in a different folder.

However, when you start with the links file in a nondefault location, you must manually load those links into the model. After you load those links, the RMI associates that model with that file and loads the links automatically.

As you work with your model, the RMI stores links using the same storage as the existing links. For example, if you open a model that has internally stored requirements links, any new links you create are also stored internally. This is true even if your preference is set to external storage.

All requirements links must be stored either with the model or in an external file. You cannot mix internal and external storage within a given model.

To see an example of the external storage capability using a Simulink model, at the

MATLAB command line, enter: slvnvdemo_powerwindow_external

3-2

Guidelines for External Storage of Requirements Links

Guidelines for External Storage of Requirements Links

If you decide to store requirements links in an external file, keep the following guidelines in mind:

When sharing models, use the default name and location.

By default, external requirements are stored in a file named model_name.req in the same folder as the model. If you give your model to others to review the requirements traceability, give the reviewer both the model and .req files. That way, when you load the model, the RMI automatically loads the links file.

Do not rename the model outside of Simulink.

If you need to resave the model with a new name or in a different location, in the model window, use File > Save As. Selecting this option causes the RMI to resave the corresponding .req file using the model name and in the same location as the model.

Be aware of unsaved requirements changes.

When you change a Simulink model, an asterisk appears next to the model name in the title bar, indicating that the model has unsaved changes. If you are creating new requirements links and storing them externally, this asterisk does not appear because the model file itself has not changed. You can explicitly save the links, or, when you close the model, the RMI prompts you to save the requirements links. When you save the model, the RMI saves the links in the external file.

3-3

3

How Is Requirements Link Information Stored?

Specify Storage for Requirements Links

By default, the Requirements Management Interface (RMI) stores requirements links with the model file. In the Requirements Settings dialog box, on the Storage tab, you can enable external storage or reenable internal storage. This setting goes into effect immediately and applies to all new models and to existing models with no links to requirements.

If you open a model that already has requirements links, the RMI uses the storage mechanism you used previously with that model, regardless of what your default storage setting is.

To specify the requirements storage setting:

1 In the model window, select Analysis > Requirements Traceability > Settings.

2 In the Requirements Settings dialog box, select the Storage tab.

3 Under Default storage location for requirements links data:

• To enable internal storage, select Store internally (embedded in model file).

• To enable external storage, select Store externally (in a separate *.req file).

These settings go into effect immediately.

3-4

Save Requirements Links in External Storage

Save Requirements Links in External Storage

The Requirements Management Interface (RMI) stores externally stored requirements links in a file whose name is based on the model file. Because of this, before you create requirements links to be stored in an external file, you must save the model with a value file name.

You add, modify, and delete requirements links in external storage the same way you do when the requirements links are stored in the model file. The main difference is when you change externally stored links, the model file does not change. The asterisk in the title bar of the model window that indicates a model has unsaved changes does not appear when you change requirements links. However, when you close the model, the

RMI asks if you want to save the requirements links modifications.

There are several ways to save requirements links that are stored in an external file, as listed in the following table.

Select...

Analysis > Requirements Traceability

> Save Links As

Analysis > Requirements Traceability

> Save Links

File > Save

File > Save As

To...

Save the requirements links in an external file using a file name that you specify. The model itself is not saved.

Save the requirements links in an external file using the default file name,

model_name.req

, or to the previously specified file. The model itself is not saved.

Save the current requirements links to an external file named model_name.req, or to the previously specified file. Any changes you have made to the model are also saved.

Rename and save the model and the external requirements links. The external file is saved as new_model_name.req.

3-5

3

How Is Requirements Link Information Stored?

Load Requirements Links from External Storage

When you open a Simulink model that does not have internally stored requirements links, the RMI tries to load requirements links from an .req file, either the default file, or a previously specified file. If that file does not exist, the RMI assumes that this model has no requirements links.

To explicitly load requirements links from an external file:

1

Select Analysis > Requirements Traceability > Load Links.

The Select a file to load RMI data dialog box opens, with the default file name or the previously used file name loaded into the File name field.

2

Select the file from which to load the requirements links.

3

Click Open to load the links from the selected file.

Caution If your model has unsaved changes to requirements links and you try to load another file, a warning appears.

3-6

Move Internally Stored Requirements Links to External Storage

Move Internally Stored Requirements Links to External Storage

If you have a model with requirements links that are stored with the model, you can move those links to an external file. When you move internally stored links to a file, the

RMI deleted the internally stored links from the model file and saves the model. From this point on, the data exists only in the external file.

1 Open the model that contains internally stored requirements links.

2 Select Analysis > Requirements Traceability > Move to File.

The Select a file to store RMI data dialog box prompts you to save the file with the default name model_name.req.

3

Accept the default name, or enter a different file name if required.

4

Click Save.

Note: Use the default name for externally stored requirements. For more

information about this recommendation, see “Guidelines for External Storage of

Requirements Links” on page 3-3.

3-7

3

How Is Requirements Link Information Stored?

Move Externally Stored Requirements Links to the Model File

If you have a model with requirements links that are stored in an external file, you can move those links to the model file.

1 Open the model that has only externally stored requirements links.

2 Make sure the right set of requirements links are loaded from the external file.

3 Select Analysis > Requirements Traceability > Copy to Model.

An asterisk appears next to the model name in the title bar of the model window indicating that your model now has unsaved changes.

4 Save the model with the requirements links.

From this point on, the RMI stores all requirements links internally, in the model file.

When you add, modify, or delete links, the changes are stored with the model, even if the Default storage location for requirements links data option is set to Store

externally (in a separate *.req file).

3-8

4

Reviewing Requirements

• “Highlight Model Objects with Requirements” on page 4-2

• “Navigate to Requirements from Model” on page 4-5

• “Customize Requirements Traceability Report for Model” on page 4-7

• “Filter Requirements with User Tags” on page 4-25

• “Create Requirements Traceability Report for Simulink Project” on page 4-33

• “View Requirements Details for a Selected Block” on page 4-34

4

Reviewing Requirements

Highlight Model Objects with Requirements

You can highlight a model to see which objects in the model have links to requirements in external documents. You highlight a model from the Model Editor or from the Model

Explorer.

In this section...

“Highlight Model Objects with Requirements Using Model Editor” on page 4-2

“Highlight Model Objects with Requirements Using Model Explorer” on page 4-3

Highlight Model Objects with Requirements Using Model Editor

If you are working in the Simulink Editor and want to see which model objects in the slvnvdemo_fuelsys_officereq

model have requirements, follow these steps:

1 Open the example model: slvnvdemo_fuelsys_officereq

2 Select Analysis > Requirements Traceability > Highlight Model.

Two types of highlighting indicate model objects with requirements:

• Yellow highlighting indicates objects that have requirements links for the object itself.

• Orange outline indicates objects, such as subsystems, whose child objects have requirements links.

4-2

Highlight Model Objects with Requirements

Objects that do not have requirements are colored gray.

3 To remove the highlighting from the model, select Analysis > Requirements

Traceability > Unhighlight Model. Alternatively, you can right-click anywhere in the model, and select Remove Highlighting.

While a model is highlighted, you can still manage the model and its contents.

Highlight Model Objects with Requirements Using Model Explorer

If you are working in Model Explorer and want to see which model objects have requirements, follow these steps:

4-3

4

Reviewing Requirements

1 Open the example model: slvnvdemo_fuelsys_officereq

2

Select View > Model Explorer.

3

To highlight all model objects with requirements, click the Highlight items with

requirements on model icon ( ).

The Simulink Editor window opens, and all objects in the model with requirements are highlighted.

Note: If you are running a 64-bit version of MATLAB, when you navigate to a requirement in a PDF file, the file opens at the top of the page, not at the bookmark location.

4-4

Navigate to Requirements from Model

Navigate to Requirements from Model

In this section...

“Navigate from Model Object” on page 4-5

“Navigate from System Requirements Block” on page 4-5

Navigate from Model Object

You can navigate directly from a model object to that object's associated requirement.

When you take these steps, the external requirements document opens in the application, with the requirements text highlighted.

1

Open the example model: slvnvdemo_fuelsys_officereq

2 Open the fuel rate controller subsystem.

3

To open the linked requirement, right-click the Airflow calculation subsystem and select Requirements Traceability > 1. “Mass airflow estimation”.

The Microsoft Word document slvnvdemo_FuelSys_DesignDescription.docx, opens with the section 2.1 Mass airflow estimation selected.

Note: If you are running a 64-bit version of MATLAB, when you navigate to a requirement in a PDF file, the file opens at the top of the page, not at the bookmark location.

Navigate from System Requirements Block

Sometimes you want to see all the requirements links at a given level of the model hierarchy. In such cases, you can insert a System Requirements block to collect all requirements links in a model or subsystem. The System Requirements block lists requirements links for the model or subsystem in which it resides; it does not list requirements links for model objects inside that model or subsystem, because those are at a different level of the model hierarchy.

In the following example, you insert a System Requirements block at the top level of the slvnvdemo_fuelsys_officereq

model, and navigate to the requirements using the links inside the block.

4-5

4

Reviewing Requirements

1 Open the example model: slvnvdemo_fuelsys_officereq

2

In the Simulink Editor, select Analysis > Requirements Traceability >

Highlight Model.

3

Open the fuel rate controller subsystem.

The Airflow calculation subsystem has a requirements link.

4

Open the Airflow calculation subsystem.

5

In the Simulink Editor, select View > Library Browser.

6

On the Libraries pane, select Simulink Verification and Validation.

This library contains only one block—the System Requirements block.

7 Drag a System Requirements block into the Airflow calculation subsystem.

The RMI software collects and displays any requirements links for that subsystem in the System Requirements block.

8 In the System Requirements block, double-click 1. “Mass airflow subsystem”.

The Microsoft Word document, slvnvdemo_FuelSys_DesignDescription.docx, opens, with the section 2.1 Mass airflow estimation selected.

4-6

Customize Requirements Traceability Report for Model

Customize Requirements Traceability Report for Model

In this section...

“Create Default Requirements Report” on page 4-7

“Report for Requirements in Model Blocks” on page 4-15

“Customize Requirements Report” on page 4-17

“Generate Requirements Reports Using Simulink” on page 4-22

Create Default Requirements Report

If you have a model that contains links to external requirements documents, you can create an HTML report that contains summarized and detailed information about those links. In addition, the report contains links that allow you to navigate to both the model and to the requirements documents.

You can generate a default report with information about all the requirements associated with a model and its objects.

Note:

If the model for which you are creating a report contains Model blocks, see “Report for Requirements in Model Blocks” on page 4-15.

Before you generate the report, add a requirement to a Stateflow chart to see information that the requirements report contains about Stateflow charts:

1 Open the example model: slvnvdemo_fuelsys_officereq

2 Open the fuel rate controller subsystem.

3

Open the Microsoft Word requirements document:

matlabroot/toolbox/slvnv/rmidemos/fuelsys_req_docs/...

slvnvdemo_FuelSys_RequirementsSpecification.docx

4 Create a link from the control logic Stateflow chart to a location in this document.

5 Keep the example model open, but close the requirements document.

To generate a default requirements report for the slvnvdemo_fuelsys_officereq model:

4-7

4

Reviewing Requirements

1 Select Analysis > Requirements Traceability > Generate Report.

The Requirements Management Interface (RMI) searches through all the blocks and subsystems in the model for associated requirements. The RMI generates and displays a complete report in HTML format.

The report is saved with the default name, model_name_requirements.html. If you generate a subsequent report on the same model, the new report file overwrites any earlier report file.

The report contains the following content:

• “Table of Contents” on page 4-8

• “List of Tables” on page 4-9

• “Model Information” on page 4-10

• “Documents Summary” on page 4-10

• “System” on page 4-11

• “Chart” on page 4-14

Table of Contents

The Table of Contents lists the major sections of the report. There is one System section for the top-level model and one System section for each subsystem, Model block, or Stateflow chart.

Click a link to view information about a specific section of the model.

4-8

Customize Requirements Traceability Report for Model

List of Tables

The List of Tables includes links to each table in the report.

4-9

4

Reviewing Requirements

Model Information

The Model Information contains general information about the model, such as when the model was created and when the model was last modified.

Documents Summary

The Documents Summary section lists all the requirements documents to which objects in the slvnvdemo_fuelsys_officereq model link, along with some additional information about each document.

4-10

Customize Requirements Traceability Report for Model

ID — The ID. In this example, DOC1, DOC2, DOC3, and DOC4 are short names for the requirements documents linked from this model.

Before you generate a report, in the Settings dialog box, on the Reports tab, if you select User document IDs in requirements tables, links with these short names are included throughout the report when referring to a requirements document. When you click a short name link in a report, the requirements document associated with that document ID opens.

When your requirements documents have long path names that can clutter the report, select the User document IDs in requirements tables option. This option is disabled by default, as you can see in the examples in this section.

Document paths stored in the model — Click this link to open the requirements document in its native application.

Last modified — The date the requirements document was last modified.

# links — The total number of links to a requirements document.

System

Each System section includes:

• An image of the model or model object. The objects with requirements are highlighted.

4-11

4

Reviewing Requirements

4-12

• A list of requirements associated with the model or model object. In this example, click the target document name to open the requirements document associated with the slvnvdemo_fuelsys_officereq model.

Customize Requirements Traceability Report for Model

• A list of blocks in the top-level model that have requirements. In this example, only the MAP sensor block has a requirement at the top level. Click the link next to

Target: to open the requirements document associated with the MAP sensor block.

The preceding table does not include these blocks in the top-level model because:

• The fuel rate controller and engine gas dynamics subsystems are in dedicated chapters of the report.

• The report lists Signal Builder blocks separately, in this example, in Table 3.3.

• A list of requirements associated with each signal group in any Signal Builder block, and a graphic of that signal group. In this example, the Test inputs Signal

Builder block in the top-level model has one signal group that has a requirement link. Click the link under Target (document name and location ID) to open the requirements document associated with this signal group in the Test inputs block.

4-13

4

Reviewing Requirements

4-14

Chart

Each Chart section reports on requirements in Stateflow charts, and includes:

• A graphic of the Stateflow chart that identifies each state.

• A list of elements that have requirements.

To navigate to the requirements document associated with a chart element, click the link next to Target.

Customize Requirements Traceability Report for Model

Report for Requirements in Model Blocks

If your model contains Model blocks that reference external models, the default report does not include information about requirements in the referenced models. To generate a report that includes requirements information for referenced models, you must have a license for the Simulink Report Generator™ software. The report includes the same information and graphics for referenced models as it does for the top-level model.

If you have a Simulink Report Generator license, before generating a requirements report, take the following steps:

1

Open the model for which you want to create a requirements report. This workflow uses the example model slvnvdemo_fuelsys_officereq.

2

To open the template for the default requirements report, at the MATLAB command prompt, enter: setedit requirements

3

In the Simulink Report Generator software window, in the far-left pane, click the

Model Loop

component.

4-15

4

Reviewing Requirements

4

On the far-right pane, locate the Model reference field. If you cannot see the dropdown arrow for that field, expand the pane.

4-16

5 In the Model reference field drop-down list, select Follow all model reference blocks

.

6 To generate a requirements report for the open model that includes information about referenced models, click the Report icon .

Customize Requirements Traceability Report for Model

Customize Requirements Report

The Requirements Management Interface (RMI) uses the Simulink Report Generator software to generate the requirements report. You can customize the requirements report using the RMI or the Simulink Report Generator software:

• “Customize Requirements Report Using the RMI Settings” on page 4-17

• “Customize Requirements Report Using Simulink Report Generator” on page 4-21

Customize Requirements Report Using the RMI Settings

There are several options for customizing a requirements report using the Requirements

Settings dialog box.

4-17

4

Reviewing Requirements

4-18

On the Report tab, select options that specify the contents that you want in the report.

Requirements Settings Report Option Description

Highlight the model before generating report

Enables highlighting of Simulink objects with requirements in the report graphics.

Show user tags for each reported link Lists the user tags, if any, for each reported link.

Use document IDs in requirements tables

Uses a document ID, if available, instead of a path name in the tables of the requirements report. This capability

Customize Requirements Traceability Report for Model

Requirements Settings Report Option Description prevents long path names to requirements documents from cluttering the report tables.

Report objects with no links to requirements

Includes lists of model objects that have no requirements.

Include details from linked documents Includes additional content from linked requirements. The following requirements documents are supported:

Include links to Simulink objects

Use internal HTTP server to support navigation from system browsers

• Microsoft Word

• Microsoft Excel

• IBM Rational DOORS

Includes links from the report to objects in

Simulink.

Specifies use of internal MATLAB HTTP server for navigation from generated report to documents and model objects.

By selecting this setting, this navigation is available from system browsers as long as the MATLAB internal HTTP server is active on your local host. To start the internal HTTP server, at the MATLAB command prompt, type rmi('httpLink').

To see how these options affect the content of the report:

1

Open the slvnvdemo_fuelsys_officereq model: slvnvdemo_fuelsys_officereq

2

In the model window, select Analysis > Requirements Traceability > Settings.

3

In the Requirements Settings dialog box, click the Report tab.

4 For this example, select Highlight the model before generating report.

When you select this option, before generating the report, the graphics of the model that are included in the report are highlighted so that you can easily see which objects have requirements.

4-19

4

Reviewing Requirements

5 To close the Requirements Settings dialog box, click Close.

6

Generate a requirements report by selecting Analysis > Requirements

Traceability > Generate Report.

The requirements report opens in a browser window so that you can review the content of the report.

7 If you do not want to overwrite the current report when you regenerate the requirements report, rename the HTML file, for example, slvnvdemo_fuelsys_officereq_requirements_old.html

.

The default report file name is model_name_requirements.html.

8 In the model window, select Analysis > Requirements Traceability > Settings.

9

On the Report tab, select:

Show user tags for each reported link — The report lists the user tags (if any) associated with each requirement.

Include details from linked documents — The report includes additional details for requirements in the following types of requirements documents.

Requirements Document Format Includes in the Report

Microsoft Word Full text of the paragraph or subsection of the requirement, including tables.

Microsoft Excel

IBM Rational DOORS

If the target requirement is a group of cells, the report includes all those cells as a table. If the target requirement is one cell, the report includes that cell and all the cells in that row to the right of the target cell.

By default, the report includes:

DOORS Object Heading

DOORS Object Text

• All other attributes except Created Thru, attributes with empty string values, and system attributes that are false.

4-20

Customize Requirements Traceability Report for Model

Requirements Document Format Includes in the Report

Use the RptgenRMI.doorsAttribs function to include or exclude specific attributes or groups of attributes.

10 Close the Requirements Settings dialog box.

11 Generate a new requirements report by selecting Analysis > Requirements

Traceability > Generate Report.

12

Compare this new report to the report that you renamed in step 7:

• User tags associated with requirements links are included.

• Details from the requirement content are included as specified in step 9.

13

When you are done reviewing the report, close the report and the model.

To see an example of including details in the requirements report, enter the following command at the MATLAB command prompt: slvnvdemo_powerwindow_report

Customize Requirements Report Using Simulink Report Generator

If you have a license for the Simulink Report Generator software, you can further modify the default requirements report.

At the MATLAB command prompt, enter the following command: setedit requirements

The Report Explorer GUI opens the requirements report template that the RMI uses when generating a requirements report. The report template contains Simulink Report

Generator components that define the structure of the requirements report.

If you click a component in the middle pane, the options that you can specify for that component appear in the right-hand pane. For detailed information about using a particular component to customize your report, click Help at the bottom of the righthand pane.

In addition to the standard report components, Simulink Report Generator provides components specific to the RMI in the Requirements Management Interface category.

4-21

4

Reviewing Requirements

Simulink Report Generator Component

Missing Requirements Block Loop

Report Information

Applies all child components to blocks that have no requirements

Missing Requirements System Loop

Applies all child components to systems that have no requirements

Requirements Block Loop

Applies all child components to blocks that have requirements

Requirements Documents Table

Requirements Signal Loop

Requirements Summary Table

Requirements System Loop

Requirements Table

Inserts a table that lists requirements documents

Applies all child components to signal groups with requirements

Inserts a property table that lists requirements information for blocks with associated requirements

Applies all child components to systems with requirements

Inserts a table that lists system and subsystem requirements

To customize the requirements report, you can:

• Add or delete components.

• Move components up or down in the report hierarchy.

• Customize components to specify how the report presents certain information.

For more information, see the Simulink Report Generator documentation.

Generate Requirements Reports Using Simulink

When you have a model open in Simulink, the Model Editor provides two options for creating requirements reports:

• “System Design Description Report” on page 4-23

• “Design Requirements Report” on page 4-23

4-22

Customize Requirements Traceability Report for Model

System Design Description Report

The System Design Description report describes a system design represented by the current Simulink model.

You can use the System Design Description report to:

• Review a system design without having the model open.

• Generate summary and detailed descriptions of the design.

• Assess compliance with design requirements.

• Archive the system design in a format independent of the modeling environment.

• Build a customized version of the report using the Simulink Report Generator software.

To generate a System Design Description report that includes requirements information:

1 Open the model for which you want to create a report.

2

Select File > Reports > System Design Description.

3 In the Design Description dialog box, select Requirements traceability.

4

Select any other options that you want for this report.

5 Click Generate.

As the software is generating the report, the status appears in the MATLAB command window.

The report name is the model name, followed by a numeral, followed by the extension that reflects the document type (.pdf, .html, etc.).

If your model has linked requirements, the report includes a chapter, Requirements

Traceability, that includes:

• Lists of model objects that have requirements with hyperlinks to display the objects

• Images of each subsystem, highlighting model objects with requirements

Design Requirements Report

In the Simulink Editor, the menu option File > Reports > System Requirements

creates a requirements report, as described in “Create Default Requirements Report”

4-23

4

Reviewing Requirements

on page 4-7. This menu option is equivalent to Analysis > Requirements

Traceability > Generate Report.

To specify options for the report, select Analysis > Requirements Traceability >

Settings. Before generating the report, on the Report tab, set the options that you

want. For detailed information about these options, see “Customize Requirements

Report” on page 4-17.

4-24

Filter Requirements with User Tags

Filter Requirements with User Tags

In this section...

“User Tags and Requirements Filtering” on page 4-25

“Apply a User Tag to a Requirement” on page 4-25

“Filter, Highlight, and Report with User Tags” on page 4-27

“Apply User Tags During Selection-Based Linking” on page 4-29

“Configure Requirements Filtering” on page 4-31

User Tags and Requirements Filtering

User tags are user-defined keywords that you associate with specific requirements. With user tags, you can highlight a model or generate a requirements report for a model in the following ways:

• Highlight or report only those requirements that have a specific user tag.

• Highlight or report only those requirements that have one of several user tags.

• Do not highlight and report requirements that have a specific user tag.

Apply a User Tag to a Requirement

To apply one or more user tags to a newly created requirement:

1

Open the example model: slvnvdemo_fuelsys_officereq

2

Open the fuel rate controller subsystem.

3 To open the requirements document, right-click the Airflow calculation subsystem and select Requirements Traceability > Open Link Editor.

The Requirements Traceability Link Editor opens with the details about the requirement that you created.

4-25

4

Reviewing Requirements

4-26

Filter Requirements with User Tags

4 In the User tag field, enter one or more keywords, separated by commas, that the

RMI can use to filter requirements. In this example, after design, enter a comma, followed by the user tag test to specify a second user tag for this requirement.

User tags:

• Are not case sensitive.

• Can consist of multiple words. For example, if you enter design requirement, the entire phrase constitutes the user tag. Separate user tags with commas.

5

Click Apply or OK to save the changes.

Filter, Highlight, and Report with User Tags

The slvnvdemo_fuelsys_officereq model includes several requirements with the user tag design. This section describes how to highlight only those model objects that have the user tag, test.

1 In the Simulink Editor, remove highlighting from the slvnvdemo_fuelsys_officereq

model by selecting Analysis > Requirements

Traceability > Unhighlight model.

2 Select Analysis > Requirements Traceability > Settings.

3 In the Requirements Settings dialog box, click the Filters tab.

4-27

4

Reviewing Requirements

4-28

4 To enable filtering with user tags, click the Filter links by user tags when

highlighting and reporting requirements option.

5

To include only those requirements that have the user tag, test, enter test in the

Include links with any of these tags field.

6 Click Close.

7 In the Simulink Editor, select Analysis > Requirements Traceability >

Highlight model.

The RMI highlights only those model objects whose requirements have the user tag test

, for example, the MAP sensor.

Filter Requirements with User Tags

8 Reopen the Requirements Settings dialog box to the Filters tab.

9

In the Include links with any of these tags field, delete test. In the Exclude

links with any of these tags field, add test.

In the model, the highlighting changes to exclude objects whose requirements have the test user tag. The MAP sensor and Test inputs blocks are no longer highlighted.

10

In the Simulink Editor, select Analysis > Requirements Traceability >

Generate Report.

The report does not include information about objects whose requirements have the test

user tag.

Apply User Tags During Selection-Based Linking

When creating a succession of requirements links, you can apply the same user tags to all links automatically. This capability, also known as selection-based linking, is available only when you are creating links to selected objects in the requirements documents.

When creating selection-based links, specify one or more user tags to apply to requirements:

1

In the Simulink Editor, select Analysis > Requirements Traceability > Settings.

2 Select the Selection Linking tab.

4-29

4

Reviewing Requirements

4-30

3 In the Apply this user tag to new links field, enter one or more user tags, separated by commas.

The RMI applies these user tags to all new selection-based requirements links that you create.

4 Click Close to close the Requirements Settings dialog box.

5 In a requirements document, select the specific requirement text.

6 Right-click a model object and select Requirements Traceability.

Filter Requirements with User Tags

The selection-based linking options specify which user tags the RMI applies to the link that you create. In the following example, you can apply the user tags design, general

, and reqtslink to the link that you create to your selected text.

Configure Requirements Filtering

In the Requirements Settings dialog box, on the Filters tab, are the following options for filtering requirements in a model.

Option

Filter links by user tags when highlighting and reporting requirements

Include links with any of these tags

Description

Enables filtering for highlighting and reporting, based on specified user tags.

Exclude links with any of these tags

Apply same filters in context menus

Includes information about all requirements that have any of the specified user tags. Separate multiple user tags with commas.

Excludes information about all requirements that have any of the specified user tags. Separate multiple user tags with commas or spaces.

Disables link labels in context menus if any of the specified filters are satisfied, for example, if a requirement has a designated user tag.

4-31

4

Reviewing Requirements

Option

Apply same filters in consistency checking

Under Link type filters, Disable

DOORS surrogate item links in context menus

Description

Includes or excludes requirements with specified user tags when running a consistency check between a model and its associated requirements documents.

Disables links to IBM Rational DOORS surrogate items from the context menus when you right-click a model object. This option does not depend on current user tag filters.

4-32

Create Requirements Traceability Report for Simulink Project

Create Requirements Traceability Report for Simulink Project

To create a report for requirements traceability data in a Simulink Project:

1 Open your Simulink Project.

2 At the MATLAB command prompt, enter the following: rmi( 'projectreport' )

The MATLAB Web browser opens, showing the traceability report for the Simulink

Project.

This top-level HTML report contains a separate section for Simulink model files,

MATLAB code files, and other files included in the project. For each individual file with one or more associated requirements links, a separate HTML report, or sub-report, shows the requirements traceability data for that file. The top-level report contains links to each sub-report.

If you have a MATLAB file with requirements traceability links that is not part of a Simulink Project, you can create a separate report for the MATLAB file using the rmi('report', matlabfilepath)

command. For more information, see rmi.

4-33

4

Reviewing Requirements

View Requirements Details for a Selected Block

In this section...

“Requirements Details Workflow” on page 4-34

“Requirements Details Limitations” on page 4-34

Requirements Details Workflow

When you highlight model objects with requirements, you can view the requirements details for a selected block. Follow this workflow:

1

From the menu bar, select Analysis > Requirements Traceability > Highlight

Model.

2 In your model, highlights indicate model objects with requirements links.

4-34

3 In the requirements details window, click the link to load the requirements details.

If your Simulink model has links to Microsoft Word, Microsoft Excel, or IBM

Rational DOORS documents, the requirements management interface loads requirements context from the documents and additional link labels stored by

Simulink.

4 Select highlighted model objects to display associated RMI links in the requirements details window.

5

Close the requirements details window to remove highlights from the Simulink model.

For more information see “Navigate to Requirements from Model”.

Requirements Details Limitations

Security restrictions in Microsoft Office can interrupt the requirements details loading process. Requirement details loaded from read-only Microsoft Office documents,

View Requirements Details for a Selected Block documents stored on network drives, and documents with Microsoft Office Trust Center

ActiveX control restrictions may not work correctly with RMI. Consider enabling ActiveX controls without prompting and using requirements stored in a writable location on the

MATLAB path.

Before loading requirements details for IBM Rational DOORS links, you must be logged in to the IBM Rational DOORS Client.

4-35

5

Requirements Links Maintenance

• “Validation of Requirements Links” on page 5-2

• “Validate Requirements Links in a Model” on page 5-4

• “Validate Requirements Links in a Requirements Document” on page 5-11

• “Document Path Storage” on page 5-15

• “Delete Requirements Links from Simulink Objects” on page 5-17

• “Requirements Links for Library Blocks and Reference Blocks” on page 5-19

5

Requirements Links Maintenance

Validation of Requirements Links

Requirements links in a model can become outdated when requirements change over time. Similarly, links in requirements documents may become invalid when your Simulink model changes, for example, when the model, or objects in the model, are renamed, moved, or deleted. The Simulink Verification and Validation software provides tools that allow you to detect and resolve these problems in the model or in the requirements document.

In this section...

“When to Check Links in a Requirements Document” on page 5-2

“How the rmi Function Checks a Requirements Document” on page 5-3

When to Check Links in a Requirements Document

When you enable Modify destination for bi-directional linking and create a link between a requirement and a Simulink model object, the RMI software inserts a navigation control into your requirements document. These links may become invalid if your model changes.

To check these links, the 'checkDoc' option of the rmi function reviews a requirements document to verify that all the navigation controls represent valid links to model objects.

The checkDoc command can check the following types of requirements documents:

• Microsoft Word

• Microsoft Excel

• IBM Rational DOORS

The rmi function only checks requirements documents that contain navigation controls;

to check links in your Simulink model, see “Validate Requirements Links in a Model” on page 5-4.

Note: For more information about inserting navigation controls in requirements documents, see:

• “Insert Navigation Objects in Microsoft Office Requirements Documents”

• “Insert Navigation Objects into DOORS Requirements”

5-2

Validation of Requirements Links

How the rmi Function Checks a Requirements Document

rmi

performs the following actions:

• Locates all links to Simulink objects in the specified requirements document.

• Checks each link to verify that the target object is present in a Simulink model. If the target object is present, rmi checks that the link label matches the target object.

• Modifies the navigation controls in the requirements document to identify any detected problems. This allows you to see invalid links at a glance:

Valid link:

Invalid link:

5-3

5

Requirements Links Maintenance

Validate Requirements Links in a Model

In this section...

“Check Requirements Links with the Model Advisor” on page 5-4

“Fix Invalid Requirements Links Detected by the Model Advisor” on page 5-7

Check Requirements Links with the Model Advisor

To make sure that every requirements link in your Simulink model has a valid target in a requirements document, run the Model Advisor Requirements consistency checks:

1

Open the example model: slvnvdemo_fuelsys_officereq

2

Open the Model Advisor to run a consistency check by selecting Analysis >

Requirements Traceability > Check Consistency.

In the Requirements Consistency Checking category, all the checks are selected.

For this tutorial, keep all the checks selected.

These checks identify the following problems with your model requirements.

Consistency Check

Identify requirement links with missing documents

Identify requirement links that specify invalid locations within documents

Problem Identified

The Model Advisor cannot find the requirements document. This might indicate a problem with the path to the requirements document.

The Model Advisor cannot find the designated location for the requirement. This check is implemented for:

• Microsoft Word documents

5-4

Validate Requirements Links in a Model

Consistency Check

Identify selection-based links having description fields that do not match their requirements document text

Identify requirement links with path type inconsistent with preferences

Problem Identified

• Microsoft Excel documents

• IBM Rational DOORS documents

• Simulink objects

The Description field for the link does not match the requirements document text.

When you create selection-based links, the

Requirements Management Interface (RMI) saves the selected text in the link Description field. This check is implemented for:

• Microsoft Word documents

• Microsoft Excel documents

• IBM Rational DOORS documents

• Simulink objects

The path to the requirements document does not match the Document file reference field in the Requirements Settings dialog box Selection

Linking tab. This might indicate a problem with the path to the requirements document.

On Linux ® systems, this check is named

Identify requirement links with absolute

path type. The check reports a warning for each requirements links that uses an absolute path.

Note: For information about how the RMI resolves the path to the requirements document,

see “Document Path Storage” on page 5-15.

The Model Advisor checks to see if any applications that have link targets are running:

• If your model has links to Microsoft Word or Microsoft Excel documents, the consistency check requires that you close all instances of those applications.

If you have one of these applications open, it displays a warning and does not

5-5

5

Requirements Links Maintenance continue the checks. The consistency checks must verify up-to-date stored copies of the requirements documents.

• If your model has links to DOORS requirements, you must be logged in to the

DOORS software. Your DOORS database must include the module that contains the target requirements.

3 For this tutorial, make sure that you close both Microsoft Word and Microsoft Excel.

4

Click Run Selected Checks.

After the check is complete:

• The green circles with the check mark indicate that two checks passed.

• The yellow triangles with the exclamation point indicate that two checks generated warnings.

The right-hand pane shows that two checks passed and two checks had warnings.

The pane includes a link to the HTML report.

5-6

Keep the Model Advisor open. The next section describes how to interpret and fix the inconsistent links.

Note: To step through an example that uses the Model Advisor to check requirements links in an IBM Rational DOORS database, run the Managing Requirements for

Fault-Tolerant Fuel Control System (IBM Rational DOORS) example in the MATLAB command prompt.

Validate Requirements Links in a Model

Fix Invalid Requirements Links Detected by the Model Advisor

In “Check Requirements Links with the Model Advisor” on page 5-4,

three requirements consistency checks generate warnings in the slvnvdemo_fuelsys_officereq

model.

Resolve Warning: Identify requirement links that specify invalid locations within documents

To fix the warning about attempting to link to an invalid location in a requirements document:

1 In the Model Advisor, select Identify requirement links that specify invalid

locations within documents to display the description of the warning.

This check identifies a link that specifies a location that does not exist in the Microsoft Word requirements document, slvnvdemo_FuelSys_DesignDescription.docx

. The link originates in the

Terminator1 block. In this example, the target location in the requirements document was deleted after the requirement was created.

2 Get more information about this link: a

To navigate to the Terminator1 block, under Block, click the hyperlink.

b

To open the “Requirements Traceability Link Editor” for this link, under

Requirements, click the hyperlink.

3 To fix the problem from the Requirements Traceability Link Editor, do one of the following:

5-7

5

Requirements Links Maintenance

• In the Location field, specify a valid location in the requirements document.

• Delete the requirements link by selecting the link and clicking Delete.

4 In the Model Advisor, select the Requirements Consistency Checking category of checks.

5

Click Run Selected Checks again, and verify that the warning no longer occurs.

Resolve Warning: Identify selection-based links having description fields that do not match their requirements document text

To fix the warnings about the Description field not matching the requirements document text:

1

In the Model Advisor, click Identify selection-based links having description

fields that do not match their requirements document text to display the description of the warning.

5-8

Validate Requirements Links in a Model

The first message indicated that the model contains a link to a bookmark named

Simulink_requirement_item_7 in the requirements document that does not exist.

In addition, this check identified the following mismatching text between the requirements blocks and the requirements document:

• The Description field in the Test inputs Signal Builder block link is Normal

mode of operation. The requirement text is The simulation is run with a throttle input that ramps from 10 to 20 degrees over a period of two

5-9

5

Requirements Links Maintenance seconds, then back to 10 degrees over the next two seconds. This cycle repeats continuously while the engine is held at a constant speed.

• The Description field in the MAP Estimate block link is Manifold pressure failure. The requirement text in slvnvdemo_FuelSys_DesignDescription.docx

is Manifold pressure

failure mode.

2 Get more information about this link: a To navigate to a block, under Block, click the hyperlink.

b To open the “Requirements Traceability Link Editor” for this link, under

Current Description, click the hyperlink.

3 Fix this problem in one of two ways:

• In the Model Advisor, click Update. This action automatically updates the

Description field for that link so that it matches the requirement.

• In the Link Editor, manually edit the link from the block so that the Description field matches the selected requirements text.

4 In the Model Advisor, select the Requirements Consistency Checking category of checks.

5 Click Run Selected Checks again, and verify that the warning no longer occurs.

5-10

Validate Requirements Links in a Requirements Document

Validate Requirements Links in a Requirements Document

In this section...

“Check Links in a Requirements Document” on page 5-11

“When Multiple Objects Have Links to the Same Requirement” on page 5-12

“Fix Invalid Links in a Requirements Document” on page 5-13

Check Links in a Requirements Document

To check the links in a requirements document:

1 At the MATLAB command prompt, enter rmi('checkdoc', docName) docName

is a string that represents one of the following:

• Module ID for a DOORS requirements document

• Full path name for a Microsoft Word requirements document

• Full path name for a Microsoft Excel requirements document

The rmi function creates and displays an HTML report that lists all requirements links in the document.

The report highlights invalid links in red. For each invalid link, the report includes brief details about the problem and a hyperlink to the invalid link in the requirements document. The report groups together links that have the same problem.

2 Double-click the hyperlink under Document content to open the requirements document at the invalid link.

The navigation controls for the invalid link has a different appearance than the navigation controls for the valid links.

3 When there are invalid links in your requirements document, you have the following options:

5-11

5

Requirements Links Maintenance

If you want to...

Fix the invalid links

Do the following...

Follow the instructions in “Fix Invalid

Links in a Requirements Document” on page 5-13.

Save the requirements document.

Keep the changes to the navigation controls without fixing the invalid links

Ignore the invalid links Close the requirements document without saving it.

When Multiple Objects Have Links to the Same Requirement

When you link multiple objects to the same requirement, as described in “Link Multiple

Model Objects to a Requirements Document”, only one navigation object is inserted into the requirements document. When you double-click that navigation object, all of the linked model objects are highlighted.

If you check the requirements document using the 'checkdoc' option of the rmi function and the check detects a navigation object that points to multiple objects, the check stops and displays the following dialog box.

5-12

You have two options:

• If you click Yes, or you close this dialog box, the RMI creates additional navigation objects, one for each model object that links to that requirement. The document check continues, but the RMI does not recheck that navigation; the report only shows one

Validate Requirements Links in a Requirements Document link for that requirement. To rerun the check so that all requirements are checked, at the top of the report, click Refresh.

• If you click No, the document check continues, and the report identifies that navigation object as a broken link.

Fix Invalid Links in a Requirements Document

Using the report that the rmi function creates, you may be able to fix the invalid links in your requirements document.

In the following example, rmi cannot locate the model specified in two links.

To fix invalid links:

1 In the report, under Document content, click the hyperlink associated with the invalid requirement link.

The requirements document opens with the requirement text highlighted.

2 In the requirements document, depending on the document format, take these steps:

• In DOORS: a

Select the navigation control for an invalid link.

b Select MATLAB > Select item.

• In Microsoft Word, double-click the navigation control.

A dialog box opens that allows you to fix, reset, or ignore all the invalid links with a given problem.

3 Click one of the following options.

5-13

5

Requirements Links Maintenance

To...

Navigate to and select a new target model or new target objects for these broken links.

Reset the navigation controls for these invalid links to their original state, the state before you checked the requirements document.

Make no changes to the requirements document.

Any modifications rmi made to the navigation controls remain in the requirements document.

Click...

Fix all

Reset all

Cancel

4 Save the requirements document to preserve the changes made by the rmi function.

5-14

Document Path Storage

Document Path Storage

When you create a requirements link, the RMI stores the location of the requirements document with the link. If you use selection-based linking or browse to select a requirements document, the RMI stores the document location as specified by the

Document file reference option on the Requirements Settings dialog box, Selection

Linking tab. The available settings are:

• Absolute path

• Path relative to current folder

• Path relative to model folder

• Filename only (on MATLAB path)

You can also manually enter an absolute or relative path for the document location. A relative path can be a partial path or no path at all, but you must specify the file name of the requirements document. If you use a relative path, the document is not constrained to a single location in the file system. With a relative path, the RMI resolves the exact location of the requirements document in this order:

1

The software attempts to resolve the path relative to the current MATLAB folder.

2 When there is no path specification and the document is not in the current folder, the software uses the MATLAB search path to locate the file.

3 If the RMI cannot locate the document relative to the current folder or the MATLAB search path, the RMI resolves the path relative to the model file folder.

The following examples illustrate the procedure for locating a requirements document.

Relative (Partial) Path Example

Current MATLAB folder

Model file

Document link

Documents searched for

(in order)

C:\work\scratch

C:\work\models\controllers\pid.mdl

..\reqs\pid.html

C:\work\reqs\pid.html

C:\work\models\reqs\pid.html

Relative (No) Path Example

Current MATLAB folder

C:\work\scratch

5-15

5

Requirements Links Maintenance

Model file

Requirements document

Documents searched for

(in order)

C:\work\models\controllers\pid.mdl

pid.html

C:\work\scratch\pid.html

<MATLAB path dir>\pid.html

C:\work\models\controllers\pid.html

Absolute Path Example

Current MATLAB folder

Model file

Requirements document

Documents searched for

C:\work\scratch

C:\work\models\controllers\pid.mdl

C:\work\reqs\pid.html

C:\work\reqs\pid.html

5-16

Delete Requirements Links from Simulink Objects

Delete Requirements Links from Simulink Objects

In this section...

“Delete a Single Link from a Simulink Object” on page 5-17

“Delete All Links from a Simulink Object” on page 5-17

“Delete All Links from Multiple Simulink Objects” on page 5-18

Delete a Single Link from a Simulink Object

If you have an obsolete link to a requirement, delete it from the model object.

To delete a single link to a requirement from a Simulink model object:

1

Right-click a model object and select Requirements Traceability > Open Link

Editor.

2 In the top-most pane of the Link Editor, select the link that you want to delete.

3 Click Delete.

4 Click Apply or OK to complete the deletion.

Delete All Links from a Simulink Object

To delete all links to requirements from a Simulink model object:

1

Right-click the model object and select Requirements Traceability > Delete All

Links

2

Click OK to confirm the deletion.

This action deletes all requirements at the top level of the object. For example, if you delete requirements for a subsystem, this action does not delete any requirements for objects inside the subsystem; it only deletes requirements for the subsystem itself. To delete requirements for child objects inside a subsystem, Model block, or

Stateflow chart, you must navigate to each child object and perform these steps for each object from which you want to delete requirements.

5-17

5

Requirements Links Maintenance

Delete All Links from Multiple Simulink Objects

To delete all requirements links from a group of Simulink model objects in the same model diagram or Stateflow chart:

1 Select the model objects whose requirements links you want to delete.

2 Right-click one of the objects and select Requirements Traceability > Delete All.

3 Click OK to confirm the deletion.

This action deletes all requirements at the top level of each object. It does not delete requirements for child objects inside subsystems, Model blocks, or Stateflow charts.

5-18

Requirements Links for Library Blocks and Reference Blocks

Requirements Links for Library Blocks and Reference Blocks

In this section...

“Introduction to Library Blocks and Reference Blocks” on page 5-19

“Library Blocks and Requirements” on page 5-19

“Copy Library Blocks with Requirements” on page 5-20

“Manage Requirements on Reference Blocks” on page 5-20

“Manage Requirements Inside Reference Blocks” on page 5-21

“Links from Requirements to Library Blocks” on page 5-24

Introduction to Library Blocks and Reference Blocks

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.

Note: For more information about reference blocks and library links, see “Libraries” in the Simulink documentation.

Library Blocks and Requirements

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.

5-19

5

Requirements Links Maintenance

Copy Library Blocks with Requirements

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.

Manage Requirements on Reference Blocks

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.

For example, in the following graphic, right-clicking the reference block shows that the reference block has locally created requirements links and requirements links on the library 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:

Speed sensor

Throttle sensor

Oxygen sensor

5-20

Requirements Links for Library Blocks and Reference Blocks

Manage Requirements Inside Reference Blocks

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:

1 Within a library you have a subsystem S1. Drag S1 to a model, creating a new subsystem. This subsystem is the reference block.

5-21

5

Requirements Links Maintenance

5-22

Library

S1 Library block

Model 1

Reference block

S1

Library link

2 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 select Diagram > Library Link > Disable Link.

3 Create a link from the object inside the reference block to the requirements document.

Library

S1

Library block

Model 1

Reference block

S1

Disabled library link

Link to requirement

Requirement

Requirements

document

Note: 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.

4 Resolve the library link between the reference block and the library block:

Requirements Links for Library Blocks and Reference Blocks a Select the reference block.

b

Select Diagram > Library Link > Resolve Link.

c In the Action column, click Push.

d

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.

Restored library link

Library

S1

Library block

Link to requirement Model 1

Reference block

S1

Link to requirement

Requirement

Requirements

document

Note: 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.

5 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.

5-23

5

Requirements Links Maintenance

Model 1

Reference block

S1

Library link

Library model

S1

Library block

Link to requirement

Library link

Model 2

S1

Reference block

Link to requirement

Requirement

Requirements

document

Link to requirement

Links from Requirements to Library Blocks

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.

5-24

Requirements Links for Library Blocks and Reference Blocks

Library

B1

Library block

Links to and from a requirement

Requirement

Requirements

document

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.

Library

Model

Reference block

B1

B1

Library block

Library link

Links to and from a requirement

Link to requirement

Requirement

Requirements

document

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.

5-25

IBM Rational DOORS Surrogate

Module Synchronization

6

• “Synchronization with DOORS Surrogate Modules” on page 6-2

• “Advantages of Synchronizing Your Model with a Surrogate Module” on page 6-4

• “Synchronize a Simulink Model to Create a Surrogate Module” on page 6-5

• “Create Links Between Surrogate Module and Formal Module in a DOORS Database” on page 6-7

• “Customize DOORS Synchronization” on page 6-8

• “Resynchronize DOORS Surrogate Module to Reflect Model Changes” on page

6-15

• “Navigate with the Surrogate Module” on page 6-17

6

IBM Rational DOORS Surrogate Module Synchronization

Synchronization with DOORS Surrogate Modules

Synchronization is a user-initiated process that creates or updates a DOORS surrogate module. A surrogate module is a DOORS formal module that is a representation of a

Simulink model hierarchy.

When you synchronize a model for the first time, the DOORS software creates a surrogate module. The surrogate module contains a representation of the model, depending on your synchronization settings. (To learn how to customize the links and

level of detail in the synchronization, see “Customize DOORS Synchronization” on page

6-8.)

If you create or remove model objects or links, keep your surrogate module up to date by resynchronizing. The updated surrogate module reflects any changes in the requirements links since the previous synchronization.

Note The RMI and DOORS software both use the term object. In the RMI, and in this document, the term object refers to a Simulink model or block, or to a Stateflow chart or its contents.

In the DOORS software, object refers to numbered elements in modules. The DOORS software assigns each of these objects a unique object ID. In this document, these objects are referred to as DOORS objects.

You use standard DOORS capabilities to navigate between the Simulink objects in the surrogate module and requirements in other formal modules. The surrogate module facilitates navigation between the Simulink model object and the requirements, as the following diagram illustrates.

6-2

Synchronization with DOORS Surrogate Modules

Objects in a Simulink Model

DOORS Formal Module(s) with Requirements

Object ID

D1

D2

D3

Requirement

1

1.1

1.2

Requirement Name

Requirement text ...

...

...

Requirement text ...

Enter requirements in the DOORS formal module and link them to objects in the

DOORS surrogate module, so you can navigate from requirements to Simulink objects.

DOORS Surrogate Module

Object ID

200

202

203

204

205

206

207

208

Block Name

1

1.1

1.1.1

1.1.2

1.1.3

1.2

1.2.1

1.3

Model

Subsystem

Block

Block

Block

Subsystem

Block

Block

A surrogate module is a representation of a Simulink model hierarchy.

6-3

6

IBM Rational DOORS Surrogate Module Synchronization

Advantages of Synchronizing Your Model with a Surrogate

Module

Synchronizing your Simulink model with a surrogate module offers the following advantages:

• You can navigate from a requirement to a Simulink object without modifying the requirements modules.

• You avoid cluttering your requirements modules with inserted navigation objects.

• The DOORS database contains complete information about requirements links. You can review requirements links and verify traceability, even if the Simulink software is not running.

• You can use DOORS reporting features to analyze requirements coverage.

• You can separate the requirements tracking work from the Simulink model developers' work, as follows:

• Systems engineers can establish requirements links to models without using the

Simulink software.

• Model developers can capture the requirements information using synchronization and store it with the model.

• You can resynchronize a model with a new surrogate module, updating any model changes or specifying different synchronization options.

6-4

Synchronize a Simulink Model to Create a Surrogate Module

Synchronize a Simulink Model to Create a Surrogate Module

The first time that you synchronize your model with the DOORS software, the DOORS software creates a surrogate module.

In this tutorial, you synchronize the sf_car model with the DOORS software.

Note: Before you begin, make sure you know how to create links from a Simulink model object to a requirement in a DOORS database. For a tutorial on creating links to DOORS

requirements, see “Link to Requirements in IBM Rational DOORS Databases” on page

2-32.

1

To create a surrogate module, start the DOORS software and open a project. If the

DOORS software is not already running, start the DOORS software and open a project.

2

Open the sf_car model.

3

Rename the model to sf_car_doors, and save the model in a writable folder.

4

Create links to a DOORS formal module from two objects in sf_car_doors:

• The transmission subsystem

• The engine torque block inside the Engine subsystem

5 Save the changes to the model.

6 In the Simulink Editor, select Analysis > Requirements Traceability >

Synchronize with DOORS.

The DOORS synchronization settings dialog box opens.

7

For this tutorial, accept the default synchronization options.

The default option under Extra mapping additionally to objects with links,

None

, creates objects in the surrogate module only for the model and any model objects with links to DOORS requirements.

Note:

For more information about the synchronization options, see “Customize

DOORS Synchronization” on page 6-8.

8

Click Synchronize to create and open a surrogate module for all DOORS requirements that have links to objects in the sf_car_doors model.

6-5

6

IBM Rational DOORS Surrogate Module Synchronization

After synchronization with the None option, the surrogate module, a formal module named sf_car_doors, contains:

• A top-level object for the model (sf_car_doors)

• Objects that represent model objects with links to DOORS requirements

(transmission, engine torque), and their parent objects (Engine).

9 Save the surrogate module and the model.

6-6

Create Links Between Surrogate Module and Formal Module in a DOORS Database

Create Links Between Surrogate Module and Formal Module in a

DOORS Database

The surrogate module is the interface between the DOORS formal module that contains your requirements and the Simulink model. To establish links between the surrogate module and the requirements module, copy the link information from the model to the surrogate module:

1 Open the sf_car_doors model.

2 In the Simulink Editor, select Analysis > Requirements Traceability >

Synchronize with DOORS.

3 In the DOORS synchronization settings dialog box, select two options:

Update links during synchronization

from Simulink to DOORS.

4 Click Synchronize.

The RMI creates links from the DOORS surrogate module to the formal module.

These links correspond to links from the Simulink model to the formal module. In this example, the DOORS software copies the links from the engine torque block and transmission subsystems to the formal module, as indicated by the red triangles.

6-7

6

IBM Rational DOORS Surrogate Module Synchronization

Customize DOORS Synchronization

In this section...

“DOORS Synchronization Settings” on page 6-8

“Resynchronize a Model with a Different Surrogate Module” on page 6-10

“Customize the Level of Detail in Synchronization” on page 6-11

“Resynchronize to Include All Simulink Objects” on page 6-12

DOORS Synchronization Settings

When you synchronize your Simulink model with a DOORS database, you can:

• Customize the level of detail for your surrogate module.

• Update links in the surrogate module or in the model to verify the consistency of requirements links among the model, and the surrogate and formal modules.

The DOORS synchronization settings dialog box provides the following options during synchronization.

DOORS Settings Option Description

DOORS surrogate module path and name Specifies a unique DOORS path to a new or an existing surrogate module.

Extra mapping additionally to objects with links

Update links during synchronization

For information about how the RMI resolves the path to the requirements document, see

“Document Path Storage” on page 5-15.

Determines the completeness of the Simulink model representation in the DOORS surrogate module. None specifies synchronizing only those Simulink objects that have linked requirements, and their parent objects. For more information about these synchronization

options, see “Customize the Level of Detail in

Synchronization” on page 6-11.

Specifies updating any unmatched links the

RMI encounters during synchronization, as designated in the Copy unmatched links and

Delete unmatched links options.

6-8

DOORS Settings Option

Copy unmatched links

Delete unmatched links

Save DOORS surrogate module

Customize DOORS Synchronization

Description

During synchronization, selecting the following options has the following results:

from Simulink to DOORS: For links between the model and the formal module, the RMI creates matching links between the

DOORS surrogate and formal modules.

from DOORS to Simulink: For links between the DOORS surrogate and formal modules, the RMI creates matching links between the model and the DOORS modules.

During synchronization, selecting the following options has the following results:

Remove unmatched in DOORS: For links between the formal and surrogate modules, when there is not a corresponding link between the model and the DOORS modules, the RMI deletes the link in DOORS.

This option is available only if you select the

from Simulink to DOORS option.

Remove unmatched in Simulink: For links between the model and the DOORS modules, when there is not a corresponding link between the formal and surrogate modules, the RMI deletes the link from the model.

This option is available only if you select the

from DOORS to Simulink option.

After the synchronization, saves changes to the surrogate module and updates the version of the surrogate module in the DOORS database.

6-9

6

IBM Rational DOORS Surrogate Module Synchronization

DOORS Settings Option

Save Simulink model (recommended)

Description

After the synchronization, saves changes to the model. If you use a version control system, selecting this option changes the version of the model.

Resynchronize a Model with a Different Surrogate Module

You can synchronize the same Simulink model with a new DOORS surrogate module.

For example, you might want the surrogate module to contain only objects that have requirements to DOORS, rather than all objects in the model. In this case, you can change the synchronization options to reduce the level of detail in the surrogate module:

1 In the DOORS synchronization settings dialog box, change the DOORS surrogate

module path and name to the path and name of the new surrogate module in the

DOORS database.

2

Specify a module with either a relative path (starting with ./) or a full path

(starting with /).

The software appends relative paths to the current DOORS project. Absolute paths must specify a project and a module name.

When you synchronize a model, the RMI automatically updates the DOORS

surrogate module path and name with the actual full path. The RMI saves the unique module ID with the module.

3

If you select a new module path or if you have renamed the surrogate module, and you click Synchronize, the Requirements: Surrogate Module Mismatch dialog box opens.

6-10

Customize DOORS Synchronization

4 Click Continue to create a new surrogate module with the new path or name.

Customize the Level of Detail in Synchronization

You can customize the level of detail in a surrogate module so that the module reflects the full or partial Simulink model hierarchy.

In “Synchronize a Simulink Model to Create a Surrogate Module” on page 6-5, you

synchronized the model with the Extra mapping additionally to objects with links option set to None. As a result, the surrogate module contains only Simulink objects that have requirement links, and their parent objects. Additional synchronization options, described in this section, can increase the level of surrogate detail. Increasing the level of surrogate detail can slow down synchronization.

The Extra mapping additionally to objects with links option can have one of the following values. Each subsequent option adds additional Simulink objects to the surrogate module. You choose None to minimize the surrogate size or Complete to create a full representation of your model. The Complete option adds all Simulink objects to the surrogate module, creating a one-to-one mapping of the Simulink model in the surrogate module. The intermediate options provide more levels of detail.

Drop-Down List Option

None (Recommended for better performance)

Minimal - Non-empty unmasked subsystems and Stateflow charts

Description

Maps only Simulink objects that have requirements links and their parent objects to the surrogate module.

Adds all nonempty Stateflow charts and unmasked

Simulink subsystems to the surrogate module.

6-11

6

IBM Rational DOORS Surrogate Module Synchronization

Drop-Down List Option

Moderate - Unmasked subsystems, Stateflow charts, and superstates

Average - Nontrivial Simulink blocks, Stateflow charts and states

Extensive - All unmasked blocks, subsystems, states and transitions

Complete - All blocks, subsystems, states and transitions

Description

Adds Stateflow superstates to the surrogate module.

Adds all Stateflow charts and states and Simulink blocks, except for trivial blocks such as ports, bus objects, and data-type converters, to the surrogate module.

Adds all unmasked blocks, subsystems, states, and transitions to the surrogate module.

Copies all blocks, subsystems, states, and transitions to the surrogate module.

Resynchronize to Include All Simulink Objects

This tutorial shows how you can include all Simulink objects in the DOORS surrogate module. Before you start these steps, make sure you have completed the tutorials

“Synchronize a Simulink Model to Create a Surrogate Module” on page 6-5 and “Create

Links Between Surrogate Module and Formal Module in a DOORS Database” on page

6-7.

1

Open the sf_car_doors model that you synchronized in “Synchronize a Simulink

Model to Create a Surrogate Module” on page 6-5 and again in “Create Links

Between Surrogate Module and Formal Module in a DOORS Database” on page 6-7.

2 In the Simulink Editor, select Analysis > Requirements Traceability >

Synchronize with DOORS.

The DOORS synchronization settings dialog box opens.

3 Resynchronize with the same surrogate module, making sure that the DOORS

surrogate module path and name specifies the surrogate module path and name

that you used in “Synchronize a Simulink Model to Create a Surrogate Module” on page 6-5.

For information about how the RMI resolves the path to the requirements document,

see “Document Path Storage” on page 5-15.

6-12

Customize DOORS Synchronization

4 Update the surrogate module to include all objects in your model. To do this, under

Extra mapping additionally to objects with links, from the drop-down list, select Complete - All blocks, subsystems, states and transitions.

5 Click Synchronize.

After synchronization, the DOORS surrogate module for the sf_car_doors model opens with the updates. All Simulink objects and all Stateflow objects in the sf_car_doors

model are now mapped in the surrogate module.

6-13

6

IBM Rational DOORS Surrogate Module Synchronization

6 Scroll through the surrogate module. Notice that the objects with requirements (the engine torque block and transmission subsystem) retain their links to the DOORS formal module, as indicated by the red triangles.

7 Save the surrogate module.

Detailed Information About The Surrogate Module You Created

Notice the following information about the surrogate module that you created in

“Resynchronize to Include All Simulink Objects” on page 6-12:

• The name of the surrogate module is sf_car_doors, as you specified in the DOORS synchronization settings dialog box.

• DOORS object headers are the names of the corresponding Simulink objects.

• The Block Type column identifies each object as a particular block type or a subsystem.

• If you delete a previously synchronized object from your Simulink model and then resynchronize, the Block Deleted column reads true. Otherwise, it reads false.

These objects are not deleted from the surrogate module. The DOORS software retains these surrogate module objects so that the RMI can recover these links if you later restore the model object.

• Each Simulink object has a unique ID in the surrogate module. For example, the ID for the surrogate module object associated with the Mux block in the preceding figure is 11.

• Before the complete synchronization, the surrogate module contained the transmission subsystem, with an ID of 3. After the complete synchronization, the transmission object retains its ID (3), but is listed farther down in the surrogate module. This order reflects the model hierarchy. The transmission object in the surrogate module retains the red arrow that indicates that it links to a DOORS formal module object.

6-14

Resynchronize DOORS Surrogate Module to Reflect Model Changes

Resynchronize DOORS Surrogate Module to Reflect Model

Changes

If you change your model after synchronization, the RMI does not display a warning message. If you want the surrogate module to reflect changes to the Simulink model, resynchronize your model.

In this tutorial, you add a new block to the sf_car_doors model, and later delete it, resynchronizing after each step:

1 In the sf_car_doors model, make a copy of the vehicle mph (yellow) & throttle %

Scope block and paste it into the model. The name of the new Scope block is vehicle mph (yellow) & throttle %1.

2

Select Analysis > Requirements Traceability > Synchronize with DOORS.

3 In the DOORS synchronization settings dialog box, leave the Extra mapping

additionally to objects with links option set to Complete - All blocks, subsystems, states, and transitions

. Click Synchronize.

After the synchronization, the surrogate module includes the new block.

4 In the sf_car_doors model, delete the newly added Scope block and resynchronize.

The block that you delete appears at the bottom of the list of objects in the surrogate module. Its entry in the Block Deleted column reads True.

6-15

6

IBM Rational DOORS Surrogate Module Synchronization

5 Delete the copied object (vehicle mph (yellow) & throttle %1 and resynchronize the model.

6 Save the surrogate module.

7 Save the sf_car_doors model.

6-16

Navigate with the Surrogate Module

Navigate with the Surrogate Module

In this section...

“Navigate Between Requirements and the Surrogate Module in the DOORS Database” on page 6-17

“Navigate Between DOORS Requirements and the Simulink Module via the Surrogate

Module” on page 6-18

Navigate Between Requirements and the Surrogate Module in the

DOORS Database

The surrogate module and the requirements in the formal module are both in the

DOORS database. When you synchronize your model, the DOORS software creates links between the surrogate module objects and the requirements in the DOORS database.

Navigating between the requirements and the surrogate module allows you to review the requirements that have links to the model without starting the Simulink software.

To navigate from the surrogate module transmission object to the requirement in the formal module:

1 In the surrogate module object for the transmission subsystem, right-click the rightfacing red arrow.

2

Select the requirement name.

The formal module opens, at the Transmission Requirements object.

To navigate from the requirement in the formal module to the surrogate module:

1

In the Transmission Requirements object in the formal module, right-click the leftfacing orange arrow.

6-17

6

IBM Rational DOORS Surrogate Module Synchronization

6-18

2 Select the object name.

The surrogate module for sf_car_doors opens, at the object associated with the transmission subsystem.

Navigate Between DOORS Requirements and the Simulink Module via the

Surrogate Module

You can create links that allow you to navigate from Simulink objects to DOORS requirements and from DOORS requirements to the model. If you synchronize your model, the surrogate module serves as an intermediary for the navigation in both directions. The surrogate module allows you to navigate in both directions even if you remove the direct link from the model object to the DOORS formal module.

Navigate from a Simulink Object to a Requirement via the Surrogate Module

To navigate from the transmission subsystem in the sf_car_doors model to a requirement in the DOORS formal module:

1

In the sf_car_doors model, right-click the transmission subsystem and select

Requirements Traceability > 1. “DOORS Surrogate Item”. (The direct link to the DOORS formal module is also available.)

The surrogate module opens, at the object associated with the transmission subsystem.

2 To display the individual requirement, in the surrogate module, right-click the rightfacing red arrow and select the requirement.

The formal module opens, at Transmission Requirements.

Navigate with the Surrogate Module

Navigate from a Requirement to the Model via the Surrogate Module

To navigate from the Transmission Requirements requirement in the formal module to the transmission subsystem in the sf_car_doors model:

1 In the formal module, in the Transmission Requirements object, right-click the left-facing orange arrow.

2 Select the path to the linked surrogate object: /sf_car Project/sf_car_doors > 4.

transmission.

The surrogate module opens, at the transmission object.

3 In the surrogate module, select MATLAB > Select item.

The linked object is highlighted in sf_car_doors.

6-19

Navigation from Requirements

Documents

• “IBM Rational DOORS” on page 7-2

• “Microsoft Office” on page 7-10

7

7

Navigation from Requirements Documents

IBM Rational DOORS

In this section...

“Why Add Navigation Objects to DOORS Requirements?” on page 7-2

“Configure Requirements Management Interface for DOORS Software” on page 7-2

“Enable Linking from DOORS Databases to Simulink Objects” on page 7-4

“Insert Navigation Objects into DOORS Requirements” on page 7-5

“Customize DOORS Navigation Objects” on page 7-7

“Navigate Between DOORS Requirement and Model Object” on page 7-8

“Diagnose and Fix DXL Errors” on page 7-9

Why Add Navigation Objects to DOORS Requirements?

IBM Rational DOORS software is a requirements management application that you use to capture, track, and manage requirements. The Requirements Management

Interface (RMI) allows you to link Simulink objects to requirements managed by external applications, including the DOORS software.

When you create a link from a Simulink object to a DOORS requirement, the RMI stores the link data in Simulink. Using this link, you can navigate from the Simulink object to its associated requirement.

You can also configure the RMI to insert a navigation object in the DOORS database.

This navigation object serves as a link from the DOORS requirement to its associated

Simulink object.

To insert navigation objects into a DOORS database, you must have write access to the

DOORS database.

Configure Requirements Management Interface for DOORS Software

• “Before You Begin” on page 7-2

• “Manually Install Additional Files for DOORS Software” on page 7-3

Before You Begin

If you plan to use DOORS software with the RMI, make sure to install additional files to establish communication between the DOORS application and the Simulink software.

7-2

IBM Rational DOORS

Follow the instructions in “Configure RMI for IBM Rational DOORS or Microsoft ActiveX

Navigation” on page 2-12.

Manually Install Additional Files for DOORS Software

The setup script automatically copies the required DOORS files to the installation folders. However, the script might fail because of file permissions in your DOORS installation. If the script fails, change the file permissions on the DOORS installation folders and rerun the script.

You can also manually install the required files into the specified folders, as described in the following steps:

1 If the DOORS software is running, close the application.

2

Copy the following files from matlabroot\toolbox\slvnv\reqmgt to the

<doors_install_dir>\lib\dxl\addins

folder.

addins.idx

addins.hlp

If you have not modified the files, replace any existing versions of the files; otherwise, merge the contents of both files into a single file.

3 Copy the following files from matlabroot\toolbox\slvnv\reqmgt to the

<doors_install_dir>\lib\dxl\addins\dmi

folder.

dmi.hlp

dmi.idx

dmi.inc

runsim.dxl

selblk.dxl

Replace any existing versions of these files.

4 Open the <doors_install_dir>\lib\dxl\startup.dxl file. In the user-defined files section, add the following include statement:

#include <addins/dmi/dmi.inc>

If you upgrade from Version 7.1 to a later version of the DOORS software, perform these additional steps: a In your DOORS installation folder, navigate to the ...\lib\dxl

\startupFiles

subfolder.

7-3

7

Navigation from Requirements Documents b In a text editor, open the copiedFromDoors7.dxl file.

c Add // before this line to comment it out:

#include <addins/dmi/dmi.inc> d Save and close the file.

5 Start the DOORS and MATLAB software.

6 Run the setup script using the following MATLAB command.

rmi setup

Enable Linking from DOORS Databases to Simulink Objects

By default, the RMI does not insert navigation objects into requirements documents. If you want to insert a navigation object into the requirements document when you create a link from a Simulink object to a requirement, you must change the RMI’s settings. The following tutorial uses the sldemo_fuelsys example model to illustrate how to do this.

To enable linking from the DOORS database to the example model:

1 Open the model: sldemo_fuelsys

Note: You can modify requirements settings in the Requirements Settings dialog box. These settings are global and not specific to open models. Changes you make apply not only to open models, but also persist for models you subsequently open. For

more information about these settings, see “Requirements Settings” on page 2-16.

2

Select Analysis > Requirements Traceability > Settings.

The Requirements Settings dialog box opens.

3 Click the Selection Linking tab.

4 Select Modify destination for bi-directional linking.

When you enable this option, every time you create a selection-based link from a Simulink object to a requirement, the RMI inserts navigation objects at the designated location. Using this option requires write access to the requirements document.

7-4

IBM Rational DOORS

5 Select Store absolute path to model file.

For this exercise, you save a copy of the example model on the MATLAB path.

If you add requirements to a model that is not on the MATLAB path, you must select this option to enable linking from your requirements document to your model.

6

In the Apply this user tag to new links field, enter one or more user tags to apply to the links that you create.

For more information about user tags, see “User Tags and Requirements Filtering” on page 4-25.

7 Click Close to close the Requirements Settings dialog box. Keep the sldemo_fuelsys

model open.

Insert Navigation Objects into DOORS Requirements

When you enable Modify destination for bi-directional linking as described in

“Enable Linking from DOORS Databases to Simulink Objects” on page 7-4, the RMI

can insert a navigation object into both the Simulink object and its associated DOORS requirement. This tutorial uses the sldemo_fuelsys example model to illustrate how to do this. For this tutorial, you also need a DOORS formal module that contains requirements.

1 Rename the sldemo_fuelsys model and save it in a writable folder on the

MATLAB path.

2 Start the DOORS software and open a formal module that contains requirements.

3

Select the requirement that you want to link to by left-clicking that requirement in the DOORS database.

4 In the sldemo_fuelsys model, select an object in the model.

This example creates a requirement from the fuel_rate_control subsystem.

5 Right-click the Simulink object (in this case, the fuel_rate_control subsystem) and select Requirements Traceability > Link to Selection in DOORS.

The RMI creates the link for the fuel_rate_control subsystem. It also inserts a navigation object into the DOORS formal module—a Simulink reference object ( ) that enables you to navigate from the requirement to the model.

7-5

7

Navigation from Requirements Documents

7-6

6 Close the model.

Note: When you navigate to a DOORS requirement from outside the software, the

DOORS module opens in read-only mode. If you want to modify the DOORS module, open the module using DOORS software.

Insert Navigation Objects to Multiple Simulink Objects

If you have several Simulink objects that correspond to one requirement, you can link them all to that requirement with a single navigation object. This eliminates the need to insert multiple navigation objects for a single requirement. The Simulink objects must be available in the same model diagram or Stateflow chart.

The workflow for linking multiple Simulink objects to one DOORS requirement is as follows:

1

Make sure that you have enabled Modify destination for bi-directional linking.

2 Select the DOORS requirement to link to.

3

Select the Simulink objects that need to link to that requirement.

4 Right-click one of the objects and select Requirements Traceability > Link to

Selection in DOORS.

A single navigation object is inserted at the selected requirement.

5

Double-click the navigation object in DOORS to highlight the Simulink objects that are linked to that requirement.

IBM Rational DOORS

Customize DOORS Navigation Objects

If the RMI is configured to modify destination for bi-directional linking as described in

“Enable Linking from DOORS Databases to Simulink Objects” on page 7-4, the RMI

can insert a navigation object into your requirements document. This object looks like the icon for the Simulink software:

Note: In IBM Rational DOORS requirements documents, clicking a navigation object does not navigate back to your Simulink object. Select MATLAB > Select object to find the Simulink object that contains the requirements link.

To use an icon of your choosing for the navigation object:

1 Select Analysis > Requirements Traceability > Settings.

2 Select the Selection Linking tab.

3 Select Modify destination for bi-directional linking.

Selecting this option enables the Use custom bitmap for navigation controls in

documents option.

4 Select Use custom bitmap for navigation controls in documents.

5 Click Browse to locate the file you want to use for the navigation objects.

For best results, use an icon file (.ico) or a small (16×16 or 32×32) bitmap image (.bmp) file for the navigation object. Other types of image files might give unpredictable results.

6 Select the desired file to use for navigation objects and click Open.

7 Close the Requirements Settings dialog box.

The next time you insert a navigation object into a requirements document, the RMI uses the file you selected.

Tip You can specify a custom template for labels of requirements links to DOORS objects.

For more information, see the rmi command.

7-7

7

Navigation from Requirements Documents

Navigate Between DOORS Requirement and Model Object

In “Insert Navigation Objects into DOORS Requirements” on page 7-5, you created

a link between a DOORS requirement and the fuel_rate_control subsystem in the sldemo_fuelsys

model. Navigate the links in both directions:

1 With the sldemo_fuelsys model closed, go to the DOORS requirement in the formal module.

2 Left-click the Simulink reference object that you inserted to select it.

3 Select MATLAB > Select item.

Your version of the sldemo_fuelsys model opens, with the fuel_rate_control subsystem highlighted.

7-8

4 Log in to the DOORS software.

5 Navigate from the model to the DOORS requirement. In the Model Editor, rightclick the fuel_rate_control subsystem and select Requirements Traceability > 1.

“<requirement name>” where <requirement name> is the name of the DOORS requirement that you created.

The DOORS formal module opens with the requirement object and its child objects highlighted in red.

IBM Rational DOORS

Diagnose and Fix DXL Errors

If you try to synchronize your Simulink model to a DOORS project, you might see the following errors:

-E- DXL: <Line:2> incorrectly concatenated tokens

-E- DXL: <Line:2> undeclared variable (dmiRefreshModule)

-I- DXL: all done with 2 errors and 0 warnings

If you see these errors, exit the DOORS software, rerun the rmi setup command at the

MATLAB command prompt, and restart the DOORS software.

7-9

7

Navigation from Requirements Documents

Microsoft Office

In this section...

“Why Add Navigation Objects to Microsoft Office Requirements?” on page 7-10

“Enable Linking from Microsoft Office Documents to Simulink Objects” on page 7-10

“Insert Navigation Objects in Microsoft Office Requirements Documents” on page

7-11

“Customize Microsoft Office Navigation Objects” on page 7-12

“Navigate Between Microsoft Word Requirement and Model” on page 7-13

“Navigate with Objects Created Using ActiveX in Microsoft Office 2007 and 2010” on page 7-14

Why Add Navigation Objects to Microsoft Office Requirements?

You can use the Microsoft Word and Microsoft Excel applications to capture, track, and manage requirements. The Requirements Management Interface (RMI) allows you to link Simulink objects to requirements managed by external applications.

When you create a link from a Simulink object to a requirement in a Microsoft Office document, the RMI stores the link data in Simulink. Using this link, you can navigate from the Simulink object to its associated requirement.

You can also configure the RMI to insert a navigation object in a Microsoft Office requirements document. This navigation object serves as a link from the requirement to its associated Simulink object.

Enable Linking from Microsoft Office Documents to Simulink Objects

By default, the RMI does not insert navigation objects into requirements documents. If you want to insert a navigation object into the requirements document when you create a link from a Simulink object to a requirement, you must change the RMI’s settings.

The following tutorial uses the slvnvdemo_fuelsys_officereq example model to illustrate how to do this.

The RMI can insert navigation objects into the following Microsoft Office applications:

• Microsoft Excel

• Microsoft Word

7-10

Microsoft Office

To enable linking from a Microsoft Office document to the example model:

1 Open the model: slvnvdemo_fuelsys_officereq

Note: You can modify requirements settings in the Requirements Settings dialog box. These settings are global and not specific to open models. Changes you make apply not only to open models, but also persist for models you subsequently open. For

more information about these settings, see “Requirements Settings” on page 2-16.

2

Select Analysis > Requirements Traceability > Settings.

The Requirements Settings dialog box opens.

3 On the Selection Linking tab of the Requirements Settings dialog box:

• Enable Modify destination for bi-directional linking.

When you select this option, every time you create a selection-based link from a Simulink object to a requirement, the RMI inserts a navigation object at the designated location in the requirements document.

• To specify one or more user tags to apply to the links that you create, in the

Apply this user tag to new links field, enter the tag names.

For more information about user tags, see “User Tags and Requirements

Filtering” on page 4-25.

4

Click Close to close the Requirements Settings dialog box. Keep the slvnvdemo_fuelsys_officereq

model open.

Insert Navigation Objects in Microsoft Office Requirements Documents

Use selection-based linking to create a link from the slvnvdemo_fuelsys_officereq model to a requirements document. If you have configured the RMI as described in

“Enable Linking from Microsoft Office Documents to Simulink Objects” on page 7-10,

the RMI can insert a navigation object into the requirements document.

1

Open the Microsoft Word requirements document:

matlabroot/toolbox/slvnv/rmidemos/fuelsys_req_docs/ slvnvdemo_FuelSys_RequirementsSpecification.docx

7-11

7

Navigation from Requirements Documents

2 Select the Throttle Sensor header.

3

In the slvnvdemo_fuelsys_officereq model, open the engine gas dynamics subsystem.

4 Right-click the Throttle & Manifold subsystem and select Requirements

Traceability > Link to Selection in Word.

5 The RMI inserts an URL-based link into the requirements document.

7-12

Insert Navigation Object That Links to Multiple Simulink Objects

If you have several Simulink objects that correspond to one requirement, you can link them all to that requirement with a single navigation object. This eliminates the need to insert multiple navigation objects for a single requirement. The Simulink objects must be available in the same model diagram or Stateflow chart.

The workflow for linking multiple Simulink objects to one Microsoft Word requirement is as follows:

1 Make sure that the RMI is configured to insert navigation objects into requirements

documents, as described in “Enable Linking from Microsoft Office Documents to

Simulink Objects” on page 7-10.

2

Select the Microsoft Word requirement to link to.

3 Select the Simulink objects that need to link to that requirement.

4 Right-click one of the Simulink objects and select Requirements Traceability >

Link to Selection in Word.

A single navigation object is inserted at the selected requirement.

5

Follow the navigation object link in Microsoft Word to highlight the Simulink objects that are linked to that requirement.

Customize Microsoft Office Navigation Objects

If the RMI is configured to modify destination for bi-directional linking, the RMI inserts a navigation object into your requirements document. This object looks like the icon for the

Simulink software:

Microsoft Office

Note: In Microsoft Office requirements documents, following a navigation object link highlights the Simulink object that contains a bi-directional link to the associated requirement.

To use an icon of your own choosing for the navigation object:

1 Select Analysis > Requirements Traceability > Settings.

2

Select the Selection Linking tab.

3 Select Modify destination for bi-directional linking.

Selecting this option enables the Use custom bitmap for navigation controls in

documents option.

4

Select Use custom bitmap for navigation controls in documents.

5 Click Browse to locate the file you want to use for the navigation objects.

For best results, use an icon file (.ico) or a small (16×16 or 32×32) bitmap image (.bmp) file for the navigation object. Other types of image files might give unpredictable results.

6 Select the desired file to use for navigation objects and click Open.

7

Close the Requirements Settings dialog box.

The next time you insert a navigation object into a requirements document, the RMI uses the file you selected.

Navigate Between Microsoft Word Requirement and Model

In “Insert Navigation Objects in Microsoft Office Requirements Documents” on page

7-11, you created a link between a Microsoft Word requirement and the Throttle &

Manifold subsystem in the slvnvdemo_fuelsys_officereq example model. Navigate these links in both directions:

1

In the slvnvdemo_fuelsys_officereq model, right-click the Throttle & Manifold subsystem and select Requirements Traceability > 1. “Throttle Sensor”.

The requirements document opens, and the header in the requirements document is highlighted.

7-13

7

Navigation from Requirements Documents

2 In the requirements document, next to Throttle Sensor, follow the navigation object link.

The engine gas dynamics subsystem opens, with the Throttle & Manifold subsystem highlighted.

7-14

Navigation from Microsoft Office requirements documents is not automatically enabled upon MATLAB startup. Navigation is enabled when you create a new requirements link or when you have enabled bi-directional linking as described in “Enable Linking from

Microsoft Office Documents to Simulink Objects”. When attempting navigation from requirements links with the icon, if you get a “Server Not Found” or similar message, enter the command rmi('httpLink') to activate the internal MATLAB HTTP server.

Navigate with Objects Created Using ActiveX in Microsoft Office 2007 and 2010

• “Save Requirements Documents to Microsoft Word 2007 or 2010 Format” on page

7-14

• “Field Codes in Requirements Documents” on page 7-16

• “ActiveX Control Does Not Link to Model Object” on page 7-18

• “Delete an ActiveX Control from Microsoft Excel 2007” on page 7-19

• “Delete an ActiveX Control from Microsoft Excel 2010” on page 7-20

Save Requirements Documents to Microsoft Word 2007 or 2010 Format

If you create a requirements document with an earlier version of Microsoft Word than

Word 2007, links to the corresponding Simulink objects automatically work. If you open

Microsoft Office a document created in an earlier version and then save it in Microsoft Word 2007 format, make sure that the links to the models continue to work:

1

Open a requirements document saved in a release of Microsoft Word earlier than

Microsoft Word 2007.

2

Depending on which version of Microsoft Word you are running, do one of the following:

• In Microsoft Word 2007, in the upper-left corner, click the Microsoft Office

Button.

• In Microsoft Word 2010, select the File tab.

3 Select Save As > Word Document.

You see the following dialog box.

4 Click OK.

If you are running Microsoft Word 2007, you see the following dialog box.

5 Click Yes to save the current document in the current Microsoft Word format, with a

.docx

extension.

7-15

7

Navigation from Requirements Documents

Note: You might need to enable ActiveX controls in the Microsoft Office Trust Center.

Field Codes in Requirements Documents

If your Microsoft Word requirements document displays the field codes in addition to, or instead of, the ActiveX icon, clear the Show field codes instead of their values option.

The following graphic shows a requirements document created in Microsoft Word 2003, with the field codes (CONTROL mwSimulink1.SLRefButton \s) displayed.

The following graphic shows a requirements document created in Microsoft Word 2007, with the field codes (CONTROL mwSimulink1.SLRefButton) displayed.

7-16

To hide the field codes and display the ActiveX icon:

1

Depending on which version of Microsoft Word you are running, do one of the following:

• In Microsoft Word 2007, in the upper-left corner, click the Microsoft Office

Button and at the bottom of the window, click Word Options.

Microsoft Office

• In Microsoft Word 2010, select File > Options.

2 In the left-hand portion of the pane, click Advanced.

3

In the Advanced pane, scroll to the Show document content section and clear the

Show field codes instead of their values option.

7-17

7

Navigation from Requirements Documents

ActiveX Control Does Not Link to Model Object

If you click an ActiveX control that links to a Simulink or Stateflow object, and the object does not open, do one of the following:

• Store your requirements documents in trusted locations, as described in the Microsoft

Office 2007 documentation. The Trust Center does not check files for ActiveX controls stored in trusted locations, so you can maintain your Trust Center restrictions.

• Enable ActiveX controls:

1

Depending on which version of Microsoft Office you are using, do one of the following:

• In Microsoft Word 2007 or Microsoft Excel 2007, in the upper-left corner, click the Microsoft Office Button.

In the pane that opens, at the bottom, click Word Options or Excel Options, depending on which program you are running.

• In Microsoft Word 2010 or Microsoft Excel 2010, select File > Options.

2 In the left-hand portion of the pane, click Trust Center.

3

In the Trust Center pane, click Trust Center Settings.

4 In the Trust Center pane, on the right, select ActiveX Settings.

7-18

Microsoft Office

5 Select the setting that you want for ActiveX controls:

Prompt me for enabling all controls with minimal restrictions to decide each time you click an ActiveX control if you want to enable all controls.

Enable all controls without restrictions and without prompting to enable all ActiveX controls whenever you open the document.

6 Close the open dialog boxes.

7 Restart the application for the settings to take effect.

Delete an ActiveX Control from Microsoft Excel 2007

Your document may have an ActiveX control in a worksheet cell:

To remove an ActiveX control from your Microsoft Excel 2007 spreadsheet:

1 In Microsoft Excel 2007, in the upper-left corner, click the Microsoft Office

Button.

7-19

7

Navigation from Requirements Documents

2 In the pane that opens, at the bottom, click Excel Options.

3 In the Microsoft Excel Options dialog box, in the left-hand pane, click Popular.

4

On the Popular pane, in the Top options for working with Excel section, select

Show Developer tab in the Ribbon.

5

Click OK.

6

In the Ribbon, on the Developer tab, select Design Mode.

When you select Design Mode, the ActiveX control is no longer visible in the cell.

7

Click where the ActiveX control was, and you see four handles showing the location of the control.

8 Select Home > Cut to delete the control.

Delete an ActiveX Control from Microsoft Excel 2010

Your document may have an ActiveX control in a worksheet cell:

To remove an ActiveX control from your Microsoft Excel 2010 spreadsheet:

1 Select the control by clicking it.

2 Select Home > Cut to delete the control.

7-20

8

MATLAB Code Traceability

• “Link Between MATLAB Code Lines and Requirements Information in External

Documents” on page 8-2

• “Enable or Disable Highlighting of Traceability Links for MATLAB Code” on page

8-4

• “Remove Traceability Links from MATLAB Code Lines” on page 8-5

• “Traceability for MATLAB Code Lines” on page 8-6

• “Associate Traceability Information with MATLAB Code Lines in Simulink” on page

8-8

8

MATLAB Code Traceability

Link Between MATLAB Code Lines and Requirements Information in

External Documents

In this section...

“Create Link Using Context Menu Shortcuts” on page 8-2

“Create Link Using Link Editor” on page 8-2

Create Link Using Context Menu Shortcuts

To create requirements traceability links from MATLAB code lines to selections in

Microsoft Word, Microsoft Excel, or IBM Rational DOORS documents, you can use shortcuts in the Requirements Traceability context menu.

1 In your requirements document, select the target for the traceability link that you want to create.

2 In the MATLAB Editor, select the line or lines of code that you want to link.

3 In the MATLAB Editor, right-click your selection.

4 From the context menu, select Requirements Traceability. Depending on the type of your requirements document, select one of the following options:

Link to Selection in Word

Link to Selection in Excel

Link to Selection in DOORS

The software creates a traceability link from the selected MATLAB code range to the selection in the requirements document. It also inserts a navigation object for the selection in the requirements document. The navigation object links to the selected

MATLAB code range.

Create Link Using Link Editor

You can create, edit, and delete traceability links with the Link Editor. To open the Link

Editor:

• In the MATLAB Editor, select the line or lines of code that you want to link.

• Right-click your selection.

8-2

Link Between MATLAB Code Lines and Requirements Information in External Documents

• From the context menu, select Requirements Traceability > Open Link Editor.

For detailed information on the Link Editor, see “Requirements Traceability Link

Editor”.

8-3

8

MATLAB Code Traceability

Enable or Disable Highlighting of Traceability Links for MATLAB

Code

In this section...

“Enable Traceability Highlighting of MATLAB Code” on page 8-4

“Disable Traceability Highlighting of MATLAB Code” on page 8-4

Enable Traceability Highlighting of MATLAB Code

To highlight traceability links in your MATLAB code, do one of the following:

• In the View tab, in the Display section, select Highlight Traceability.

• In the MATLAB Editor, right-click in a line of code with a traceability link. From the context menu, select Requirements Traceability > Enable Traceability

Highlighting.

Disable Traceability Highlighting of MATLAB Code

To turn off highlighting of traceability links in your MATLAB code, do one of the following:

• In the View tab, in the Display section, clear Highlight Traceability.

• In the MATLAB Editor, right-click in a line of code with a traceability link. From the context menu, select Requirements Traceability > Disable Traceability

Highlighting.

8-4

Remove Traceability Links from MATLAB Code Lines

Remove Traceability Links from MATLAB Code Lines

In this section...

“Delete Links to Requirements from MATLAB Code Lines” on page 8-5

“Delete Link Targets in MATLAB Code Lines” on page 8-5

Delete Links to Requirements from MATLAB Code Lines

To remove requirements traceability links from a line or lines of MATLAB code:

1

In the MATLAB Editor, right-click within a range of code that has requirements traceability links.

2

From the context menu, select Requirements Traceability > Delete All Links.

All links to requirements from this MATLAB code range are deleted. Links to this

MATLAB code range from external requirements documents are not deleted.

Delete Link Targets in MATLAB Code Lines

If you have links to MATLAB code ranges from external requirements documents, you can delete the targets for these links from your MATLAB code.

To remove requirements traceability targets from a line or lines of MATLAB code, after you have deleted its outgoing links as described in the previous section:

1 In the MATLAB Editor, right-click within a previously linked range of code.

2 From the context menu, select Requirements Traceability > Discard Named

Range.

When you discard a named range, links to that MATLAB code range from external documents no longer work. Note, however, that this does not delete navigation objects in external requirements documents.

8-5

8

MATLAB Code Traceability

Traceability for MATLAB Code Lines

In this section...

“Traceability Link Targets” on page 8-6

“Storage of Traceability Links” on page 8-6

“Limitations of MATLAB Code Traceability” on page 8-7

Traceability Link Targets

You can create MATLAB code traceability links for:

• Lines of MATLAB code in a standalone file.

• Lines of MATLAB code inside a MATLAB Function block.

You can create links from a line or lines of MATLAB code to:

• Objects in Simulink models.

• Targets in Microsoft Word or Microsoft Excel documents.

• Targets in IBM Rational DOORS databases.

• Targets in text, HTML, or PDF documents.

• HTTP URLs.

Bi-directional linking is supported for targets in MATLAB, Simulink, Microsoft Word,

Microsoft Excel, and IBM Rational DOORS. Bi-directional linking creates links to and from the selected link destination. To enable bi-directional linking, in the Requirements

Settings dialog box, under the Selection Linking tab, select Modify destination for bi-

directional linking. For more information, see “Selection Linking Tab”.

You can also create links to MATLAB code lines from any external application that supports HTTP navigation. For more information, see “Link from External Applications”.

Storage of Traceability Links

In a standalone MATLAB file, you can create, navigate, and delete traceability links for lines of code without changing the MATLAB file. The Requirements Management

Interface stores requirements traceability data for a MATLAB file in a .req file with the same name and location as the MATLAB file.

8-6

Traceability for MATLAB Code Lines

If you want to create traceability links for lines of code in a MATLAB Function block, set the parent model to store requirements data externally. For a new model, see “Specify

Storage for Requirements Links”. For an existing model, see “Move Internally Stored

Requirements Links to External Storage”. When you create traceability links for code inside a MATLAB Function block, the RMI stores them in a .req file for the parent model. The .req file for the model contains requirements traceability data for linked model objects and for linked code in MATLAB Function blocks in the model.

Limitations of MATLAB Code Traceability

Overlapping Linked Ranges

The software does not support traceability links for overlapping regions of MATLAB code. If one linked range of code completely overlaps another smaller region of code, the link for the larger range overshadows the link for the smaller range. To avoid complications from overlapping linked ranges, when you create traceability links for

MATLAB code lines, choose ranges of code that do not overlap.

Cut and Paste Operations

You can cut or copy a selection of code that has traceability links. When you paste that selection, the software attempts to recreate the corresponding traceability links at the paste location. Depending on paste location and code formatting, you might need to recreate the traceability links manually.

Drag Operation

If you select code that has traceability links and drag that code to a new location, you might need to recreate traceability links for the code in the new location.

MATLAB Function Block Code Traceability in Web View

Requirements linked to individual MATLAB code lines inside a MATLAB Function block appear in HTML requirements traceability reports, but do not appear the Simulink

Report Generator Web view. See “Create and Use a Web View” in the Simulink Report

Generator documentation.

8-7

8

MATLAB Code Traceability

Associate Traceability Information with MATLAB Code Lines in

Simulink

Traceability management support in the MATLAB Editor is an extension of the

Simulink-based Requirements Management Interface to allow associations between

MATLAB code lines and external artifacts. This capability does not require editing

MATLAB files; all traceability data is stored separately. This is similar to "external" storage of RMI links when working with Simulink models.

In addition, using "external storage" mode for managing traceability information,

Simulink and Stateflow users can benefit from finer granularity when associating external documents with contents of MATLAB Function blocks.

The included example model has traceability data associated both with Simulink blocks and individual code lines of MATLAB Function blocks.

Open Example Model

This example demonstrates linking between external documents and MATLAB code lines when modeling stimulated spiking in connected neural cells.

Open the slvnvdemo_synaptic_transmission model. There are three Model blocks referencing the same model of a spiking neural cell. The neural cell model follows a

"Leaky Integrators" equation:

8-8

For the purpose of simulation, we converted to:

Associate Traceability Information with MATLAB Code Lines in Simulink

Two MATLAB Functions between neurons calculate post-synaptic currents. When presynaptic depolarization crosses the neurotransmitter release threshold, we increment post-synaptic current by one pulse of given amplitude:

Resulting total current decays exponentially according to

We disallow the next increment for a certain timeframe after the previous pulse, to model the effect of short-term synaptic depression. Our model neglects the time delay of axonal transmission.

open_system( 'slvnvdemo_neuron' ); open_system( 'slvnvdemo_synaptic_transmission' );

Loading neural cell parameters

Loading RMI data from ...olbox\slvnv\rmidemos\slvnvdemo_neuron.req

Loading transmission parameters

Loading RMI data from ...demos\slvnvdemo_synaptic_transmission.req

8-9

8

MATLAB Code Traceability

8-10

Associate Traceability Information with MATLAB Code Lines in Simulink

8-11

8

MATLAB Code Traceability

8-12

Simulate Model and View Results

Simulate slvnvdemo_synaptic_transmission model. Check Scope for results. The six plots are:

• externally injected electrical current pulse,

• injection-stimulated intracellular voltage spiking of the first neuron,

• post-synaptic current generated in the second neuron,

• synaptically stimulated activity of the second neuron,

• post-synaptic current generated in the third neuron,

• synaptically stimulated activity of the third neuron.

Observe regular spiking of the upstream neuron (plot 2) while stimulation pulse is applied (plot 1). Synaptically induced current in downstream neuron (plot 3) skips some action potentials of the upstream neuron due to short-term neurotransmitter depletion modeled as a temporary turn-off period in Synaptic current function. Downstream neuron is seen to, sometimes, integrate more than one synaptic input to produce a spike

(plot 4). The third neuron integrates synaptic inputs from the second neuron (plot 5) and spikes at a later time (plot 6). With our default parameter values, the third neuron may spike 1 or more times, depending on intentionally introduced random noise in the model.

We assign same parameter values for all three neurons and both synapses. Traceability linking is used to justify parameter values and implementation.

sim( 'slvnvdemo_synaptic_transmission' );

### Successfully updated the model reference SIM target for model: slvnvdemo_neuron

Navigate Between Simulink and Standalone MATLAB Files

The slvnvdemo_synaptic_transmission model runs an external script to load required parameter values into workspace. MATLAB code linking allows you to trace from a dependent block in Simulink, not only to a script file but to the specific line that defines a value used in simulation.

Locate the Stimulation pulse block in the model. Right-click the block and select

Requirements Traceability > 1. "I_inj = 2e-11; % 20 pA" to follow the link and view the relevant highlighted region in the MATLAB code file. Notice the mismatched value so easily detected via Traceability link. Right-click another highlighted line in the MATLAB

Associate Traceability Information with MATLAB Code Lines in Simulink file and navigate back to Simulink by selecting the shortcut in the Requirements

Traceability context menu.

rmi( 'highlightModel' , 'slvnvdemo_synaptic_transmission' ); rmipref( 'BiDirectionalLinking' ,true);

Create Traceability Link for Lines of MATLAB Code

The Synaptic time constant block in the bottom left corner of the model is not yet linked to its related line in parameters script.

Make sure that bi-directional linking is enabled, so that you can create two-way traceability links in one step. First, in the Simulink Editor, select the Synaptic time constant block. Then, in the MATLAB Editor, select the variable name Syn_decay_time at the bottom of the synaptic_params script. Right-click on the selected line and from the context menu, choose Requirements Traceability > Link to Selection in Simulink.

Test the new links by navigating from MATLAB to Simulink and back to MATLAB.

8-13

8

MATLAB Code Traceability

8-14

Associate Traceability Information with MATLAB Code Lines in Simulink

Create Traceability Link for Lines of Code Inside MATLAB Function Blocks

The slvnvdemo_synaptic_transmission model has a MATLAB Function block that we will want to trace to parameter value sources. Instead of linking the block itself, open the

MATLAB code of this block and link specific lines. For example, in the Simulink Editor, click on the Synaptic strength constant block to select it for linking. In the MATLAB

Editor, find the occurrence of I_amplitude on line 33 of the MATLAB Function block code. Right-click the line and from the Requirements Traceability context menu, select Link to Selection in Simulink.

Create Traceability Link Between Lines in MATLAB Code and Microsoft Word

Until this point we only looked at linking between MATLAB and Simulink. Open the

Ion current calculation MATLAB Function block that belongs to the Sodium current calculation subsystem of the referenced slvnvdemo_neuron model. Right-click on a highlighted line or lines and from the Requirements Traceability context menu, navigate a link at the top. The associated Word document opens to the associated text.

To create a similar link in another MATLAB Function block of this model, Ion current calculation Function in Potassium channel current subsystem, select the relevant content in the Word document (i.e. outward current of potassium ions). Then, open the

Potassium channel current MATLAB Function block. In the MATLAB Editor, select the implementation for outwardCurrent subfunction (lines 34-37). Right-click the selected lines and in the context menu, select Requirements Traceability > Link to Selection

in Word. Minimize the Word document, then navigate from the newly highlighted lines at the bottom of the MATLAB code to the related description in Word. When the correct location is highlighted, use the MATLAB icon to navigate back to code.

8-15

8

MATLAB Code Traceability

8-16

Associate Traceability Information with MATLAB Code Lines in Simulink

Report Traceability Links

Traceability links associated with MATLAB code lines of MATLAB Function blocks are included in the Requirements Traceability Report generated for the parent

Simulink model. Use Analysis > Requirements Traceability > Generate Report in slvnvdemo_neuron model window to generate the report. See MATLAB Function block links information present in the report, including quotations of linked MATLAB Code lines.

8-17

8

MATLAB Code Traceability

8-18

Associate Traceability Information with MATLAB Code Lines in Simulink

8-19

Custom Types of Requirements

Documents

• “Why Create a Custom Link Type?” on page 9-2

• “Implement Custom Link Types” on page 9-3

• “Custom Link Type Functions” on page 9-4

• “Links and Link Types” on page 9-5

• “Link Type Properties” on page 9-6

• “Custom Link Type Registration” on page 9-10

• “Create a Custom Requirements Link Type” on page 9-11

• “Custom Link Type Synchronization” on page 9-19

• “Navigate to Simulink Objects from External Documents” on page 9-20

9

9

Custom Types of Requirements Documents

Why Create a Custom Link Type?

In addition to linking to built-in types of requirements documents, you can register custom requirements document types with the Requirements Management Interface

(RMI). Then you can create requirement links from your model to these types of documents.

With custom link types, you can:

• Link to requirement items in commercial requirement tracking software

• Link to in-house database systems

• Link to document types that the RMI does not support

The custom link type API allows you to define MATLAB functions that enable linking between your Simulink model and your custom requirements document type. These functions also enable new link creation and navigation between the model and documents.

For example, navigation involves opening a requirements document and finding the specific requirement record. When you click your custom link in the content menu of a linked object in the model, Simulink uses your custom link type navigation function to open the document and highlight the target requirement based on the implementation provided. The navigation function you implement uses the available API to communicate with your requirements storage application.

Typically, MATLAB runs an operating system shell command or uses ActiveX communication for sending navigation requests to external applications.

Alternatively, if your requirements are stored as custom variants of text or HTML files, you can use the built-in editor or Web browser to open the requirements document.

9-2

Implement Custom Link Types

Implement Custom Link Types

To implement a custom link type:

1 Create a MATLAB function file based on the custom link type template, as described

in “Custom Link Type Functions” on page 9-4.

2 Customize the custom link type file to specify the link type properties and custom

callback functions required for the custom link type, as described in “Link Type

Properties” on page 9-6.

3 Register the custom link type using the rmi command 'register' option, as

described in “Custom Link Type Registration” on page 9-10.

9-3

9

Custom Types of Requirements Documents

Custom Link Type Functions

To create a MATLAB function file, start with the custom link type template, located in:

matlabroot/toolbox/slvnv/reqmgt/linktypes/linktype_TEMPLATE.m

Your custom link type function:

• Must exist on the MATLAB path with a unique function and file name.

• Cannot require input arguments.

• Must return a single output argument that is an instance of the requirements link type class.

To view similar files for the built-in link types, see the following files in

matlabroot\toolbox\slvnv\reqmgt\linktypes

: linktype_rmi_doors.m

linktype_rmi_excel.m

linktype_rmi_html.m

linktype_rmi_text.m

9-4

Links and Link Types

Links and Link Types

Requirements links are the data structures, managed by Simulink, that identify a specific location within a document. You get and set the links on a block using the rmi command.

Links and link types work together to perform navigation and manage requirements. The doc

and id fields of a link uniquely identify the linked item in the external document.

The RMI passes both of these strings to the navigation command when you navigate a link from the model.

9-5

9

Custom Types of Requirements Documents

Link Type Properties

Link type properties define how links are created, identified, navigated to, and stored within the requirement management tool. The following table describes each of these properties.

Property

Registration

Label

IsFile

Extensions

LocDelimiters

NavigateFcn

Description

The name of the function that creates the link type. The RMI stores this name in the Simulink model.

A string to identify this link type. In the “Requirements

Traceability Link Editor”, this string appears on the

Document type drop-down list for a Simulink or Stateflow object.

A Boolean property that indicates if the linked documents are files within the computer file system. If a document is a file:

• The software uses the standard method for resolving the path.

• In the Requirements Traceability Link Editor, when you click Browse, the file selection dialog box opens.

An array of file extensions. Use these file extensions as filter options in the Requirements Traceability Link Editor when you click Browse. The file extensions infer the link type based on the document name. If you registered more than one link type for the same file extension, the link type that you registered takes first priority.

A string containing the list of supported navigation delimiters.

The first character in the ID of a requirement specifies the type of identifier. For example, an identifier can refer to a specific page number (#4), a named bookmark (@my_tag), or some searchable text (?search_text). The valid location delimiters determine the possible entries in the Requirements

Traceability Link Editor Location drop-down list.

The MATLAB callback invoked when you click a link. The function has two input arguments: the document field and the

ID field of the link: feval(LinkType.NavigateFcn, Link.document, Link.id)

9-6

Link Type Properties

Property

ContentsFcn

BrowseFcn

CreateURLFcn

IsValidDocFcn

Description

The MATLAB callback invoked when you click the Document

Index tab in the Requirements Traceability Link Editor. This function has a single input argument that contains the full path of the resolved function or, if the link type is not a file, the

Document field contents.

The function returns three outputs:

• Labels

• Depths

• Locations

The MATLAB callback invoked when you click Browse in the

Requirements Traceability Link Editor. You do not need this function when the link type is a file. The function takes no input arguments and returns a single output argument that identifies the selected document.

The MATLAB callback that constructs a path name to the requirement. This function uses the document path or URL to create a specific requirement URL. The requirement URL is based on a location identifier specified in the third input argument. The input arguments are:

• Full path name to the requirements document

• Info about creating a URL to the document (if applicable)

• Location of the requirement in the document

This function returns a single output argument, the string to use when navigating to the requirement from the generated report.

The MATLAB callback invoked when you run a requirements consistency check. The function takes one input argument—the fully qualified name for the requirements document. It returns true if the document can be located; it returns false if the document cannot be found or the document name is invalid.

9-7

9

Custom Types of Requirements Documents

Property

IsValidIdFcn

IsValidDescFcn

Description

The MATLAB callback invoked when you run a requirements consistency check. This function takes two input arguments:

• Fully qualified name for the requirements document

• Location of the requirement in the document

IsValidIdFcn

returns true if it finds the requirement and false if it cannot find that requirement in the specified document.

The MATLAB callback invoked when you run a requirements consistency check. This function has three input arguments:

• Full path to the requirements document

• Location of the requirement in the document

• Requirement description label as stored in Simulink

IsValidDescFcn

returns two outputs:

• True if the description matches the requirement, false otherwise.

• The requirement label in the document, if not matched in

Simulink.

9-8

Link Type Properties

Property

DetailsFcn

SelectionLinkFcn

Description

The MATLAB callback invoked when you generate the requirements report with the Include details from linked

documents option. This function returns detailed content associated with the requirement and has three input arguments:

• Full path to the requirements document

• Location of the requirement in the document

• Level of details to include in report (Unused)

The DetailsFcn returns two outputs:

• Numeric array that describes the hierarchical relationship among the fragments in the cell array

• Cell array of formatted fragments (paragraphs, tables, et al.) from the requirement

The MATLAB callback invoked when you use the selectionbased linking menu option for this document type. This function has two input arguments:

• Handle to the model object that will have the requirement link

• True if a navigation object is inserted into the requirements document, or false if no navigation object is inserted

SelectionLinkFcn

returns the requirements link structure for the selected requirement.

9-9

9

Custom Types of Requirements Documents

Custom Link Type Registration

Register your custom link type by passing the name of the MATLAB function file to the rmi

command as follows: rmi register mytargetfilename

Once you register a link type, it appears in the “Requirements Traceability Link Editor” as an entry in the Document type drop-down list. A file in your preference folder contains the list of registered link types, so the custom link type is loaded each time you run MATLAB.

When you create links using custom link types, the software saves the registration name and the other link properties specified in the function file. When you attempt to navigate to such a link, the RMI resolves the link type against the registered list. If the software cannot find the link type, you see an error message.

You can remove a link type with the following MATLAB command: rmi unregister mytargetfilename

9-10

Create a Custom Requirements Link Type

Create a Custom Requirements Link Type

In this example, you implement a custom link type to a hypothetical document type, a text file with the extension .abc. Within this document, the requirement items are identified with a special text string, Requirement::, followed by a single space and then the requirement item inside quotation marks (").

You will create a document index listing all the requirement items. When navigating from the Simulink model to the requirements document, the document opens in the

MATLAB Editor at the line of the requirement that you want.

To create a custom link requirement type:

1

Write a function that implements the custom link type and save it on the MATLAB path.

For this example, the file is rmicustabcinterface.m, containing the function, rmicustabcinterface

, that implements the ABC files shipping with your installation.

2 To view this function, at the MATLAB prompt, type: edit rmicustabcinterface

The file rmicustabcinterface.m opens in the MATLAB Editor. The content of the file is: function linkType = rmicustabcinterface

%RMICUSTABCINTERFACE - Example custom requirement link type

%

% This file implements a requirements link type that maps

% to "ABC" files.

% You can use this link type to map a line or item within an ABC

% file to a Simulink or Stateflow object.

%

% You must register a custom requirement link type before using it.

% Once registered, the link type will be reloaded in subsequent

% sessions until you unregister it. The following commands

% perform registration and registration removal.

%

% Register command: >> rmi register rmicustabcinterface

% Unregister command: >> rmi unregister rmicustabcinterface

%

% There is an example document of this link type contained in the

% requirement demo directory to determine the path to the document

% invoke:

%

% >> which demo_req_1.abc

% Copyright 1984-2010 The MathWorks, Inc.

9-11

9

Custom Types of Requirements Documents

% Create a default (blank) requirement link type

linkType = ReqMgr.LinkType;

linkType.Registration = mfilename;

% Label describing this link type

linkType.Label = 'ABC file (for demonstration)';

% File information

linkType.IsFile = 1;

linkType.Extensions = {'.abc'};

% Location delimiters

linkType.LocDelimiters = '>@';

linkType.Version = ''; % not required

% Uncomment the functions that are implemented below

linkType.NavigateFcn = @NavigateFcn;

linkType.ContentsFcn = @ContentsFcn; function NavigateFcn(filename,locationStr)

if ~isempty(locationStr)

findId=0;

switch(locationStr(1))

case '>'

lineNum = str2num(locationStr(2:end));

openFileToLine(filename, lineNum);

case '@'

openFileToItem(filename,locationStr(2:end));

otherwise

openFileToLine(filename, 1);

end

end function openFileToLine(fileName, lineNum)

if lineNum > 0

if matlab.desktop.editor.isEditorAvailable

matlab.desktop.editor.openAndGoToLine(fileName, lineNum);

end

else

edit(fileName);

end function openFileToItem(fileName, itemName)

reqStr = ['Requirement:: "' itemName '"'];

lineNum = 0;

fid = fopen(fileName);

i = 1;

while lineNum == 0

lineStr = fgetl(fid);

if ~isempty(strfind(lineStr, reqStr))

lineNum = i;

end;

if ~ischar(lineStr), break, end;

i = i + 1;

end;

fclose(fid);

openFileToLine(fileName, lineNum);

9-12

Create a Custom Requirements Link Type function [labels, depths, locations] = ContentsFcn(filePath)

% Read the entire file into a variable

fid = fopen(filePath,'r');

contents = char(fread(fid)');

fclose(fid);

% Find all the requirement items

fList1 = regexpi(contents,'\nRequirement:: "(.*?)"','tokens');

% Combine and sort the list

items = [fList1{:}]';

items = sort(items);

items = strcat('@',items);

if (~iscell(items) && length(items)>0)

locations = {items};

labels = {items};

else

locations = [items];

labels = [items];

end

depths = [];

3 To register the custom link type ABC, type the following MATLAB command: rmi register rmicustabcinterface

The ABC file type appears on the “Requirements Traceability Link Editor” dropdown list of document types.

4 Create a text file with the .abc extension containing several requirement items marked by the Requirement:: string.

For your convenience, an example file ships with your installation. The example file is matlabroot\toolbox\slvnv\rmidemos\demo_req_1.abc. demo_req_1.abc

contains the following content:

Requirement:: "Altitude Climb Control"

Altitude climb control is entered whenever:

|Actual Altitude- Desired Altitude | > 1500

Units:

Actual Altitude - feet

Desired Altitude - feet

Description:

When the autopilot is in altitude climb control mode, the controller maintains a constant user-selectable target climb rate.

9-13

9

Custom Types of Requirements Documents

The user-selectable climb rate is always a positive number if the current altitude is above the target altitude. The actual target climb rate is the negative of the user setting.

End of "Altitude Climb Control">

Requirement:: "Altitude Hold"

Altitude hold mode is entered whenever:

|Actual Altitude- Desired Altitude | <

30*Sample Period*(Pilot Climb Rate / 60)

Units:

Actual Altitude - feet

Desired Altitude - feet

Sample Period - seconds

Pilot Climb Rate - feet/minute

Description:

The transition from climb mode to altitude hold is based on a threshold that is proportional to the Pilot Climb Rate.

At higher climb rates the transition occurs sooner to prevent excessive overshoot.

End of "Altitude Hold"

Requirement:: "Autopilot Disable"

Altitude hold control and altitude climb control are disabled when autopilot enable is false.

Description:

Both control modes of the autopilot can be disabled with a pilot setting.

9-14

Create a Custom Requirements Link Type

ENd of "Autopilot Disable"

Requirement:: "Glide Slope Armed"

Glide Slope Control is armed when Glide

Slope Enable and Glide Slope Signal are both true.

Units:

Glide Slope Enable - Logical

Glide Slope Signal - Logical

Description:

ILS Glide Slope Control of altitude is only enabled when the pilot has enabled this mode and the Glide Slope Signal is true. This indicates the Glide Slope broadcast signal has been validated by the on board receiver.

End of "Glide Slope Armed"

Requirement:: "Glide Slope Coupled"

Glide Slope control becomes coupled when the control is armed and (Glide Slope Angle Error > 0) and

Distance < 10000

Units:

Glide Slope Angle Error - Logical

Distance - feet

Description:

When the autopilot is in altitude climb control mode the controller maintains a constant user selectable target climb rate.

The user-selectable climb rate is always a positive number if the current altitude is above the target altitude the actual target climb rate is the

9-15

9

Custom Types of Requirements Documents negative of the user setting.

End of "Glide Slope Coupled"

5 Open the following example model: aero_dap3dof

6 Right-click the Reaction Jet Control subsystem and select Requirements

Traceability > Open Link Editor.

The Requirements Traceability Link Editor opens.

7

Click New to add a new requirement link. The Document type drop-down list now contains the ABC file (for demonstration) option.

9-16

8 Set Document type to ABC file (for demonstration) and browse to the

matlabroot\toolbox\slvnv\rmidemos\demo_req_1.abc

file. The browser shows only the files with the .abc extension.

9 To define a particular location in the requirements document, use the Location field.

In this example, the rmicustabcinterface function specifies two types of location delimiters for your requirements:

• > — Line number in a file

• @ — Named item, such as a bookmark, function, or HTML anchor

Create a Custom Requirements Link Type

Note: The rmi reference page describes other types of requirements location delimiters.

The Location drop-down list contains these two types of location delimiters whenever you set Document type to ABC file (for demonstration).

10

Select Line number. Enter the number 26, which corresponds with the line number for the Altitude Hold requirement in demo_req_1.abc.

11

In the Description field, enter Altitude Hold, to identify the requirement by name.

12 Click Apply.

13 Verify that the Altitude Hold requirement links to the Reaction Jet Control subsystem. Right-click the subsystem and select Requirements Traceability > 1.

“Altitude Hold”.

Create a Document Index

A document index is a list of all the requirements in a given document. To create a document index, MATLAB uses file I/O functions to read the contents of a requirements document into a MATLAB variable. The RMI extracts the list of requirement items.

The example requirements document, demo_req_1.abc, defines four requirements using the string Requirement::. To generate the document index for this ABC file, the

ContentsFcn

function in rmicustabcinterface.m extracts the requirements names and inserts @ before each name.

For the demo_req_1.abc file, in the Link Editor: Reaction Jet Control dialog box, click the Document Index tab. The ContentsFcn function generates the document index automatically.

9-17

9

Custom Types of Requirements Documents

9-18

Custom Link Type Synchronization

Custom Link Type Synchronization

Simulink Verification and Validation provides an API for synchronization of links for custom requirements documents. To support synchronization for your custom requirements link type, create a custom type implementation in a new subclass and inherit from the rmisync.SyncApi base class in the Requirements Management

Interface API.

For example, to implement synchronization for links to requirements documents in

Requirements Interchange Format (RIF/ReqIF), create the new package +rmireqif with the new subclass @SyncApiReqif:

matlabroot/toolbox/slvnv/reqmgt/+rmireqif/@SyncApiReqif/SyncApiReqif.m

Your subclass needs to implement the following methods:

% Open surrogate module in your RM application openSrgModule(this)

% Convert from identifier strings stored by RMI

% to numeric IDs used by your RM application numericIds = idStrToNum(this, strIds) ids = srgIds(this, reqStrings)

% Convert from your RM links data to Simulink link structure array slReqs = linkinfoToReqs(surrlinksInfo)

% update surrogate module after objects were deleted in Simulink markDeleted(this, deletedIds)

% push Simulink model structure updates to your RM application firstNewId = updateModule(this, mods, dmDeletedIds)

% push RMI link updates from Simulink to your RM application newLinkStr = propagateChanges(this, origReqs, srgId, srgLinkInfo) updateSrgLinks(this, surrogateLinkUpdates) updateModuleProps(this)

% query updates from surrogate module reqs = updateSrgLink(this, reqs, doorsId) myReqs = updateDocNames(this, myReqs)

9-19

9

Custom Types of Requirements Documents

Navigate to Simulink Objects from External Documents

The RMI includes several functions that simplify creating navigation interfaces in external documents. The external application that displays your document must support an application programming interface (API) for communicating with the MATLAB software.

Provide Unique Object Identifiers

Whenever you create a requirement link for a Simulink or Stateflow object, the RMI uses a globally unique identifier for that object. This identifier identified the object. The identifier does not change if you rename or move the object, or add or delete requirement links. The RMI uses the unique identifier only to resolve an object within a model.

Use the rmiobjnavigate Function

The rmiobjnavigate function identifies the Simulink or Stateflow object, highlights that object, and brings the editor window to the front of the screen. When you navigate to a Simulink model from an external application, invoke this function.

The first time you navigate to an item in a particular model, you might experience a slight delay while the software initializes the communication API and the internal data structures. You do not experience a long delay on subsequent navigation.

Determine the Navigation Command

To create a requirement link for a Simulink or Stateflow object, at the MATLAB prompt, use the following command to find the navigation command string, where obj is a handle or a uniquely resolved name for the object:

[ navCmd, objPath ] = rmi('navCmd', obj);

The return values of the navCmd method are:

• navCmd — A string that navigates to the object when evaluated by the MATLAB software.

• objPath — A string that identifies the model object

Send the navCmd strings to the MATLAB software for evaluation when navigating from the external application to the object obj in the Simulink model. Use and objPath string to visually identify the target object in the requirements document.

9-20

Navigate to Simulink Objects from External Documents

Use the ActiveX Navigation Control

The RMI uses software that includes a special Microsoft ActiveX control to enable navigation to Simulink objects from Microsoft Word and Excel documents. You can use this same control in any other application that supports ActiveX within its documents.

The control is derived from a push button and has the Simulink icon. There are two instance properties that define how the control works. The tooltipstring property is the string that is displayed in the control tooltip. The MLEvalCmd property is the string that you pass to the MATLAB software for evaluation when you click the control.

Typical Code Sequence for Establishing Navigation Controls

When you create an interface to an external tool, you can automate the procedure for establishing links. This way, you do not need to manually update the dialog box fields.

This type of automation occurs as part of the selection-based linking for certain built-in types, such as Microsoft Word and Excel documents.

To automate the procedure for establishing links:

1 Select a Simulink or Stateflow object and an item in the external document.

2 Invoke the link creation action either from a Simulink menu or command, or a similar mechanism in the external application.

3 Identify the document and current item using the scripting capability of the external tool. Pass this information to the MATLAB software. Create a requirement link on the selected object using the RMI API as follows: a Create an empty link structure using the following command: rmi('createempty') b Fill in the link structure fields based on the target location in the requirements document.

c Attach the link to the object using the following command: rmi('cat')

4 Determine the MATLAB navigation command string that you must embed in the external tool, using the navCmd method:

[ navCmd, objPath ] = rmi('navCmd',obj)

9-21

9

Custom Types of Requirements Documents

5 Create a navigation item in the external document using the scripting capability of the external tool. Set the MATLAB navigation command string in the property.

When using ActiveX navigation objects provided by the external tool, set the

MLEvalCmd

property to the navCmd and set the tooltipstring property to objPath

.

You define the MATLAB code implementation of this procedure as the

SelectionLinkFcn

function in the link type definition file. The following files in

matlabroot\toolbox\slvnv\reqmgt\linktypes

contain examples of how to implement this functionality: linktype_rmi_doors.m

linktype_rmi_excel.m

linktype_rmi_html.m

linktype_rmi_text.m

9-22

10

Requirements Information in

Generated Code

• “How Requirements Information Is Included in Generated Code” on page 10-2

• “Generate Code for Models with Requirements Links” on page 10-4

10

Requirements Information in Generated Code

How Requirements Information Is Included in Generated Code

After you simulate your model and verify its performance against the requirements, you can generate code from the model for an embedded real-time application. The Embedded

Coder ® software generates code for Embedded Real-Time (ERT) targets.

If the model has any links to requirements, the Embedded Coder software inserts information about the requirements links into the code comments.

For example, if a block has a requirement link, the software generates code for that block. In the code comments for that block, the software inserts:

• Requirement description

• Hyperlink to the requirements document that contains the linked requirement associated with that block

Note:

• You must have a license for Embedded Coder to generate code for an embedded realtime application.

• If you use an external .req file to store your requirement links, to avoid stale comments in generated code, before code generation, you must save any change in your requirement links. For information on how to save, see “Save Requirements

Links in External Storage”.

Comments for the generated code include requirements descriptions and hyperlinks to the requirements documents in the following locations.

Model Object with Requirement

Model

Nonvirtual subsystem

Virtual subsystem

Location of Code Comments with Requirements

Links

In the main header file, <model>.h

At the call site for the subsystem

At the call site of the closest nonvirtual parent subsystem. If a virtual subsystem does not have a nonvirtual parent, requirement descriptions appear in the main header file for the model, <model>.h.

10-2

How Requirements Information Is Included in Generated Code

Model Object with Requirement

Nonsubsystem block

MATLAB code line in MATLAB Function block

Location of Code Comments with Requirements

Links

In the generated code for the block

In the generated code for the MATLAB code line(s)

10-3

10

Requirements Information in Generated Code

Generate Code for Models with Requirements Links

To specify that generated code of an ERT target include requirements:

1 Open the rtwdemo_requirements example model.

2 Select Simulation > Model Configuration Parameters.

3 In the Select tree of the Configuration Parameters dialog box, select the Code

Generation node.

The currently configured system target must be an ERT target.

10-4

4

Under Code Generation, select Comments.

5 In the Custom comments section on the right, select the Requirements in block

comments check box.

6 Under Code Generation, select Report.

7

On the Report pane, select:

Create code generation report

Open report automatically

8 On the Code Generation main pane, click Build.

9 In the code-generation report, open rtwdemo_requirements.c.

10 Scroll to the code for the Pulse Generator block, clock. The comments for the code associated with that block include a hyperlink to the requirement linked to that block.

Generate Code for Models with Requirements Links

11

Click the link Clock period shall be consistent with chirp tolerance to open the HTML requirements document to the associated requirement.

Note: When you click a requirements link in the code comments, the software opens the application for the requirements document, except if the requirements document is a DOORS module. To view a DOORS requirement, start the DOORS software and log in before clicking the hyperlink in the code comments.

10-5

Model Component Testing

11

Overview of Component Verification

• “Component Verification” on page 11-2

• “Basic Approach to Component Verification” on page 11-4

• “Functions for Component Verification” on page 11-8

11

Overview of Component Verification

Component Verification

In this section...

“Component Verification Approaches” on page 11-2

“Simulink Verification and Validation Tools for Component Verification” on page

11-2

Component Verification Approaches

Component verification allows you to test a design component in your model using one of two approaches:

• Within the context of the model that contains the component — Using systematic simulation of closed-loop controllers requires that you verify components within a control system model. Doing so allows you to test the control algorithms with your model. This approach is called system analysis.

• As standalone components — For a high level of confidence in the component algorithm, verify the component in isolation from the rest of the system. This approach is called component analysis.

Verifying standalone components provides several advantages:

• You can use the analysis to focus on portions of the design that you cannot test because of the physical limitations of the system being controlled.

• You can use this approach for open-loop simulations to test the plant model without feedback control.

• You can use this approach when the model is not yet available or when you need to simulate a control system model in accelerated mode for performance reasons.

Simulink Verification and Validation Tools for Component Verification

By isolating the component to verify and using tools that the Simulink Verification and

Validation software provides, you create test cases that allow you to expand the scope of the testing for large models. This expanded testing helps you accomplish the following:

• Achieve 100% model coverage — If certain model components do not record 100% coverage, the top-level model cannot achieve 100% coverage. By verifying these

11-2

Component Verification components individually, you can create test cases that fully specify the component interface, allowing the component to record 100% coverage.

• Debug the component — To verify that each model component satisfies the specified design requirements, you can create test cases that verify that specific components perform as designed.

• Test the robustness of the component — To verify that a component handles unexpected inputs and calculations properly, you can create test cases that generate data. Then, test the error-handling capabilities in the component.

11-3

11

Overview of Component Verification

Basic Approach to Component Verification

In this section...

“Workflow for Component Verification” on page 11-4

“Verify a Component Independently of the Container Model” on page 11-6

“Verify a Model Block in the Context of the Container Model” on page 11-7

Workflow for Component Verification

The following graphic illustrates the common workflow for component verification.

Closed-loop simulation

Open-loop simulation

Component to verify

Simulink

Design

Verifier analysis

Data file

Log signals

Data file

Merge test case data

Data file

Generate harness

Log signals

Signal

Builder

Component to verify

Harness model

Merged test case data file

Simulate component, execute in

SIL or PIL mode

Unit testing of code

This graphic illustrates the two approaches for component verification, described in

“Component Verification” on page 11-2:

1

Choose your approach for component verification:

11-4

Basic Approach to Component Verification

• For closed-loop simulations, verify a component within the context of its container model by logging the signals to that component and storing them in a data file.

If those signals do not constitute a complete test suite, generate a harness model and add or modify the test cases in the Signal Builder.

• For open-loop simulations, verify a component independently of the container model by extracting the component from its container model and creating a harness model for the extracted component. Add or modify test cases in the

Signal Builder and log the signals to the component in the harness model.

2 Prepare component for verification.

3

Create and log test cases. If desired, merge the test case data into a single data file.

The data file contains the test case data for simulating the component. If you cannot achieve the desired results with a certain set of test cases, add new test cases or modify existing test cases in the data file, and merging them into a single data file.

Continue adding or modifying test cases until you achieve a test suite that satisfies the goals of your analysis.

4 Execute the test cases in Software-in-the-Loop or Processor-in-the-Loop mode.

5

After you have a complete test suite, you can:

• Simulate the model and execute the test cases to:

• Record coverage.

• Record output values to make sure that you get the expected results.

• Invoke the Code Generation Verification (CGV) API to execute the generated code for the model that contains the component in simulation, Software-in-the-Loop

(SIL), or Processor-in-the-Loop (PIL) mode.

Note: To execute a model in different modes of execution, you use the CGV API to verify the numerical equivalence of results. For more information about the CGV

API, see “Programmatic Code Generation Verification”.

The next sections describe the steps for component verification in more detail:

• “Verify a Component Independently of the Container Model” on page 11-6

• “Verify a Model Block in the Context of the Container Model” on page 11-7

11-5

11

Overview of Component Verification

11-6

Verify a Component Independently of the Container Model

Use component analysis to verify:

• Model blocks

• Atomic subsystems

• Stateflow atomic subcharts

The recommended steps for verifying a component independently of the container model:

1

Depending on the type of component, take one of the following actions:

• Model blocks — Open the referenced model.

• Atomic subsystems — Extract the contents of the subsystem into its own

Simulink model.

• Atomic subcharts — Extract the contents of the Stateflow atomic subchart into its own Simulink model.

2

Create a harness model for:

• The referenced model

• The extracted model that contains the contents of the atomic subsystem or atomic subchart

3 Add or modify test cases in the Signal Builder in the harness model.

4

Log the input signals from the Signal Builder to the test unit.

5 Repeat steps 3 and 4 until you are satisfied with the test suite.

6 Merge the test case data into a single file.

7

Depending on your goals, take one of the following actions:

• Execute the test cases to:

• Record coverage.

• Record output values and make sure that they equal the expected values.

• Invoke the Code Generation Verification (CGV) API to execute the test cases in

Software-in-the-Loop (SIL) or Processor-in-the-Loop (PIL) mode on the generated code for the model that contains the component.

If the test cases do not achieve the desired results, repeat steps 3 through 5.

Basic Approach to Component Verification

Verify a Model Block in the Context of the Container Model

Use system analysis to verify a Model block in the context of the block's container model.

Use this technique when you analyze a closed-loop controller.

The recommended steps for system analysis:

1 Log the input signals to the component by simulating the container model.

or

Analyze the model using the Simulink Design Verifier™ software.

2 If you want to add test cases to your test suite or modify existing test cases, create a harness model using the logged signals.

3 Add or modify test cases in the Signal Builder in the harness model.

4 Log the input signals from the Signal Builder to the test unit.

5 Repeat steps 3 and 4 until you are satisfied with the test suite.

6 Merge the test case data into a single file.

7 Depending on your goals, do one of the following:

• Execute the test cases to:

• Record coverage.

• Record output values and make sure that they equal the expected values.

• Invoke the Code Generation Verification (CGV) API to execute the test cases in

Software-in-the-Loop (SIL) or Processor-in-the-Loop (PIL) mode on the generated code for the model.

If the test cases do not achieve the desired results, repeat steps 3 through 5.

11-7

11

Overview of Component Verification

Functions for Component Verification

The Simulink Verification and Validation software provides several functions that facilitate the tasks associated with component verification.

Task

Simulate a Simulink model and log input signals to a

Model block in the model. If you modify the test cases in the

Signal Builder harness model, use this approach for logging input signals to the harness model itself.

Create a harness model for a component, using logged input signals if specified, or using the default signals.

Function slvnvlogsignals slvnvmakeharness

A harness model contains four Simulink blocks as described

in “Prepare the Component for Verification” on page

12-4 in “Verify Generated Code for a Component”.

Merge test case data into a single data structure for batch execution or harness generation.

Merge test cases from several harness models into a single harness model.

Extract an atomic subsystem or atomic subchart into a new model.

Simulate a model, executing the specified test cases to record model coverage and outport values.

Invoke the Code Generation Verification (CGV) API, and execute the specified test cases on the generated code for the model.

slvnvmergedata slvnvmergeharness slvnvextract slvnvruntest slvnvruncgvtest

Component verification functions do not support the following Simulink software features:

• Variable-step solvers for slvnvruntest

• Component interfaces that contain:

• Complex signals

• Variable-size signals

• Array of buses

11-8

• Multiword fixed-point data types

Functions for Component Verification

11-9

Verifying Generated Code for a

Component

12

12

Verifying Generated Code for a Component

Verify Generated Code for a Component

In this section...

“About the Example Model” on page 12-2

“Prepare the Component for Verification” on page 12-4

“Create and Log Test Cases” on page 12-6

“Merge Test Case Data” on page 12-7

“Record Coverage for Component” on page 12-7

“Execute Component in Simulation Mode” on page 12-8

“Execute Component in Software-in-the-Loop (SIL) Mode” on page 12-9

About the Example Model

This example uses the slvnvdemo_powerwindow example model to show how to verify a component in the context of the model that contains that component. As you work through this example, you use the Simulink Verification and Validation component verification functions to create test cases and measure coverage for a referenced model.

In addition, you execute the referenced model in both simulation mode and Softwarein-the-Loop (SIL) mode using the Code Generation Verification (CGV) API and then compare the results.

Note: You must have the following product licenses to run this example:

• Stateflow

• Embedded Coder

• Simulink Coder™

The component you verify is a Model block named control. This component resides inside the power_window_control_system subsystem in the top level of the slvnvdemo_powerwindow

model.

12-2

Verify Generated Code for a Component

The Model block references the slvnvdemo_powerwindow_controller model.

The referenced model contains a Stateflow chart control, which implements the logic for the power window controller.

12-3

12

Verifying Generated Code for a Component

12-4

Prepare the Component for Verification

To verify the referenced model slvnvdemo_powerwindow_controller, you need to create a harness model that contains the input signals that simulate the controller in the plant model. Perform the following steps:

1

Open the slvnvdemo_powerwindow example model: slvnvdemo_powerwindow

2

Open the power_window_control_system subsystem.

3 The Model block named control in the power_window_control_system subsystem references the component you verify during this example

—slvnvdemo_powerwindow_controller. Load the referenced model: load_system('slvnvdemo_powerwindow_controller');

4 Simulate the Model block that references slvnvdemo_powerwindow_controller and log the input signals to the Model block: loggedSignalsPlant = ...

slvnvlogsignals(...

'slvnvdemo_powerwindow/power_window_control_system/control');

Verify Generated Code for a Component slvnvlogsignals

stores the logged signals in loggedSignalsPlant.

5

Generate an empty harness model so that you can create new test cases manually: harnessModelFilePath = ...

slvnvmakeharness('slvnvdemo_powerwindow_controller'); slvnvmakeharness

creates a harness model named slvnvdemo_powerwindow_controller_harness

. The harness model includes:

• Test Unit — A Model block that references the slvnvdemo_powerwindow_controller

model.

• Inputs — A Signal Builder block that contains one test case. That test case specifies the values of the input signals logged when the model slvnvdemo_powerwindow

was simulated.

• Test Case Explanation — A DocBlock block that describes the test case.

• Size-Type — A Subsystem block that transmits signals from the Inputs block to the Test Unit block. The output signals from this block match the input signals for the Model block you are verifying.

• moveUp and moveDown — Two output ports that match the output ports from the Model block.

12-5

12

Verifying Generated Code for a Component

12-6

6

Save the name of the harness model for use later in this example:

[~,harnessModel] = fileparts(harnessModelFilePath);

7

Leave all models open for the next part of this example.

Next, create a test case that tests values for input signals to the component.

Create and Log Test Cases

Add a test case for your component to help you get closer to achieving 100% coverage.

For this example, use the signalbuilder function to add a new test case to the Signal

Builder block in the harness model. The new test case specifies new values for the input signals to the component:

1 Load the file that contains the data for the new test case into the MATLAB workspace: load('slvnvdemo_powerwindow_controller_newtestcase.mat');

The workspace variables newTestData and newTestTime contain the test-case data.

Verify Generated Code for a Component

2 Add the new test case to the Signal Builder block in the harness model.

signalBuilderBlock = slvnvdemo_signalbuilder_block(harnessModel); signalbuilder(signalBuilderBlock,'Append',...

newTestTime, newTestData,...

{'endstop','obstacle','driver(1)','driver(2)','driver(3)',...

'passenger(1)','passenger(2)','passenger(3)'},'New Test Case');

3 Simulate the harness model with both test cases, then log the signals to the referenced model, and save the results: loggedSignalsHarness = slvnvlogsignals(harnessModel);

Next, record coverage for the slvnv_powerwindow_controller model.

Merge Test Case Data

You have two sets of test case data:

• loggedSignalsPlant — Logged signals to the Model block control

• loggedSignalsHarness — Logged signals to the test cases you added to the empty harness

To simulate all the test data at the same time, merge the two data files into a single data file:

1 Combine the test case data: mergedTestCases = slvnvmergedata(loggedSignalsPlant,...

loggedSignalsHarness);

2 View the merged data: disp(mergedTestCases);

Next, simulate the referenced model with the merged data and recover coverage for the referenced model, slvnv_powerwindow_controller.

Record Coverage for Component

Model coverage is a measure of how thoroughly a test case tests a model and the percentage of pathways that a test case exercises. To record coverage for the slvnv_powerwindow_controller

model:

1 Create a default options object, required by the slvnvruntest function:

12-7

12

Verifying Generated Code for a Component runopts = slvnvruntestopts;

2

Specify to simulate the model, and record coverage: runopts.coverageEnabled = true;

3 Simulate the model using the logged input signals:

[~, covdata] = slvnvruntest('slvnvdemo_powerwindow_controller',...

mergedTestCases,runopts);

4 Display the HTML coverage report: cvhtml('Coverage with Test Cases from Harness', covdata);

The slvnv_powerwindow_controller model achieved:

• Decision coverage: 44%

• Condition coverage: 45%

• MCDC coverage: 10%

Note: For more information about decision coverage, condition coverage, and MCDC

coverage, see “Types of Model Coverage” on page 15-3.

If you do not achieve the desired coverage, continue to modify the test cases in the Signal

Builder in the harness model, log the input signals to the harness model, and repeat the preceding steps until you achieve the desired coverage.

To achieve additional coverage to bring your model closer to 100% coverage, modify or add test cases using the Signal Builder block in the harness model, as described in

“Create and Log Test Cases” on page 12-6.

Execute Component in Simulation Mode

To verify that the generated code for the model produces the same results as simulating the model, use the Code Generation Verification (CGV) API methods. When you perform this procedure, the simulation compiles and executes the model code using the merged test cases:

1

Create a default options object for slvnvruncgvtest: runcgvopts = slvnvruntestopts('cgv');

2 Specify to execute the model in simulation mode:

12-8

Verify Generated Code for a Component runcgvopts.cgvConn = 'sim';

3 Execute the slvnv_powerwindow_controller model using the two test cases and the runopts object: cgvSim = slvnvruncgvtest('slvnvdemo_powerwindow_controller', ...

mergedTestCases, runcgvopts);

These steps save the results in the workspace variable cgvSim.

Next, execute the same model with the same test cases in Software-in-the-Loop (SIL) mode and compare the results from both simulations.

For more information about Normal simulation mode, see “Execute the Model”.

Execute Component in Software-in-the-Loop (SIL) Mode

When you execute a model in Software-in-the-Loop (SIL) mode, the simulation compiles and executes the generated code on your host computer.

To execute a model in SIL mode, you must have an Embedded Coder license.

In this section, you execute the slvnvdemo_powerwindow_controller model in SIL mode and compare the results to the previous section, where you executed the model in simulation mode:

1

Specify to execute the model in SIL mode: runcgvopts.cgvConn = 'sil';

2 Execute the slvnv_powerwindow_controller model using the merged test cases and the runopts object: cgvSil = slvnvruncgvtest('slvnvdemo_powerwindow_controller', ...

mergedTestCases, runcgvopts);

The workspace variable cgvSil contains the results of the SIL mode execution.

3

Compare the results in cgvSil to the results in to cgvSim (the results from the simulation mode execution). Use the compare (cgv.CGV) method to compare the results from the two simulations: for i=1:length(loggedSignalsHarness.TestCases)

simout = cgvSim.getOutputData(i);

12-9

12

Verifying Generated Code for a Component

silout = cgvSil.getOutputData(i);

[matchNames, ~, mismatchNames, ~ ] = ...

cgv.CGV.compare(simout, silout);

4

Display the results of the comparison in the MATLAB command window: fprintf('\nTest Case(%d): %d Signals match, ...

%d Signals mismatch', i, length(matchNames), ...

length(mismatchNames)); end

For more information about Software-in-the-Loop (SIL) simulations, see “What are SIL and PIL Simulations?”

12-10

Signal Monitoring with

Model Verification Blocks

13

Using Model Verification Blocks

• “Model Verification Blocks and the Verification Manager” on page 13-2

• “Use Check Static Lower Bound Block to Check for Out-of-Bounds Signal” on page

13-3

• “Linear System Modeling Blocks in Simulink Control Design” on page 13-6

13

Using Model Verification Blocks

Model Verification Blocks and the Verification Manager

Simulink Model Verification library blocks monitor time-domain signals in your model during simulation, according to the specifications that you assign to the blocks.

Note: To see a complete description of all Simulink model verification blocks, see the

“Model Verification” category in the Simulink documentation.

You set a verification block to assert when its signal leaves the limit or range that you specify. During simulation, when the signal crosses the limit, the verification block can:

• Stop the simulation and bring immediate focus to that part of the model.

• Report the limit encounter with a logical signal output of its own. If the simulation does not encounter the limit, the signal output is true. If the simulation encounters the limit, the signal output is false.

The Verification Manager is a graphical interface in the Signal Builder dialog box. Using this tool, you can manage all the Model Verification blocks in your model from a central location.

If you have Simulink Control Design™ software, you can also monitor frequency-domain characteristics such as:

• Gain and phase margins

• Peak magnitude

Note: For more information about the Simulink Control Design model verification blocks, see “Model Verification” in the Simulink Control Design documentation.

13-2

Use Check Static Lower Bound Block to Check for Out-of-Bounds Signal

Use Check Static Lower Bound Block to Check for Out-of-Bounds

Signal

The following example uses a Check Static Lower Bound block to stop simulation when a signal from a Sine Wave block crosses its lower bound limit.

1

Attach a Check Static Lower Bound block to the signal from a Sine Wave block.

2

Set the Simulation stop time to 2 seconds.

3 Double-click the Sine Wave block and set the following parameters:

• Set the Amplitude to 1.

• Set the Frequency to pi radians per second.

4

Double-click the Check Static Lower Bound block and set the Lower bound parameter to -0.8.

Enable assertion is the default. This parameter enables a verification block for an assertion. You set the Check Static Lower Bound block to detect a signal value of –

0.8 or lower. If the signal value reaches that value or falls below it, the simulation stops.

5 Run the simulation.

The model stops simulating after 1.295 seconds, when the output is –0.8. The software highlights the Check Static Lower Bound block.

When the simulation stops, you see the following diagnostic message.

13-3

13

Using Model Verification Blocks

13-4

6 To verify the signal value, double-click the Scope block.

Use Check Static Lower Bound Block to Check for Out-of-Bounds Signal

7 To disable the Check Static Lower Bound block from asserting its limit, clear the

Enable assertion check box.

The block is crossed out in the model, as shown.

13-5

13

Using Model Verification Blocks

Linear System Modeling Blocks in Simulink Control Design

If you have Simulink Control Design software, you can:

• Specify bounds on linear system characteristics.

• Check that the bounds are satisfied during simulation.

For example, you can check if the linearized behavior of your model satisfied upper and lower magnitude bounds on a Bode plot or gain and phase margins. For more information, see the individual block reference pages in the “Model Verification” category of the Simulink Control Design documentation.

13-6

14

Constructing Simulation Tests Using the Verification Manager

• “What Is the Verification Manager?” on page 14-2

• “Construct Simulation Tests Using the Verification Manager” on page 14-3

14

Constructing Simulation Tests Using the Verification Manager

What Is the Verification Manager?

The Verification Manager is a graphical interface in the Signal Builder dialog box. Using this tool, you can manage all the Model Verification blocks in your model from a central location.

14-2

Construct Simulation Tests Using the Verification Manager

Construct Simulation Tests Using the Verification Manager

In this section...

“View Model Verification Blocks” on page 14-3

“Enable and Disable Model Verification Blocks in a Model” on page 14-9

“Enable and Disable Model Verification Blocks in a Subsystem” on page 14-12

“Use Check Static Lower Bound Block to Check for Out-of-Bounds Signal” on page

14-16

“Link Test Cases to Requirements Documents Using the Verification Manager” on page

14-19

View Model Verification Blocks

Create a Simulink model that you can use to examine the Verification Manager.

1 In the Simulink software, create the following example model.

14-3

14

Constructing Simulation Tests Using the Verification Manager

In the example model, the contents of the subsystem are as follows.

14-4 a

In the Signal Builder block, create a signal group with five signals in the group.

Construct Simulation Tests Using the Verification Manager b Make two copies of the signal group, so that you have three signal groups:

Group 1, Group 2, Group 3.

Note: A Signal Builder block provides test signals for an entire model from one location. This model contains a Signal Builder block that feeds five test signals to the Model Verification blocks. The model sends the first four signals directly to Check Static Upper Bound blocks. The model sends the fifth signal to a subsystem that contains a Check Static Upper Bound block.

For more information on the Signal Builder block, see “Signal Groups” in the

Simulink documentation.

c

To set each Check Static Upper Bound verification block to assert for an upper bound of 1, set the Upper bound parameter to 1.

d For the following blocks, disable the assertion by clearing the Enable assertion parameter:

• Check Static Upper Bound

• Check Static Upper Bound1

• Check Static Upper Bound2

• Check Static Upper Bound in the subsystem

These blocks are crossed out in the model.

e To enable the Check Static Upper Bound3 block, select the Enable assertion parameter.

2 Save this model and name it ex_verif_mgr_test_signals.

3

To open the model Signal Builder dialog box, double-click the Signal Builder block.

The signals in the first group (Group 1 in this example) are displayed.

14-5

14

Constructing Simulation Tests Using the Verification Manager

14-6

4 On the Signal Builder dialog box toolbar, select the Show Verification Settings tool

.

The Verification block settings pane and the Requirements pane are displayed.

Construct Simulation Tests Using the Verification Manager

The Verification block settings pane lists all Model Verification blocks in the model, grouped by subsystem. If you right-click in this pane, you can select on of three options for viewing Model Verification blocks in this window:

Display > Tree format — If enabled, lists the blocks as they appear in the model hierarchy.

Display > Overridden blocks only — If enabled, lists only the blocks that have been disabled.

14-7

14

Constructing Simulation Tests Using the Verification Manager

Display > Active blocks only — If enabled, lists only the blocks that are enabled.

Note: If both Overridden blocks only and Active blocks only are enabled, no

Model Verification blocks appear. If both Overridden blocks only and Active

blocks only are disabled, all Model Verification blocks appear.

In this example, the Verification block settings pane displays five Check

Static Upper Bound blocks. Four are in the top level of the model, and one is in a subsystem.

The Requirements pane lists the requirements document links for the current signal group. For details on adding requirement document links in the Signal

Builder dialog box, see “Link Test Cases to Requirements Documents Using the

Verification Manager” on page 14-19.

5

For this example, select to close the Requirements pane.

6 To display only the enabled Model Verification blocks for the current signal group, in the Verification block settings toolbar, select the List Enabled Verifications tool

.

14-8

7 To redisplay all Model Verification blocks for the current group, click the Show

Verification Block Hierarchy tool .

Construct Simulation Tests Using the Verification Manager

Enable and Disable Model Verification Blocks in a Model

Use the Verification Manager to enable and disable individual Model Verification blocks in signal groups. To open the Verification Manager in the Signal Builder dialog box, click

.

The Verification block settings pane lists the Model Verification blocks in the model.

Each verification block has a status node that indicates whether its assertion is enabled or disabled. Each verification block's status node also indicates whether the enabled or disabled setting applies universally or to the active group. The following table describes the different types of status nodes.

Node Status

Verification block is disabled for this group. Click to enable for the current group.

Verification block is enabled for the current group. Click to disable for the current group.

Verification block is enabled for all test groups.

Use the Verification Manager to enable or disable model verification blocks in the ex_verif_mgr_test_signals

model that you created in “View Model Verification

Blocks” on page 14-3.

1

In the Verification Manager, click the empty check box next to the Check Static

Upper Bound1 node to enable that node for the current active group (Group 1).

In the Verification block settings pane, when you enable a disabled block, you see the following change in how the block is displayed in the model.

14-9

14

Constructing Simulation Tests Using the Verification Manager

14-10

Because you enabled the Check Static Upper Bound1 block in the current group, an

Override label is applied to the block and it is no longer crossed out.

2 In the Signal Builder, from the Active Group list, select Group 2.

3

Select the empty check box next to the Check Static Upper Bound2 node to enable that block for the current group (Group 2).

Construct Simulation Tests Using the Verification Manager

The Check Static Upper Bound2 block is no longer crossed out, indicating that the block is enabled for the current group. Check Static Upper Bound1, however, is crossed out because it is enabled in a different group.

14-11

14

Constructing Simulation Tests Using the Verification Manager

14-12

4 Save the model with these changes.

Enable and Disable Model Verification Blocks in a Subsystem

If you have a lot of verification blocks, it is tedious to enable and disable blocks individually. Using the Verification Manager, you can enable and disable blocks from context menu options. Depending on the status of the node, you have the following options.

Node Status Context Menu Options

• Contents enable for all groups

• Contents enable by group

Construct Simulation Tests Using the Verification Manager

Node Status Context Menu Options

• Contents group enable

• Contents group disable

• Block enable by group

• Block enable for all groups

• Block group enable

• Block enable for all groups

• Block group disable

For example, assume that you define the following groups in the Verification Manager for a model with five Model Verification blocks.

Group 1 Group 2 Group 3

1 In the Verification Manager window, right-click the ex_verif_mgr_test_signals node and select Contents enable for all groups.

This option enables all verification blocks, for all test groups, in all subsystems; the settings for all groups look as follows:

2 Right-click ex_verif_mgr_test_signals and select Contents enable by group.

14-13

14

Constructing Simulation Tests Using the Verification Manager

This option restores the individually enabled/disabled settings for each verification block in each group.

Group 1 Group 2 Group 3

3

From the Active Group list, select Group 1. Right-click ex_verif_mgr_test_signals

, and select Contents group enable.

This option individually enables all contained blocks for only Group 1.

Group 1 Group 2 (unchanged) Group 3 (unchanged)

4

From the Active Group list, select Group 1. Right-click ex_verif_mgr_test_signals

and select Contents group disable.

This option individually disables all contained blocks for only Group 1.

Group 1 Group 2 (unchanged) Group 3 (unchanged)

14-14

Construct Simulation Tests Using the Verification Manager

5 From the Active Group list, select Group 1. Right-click the Check Static Upper

Bound node, and select Block enable for all groups.

This option enables the Check Static Upper Bound block for all groups.

Group 1 Group 2 Group 3

6 From the Active Group list, select Group 1. Right-click the Check Static Upper

Bound node, and select Block enable by group.

This option restores the individually enabled/disabled state to this block for all groups. The Block enable by group option lets you enable or disable this node individually for each group.

Group 1 Group 2 Group 3

7

From the Active Group list, select Group 1. Right-click the Check Static Upper

Bound node, and select Block group enable.

This option enables the Check Static Upper Bound block for this group only.

14-15

14

Constructing Simulation Tests Using the Verification Manager

Group 1 Group 2 (unchanged) Group 3 (unchanged)

Selecting Block group disable disables the specified block for this group only.

Use Check Static Lower Bound Block to Check for Out-of-Bounds Signal

The following example uses a Check Static Lower Bound block to stop simulation when a signal from a Sine Wave block crosses its lower bound limit.

1 Attach a Check Static Lower Bound block to the signal from a Sine Wave block.

14-16

2

Set the Simulation stop time to 2 seconds.

3 Double-click the Sine Wave block and set the following parameters:

• Set the Amplitude to 1.

• Set the Frequency to pi radians per second.

4 Double-click the Check Static Lower Bound block and set the Lower bound parameter to -0.8.

Enable assertion is the default. This parameter enables a verification block for an assertion. You set the Check Static Lower Bound block to detect a signal value of –

Construct Simulation Tests Using the Verification Manager

0.8 or lower. If the signal value reaches that value or falls below it, the simulation stops.

5

Run the simulation.

The model stops simulating after 1.295 seconds, when the output is –0.8. The software highlights the Check Static Lower Bound block.

When the simulation stops, you see the following diagnostic message.

6 To verify the signal value, double-click the Scope block.

14-17

14

Constructing Simulation Tests Using the Verification Manager

14-18

7 To disable the Check Static Lower Bound block from asserting its limit, clear the

Enable assertion check box.

The block is crossed out in the model, as shown.

Construct Simulation Tests Using the Verification Manager

Link Test Cases to Requirements Documents Using the Verification

Manager

You can link requirements documents to test cases and their corresponding Model

Verification blocks through the Verification Manager Requirements pane in the Signal

Builder.

1 To display the Requirements pane in the Signal Builder dialog box: a

Click the Show verification settings button ( ).

b

Click the Requirements display button ( ).

2 In the Requirements pane, right-click anywhere.

3

From the context menu, select Link Editor.

The Requirements dialog box opens.

4 When you browse and select a requirements document, the RMI stores the document path as specified by the Document file reference option on the Requirements

Settings dialog box, Selection Linking tab.

For information about which setting to use for your working environment, see

“Document Path Storage” on page 5-15.

5

Add links to requirements documents, as described in “Link to Requirements

Document Using Selection-Based Linking” on page 2-11.

The names of the linked requirements appear in the Requirements pane.

14-19

14

Constructing Simulation Tests Using the Verification Manager

14-20

6 To view the requirements document in its native editor, right-click a requirement link and select View.

7 Optionally, to delete a requirement link, right-click the link and select Delete.

Model Coverage Analysis

Model Coverage Definition

• “Model Coverage” on page 15-2

• “Types of Model Coverage” on page 15-3

• “Simulink Optimizations and Model Coverage” on page 15-11

15

15

Model Coverage Definition

Model Coverage

Model coverage helps you validate your model tests by measuring how thoroughly the model objects are tested. Model coverage calculates how much a model test case exercises simulation pathways through a model. Model coverage is a measure of how thoroughly a test case tests a model and the percentage of pathways that a test case exercises. Model coverage helps you validate your model tests.

Model coverage analyzes the execution of the following types of model objects that directly or indirectly determine simulation pathways through your model:

• Simulink blocks

• Models referenced in Model blocks

• The states and transitions of Stateflow charts

During a simulation run, the tool records the behavior of the covered objects, states, and transitions. At the end of the simulation, the tool reports the extent to which the run exercised potential simulation pathways through each covered object in the model.

The Simulink Verification and Validation software can only collect coverage for a model if its simulation mode is set to Normal. If the simulation mode is set to any mode other than Normal, coverage will not be measured during simulation.

For the types of coverage that model coverage performs, see “Types of Model Coverage” on page 15-3. For an example of a model coverage report, see “Top-Level Model

Coverage Report”.

15-2

Types of Model Coverage

Types of Model Coverage

Simulink Verification and Validation software can perform several types of coverage analysis.

In this section...

“Cyclomatic Complexity” on page 15-3

“Condition Coverage (CC)” on page 15-4

“Decision Coverage (DC)” on page 15-4

“Lookup Table Coverage” on page 15-4

“Modified Condition/Decision Coverage (MCDC)” on page 15-5

“Relational Boundary Coverage” on page 15-6

“Saturate on Integer Overflow Coverage” on page 15-8

“Signal Range Coverage” on page 15-8

“Signal Size Coverage” on page 15-9

“Simulink Design Verifier Coverage” on page 15-9

Cyclomatic Complexity

Cyclomatic complexity is a measure of the structural complexity of a model. It approximates the McCabe complexity measure for code generated from the model. The

McCabe complexity measure is slightly higher on the generated code due to error checks that the model coverage analysis does not consider.

To compute the cyclomatic complexity of an object (such as a block, chart, or state), model coverage uses the following formula: c

=

N

(

1 )

1 o n

N is the number of decision points that the object represents and o subsystems and Stateflow charts.

n

is the number of outcomes for the nth decision point. The tool adds 1 to the complexity number for atomic

15-3

15

Model Coverage Definition

15-4

For an example of cyclomatic complexity data in a model coverage report, see “Cyclomatic

Complexity” on page 19-22.

Condition Coverage (CC)

Condition coverage analyzes blocks that output the logical combination of their inputs

(for example, the Logical Operator block) and Stateflow transitions. A test case achieves full coverage when it causes each input to each instance of a logic block in the model and each condition on a transition to be true at least once during the simulation, and false at least once during the simulation. Condition coverage analysis reports whether the test case fully covered the block for each block in the model.

When you collect coverage for a model, you may not be able to achieve 100% condition coverage. For example, if you specify to short-circuit logic blocks, by selecting Treat

Simulink Logic blocks as short-circuited in the Coverage Settings dialog box, you

might not be able to achieve 100% condition coverage for that block. See “Treat Simulink logic blocks as short-circuited” on page 17-12 for more information.

For an example of condition coverage data in a model coverage report, see “Conditions

Analyzed” on page 19-25.

Decision Coverage (DC)

Decision coverage analyzes elements that represent decision points in a model, such as a Switch block or Stateflow states. For each item, decision coverage determines the percentage of the total number of simulation paths through the item that the simulation actually traversed.

For an example of decision coverage data in a model coverage report, see “Decisions

Analyzed” on page 19-24.

Lookup Table Coverage

Lookup table coverage (LUT) examines blocks, such as the 1-D Lookup Table block, that output information from inputs in a table of inputs and outputs, interpolating between or extrapolating from table entries. Lookup table coverage records the frequency that table lookups use each interpolation interval. A test case achieves full coverage when it executes each interpolation and extrapolation interval at least once. For each lookup table block in the model, the coverage report displays a colored map of the lookup table,

Types of Model Coverage indicating each interpolation. If the total number of breakpoints of an n-D Lookup Table block exceeds 1,500,000, the software cannot record coverage for that block.

For an example of lookup table coverage data in a model coverage report, see “N-

Dimensional Lookup Table” on page 19-30.

Note: Configure lookup table coverage only at the start of a simulation. If you tune a parameter that affects lookup table coverage at run time, the coverage settings for the affected block are not updated.

Modified Condition/Decision Coverage (MCDC)

Modified condition/decision coverage analysis by the Simulink Verification and

Validation software extends the decision and condition coverage capabilities. It analyzes blocks that output the logical combination of their inputs and Stateflow transitions to determine the extent to which the test case tests the independence of logical block inputs and transition conditions.

• A test case achieves full coverage for a block when a change in one input, independent of any other inputs, causes a change in the block's output.

• A test case achieves full coverage for a Stateflow transition when there is at least one time when a change in the condition triggers the transition for each condition.

If your model contains blocks that define expressions that have different types of logical operators and more than 12 conditions, the software cannot record MCDC coverage.

Because the Simulink Verification and Validation MCDC coverage may not achieve full decision or condition coverage, you can achieve 100% MCDC coverage without achieving

100% decision coverage.

Some Simulink objects support MCDC coverage, some objects support only condition coverage, and some objects support only decision coverage. The table in “Model Objects

That Receive Coverage” lists which objects receive which types of model coverage. For example, the Combinatorial Logic block can receive decision coverage and condition coverage, but not MCDC coverage.

To achieve 100% MCDC coverage for your model, as defined by the DO-178C/DO-331 standard, in the Coverage Settings dialog box, collect coverage for all of the following coverage metrics:

15-5

15

Model Coverage Definition

15-6

• Condition Coverage

• Decision Coverage

• MCDC Coverage

When you collect coverage for a model, you may not be able to achieve 100% MCDC coverage. For example, if you specify to short-circuit logic blocks, you may not be able to achieve 100% MCDC coverage for that block.

If you run the test cases independently and accumulate all the coverage results, you can determine if your model adheres to the modified condition and decision coverage standard. For more information about the DO-178C/DO-331 standard, see “DO-178C/

DO-331 Checks”.

For an example of MCDC coverage data in a model coverage report, see “MCDC Analysis”

on page 19-26. For an example of accumulated coverage results, see “Cumulative

Coverage” on page 19-27.

Relational Boundary Coverage

Relational boundary coverage examines blocks, Stateflow charts and MATLAB function blocks that have an explicit or implicit relational operation.

• Blocks such as Relational Operator and If have an explicit relational operation.

• Blocks such as Abs and Saturation have an implicit relational operation.

For these model objects, the metric records whether a simulation tests the relational operation with:

• Equal operand values.

This part of relational boundary coverage applies only if both operands are integers or fixed-point numbers.

• Operand values that differ by a certain tolerance.

This part of relational boundary coverage applies to all operands. For integer and fixed-point operands, the tolerance is fixed. For floating-point operands, you can either use a predefined tolerance or you can specify your own tolerance.

The tolerance value depends on the data type of both the operands. If both operands have the same type, the tolerance follows the following rules:

Types of Model Coverage

Data Type of Operand Tolerance

Floating point, such as single or double max(absTol, relTol* max(|lhs|,| rhs|))

Fixed point

Integer

Boolean

Enum

• absTol is an absolute tolerance value you specify. Default is 1e-05.

• relTol is a relative tolerance value you specify. Default is 0.01.

• lhs is the left operand and rhs the right operand.

• max(x,y) returns x or y, whichever is greater.

Value corresponding to least significant bit. For more information, see “Precision”.

To find the precision value, use the lsb function.

1

N/A

N/A

If the two operands have different types, the tolerance follows the rules for the stricter type. If one of the operands is boolean, the tolerance follows the rules for the other operand. The strictness decreases in this order:

1 Floating point

2 Fixed point

3 Integer

If both operands are fixed-point but have different precision, the smaller value of precision is used as tolerance.

For more information on:

• How to specify this coverage metric, see “Coverage Tab”.

• How to specify the tolerance for floating-point numbers, see “Options Tab”.

• How this coverage metric appears in reports, see “Relational Boundary”.

15-7

15

Model Coverage Definition

15-8

• Which model objects receive this coverage, see the table in “Model Objects That

Receive Coverage”.

• How to obtain coverage results from the MATLAB command-line, see “Collect

Relational Boundary Coverage for Supported Block in Model”.

Saturate on Integer Overflow Coverage

Saturate on integer overflow coverage examines blocks, such as the Abs block, with the

Saturate on integer overflow parameter selected. Only blocks with this parameter selected receive saturate on integer overflow coverage.

Saturate on integer overflow coverage records the number of times the block saturates on integer overflow.

A test case achieves full coverage when the blocks saturate on integer overflow at least once and does not saturate at least once.

For an example of saturate on integer overflow coverage data in a model coverage report,

see “Saturate on Integer Overflow Analysis” on page 19-41.

Signal Range Coverage

Signal range coverage records the minimum and maximum signal values at each block in the model, as measured during simulation. Only blocks with output signals receive signal range coverage.

The software does not record signal range coverage for control signals, signals used by one block to initiate execution of another block. See “Control Signals”.

If the total number of signals in your model exceeds 65535, or your model contains a signal whose width exceeds 65535, the software cannot record signal range coverage.

For an example of signal range coverage data in a model coverage report, see “Signal

Range Analysis” on page 19-42.

Note: When you create cumulative coverage for reusable subsystems or Stateflow constructs with single range coverage, the cumulative coverage has the largest possible range of signal values. For more information, see “Obtain Cumulative Coverage for

Reusable Subsystems and Stateflow® Constructs”.

Types of Model Coverage

Signal Size Coverage

Signal size coverage records the minimum, maximum, and allocated size for all variablesize signals in a model. Only blocks with variable-size output signals are included in the report.

If the total number of signals in your model exceeds 65535, or your model contains a signal whose width exceeds 65535, the software cannot record signal size coverage.

For an example of signal size coverage data in a model coverage report, see “Signal Size

Coverage for Variable-Dimension Signals” on page 19-44.

For more information about variable-size signals, see “Variable-Size Signal Basics”.

Simulink Design Verifier Coverage

The Simulink Verification and Validation software collects model coverage data for the following Simulink Design Verifier blocks and MATLAB for code generation functions:

Simulink Design Verifier blocks

Test Condition

Test Objective

Proof Assumption

Proof Objective

MATLAB for code generation functions sldv.condition

sldv.test

sldv.assume

sldv.prove

If you do not have a Simulink Design Verifier license, you can collect model coverage for a model that contains these blocks or functions, but you cannot analyze the model using the Simulink Design Verifier software.

By adding one or more Simulink Design Verifier blocks or functions into your model, you can:

• Check the results of a Simulink Design Verifier analysis, run generated test cases, and use the blocks to observe the results.

• Define model requirements using the Test Objective block and verify the results with model coverage data that the software collected during simulation.

• Analyze the model, create a test harness, and simulate the harness with the Test

Objective block to collect model coverage data.

15-9

15

Model Coverage Definition

• Analyze the model and use the Proof Assumption block to verify any counterexamples that the Simulink Design Verifier identifies.

If you specify to collect Simulink Design Verifier coverage:

• The software collects coverage for the Simulink Design Verifier blocks and functions.

• The software checks the data type of the signal that links to each Simulink Design

Verifier block. If the signal data type is fixed point, the block parameter must also be fixed point. If the signal data type is not fixed point, the software tries to convert the block parameter data type. If the software cannot convert the block parameter data type, the software reports an error and you must explicitly assign the block parameter data type to match the signal.

• If your model contains a Verification Subsystem block, the software only records coverage for Simulink Design Verifier blocks in the Verification Subsystem block; it does not record coverage for any other blocks in the Verification Subsystem.

If you do not specify to collect Simulink Design Verifier coverage, the software does not check the data types for any Simulink Design Verifier blocks and functions in your model and does not collect coverage.

For an example of coverage data for Simulink Design Verifier blocks or functions in a

model coverage report, see “Simulink Design Verifier Coverage” on page 19-45.

15-10

Simulink Optimizations and Model Coverage

Simulink Optimizations and Model Coverage

In the Configuration Parameters dialog box Optimization pane, there are three

Simulink optimization parameters that can affect your model coverage data:

In this section...

“Inline parameters” on page 15-11

“Block reduction” on page 15-11

“Conditional input branch execution” on page 15-12

Inline parameters

To transform tunable model parameters into constant values for code generation, in the

Configuration Parameters dialog box, on the Optimization > Signals and Parameters pane, select Inline parameters. When you enable this option, you cannot change the values of block parameters during simulation.

When the parameters are transformed into constants, Simulink may eliminate certain decisions in your model. You cannot achieve coverage for eliminated decision, so the coverage report displays 0/0 for those decisions.

Block reduction

To achieve faster execution during model simulation and in generated code, in the

Configuration Parameters dialog box, on the Optimization pane, select the Block

reduction parameter. The Simulink software collapses certain groups of blocks into a single, more efficient block, or removes them entirely.

One of the model coverage options, Force block reduction off, allows you to ignore the

Block reduction parameter when collecting model coverage.

If you do not select the Block reduction parameter, or if you select Force block

reduction off, the Simulink Verification and Validation software provides coverage data for every block in the model that collects coverage.

If you select the Block reduction parameter and do not set Force block reduction

off, the coverage report lists the reduced blocks that would have collected coverage.

15-11

15

Model Coverage Definition

Conditional input branch execution

To improve model execution when the model contains Switch and Multiport Switch blocks, in the Configuration Parameters dialog box, on the Optimization pane, select

Conditional input branch execution. If you select this parameter, the simulation executes only blocks that are required to compute the control input and the data input selected by the control input.

When Conditional input branch execution is enabled, instead of executing all blocks driving the Switch block input ports at each time step, only the blocks required to compute the control input and the data input selected by the control input execute.

Several considerations affect or limit Switch block optimization:

• Only blocks with -1 (inherited) or inf (Constant) sample time can be optimized.

• Blocks with outputs flagged as test points cannot be optimized.

• Multirate blocks cannot be optimized.

• Blocks with states cannot be optimized.

• Only S-functions with the SS_OPTION_CAN_BE_CALLED_CONDITIONALLY option enabled can be optimized.

For example, if your model has a Switch block with output flagged as a test point, such as when a Scope block is attached, that Switch block is not executed, and the model coverage data is incomplete. If you have a model with Switch blocks and you want to verify that the model coverage data is complete, clear Conditional input branch

execution.

Conditional input branch execution does not apply to Stateflow charts.

15-12

16

Model Objects That Receive Model

Coverage

16

Model Objects That Receive Model Coverage

Model Objects That Receive Coverage

Certain Simulink objects can receive any type of model coverage. Other Simulink objects can receive only certain types of coverage, as the following table shows. Click a link in the first column to get more detailed information about coverage for specific model objects.

For Stateflow states, events, and state temporal logic decisions, model coverage provides only decision coverage. For Stateflow transitions, model coverage provides decision,

condition, and MCDC coverage. For more information, see “Model Coverage for Stateflow

Charts” on page 18-45.

Model Object Decision Condition MCDC

“Abs” on page

16-7

“Bias” on page

16-8

“Combinatorial

Logic” on page

16-8

“Compare to

Constant” on page 16-9

“Compare to

Zero” on page

16-9

“Data Type

Conversion” on page 16-10

“Dead Zone” on page 16-10

“Direct Lookup

Table (n-D)” on page 16-11

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Lookup

Table

 

 

 

 

 

 

 

Simulink

Design

Verifier

 

Saturate on Integer

Overflow

Relational

Boundary

   

 

 

 

 

 

 

 

 

 

 

 

 

 

16-2

Model Objects That Receive Coverage

Model Object Decision Condition MCDC

“Discrete

Filter” on page

16-11

“Discrete FIR

Filter” on page

16-11

“Discrete-Time

Integrator” on page

16-11 (when

saturation limits are enabled or reset)

“Discrete

Transfer Fcn” on page 16-12

“Dot Product” on page 16-13

“Enabled

Subsystem” on page 16-13

“Enabled and

Triggered

Subsystem” on page 16-13

“Fcn” on page

16-14

“For Iterator,

For Iterator

Subsystem” on page 16-15

“Gain” on page

16-15

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Lookup

Table

 

Simulink

Design

Verifier

Saturate on Integer

Overflow

Relational

Boundary

   

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

16-3

16

Model Objects That Receive Model Coverage

Model Object Decision Condition MCDC

“If, If Action

Subsystem” on page 16-16

“Interpolation

Using

Prelookup” on page 16-16

“Library-Linked

Objects” on page

16-17

“Logical

Operator” on page 16-17

“1-D Lookup

Table” on page

16-18

“2-D Lookup

Table” on page

16-18

“n-D Lookup

Table” on page

16-19

“Math Function” on page

16-20

“MATLAB

Function” on page 16-20

“MinMax” on page 16-20

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Lookup

Table

 

Simulink

Design

Verifier

Saturate on Integer

Overflow

Relational

Boundary

   

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

16-4

Model Objects That Receive Coverage

Model Object Decision Condition MCDC Lookup

Table

Simulink

Design

Verifier

Saturate on Integer

Overflow

Relational

Boundary

“Model” on page

16-20

See also

“Triggered

Models” on page

16-29.

“Multiport

Switch” on page

16-21

“PID Controller,

PID Controller

(2 DOF)” on page 16-21

“Product” on page 16-22

“Proof

Assumption” on page 16-22

“Proof Objective” on page

16-22

“Rate Limiter” on page

16-23

 

 

 

 

(Relative to slew rates)

“Relational

Operator” on page 16-23

“Relay” on page

16-24

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

16-5

16

Model Objects That Receive Model Coverage

Model Object Decision Condition MCDC

“C/C++ S-

Function” on page 16-25

“Saturation” on page 16-26

“Saturation

Dynamic” on page 16-26

“Simulink

Design Verifier

Functions in MATLAB

Function

Blocks” on page

16-27

Stateflow charts

Stateflow state transition tables

“Sqrt, Signed

Sqrt, Reciprocal

Sqrt” on page

16-27

“Sum, Add,

Subtract, Sum of Elements” on page 16-27

“Switch” on page

16-27

“SwitchCase,

SwitchCase

Action

Subsystem” on page 16-28

16-6

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Lookup

Table

 

 

 

Simulink

Design

Verifier

Saturate on Integer

Overflow

Relational

Boundary

     

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Model Objects That Receive Coverage

Model Object

“Test Condition” on page

16-28

“Test Objective” on page

16-29

“Triggered

Models” on page

16-29

“Triggered

Subsystem” on page 16-30

“Truth Table” on page 16-31

“Unary Minus” on page

16-31

“Weighted

Sample Time

Math” on page

16-31

“While Iterator,

While Iterator

Subsystem” on page 16-31

Decision Condition MCDC

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Lookup

Table

 

 

 

 

 

 

 

 

Simulink

Design

Verifier

Saturate on Integer

Overflow

Relational

Boundary

   

 

 

 

 

 

 

 

 

 

 

 

Abs

The Abs block receives decision coverage. Decision coverage is based on:

• Input to the block being less than zero.

• Data type of the input signal.

For input to the block being less than zero, the decision coverage measures:

 

 

 

 

 

 

 

16-7

16

Model Objects That Receive Model Coverage

16-8

• The number of time steps that the block input is less than zero, indicating a true decision.

• The number of time steps the block input is not less than zero, indicating a false decision.

If you select the Saturate on integer overflow coverage metric, the Abs block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer

Overflow Coverage”.

If the input data type to the Abs block is uint8, uint16, or uint32, the Simulink

Verification and Validation software reports no coverage for the block. The software sets the block output equal to the block input without making a decision. If the input data type to the Abs block is Boolean, an error occurs.

The Abs block contains an implicit comparison of the input with zero. Therefore, if you select the Relational Boundary coverage metric, the Abs block receives relational boundary coverage. For more information, see “Relational Boundary Coverage”.

Bias

If you select the Saturate on integer overflow coverage metric, the Bias block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer

Overflow Coverage”.

Combinatorial Logic

The Combinatorial Logic block receives decision and condition coverage. Decision coverage is based on achieving each output row of the truth table. The decision coverage measures the number of time steps that each output row of the truth table is set to the block output.

The condition coverage measures the number of time steps that each input is false

(equal to zero) and the number of times each input is true (not equal to zero). If the

Combinatorial Logic block has a single input element, the Simulink Verification and

Validation software reports only decision coverage, because decision and condition coverage are equivalent.

If all truth table values are set to the block output for at least one time step, decision coverage is 100%. Otherwise, the software reports the coverage as the number of truth table values output during at least one time step, divided by the total number of truth

Model Objects That Receive Coverage table values. Because this block always has at least one value in the truth table as output, the minimum coverage reported is one divided by the total number of truth table values.

If all block inputs are false for at least one time step and true for at least one time step, condition coverage is 100%. Otherwise, the software reports the coverage as achieving a false value at each input for at least one time step, plus achieving a true value for at least one time step, divided by two raised to the power of the total number of inputs (i.e.,

2^number_of_inputs). The minimum coverage reported is the total number of inputs divided by two raised to the power of the total number of inputs.

Compare to Constant

The Compare to Constant block receives condition coverage.

Condition coverage measures:

• the number of times that the comparison between the input and the specified constant was true.

• the number of times that the comparison between the input and the specified constant was false.

The Compare to Constant block contains a comparison of the input with a constant.

Therefore, if you select the Relational Boundary coverage metric, the Compare to Constant block receives relational boundary coverage. For more information, see

“Relational Boundary Coverage”.

Compare to Zero

The Compare to Zero block receives condition coverage.

Condition coverage measures:

• the number of times that the comparison between the input and zero was true.

• the number of times that the comparison between the input and zero was false.

The Compare to Zero block contains a comparison of the input with zero. Therefore, if you select the Relational Boundary coverage metric, the Compare to Zero block receives relational boundary coverage. For more information, see “Relational Boundary

Coverage”.

16-9

16

Model Objects That Receive Model Coverage

16-10

Data Type Conversion

If you select the Saturate on integer overflow coverage metric, the Data Type

Conversion block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer Overflow Coverage”.

Dead Zone

The Dead Zone block receives decision coverage. The Simulink Verification and

Validation software reports decision coverage for these parameters:

Start of dead zone

End of dead zone

The Start of dead zone parameter specifies the lower limit of the dead zone. For the

Start of dead zone parameter, decision coverage measures:

• The number of time steps that the block input is greater than or equal to the lower limit, indicating a true decision.

• The number of time steps that the block input is less than the lower limit, indicating a false decision.

The End of dead zone parameter specifies the upper limit of the dead zone. For the

End of dead zone, decision coverage measures:

• The number of time steps that the block input is greater than the upper limit, indicating a true decision.

• The number of time steps that the block input is less than or equal to the upper limit, indicating a false decision.

When the upper limit is true, the software does not measure Start of dead zone coverage for that time step. Therefore, the total number of Start of dead zone decisions equals the number of time steps that the End of dead zone is false.

If you select the Saturate on integer overflow coverage metric, the Dead Zone block receives saturate on integer overflow coverage. For more information, see “Saturate on

Integer Overflow Coverage”.

The Dead Zone block contains an implicit comparison of the input with an upper and lower limit value. Therefore, if you select the Relational Boundary coverage metric, the Dead Zone block receives relational boundary coverage. For more information, see

“Relational Boundary Coverage”.

Model Objects That Receive Coverage

Direct Lookup Table (n-D)

The Direct Lookup Table (n-D) block receives lookup table coverage. For an ndimensional lookup table, the number of output break points is the product of all the number of break points for each table dimension.

Lookup table coverage measures:

• The number of times during simulation that each combination of dimension input values is between each of the break points.

• The number of times during simulation that each combination of dimension input values is below the lowest break point and above the highest break point for each table dimension.

The total number of coverage points for an n-dimensional lookup table is the product of the number of break points in each table dimension plus one. In the coverage report, an increasing white-to-green color scale, with six evenly spaced data ranges starting with zero, indicates the number of time steps that the software measures each interpolation or extrapolation point.

The software determines a percentage of total coverage by measuring the total interpolation and extrapolation points that achieve a measurement of at least one time step during simulation between a break point or beyond the end points.

Discrete Filter

If you select the Saturate on integer overflow coverage metric, the Discrete Filter block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer Overflow Coverage”.

Discrete FIR Filter

If you select the Saturate on integer overflow coverage metric, the Discrete FIR Filter block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer Overflow Coverage”.

Discrete-Time Integrator

The Discrete-Time Integrator block receives decision coverage. The Simulink Verification and Validation software reports decision coverage for these parameters:

16-11

16

Model Objects That Receive Model Coverage

16-12

External reset

Limit output

If you set External reset to none, the Simulink Verification and Validation software does not report decision coverage for the reset decision. Otherwise, the decision coverage measures:

• The number of time steps that the block output is reset, indicating a true decision.

• The number of time steps that the block output is not reset, indicating a false decision.

If you do not select Limit output, the software does not report decision coverage for that decision. Otherwise, the software reports decision coverage for the Lower saturation

limit and the Upper saturation limit.

For the Upper saturation limit, decision coverage measures:

• The number of time steps that the integration result is greater than or equal to the upper limit, indicating a true decision.

• The number of time steps that the integration result is less than the upper limit, indicating a false decision.

For the Lower saturation limit, decision coverage measures

• The number of time steps that the integration result is less than or equal to the lower limit, indicating a true decision.

• The number of time steps that the integration result is greater than the lower limit, indicating a false decision.

For a time step when the upper limit is true, the software does not measure Lower

saturation limit coverage. Therefore, the total number of lower limit decisions equals the number of time steps that the upper limit is false.

If you select the Saturate on integer overflow coverage metric, the Discrete-Time

Integrator block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer Overflow Coverage”.

Discrete Transfer Fcn

If you select the Saturate on integer overflow coverage metric, the Discrete Transfer

Fcn block receives saturate on integer overflow coverage. For more information, see

“Saturate on Integer Overflow Coverage”.

Model Objects That Receive Coverage

Dot Product

If you select the Saturate on integer overflow coverage metric, the Dot Product block receives saturate on integer overflow coverage. For more information, see “Saturate on

Integer Overflow Coverage”.

Enabled Subsystem

The Enabled Subsystem block receives decision, condition, and MCDC coverage.

Decision coverage measures:

• The number of time steps that the block is enabled, indicating a true decision.

• The number of time steps that the block is disabled, indicating a false decision.

If at least one time step is true and at least one time step is false, decision coverage is

100%. If no time steps are true, or if no time steps are false, decision coverage is 50%.

The Simulink Verification and Validation software measures condition coverage for the enable input only if the enable input is a vector. For the enable input, condition coverage measures the number of time steps each element of the enable input is true and the number of time steps each element of the enable input is false. The software reports condition coverage based on the total number of possible conditions and how many are true for at least one time step and how many are false for at least one time step.

The software measures MCDC coverage for the enable input only if the enable input is a vector. Because the enable of the subsystem is an OR of the vector inputs, MCDC coverage is 100% if, during at least one time step, each vector enable input is exclusively true and if, during at least one time step, all vector enable inputs are false. For MCDC coverage measurement, the software treats each element of the vector as a separate condition.

Enabled and Triggered Subsystem

The Enabled and Triggered Subsystem block receives decision, condition, and MCDC coverage. Decision coverage measures:

• The number of time steps that a trigger edge occurs while the block is enabled, indicating a true decision.

• The number of time steps that a trigger edge does not occur while the block is enabled, or the block is disabled, indicating a false decision.

16-13

16

Model Objects That Receive Model Coverage

16-14

If at least one time step is true and at least one time step is false, decision coverage is

100%. If no time steps are true, or if no time steps are false, decision coverage is 50%.

The software measures condition coverage for the enable input and for the trigger input separately:

• For the enable input, condition coverage measures the number of time steps the enable input is true and the number of time steps the enable input is false.

• For the trigger input, condition coverage measures the number of time steps the trigger edge occurs, indicating true, and the number of time steps the trigger edge does not occur, indicating false.

The software reports condition coverage based on the total number of possible conditions and how many conditions are true for at least one time step and how many are false for at least one time step. The software treats each element of a vector as a separate condition coverage measurement.

The software measures MCDC coverage for the enable input and for the trigger input in combination. Because the enable input of the subsystem is an AND of these two inputs,

MCDC coverage is 100% if all of the following occur:

• During at least one time step, both inputs are true.

• During at least one time step, the enable input is true and the trigger edge is false.

• During one time step, the enable input is false and the trigger edge is true.

The software treats each vector element as a separate MCDC coverage measurement. It measures each trigger edge element against each enable input element. However, if the number of elements in both the trigger and enable inputs exceeds 12, the software does not report MCDC coverage.

Fcn

The Fcn block receives condition and MCDC coverage. The Simulink Verification and

Validation software reports condition or MCDC coverage for Fcn blocks only if the toplevel operator is Boolean (&&, ||, or !).

Condition coverage is based on input values or arithmetic expressions that are inputs to

Boolean operators in the block. The condition coverage measures:

• The number of time steps that each input to a Boolean operator is true (not equal to zero).

Model Objects That Receive Coverage

• The number of time steps that each input to a Boolean operator is false (equal to zero).

If all Boolean operator inputs are false for at least one time step and true for at least one time step, condition coverage is 100%. Otherwise, the software reports condition coverage based on the total number of possible conditions and how many are true for at least one time step and how many are false for at least one time step.

The software measures MCDC coverage for Boolean expressions within the Fcn block.

If, during at least one time step, each condition independently sets the output of the expression to true and if, during at least one time step, each condition independently sets the output of the expression to false, MCDC coverage is 100%. Otherwise, the software reports MCDC coverage based on the total number of possible conditions and how many times each condition independently sets the output to true during at least one time step and how many conditions independently set the output to false during at least one time step.

If the Fcn block contains a relational operation and you select the Relational Boundary coverage metric, the Fcn block receives relational boundary coverage. For more information, see “Relational Boundary Coverage”.

For Iterator, For Iterator Subsystem

The For Iterator block and For Iterator Subsystem receive decision coverage. The

Simulink Verification and Validation software measures decision coverage for the loop condition value, which is determined by one of the following:

• The iteration value being at or below the iteration limit, indicated as true.

• The iteration value being above the iteration limit, indicated as false.

The software reports the total number of times that each loop condition evaluates to true and to false. If the loop condition evaluates to true at least once and false at least once, decision coverage is 100%. If no loop conditions are true, or if no loop conditions are false, decision coverage is 50%.

Gain

If you select the Saturate on integer overflow coverage metric, the Gain block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer

Overflow Coverage”.

16-15

16

Model Objects That Receive Model Coverage

16-16

If, If Action Subsystem

The If block that causes an If Action Subsystem to execute receives condition, decision, and MCDC coverage:

• The software measures decision coverage for the if condition and all elseif conditions defined in the If block.

• If the if condition or any of the elseif conditions contains a logical expression with multiple conditions, such as u1 & u2 & u3, the software also measures condition and MCDC coverage for each condition in the expression, u1, u2, and u3 in the preceding example.

The software does not directly measure the else condition. When there are no elseif conditions, the else condition is the direct complement of the if condition, or the else condition is the direct complement of the last elseif condition.

The software reports the total number of time steps that each if and elseif condition evaluates to true and to false. If the if or elseif condition evaluates to true at least once, and evaluates to false at least once, decision coverage is 100%. If no if or elseif conditions are true, or if no if or elseif conditions are false, decision coverage is 50%.

If the previous if or elseif condition never evaluates as false, an elseif condition can have 0% decision coverage.

The If block contains a comparison between its inputs. Therefore, if you select the

Relational Boundary coverage metric, the If block receives relational boundary coverage. For more information, see “Relational Boundary Coverage”.

Interpolation Using Prelookup

The Interpolation Using Prelookup block receives lookup table coverage. For an n-D lookup table, the number of output break points equals the product of all the number of break points for each table dimension. The lookup table coverage measures:

• The number of times during simulation that each combination of dimension input values is between each of the break points.

• The number of times during simulation that each combination of dimension input values is below the lowest break point and above the highest break point for each table dimension.

The total number of coverage points for an n-dimensional lookup table is the product of the number of break points in each table dimension plus one. In the coverage report, an

Model Objects That Receive Coverage increasing white-to-green color scale, with six evenly spaced data ranges starting with zero, indicates the number of time steps that the software measures each interpolation or extrapolation point.

The software determines a percentage of total coverage by measuring the total interpolation and extrapolation points that achieve a measurement of at least one time step during simulation between a break point or beyond the end points.

If you select the Saturate on integer overflow, the Interpolation Using Prelookup block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

Library-Linked Objects

Simulink blocks and Stateflow charts that are linked to library objects receive the same coverage that they would receive if they were not linked to library objects. The Simulink

Verification and Validation software records coverage individually for each library object in the model. If your model contains multiple instances of the same library object, each instance receives its own coverage data.

Logical Operator

The Logical Operator block receives condition and MCDC coverage. The Simulink

Verification and Validation software measures condition coverage for each input to the block. The condition coverage measures:

• The number of time steps that each input is true (not equal to zero).

• The number of time steps that each input is false (equal to zero).

If all block inputs are false for at least one time step and true for at least one time step, the software condition coverage is 100%. Otherwise, the software reports the condition coverage based on the total number of possible conditions and how many are true at least one time step and how many are false at least one time step.

The software measures MCDC coverage for all inputs to the block. If, during at least one time step, each condition independently sets the output of the block to true and if, during at least one time step, each condition independently sets the output of the block to false, MCDC coverage is 100%. Otherwise, the software reports the MCDC coverage based on the total number of possible conditions and how many times each one

16-17

16

Model Objects That Receive Model Coverage

16-18 of them independently set the output to true for at least one time step and how many independently set the output to false for at least one time step.

1-D Lookup Table

The 1-D Lookup Table block receives lookup table coverage; for a one-dimensional lookup table, the number of input and output break points is equal. Lookup table coverage measures:

• The number of times during simulation that the input and output values are between each of the break points.

• The number of times during simulation that the input and output values are below the lowest break point and above the highest break point.

The total number of coverage points for a one-dimensional lookup table is the number of break points in the table plus one. In the coverage report, an increasing white-to-green color scale, with six evenly spaced data ranges starting with zero, indicates the number of time steps that the software measures each interpolation or extrapolation point.

The software determines a percentage of total coverage by measuring the total interpolation and extrapolation points that achieve a measurement of at least one time step during simulation between a break point or beyond the end points.

If you select the Saturate on integer overflow coverage metric, the 1-D Lookup Table block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

2-D Lookup Table

The 2-D Lookup Table block receives lookup table coverage. For a two-dimensional lookup table, the number of output break points equals the number of row break points multiplied by the number of column inputs. Lookup table coverage measures:

• The number of times during simulation that each combination of row input and column input values is between each of the break points.

• The number of times during simulation that each combination of row input and column input values is below the lowest break point and above the highest break point for each row and column.

Model Objects That Receive Coverage

The total number of coverage points for a two-dimensional lookup table is the number of row break points in the table plus one, multiplied by the number of column break points in the table plus one. In the coverage report, an increasing white-to-green color scale, with six evenly spaced data ranges starting with zero, indicates the number of time steps that the software measures each interpolation or extrapolation point.

If you select the Saturate on integer overflow coverage metric, the 2-D Lookup Table block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

n-D Lookup Table

The n-D Lookup Table block receives lookup table coverage. For an n-dimensional lookup table, the number of output break points equals the product of all the number of break points for each table dimension. Lookup table coverage measures:

• The number of times during simulation that each combination of dimension input values is between each of the break points.

• The number of times during simulation that each combination of dimension output values is below the lowest break point and above the highest break point for each table dimension.

The total number of coverage points for an n-dimensional lookup table is the product of the number of break points in each table dimension plus one. In the coverage report, an increasing white-to-green color scale, with six evenly spaced data ranges starting with zero, indicates the number of time steps that the software measures each interpolation or extrapolation point.

The software determines a percentage of total coverage by measuring the total interpolation and extrapolation points that achieve a measurement of at least one time step during simulation between a break point or beyond the end points.

If you select the Saturate on integer overflow coverage metric, the n-D Lookup Table block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

16-19

16

Model Objects That Receive Model Coverage

16-20

Math Function

If you select the Saturate on integer overflow coverage metric, the Math Function block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

MATLAB Function

For information about the type of coverage that the Simulink Verification and Validation

software reports for the MATLAB Function block, see “Model Coverage for MATLAB

Functions” on page 18-20.

MinMax

The MinMax block receives decision coverage based on passing each input to the output of the block.

For decision coverage based on passing each input to the output of the block, the coverage measures the number of time steps that the simulation passes each input to the block output. The number of decision points is based on the number of inputs to the block and whether they are scalar, vector, or matrix.

If all inputs are passed to the block output for at least one time step, the Simulink

Verification and Validation software reports the decision coverage as 100%. Otherwise, the software reports the coverage as the number of inputs passed to the output during at least one time step, divided by the total number of inputs.

If you select the Saturate on integer overflow coverage metric, the MinMax block receives saturate on integer overflow coverage. For more information, see “Saturate on

Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

Model

The Model block does not receive coverage directly; the model that the block references receives coverage. If the simulation mode for the referenced model is set to Normal, the

Simulink Verification and Validation software reports coverage for all objects within the referenced model that receive coverage. If the simulation mode is set to a value other than Normal, the software cannot measure coverage for the referenced model.

Model Objects That Receive Coverage

In the Coverage Settings dialog box, select the referenced models for which you want to report coverage. The software generates a coverage report for each referenced model you select.

If your model contains multiple instances of the same referenced model, the software records coverage for all instances of that model where the simulation mode of the Model block is set to Normal. The coverage report for that referenced model combines the coverage data for all Normal mode instances of that model.

The coverage reports for referenced models are linked from a summary report for the parent model.

Note:

For details on how to select referenced models to report coverage, see “Coverage for referenced models” on page 17-4.

Multiport Switch

The Multiport Switch block receives decision coverage based on passing each input, excluding the first control input, to the output of the block.

For decision coverage based on passing each input, excluding the first control input, to the output of the block, the coverage measures the number of time steps that each input is passed to the block output. The number of decision points is based on the number of inputs to the block and whether the control input is scalar or vector.

If all inputs, excluding the first control input, are passed to the block output for at least one time step, decision coverage is 100%. Otherwise, the Simulink Verification and

Validation software reports coverage as the number of inputs passed to the output during at least one time step, divided by the total number of inputs minus one.

If you select the Saturate on integer overflow coverage metric, the Multiport Switch block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

PID Controller, PID Controller (2 DOF)

If you select the Saturate on integer overflow coverage metric, the PID Controller and PID Controller (2 DOF) blocks receive saturate on integer overflow coverage. For

16-21

16

Model Objects That Receive Model Coverage more information, see “Saturate on Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

Product

If you select the Saturate on integer overflow coverage metric, the Product block receives saturate on integer overflow coverage. For more information, see “Saturate on

Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

Proof Assumption

The Proof Assumption block receives Simulink Design Verifier coverage. Simulink

Design Verifier coverage is based on the points and intervals defined in the block dialog box. Simulink Design Verifier coverage measures the number of time steps that each point or interval defined in the block is satisfied. The total number of objective outcomes is based on the number of points or intervals defined in the Proof Assumption block.

If all points and intervals defined in the block are satisfied for at least one time step,

Simulink Design Verifier coverage is 100%. Otherwise, the Simulink Verification and

Validation software reports coverage as the number of points and intervals satisfied during at least one time step, divided by the total number of points and intervals defined for the block.

Proof Objective

The Proof Objective block receives Simulink Design Verifier coverage. Simulink Design

Verifier coverage is based on the points and intervals defined in the block dialog box.

Simulink Design Verifier coverage measures the number of time steps that each point or interval defined in the block is satisfied. The total number of objective outcomes is based on the number of points or intervals defined in the Proof Objective block.

If all points and intervals defined in the block are satisfied for at least one time step,

Simulink Design Verifier coverage is 100%. Otherwise, the Simulink Verification and

Validation software reports coverage as the number of points and intervals satisfied during at least one time step, divided by the total number of points and intervals defined for the block.

16-22

Model Objects That Receive Coverage

Rate Limiter

The Rate Limiter block receives decision coverage. The Simulink Verification and

Validation software reports decision coverage for the Rising slew rate and Falling

slew rate parameters.

For the Rising slew rate, decision coverage measures:

• The number of time steps that the block input changes more than or equal to the rising rate, indicating a true decision.

• The number of time steps that the block input changes less than the rising rate, indicating a false decision.

For the Falling slew rate, decision coverage measures:

• The number of time steps that the block input changes less than or equal to the falling rate, indicating a true decision.

• The number of time steps that the block input changes more than the falling rate, indicating a false decision.

The software does not measure Falling slew rate coverage for a time step when the

Rising slew rate is true. Therefore, the total number of Falling slew rate decisions equals the number of time steps that the Rising slew rate is false.

If at least one time step is true and at least one time step is false, decision coverage for each of the two individual decisions for the block is 100%. If no time steps are true, or if no time steps are false, decision coverage is 50%. The software treats each element of a vector or matrix as a separate coverage measurement.

The Rate Limiter block implicitly compares the derivative of the input signal with an upper and lower limit value. Therefore, if you select the Relational Boundary coverage metric, the Rate Limiter block receives relational boundary coverage. For more information, see “Relational Boundary Coverage”.

Relational Operator

The Relational Operator block receives condition coverage.

Condition coverage measures:

• the number of times that the specified relational operation was true.

16-23

16

Model Objects That Receive Model Coverage

16-24

• the number of times that the specified relational operation was false.

The Relational Operator block contains a comparison between its inputs. Therefore, if you select the Relational Boundary coverage metric, the Relational Operator block receives relational boundary coverage. For more information, see “Relational Boundary

Coverage”.

Relay

The Relay block receives decision coverage. The Simulink Verification and Validation software reports decision coverage for the Switch on point and the Switch off point parameters.

For the Switch on point, decision coverage measures:

• The number of consecutive time steps that the block input is greater than or equal to the Switch on point, indicating a true decision.

• The number of consecutive time steps that the block input is less than the Switch on

point, indicating a false decision.

For the Switch off point, decision coverage measures:

• The number of consecutive time steps that the block input is less than or equal to the

Switch off point, indicating a true decision.

• The number of consecutive time steps that the block input is greater than the Switch

off point, indicating a false decision.

The software does not measure Switch off point coverage for a time step when the switch on threshold is true. Therefore, the total number of Switch off point decisions equals the number of time steps that the Switch on point is false.

If at least one time step is true and at least one time step is false, decision coverage for each of the two individual decisions for the block is 100%. If no time steps are true, or if no time steps are false, decision coverage is 50%. The software treats each element of a vector or matrix as a separate coverage measurement.

The Relay block contains an implicit comparison of its second input with a threshold value. Therefore, if you select the Relational Boundary coverage metric, the Relay block receives relational boundary coverage. For more information, see “Relational

Boundary Coverage”.

Model Objects That Receive Coverage

C/C++ S-Function

Model coverage is supported for C/C++ S-Functions. The coverage report for the model contains results for each instance of an S-Function block in the model. The results for an

S-Function block link to a separate coverage report for the C/C++ code in the block.

To generate coverage report for S-Functions:

1 When creating the S-Functions, enable support for coverage. For more information, see “Make S-Function Compatible with Model Coverage”.

2 When generating the coverage report, enable support for S-Functions. For more information, see “Generate Coverage Report for S-Function”.

The following coverage types are reported for S-Functions:

• “Cyclomatic Complexity”

• “Condition Coverage (CC)”

• “Decision Coverage (DC)”

• “MCDC Coverage”

• Percentage of statements covered

The coverage data for S-Function blocks is obtained in the following way:

• The coverage result for a block is a weighted average of the result over all files in the block.

For instance, an S-Function block has two files, file1.c and file2.c. The decision coverage for file1.c is 75% (3/4 outcomes covered) and that for file2.c is 50%

(10/20 outcomes covered). The decision coverage for the block is 13/24 ≈ 54 %.

• For each file, the coverage result is a weighted average of the result over all functions in the file.

• For each function, the coverage result is a weighted average of the result over all statements in the function that receive that coverage.

Note: Model coverage for S-Functions have the following restrictions:

• Only Level-2 C/C++ S-Functions are supported for coverage. For an example of a level-2 C S-Function, see “Basic C MEX S-Function”.

16-25

16

Model Objects That Receive Model Coverage

16-26

• C++ class templates are not instrumented for coverage.

Saturation

The Saturation block receives decision coverage. The Simulink Verification and

Validation software reports decision coverage for the Lower limit and Upper limit parameters.

For the Upper limit, decision coverage measures:

• The number of time steps that the block input is greater than or equal to the upper limit, indicating a true decision.

• The number of time steps that the block input is less than the upper limit, indicating a false decision.

For the Lower limit, decision coverage measures:

• The number of time steps that the block input is greater than the lower limit, indicating a true decision.

• The number of time steps that the block input is less than or equal to the lower limit, indicating a false decision.

The software does not measure Lower limit coverage for a time step when the upper limit is true. Therefore, the total number of Lower limit decisions equals the number of time steps that the Upper limit is false.

If at least one time step is true and at least one time step is false, decision coverage for each of the two individual decisions for the Saturation block is 100%. If no time steps are true, or if no time steps are false, decision coverage is 50%. The software treats each element of a vector or matrix as a separate coverage measurement.

The Saturation block contains an implicit comparison of the input with an upper and lower limit value. Therefore, if you select the Relational Boundary coverage metric, the Saturation block receives relational boundary coverage. For more information, see

“Relational Boundary Coverage”.

Saturation Dynamic

If you select the Saturate on integer overflow coverage metric, the Saturation

Dynamic block receives saturate on integer overflow coverage. For more information, see

Model Objects That Receive Coverage

“Saturate on Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

Simulink Design Verifier Functions in MATLAB Function Blocks

The following functions in MATLAB Function blocks receive Simulink Design Verifier coverage:

• sldv.condition

• sldv.test

• sldv.assume

• sldv.prove

Each of these functions evaluates an expression expr, for example, sldv.test(expr), where expr is any valid Boolean MATLAB expression. Simulink Design Verifier coverage measures the number of time steps that the expression expr evaluates to true.

If expr is true for at least one time step, Simulink Design Verifier coverage for that function is 100%. Otherwise, the Simulink Verification and Validation software reports coverage for that function as 0%.

Sqrt, Signed Sqrt, Reciprocal Sqrt

If you select the Saturate on integer overflow coverage metric, the Sqrt, Signed

Sqrt, and Reciprocal Sqrt blocks receive saturate on integer overflow coverage. For more information, see “Saturate on Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

Sum, Add, Subtract, Sum of Elements

If you select the Saturate on integer overflow coverage metric, the Sum, Add,

Subtract, and Sum of Elements blocks receive saturate on integer overflow coverage. For more information, see “Saturate on Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

Switch

The Switch block receives decision coverage based on the control input to the block.

Decision coverage measures:

16-27

16

Model Objects That Receive Model Coverage

16-28

• The number of time steps that the control input evaluates to true.

• The number of time steps the control input evaluates to false.

The number of decision points is based on whether the control input is scalar or vector.

If you select the Saturate on integer overflow coverage metric, the Switch block receives saturate on integer overflow coverage. For more information, see “Saturate on

Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

The Switch block contains an implicit comparison of its second input with a threshold value. Therefore, if you select the Relational Boundary coverage metric, the Switch block receives relational boundary coverage. For more information, see “Relational

Boundary Coverage”.

SwitchCase, SwitchCase Action Subsystem

The SwitchCase block and SwitchCase Action Subsystem receive decision coverage. The

Simulink Verification and Validation software measures decision coverage individually for each switch case defined in the block and also for the default case. The number of decision outcomes is equal to the number of case conditions plus one for the default case, if one is defined.

The software reports the total number of time steps that each case evaluates to true. If each case, including the default case, evaluates to true at least once, decision coverage is 100%. The software determines the decision coverage by the number of cases that evaluate true for at least one time step divided by the total number of cases.

If the SwitchCase block does not contain a default case, the software measures decision coverage for the number of time steps in which none of the cases evaluated to true. In the coverage report, this coverage is reported as implicit-default.

Test Condition

The Test Condition block receives Simulink Design Verifier coverage. Simulink Design

Verifier coverage is based on the points and intervals defined in the block dialog box.

Simulink Design Verifier coverage measures the number of time steps that each point or interval defined in the block is satisfied. The total number of objective outcomes is based on the number of points or intervals defined in the Test Condition block.

Model Objects That Receive Coverage

If all points and intervals defined in the block are satisfied for at least one time step,

Simulink Design Verifier coverage is 100%. Otherwise, the Simulink Verification and

Validation software reports coverage as the number of points and intervals satisfied during at least one time step, divided by the total number of points and intervals defined for the block.

Test Objective

The Test Objective block receives Simulink Design Verifier coverage. Simulink Design

Verifier coverage is based on the points and intervals defined in the block dialog box.

Simulink Design Verifier coverage measures the number of time steps that each point or interval defined in the block is satisfied. The total number of objective outcomes is based on the number of points or intervals defined in the Test Objective block.

If all points and intervals defined in the block are satisfied for at least one time step,

Simulink Design Verifier coverage is 100%. Otherwise, the Simulink Verification and

Validation software reports coverage as the number of points and intervals satisfied during at least one time step, divided by the total number of points and intervals defined for the block.

Triggered Models

A Model block can reference a model that contains edge-based trigger ports at the root level of the model. Triggered models receive decision, condition, and MCDC coverage.

Decision coverage measures:

• The number of time steps that the referenced model is triggered, indicating a true decision.

• The number of time steps that the referenced model is not triggered, indicating a false decision.

If at least one time step is true and at least one time step is false, decision coverage for the Model block that references the triggered model is 100%. If no time steps are true, or if no time steps are false, decision coverage is 50%.

Only if the trigger input is a vector, the Simulink Verification and Validation software measures condition coverage for the trigger port in the referenced model. For the trigger port, condition coverage measures:

• The number of time steps that each element of the trigger port is true.

16-29

16

Model Objects That Receive Model Coverage

16-30

• The number of time steps that each element of the trigger port is false.

The software reports condition coverage based on the total number of possible conditions and how many are true for at least one time step and how many are false for at least one time step.

If the trigger port is a vector, the software measures MCDC coverage for the trigger port only. Because the trigger port of the referenced model is an OR of the vector inputs, if, during at least one time step, each vector trigger port is exclusively true and if, during at least one time step, all vector trigger port inputs are false, MCDC coverage is 100%. The software treats each element of the vector as a separate condition for MCDC coverage measurement.

Triggered Subsystem

The Triggered Subsystem block receives decision, condition, and MCDC coverage.

Decision coverage measures:

• The number of time steps that the block is triggered, indicating a true decision.

• The number of time steps that the block is not triggered, indicating a false decision.

If at least one time step is true and at least one time step is false, decision coverage is

100%. If no time steps are true, or if no time steps are false, decision coverage is 50%.

The Simulink Verification and Validation software measures condition coverage for the trigger input only if the trigger input is a vector. For the trigger input, condition coverage measures:

• The number of time steps that each element of the trigger edge is true.

• The number of time steps that each element of the trigger edge is false.

The software reports condition coverage based on the total number of possible conditions and how many are true for at least one time step and how many are false for at least one time step.

If the trigger input is a vector, the software measures MCDC coverage for the trigger input only. Because the trigger edge of the subsystem is an OR of the vector inputs, if, during at least one time step, each vector trigger edge input is exclusively true and if, during at least one time step, all vector trigger edge inputs are false, MCDC coverage is

Model Objects That Receive Coverage

100%. The software treats each element of the vector as a separate condition for MCDC coverage measurement.

Truth Table

The Truth Table block is a Stateflow block that enables you to use truth table logic directly in a Simulink model. The Truth Table block receives condition, decision, and

MCDC coverage. For more information on model coverage with Stateflow truth tables, see “Model Coverage for Stateflow Truth Tables”.

Unary Minus

If you select the Saturate on integer overflow coverage metric, the Unary Minus block receives saturate on integer overflow coverage. For more information, see “Saturate on

Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

Weighted Sample Time Math

If you select the Saturate on integer overflow coverage metric, the Weighted Sample

Time Math block receives saturate on integer overflow coverage. For more information, see “Saturate on Integer Overflow Coverage”. The software treats each element of a vector or matrix as a separate coverage measurement.

While Iterator, While Iterator Subsystem

The While Iterator block and While Iterator Subsystem receive decision coverage.

Decision coverage is measured for the while condition value, which is determined by the while

condition being satisfied (true), or the while condition not being satisfied (false).

Simulink Verification and Validation software reports the total number of times that each while condition evaluates to true and to false. If the while condition evaluates to true at least once, and false at least once, decision coverage for the while condition is 100%. If no while conditions are true, or if no while conditions are false, decision coverage is 50%.

If the iteration limit is exceeded (true) or is not exceeded (false), the software measures decision coverage independently. If the iteration limit evaluates to true at least once, and false at least once, decision coverage for the iteration limit is 100%. If no iteration limits are true, or if no iteration limits are false, decision coverage is 50%. If you set Maximum

16-31

16

Model Objects That Receive Model Coverage

number of iterations to -1 (no limit), the decision coverage for the iteration limit is true for all iterations and false for zero iterations, and decision coverage is 50%.

16-32

Model Objects That Do Not Receive Coverage

Model Objects That Do Not Receive Coverage

The Simulink Verification and Validation software does not record coverage for blocks that are not listed in “Model Objects That Receive Coverage”.

Note: The software only records coverage when the Simulation mode parameter is set to Normal.

The following table identifies specific model objects that do not receive coverage in certain conditions.

Model object

Logical Operator block

Model blocks

Subsystem block

Stateflow chart

MATLAB Function block

Does not receive coverage...

When the Operator parameter specifies

XOR

or NXOR and there are two or more inputs.

When the Simulation mode parameter specifies Accelerator.

Coverage for Model blocks is the sum of the coverage data for the contents of the referenced model.

When the Read/Write Permissions parameter is set to NoReadOrWrite.

When debugging/animation is not enabled for the model or object.

16-33

Setting Model Coverage Options

17

• “Specify Model Coverage Options” on page 17-2

• “Cumulative Coverage Data” on page 17-17

17

Setting Model Coverage Options

Specify Model Coverage Options

Before starting a model coverage analysis, you must specify several model coverage recording and reporting options. In the Simulink Editor, select Analysis > Coverage >

Settings. The Coverage Settings dialog box opens, with the Coverage tab displayed.

The following sections describe the settings for each tab in the Coverage Settings dialog box.

In this section...

“Coverage Tab” on page 17-2

“Results Tab” on page 17-6

“Reporting Tab” on page 17-8

“Options Tab” on page 17-12

“Filter Tab” on page 17-14

Coverage Tab

On the Coverage tab, select the model coverages calculated during simulation.

17-2

Specify Model Coverage Options

Coverage for this model

Instructs the software to gather and report the model coverages that you specify during simulation. When you select the Coverage for this model option, the Select

17-3

17

Setting Model Coverage Options

Subsystem button and the Coverage metrics section of the Coverage pane become available.

Select Subsystem

Specifies the subsystem for which the software gathers and reports coverage data. When you select the Coverage for this model option, the software, by default, generates coverage data for the entire model.

To restrict coverage reporting to a particular subsystem:

1 On the Coverage tab, click Select Subsystem.

The Subsystem Selection dialog box opens.

17-4

2

In the Subsystem Selection dialog box, select the subsystem for which you want to enable coverage reporting and click OK.

Coverage for referenced models

Causes the software to record and report the model coverages that you specify for referenced models during simulation. When you select the Coverage for referenced

models option, the Select Models button and the Coverage metrics section of the

Coverage tab become available.

Specify Model Coverage Options

Select Models

Click to specify the referenced models for which the Simulink Verification and Validation software records and reports coverage data. When you select Coverage for referenced

models, the software, by default, generates coverage data for all referenced models where the simulation mode of the Model block is set to Normal.

To enable coverage reporting for particular referenced models:

1 On the Coverage pane, click Select Models.

2 In the Select Models for Coverage Analysis dialog box, select the referenced models for which you want to record coverage.

17-5

17

Setting Model Coverage Options

The icon next to the model name indicates the simulation mode for that referenced model. You can select only referenced models whose simulation mode is set to

Normal

.

If you have multiple Model blocks that reference the same model and whose simulation mode is set to Normal, selecting or clearing one check box for that model causes the check boxes for all Normal mode instances of that model to be selected or cleared.

3 Click OK to close the Select Models for Coverage Analysis dialog box and return to the Coverage Settings dialog box.

Coverage for MATLAB files

Enables coverage for any external functions called by MATLAB functions in your model.

The MATLAB functions may be defined in a MATLAB Function block or in a Stateflow chart.

You must select either Coverage for this model or Coverage for referenced models to select the Coverage for MATLAB files option.

Coverage for S-Functions

Enables coverage for C/C++ S-Function blocks in your model. If you select this option, coverage metrics are reported for the S-Function blocks and the C/C++ code in those blocks. For more information, see “Generate Coverage Report for S-Function”.

You must select either Coverage for this model or Coverage for referenced models to select the Coverage for S-Functions option.

Coverage metrics

Select the types of test case coverage analysis that you want the tool to perform (see

“Types of Model Coverage” on page 15-3). The Simulink Verification and Validation

software gathers and reports those types of coverage for the subsystems, models, and referenced models you specify.

Results Tab

On the Results tab, select the destination for model coverage results.

17-6

Specify Model Coverage Options

Enable cumulative data collection

Accumulates model coverage results from successive simulations. Select this and Save

cumulative results in workspace variable to collect model coverage results for

multiple simulations in one cvdata object. For more information, see “Cumulative

Coverage Data” on page 17-17.

17-7

17

Setting Model Coverage Options

Clear data

Removes existing internal cumulative coverage data. If cumulative coverage data is saved in a workspace variable, rename that workspace variable to avoid overwriting it in future simulations.

Save cumulative results in workspace variable

Accumulates and saves the results of successive simulations in a cvdata object in the workspace. Specify the workspace variable name in the cvdata object name field. For

more information, see “Cumulative Coverage Data” on page 17-17.

Save last run in workspace variable

Saves the results of the last simulation run in a cvdata object in the workspace. Specify the workspace variable name in the cvdata object name field.

Increment variable name with each simulation

Increments the name of the coverage data object variable that saves the coverage data from each last simulation run. Therefore the current simulation run does not overwrite the results of the previous run.

Update results on pause

Records results up to the point at which you pause the simulation for the first time.

When you resume simulation and later pause or stop, the model coverage report reappears, with coverage results up to the current pause or stop time.

Display coverage results using model coloring

Colors model objects according to their level of coverage, after simulation. Objects highlighted in light green received full coverage during testing. Objects highlighted in light red received incomplete coverage. See “View Coverage Results in a Model”.

Reporting Tab

On the Reporting tab, specify whether the model coverage tool generates an HTML report and what data the report includes.

17-8

Specify Model Coverage Options

Generate report

Creates an HTML report containing the coverage data collected from simulation. Click the Settings button to select various reporting options.

17-9

17

Setting Model Coverage Options

Show report

Specifies whether to open the generated HTML coverage report in a MATLAB browser window at the end of model simulation.

Settings

On the Reporting tab, for Detailed Report, click Settings to open the Settings dialog box. In the Settings dialog box, choose model coverage report options.

17-10

Option

Include each test in the model summary

Produce bar graphs in the model summary

Use two color bar graphs (red, blue)

Description

At the top of the HTML report, the model hierarchy table includes columns listing the coverage metrics for each test. If you do not select this option, the model summary reports only the total coverage.

Causes the model summary to include a bar graph for each coverage result for a visual representation of the coverage.

Red and blue bar graphs are displayed in the report instead of black and white bar graphs.

Specify Model Coverage Options

Option

Do not report fully covered model objects

Display hit/count ratio in the model summary

Include cyclomatic complexity numbers in summary

Include cyclomatic complexity numbers in block details

Filter Stateflow events from report

Description

The coverage report includes only model objects that the simulation does not cover fully, useful when developing tests, because it reduces the size of the generated reports.

Reports coverage numbers as both a percentage and a ratio, for example, 67%

(8/12).

Includes the cyclomatic complexity (see

“Types of Model Coverage” on page 15-3) of

the model and its top-level subsystems and charts in the report summary. A cyclomatic complexity number shown in boldface indicates that the analysis considered the subsystem itself to be an object when computing its complexity. This occurs for atomic and conditionally executed subsystems, as well as for Stateflow Chart blocks.

Includes the cyclomatic complexity metric in the block details section of the report.

Excludes coverage data on Stateflow events.

Cumulative data

Include model coverage results from successive simulations in the report. For more

information, see “Cumulative Coverage Data” on page 17-17.

Last run

Include in the report only the results of the most recent simulation run.

Additional data to include in report

Specify names of coverage data objects from previous runs to include in the current report along with the current coverage data. Each entry creates a new set of columns in the report.

17-11

17

Setting Model Coverage Options

Options Tab

On the Options tab, select options for model coverage reports.

17-12

Treat Simulink logic blocks as short-circuited

The Treat Simulink logic blocks as short-circuited option applies only to condition and MCDC coverage. If you select this option, coverage analysis treats Simulink logic

Specify Model Coverage Options blocks as if the block ignores remaining inputs when the previous inputs alone determine the block's output. For example, if the first input to a Logical Operator block whose

Operator parameter specifies AND is false, MCDC coverage analysis ignores the values of the other inputs when determining MCDC coverage for a test case.

If you enable this feature and logic blocks are short-circuited while collecting model coverage, you may not be able to achieve 100% coverage for that block.

To generate code from a model, select this option. Also select this option for where you want the MCDC coverage analysis to approximate the degree of coverage that your test cases achieve for the generated code (most high-level languages short-circuit logic expressions).

Note: A test case that does not achieve full MCDC coverage for non-short-circuited logic expressions might achieve full coverage for short-circuited expressions.

Warn when unsupported blocks exist in model

Select this option to warn you at the end of the simulation that the model contains blocks that require coverage analysis but are not currently covered by the tool.

Force block reduction off

To achieve faster execution during model simulation and in generated code, in the

Configuration Parameters dialog box, on the Optimization pane, enable the Block

reduction parameter. The Simulink software collapses certain groups of blocks into a single, more efficient block, or removes them entirely.

One of the model coverage options, Force block reduction off, allows you to ignore the

Block reduction parameter when collecting model coverage.

If you do not enable the Block reduction parameter, or if you select Force block

reduction off, the Simulink Verification and Validation software provides coverage data for every block in the model that collects coverage.

If you enable the Block reduction parameter and do not set Force block reduction

off, the coverage report lists the reduced blocks that would have collected coverage.

The model coverage report identifies any reduced blocks. For an example of a reduced

blocks report, see “Block Reduction” on page 19-36.

17-13

17

Setting Model Coverage Options

Restrict recording to interval

To record model coverage only inside a specified simulation time interval, check Restrict

recording to interval and define a Start time and Stop time. Model coverage is not recorded for simulation times outside Start time and Stop time. If your simulation starts at a time greater than or equal to Stop time, model coverage is not recorded.

For example, you might want to restrict model coverage recording if your model has transient effects early in simulation, or if you need model coverage reported only for a particular model operation.

Boundary Tolerance — Absolute

Specify the value of absolute tolerance for relational boundary coverage of floating point inputs. For more information, see “Relational Boundary Coverage”.

Boundary Tolerance — Relative

Specify the value of relative tolerance for relational boundary coverage of floating point inputs. For more information, see “Relational Boundary Coverage”.

Filter Tab

On the Filter tab, enter the file name that specifies the model objects to be excluded from model coverage collection. You can use the same filter file for multiple models.

17-14

Specify Model Coverage Options

Filename

If you enable coverage for this model, you can create a filter file or open an existing filter file. In this filter file, you can then specify objects that you want to exclude from model coverage collection during simulation.

In the Filename field, enter the full path to the file that specifies the model objects to be excluded from model coverage collection. You can also click Browse to navigate to the file. You can only open files that have the valid .cvf filter file format.

17-15

17

Setting Model Coverage Options

If the current model has a filter file already associated with it, the file name appears in the Filename field, and the Open in Filter Viewer link is displayed. To edit the coverage filter settings, click this link.

If the Open in Filter Viewer link is unavailable, go to the Coverage tab. Select

Coverage for this model to enable coverage for the current model. You can then enter the filter file name and edit the file.

For more information on coverage filtering, see “Coverage Filter Rules and Files” and the example “Filter Model Objects to Refine Coverage Results”.

17-16

Cumulative Coverage Data

Cumulative Coverage Data

On the Results tab, if you select Enable cumulative data collection and Save

cumulative results in workspace variable, a coverage running total is updated with new results at the end of each simulation. However, if you change model or block settings between simulations that are incompatible with settings from previous simulations and affect the type or number of coverage points, the cumulative coverage data resets.

You can make cumulative coverage results persist between MATLAB sessions. The cvload

parameter RESTORETOTAL must be 1 in order to restore cumulative results.

At the end of the sessions, use cvsave to save results to a file. At the beginning of the session, cvload to load the results.

When you save the coverage results to a file using cvsave and a model name argument, the file also contains the cumulative running total. When you load that file into the coverage tool using cvload, you can select whether you want to restore the running total from the file.

When you restore a running total from saved data, the saved results are reflected in the next cumulative report. If a running total already exists when you restore a saved value, the existing value is overwritten.

Whenever you report on more than one single simulation, the coverage displayed for truth tables and lookup-table maps is based on the total coverage of all the reported runs.

For cumulative reports, this information includes all the simulations where cumulative results are stored.

You can also calculate cumulative coverage results at the command line, through the + operator: covdata1 = cvsim(test1); covdata2 = cvsim(test2); cvhtml('cumulative_report', covdata1 + covdata2);

17-17

18

Coverage Collection During

Simulation

• “Model Coverage Collection Workflow” on page 18-2

• “Create and Run Test Cases” on page 18-3

• “View Coverage Results in a Model” on page 18-4

• “Model Coverage for Multiple Instances of a Referenced Model” on page 18-10

• “Model Coverage for MATLAB Functions” on page 18-20

• “Model Coverage for C and C++ S-Functions” on page 18-37

• “View Coverage Results for C/C++ Code in S-Function Blocks” on page 18-41

• “Model Coverage for Stateflow Charts” on page 18-45

18

Coverage Collection During Simulation

Model Coverage Collection Workflow

To develop effective tests with model coverage:

1

Develop one or more test cases for your model. (See “Create and Run Test Cases” on page 18-3.)

2 Run the test cases to verify model behavior.

3 Analyze the coverage reports produced by the Simulink Verification and Validation software.

4 Using the information in the coverage reports, modify the test cases to increase their coverage or add new test cases to cover areas not currently covered.

5 Repeat the preceding steps until you are satisfied with the coverage of your test suite.

Note: The Simulink Verification and Validation software comes with an example of model coverage to validate model tests. To step through the example, at the

MATLAB command prompt, enter simcovdemo.

18-2

Create and Run Test Cases

Create and Run Test Cases

To create and run test cases, model coverage provides two MATLAB commands, cvtest and cvsim. The cvtest command creates test cases that the cvsim command runs. (See

“Run Tests with cvsim” on page 21-5.)

You can also run the coverage tool interactively:

1

Open the sldemo_fuelsys model.

2 In the Simulink model window, select Analysis > Coverage > Settings.

The Coverage Settings dialog box appears, with the Coverage tab open.

3 Select Coverage for this model: sldemo_fuelsys, which enables:

• The Select Subsystem button

• The metrics options in the Coverage metrics section

• Fields on the Results, Reporting, and Options tabs of the Coverage Settings dialog box

4

Under Coverage metrics, select the types of coverage that you want to record in the coverage report.

5

Click OK.

6

In the Simulink Editor, select Simulation > Run to start simulating the model.

If you specify to report model coverage, the Simulink Verification and Validation software saves coverage data for the current run in the workspace object covdata and cumulative coverage data in covCumulativeData, by default. At the end of the simulation, this data appears in an HTML report that opens in a browser window.

Note: You cannot run simulations if you select both model coverage reporting and acceleration options. If you select Simulation > Mode > Accelerator in the

Simulink Editor, Simulink does not record coverage.

You cannot select both block reduction and conditional branch input optimization when you perform coverage analysis because they interfere with coverage recording.

18-3

18

Coverage Collection During Simulation

View Coverage Results in a Model

In this section...

“Overview of Model Coverage Highlighting” on page 18-4

“Enable Coverage Highlighting” on page 18-5

“View Results in Coverage Display Window” on page 18-8

Overview of Model Coverage Highlighting

When you simulate a Simulink model, you can configure your model to provide visual results that allow you to see at a glance which objects recorded 100% coverage. After the simulation:

• In the model window, model objects are highlighted in certain colors according to what coverage was recorded:

• Light green indicates that an object received full coverage during testing.

• Light red indicates that an object received incomplete coverage.

• Gray indicates that an object was filtered from coverage.

• Objects with no color highlighting received no coverage.

• When you click a colored object, the Coverage Display Window provides details about the coverage recorded for that block. For subsystems and Stateflow charts, the Coverage Display Window lists the summary coverage for all objects in that subsystem or chart. For other blocks, the Coverage Display Window lists specific details about the objects that did not receive 100% coverage.

The simulation highlights blocks that received the following types of model coverage:

• “Decision Coverage (DC)” on page 15-4

• “Condition Coverage (CC)” on page 15-4

• “Modified Condition/Decision Coverage (MCDC)” on page 15-5

• “Saturate on Integer Overflow Coverage”

• “Simulink Design Verifier Coverage” on page 15-9

18-4

View Coverage Results in a Model

Enable Coverage Highlighting

To enable the model coverage colored diagram display:

1

In the Simulink Editor, select Analysis > Coverage > Settings to open the

Coverage Settings dialog box.

2

In the Coverage tab, select Coverage for this model. Click Select Subsystem to open the Subsystem Selection dialog box. Select the top-level model sldemo_fuelsys

so that all subsystems are included in coverage analysis. Close the

Subsystem Selection dialog box.

3

In the Coverage Settings dialog box, under the Coverage metrics pane, select

Decision, Condition, MCDC, and Simulink Design Verifier.

4

Select the Results tab.

5

Select Display coverage results using model coloring. This is the default setting.

After you have enabled the coverage coloring, simulate your model. In the model, you can see at a glance which objects received full, partial, or no coverage.

Highlighted Coverage Results

The following sections show examples of highlighted model objects in colors that correspond to the recorded coverage.

• “Green: Full Coverage” on page 18-5

• “Red: Partial Coverage” on page 18-6

• “Gray: Filtered Coverage” on page 18-8

Green: Full Coverage

In this example, the Switch block received 100% coverage, as indicated by the green highlighting and the information in the Coverage Display Window.

18-5

18

Coverage Collection During Simulation

Red: Partial Coverage

In this example, the control_logic Stateflow chart received the following coverage:

• Decision: 25%

• Condition: 21%

• MCDC: 0%

18-6

Inside the control_logic subsystem, the Pressure substate was never fail.

View Coverage Results in a Model

In the next example, in the Multiport Switch block, two of the data ports were never executed.

18-7

18

Coverage Collection During Simulation

Gray: Filtered Coverage

In this example, the fuel_rate_control subsystem is highlighted in gray because it was filtered out of coverage recording.

18-8

View Results in Coverage Display Window

After simulating the model and recording coverage, by default, the Coverage Display

Window is the top-most visible window. When you click an object that recorded coverage, the Coverage Display Window displays details of the coverage recorded during simulation.

In the Coverage Display Window, you can:

• Configure the window so it is not always the top-most visible window. Next to Always

on top, click and removing the check.

• Configure the window to display coverage information when you click an object that recorded coverage. Click and select Click.

• Configure the window to display coverage information when you hover your cursor on an object that recorded coverage. Click and select Focus.

View Coverage Results in a Model

• Close the window. Press Alt+F4.

• Close the window and remove highlighting on the model. Select Display > Remove

Highlighting.

Abbreviations in Coverage Results

The Coverage Display Window shows results with abbreviations. You can view expanded results in the “Top-Level Model Coverage Report”.

Abbreviation

CND

ENBL

FCALL

IN

LGC

LL

MX ITER

NA

OffThresh

OnThresh

OUT

SO

TBL

THRESH

TI

TO

TP

TRIG

U

UL

X

Meaning condition enable function call input logic lower limit maximum iterations exceeded not applicable

[switch] off threshold switch on threshold output saturate on integer overflow lookup table threshold test interval test objective test point trigger input upper limit

• integration result (Discrete-Time

Integrator block)

• slew rate (Rate Limiter block)

18-9

18

Coverage Collection During Simulation

Model Coverage for Multiple Instances of a Referenced Model

In this section...

“About Coverage for Model Blocks” on page 18-10

“Record Coverage for Multiple Instances of a Referenced Model” on page 18-10

About Coverage for Model Blocks

Model blocks do not receive coverage directly; if you set the simulation mode of the Model block to Normal, the Simulink Verification and Validation software records coverage for the model referenced from the Model block. If the simulation mode for the Model block is anything other than Normal, the software does not record coverage for the referenced model.

Your Simulink model can contain multiple Model blocks with Normal simulation mode that reference the same model. When the software records coverage, each instance of the referenced model can be exercised with different inputs or parameters, possibly resulting in additional coverage for the referenced model.

The Simulink Verification and Validation software records coverage for all instances of the referenced model with Normal simulation mode and combines the coverage data for that referenced model in the final results.

Record Coverage for Multiple Instances of a Referenced Model

To see how this works, simulate a model twice. The first time, you record coverage for one

Model block in Normal simulation mode. The second time, you record coverage for two

Model blocks in Normal simulation mode. Both Model blocks reference the same model.

• “Record Coverage for the First Instance of the Referenced Model” on page 18-10

• “Record Coverage for the Second Instance of the Referenced Model” on page 18-16

Record Coverage for the First Instance of the Referenced Model

Record coverage for one Model block.

1

Open your top-level model. This example uses the following model:

18-10

Model Coverage for Multiple Instances of a Referenced Model

This model contains three Model blocks that reference the sldemo_mdlref_counter_datamngt

example model. The corners of each Model block indicate the value of their Simulation mode parameter:

• Counter1 — Simulation mode: Normal

• Counter2 — Simulation mode: Accelerator

• Counter3 — Simulation mode: Accelerator

2 Configure your model to record coverage during simulation: a In the model window, select Analysis > Coverage > Settings.

b On the Coverage tab, select:

Coverage for this model

Coverage for referenced models c

Under Coverage for referenced models, click Select Models. In the Select

Models for Coverage Analysis dialog box, you can select only those referenced

18-11

18

Coverage Collection During Simulation models whose simulation mode is Normal. In this example, only the first Model block that references sldemo_mdlref_counter_datamngt is available for recording coverage.

d

Click OK to exit the Select Models for Coverage Analysis dialog box.

e In the Coverage Settings dialog box, on the Reporting tab, select Last Run so that you can compare coverage data from individual simulations, not accumulated coverage for successive simulations.

3

Click OK to save your coverage settings and exit the Coverage Settings dialog box.

4 Simulate your model.

When the simulation is complete, the HTML coverage report opens. In this example, the coverage data for the referenced model, sldemo_mdlref_counter_datamngt, shows that the model achieved 69% coverage.

5 Click the hyperlink in the report for the referenced model.

The detailed coverage report for the referenced model opens, and the referenced model appears with highlighting to show coverage results.

18-12

Model Coverage for Multiple Instances of a Referenced Model

Note the following about the coverage for the Range Check subsystem in this example:

• The Saturate Count block executed 100 times. This block has four Boolean decisions. Decision coverage was 50%, because two of the four decisions were never recorded:

• The decision input > lower limit was never false.

• The decision input >= upper limit was never true.

18-13

18

Coverage Collection During Simulation

18-14

• The DetectOverflow function executed 50 times. This script has five decisions.

The DetectOverflow script achieved 60% coverage because two of the five decisions were never recorded:

• The expression count >= CounterParams.UpperLimit was never true.

• The expression count > CounterParams.LowerLimit was never false.

Model Coverage for Multiple Instances of a Referenced Model

18-15

18

Coverage Collection During Simulation

Record Coverage for the Second Instance of the Referenced Model

Record coverage for two Model blocks. Set the simulation mode of a second Model block to Normal and simulate the model. In this example, the Counter2 block adds to the coverage for the model referenced from both Model blocks.

1 In the Simulink Editor for your top-level model, right-click a second Model block and select Block Parameters (ModelReference).

The Function Block Parameters dialog box opens.

2

Set the Simulation mode parameter to Normal.

3

Click OK to save your change and exit the Function Block Parameters dialog box.

The corners of the Model block change to indicate that the simulation mode for this block is Normal, as in the example below.

18-16

Model Coverage for Multiple Instances of a Referenced Model

4 To make sure that the software records coverage for both instances of this model: a Select Analysis > Coverage > Settings.

b

On the Coverage pane, under Coverage for referenced models, click Select

Models.

In the Select Models for Coverage Analysis dialog box, verify that both instances of the referenced model are selected. In this example, the list now looks like the following.

If you have multiple instances of a referenced model in Normal mode, you can choose to record coverage for all of them or none of them.

c Click OK to close the Select Models for Coverage Analysis dialog box.

5 Simulate your model again.

6 When the simulation is complete, open the HTML coverage report.

In this example, the referenced model achieved 85% coverage. Note the following about the coverage data for the Range Check subsystem:

• The Saturate Count block executed 179 times. The simulation of the Counter2 block executed the Saturate Count block an additional 79 times, for a total of 179 executions.

The decision input >= upper limit was true 21 times during this simulation, compared to 0 during the first simulation. The fourth decision input

> lower limit

was still never false. Three out of four decisions were recorded during simulation, so this block achieved 75% coverage.

18-17

18

Coverage Collection During Simulation

18-18

• The DetectOverflow function executed 100 times. The simulation of the

Counter2 block executed the DetectOverflow function an additional 50 times.

The DetectOverflow function has five decisions. The expression count >=

CounterParams.UpperLimit

was true 21 times during this simulation, compared to 0 during the first simulation. The expression count >

CounterParams.LowerLimit

was never false. Four out of five decisions were recorded during simulation, so the DetectOverflow function achieved 80% coverage.

Model Coverage for Multiple Instances of a Referenced Model

18-19

18

Coverage Collection During Simulation

Model Coverage for MATLAB Functions

In this section...

“About Model Coverage for MATLAB Functions” on page 18-20

“Types of Model Coverage for MATLAB Functions” on page 18-20

“How to Collect Coverage for MATLAB Functions” on page 18-22

“Examples: Model Coverage for MATLAB Functions” on page 18-23

About Model Coverage for MATLAB Functions

The Simulink Verification and Validation software simulates a Simulink model and reports model coverage data for the decisions and conditions of code in MATLAB

Function blocks. Model coverage only supports coverage for MATLAB functions configured for code generation.

For example, consider the following if statement: if (x > 0 || y > 0)

reset = 1;

The if statement contains a decision with two conditions (x > 0 and y > 0). The

Simulink Verification and Validation software verifies that all decisions and conditions are taken during the simulation of the model.

Types of Model Coverage for MATLAB Functions

The types of model coverage that the Simulink Verification and Validation software records for MATLAB functions configured for code generation are:

• “Decision Coverage” on page 18-20

• “Condition and MCDC Coverage” on page 18-21

• “Simulink Design Verifier Coverage” on page 18-21

• “Relational Boundary Coverage” on page 18-22

Decision Coverage

During simulation, the following MATLAB Function block statements are tested for decision coverage:

18-20

Model Coverage for MATLAB Functions

• Function header — Decision coverage is 100% if the function or local function is executed.

• if — Decision coverage is 100% if the if expression evaluates to true at least once, and false at least once.

• switch — Decision coverage is 100% if every switch case is taken, including the fallthrough case.

• for — Decision coverage is 100% if the equivalent loop condition evaluates to true at least once, and false at least once.

• while — Decision coverage is 100% if the equivalent loop condition evaluates to true at least once, and evaluates to false at least once.

Condition and MCDC Coverage

During simulation, in the MATLAB Function block function, the following logical conditions are tested for condition and MCDC coverage:

• if statement conditions

• while statement conditions

Simulink Design Verifier Coverage

The following MATLAB functions are active in code generation and in Simulink Design

Verifier:

• sldv.condition

• sldv.test

• sldv.assume

• sldv.prove

When you specify the Simulink Design Verifier coverage metric in the Coverage

Settings dialog box, the Simulink Verification and Validation software records coverage for these functions.

Each of these functions evaluates an expression expr, for example, sldv.test(expr), where expr is a valid Boolean MATLAB expression. Simulink Design Verifier coverage measures the number of time steps that the expression expr evaluates to true.

If expr is true for at least one time step, Simulink Design Verifier coverage for that function is 100%. Otherwise, the Simulink Verification and Validation software reports coverage for that function as 0%.

18-21

18

Coverage Collection During Simulation

18-22

For an example of coverage data for Simulink Design Verifier functions in a coverage

report, see “Simulink Design Verifier Coverage” on page 19-45.

Relational Boundary Coverage

If the MATLAB function block contains a relational operation, the relational boundary coverage metric applies to this block.

If the MATLAB function block calls functions containing relational operations multiple times, the relational boundary coverage reports a cumulative result over all instances where the function is called. If a relational operation in the function uses operands of different types in the different calls, relational boundary coverage uses tolerance rules for the stricter operand type. For instance, if a relational operation uses int32 operands in one call, and double operands in another call, relational boundary coverage uses tolerance rules for double operands.

For information on the tolerance rules and the order of strictness of types, see “Relational

Boundary Coverage”.

How to Collect Coverage for MATLAB Functions

When you simulate your model, the Simulink Verification and Validation software can collect coverage data for MATLAB functions configured for code generation. To enable model coverage, select Analysis > Coverage > Settings and select Coverage for this

model.

You collect model coverage for MATLAB functions as follows:

• Functions in a MATLAB Function block

• Functions in an external MATLAB file

To collect coverage for an external MATLAB file, on the Coverage tab of the

Coverage Settings dialog box, select Coverage for MATLAB files.

• Simulink Design Verifier functions:

• sldv.condition

• sldv.test

• sldv.assume

• sldv.prove

Model Coverage for MATLAB Functions

To collect coverage for these functions, on the Coverage tab of the Coverage Settings dialog box, select the Simulink Design Verifier coverage metric.

The following section provides model coverage examples for each of these situations.

Examples: Model Coverage for MATLAB Functions

• “Model Coverage for MATLAB Function Blocks” on page 18-23

• “Model Coverage for MATLAB Functions in an External File” on page 18-33

• “Model Coverage for Simulink Design Verifier MATLAB Functions” on page 18-33

Model Coverage for MATLAB Function Blocks

Simulink Verification and Validation software measures model coverage for functions in a MATLAB Function block.

The following model contains two MATLAB functions in its MATLAB Function block:

In the Configuration Parameters dialog box, on the Solver pane, under Solver options, the simulation parameters are set as follows:

Type — Fixed-step

Solver — discrete (no continuous states)

Fixed-step size (fundamental sample time) — 1

The MATLAB Function block contains two functions:

• The top-level function, run_intersect_test, sends the coordinates for two rectangles, one fixed and the other moving, as arguments to rect_intersect.

• The local function, rect_intersect, tests for intersection between the two rectangles. The origin of the moving rectangle increases by 1 in the x and y directions with each time step.

18-23

18

Coverage Collection During Simulation

The coordinates for the origin of the moving test rectangle are represented by persistent data x1 and y1, which are both initialized to -1. For the first sample, x1 and y1 both increase to 0. From then on, the progression of rectangle arguments during simulation is as shown in the following graphic.

Stationary rectangle

Test rectangles

18-24

The fixed rectangle is shown in bold with a lower-left origin of (2,4) and a width and height of 2. At time t = 0, the first test rectangle has an origin of (0,0) and a width and height of 2. For each succeeding sample, the origin of the test rectangle increments by (1,1). The rectangles at sample times t = 2, 3, and 4 intersect with the test rectangle.

Model Coverage for MATLAB Functions

The local function rect_intersect checks to see if its two rectangle arguments intersect. Each argument consists of coordinates for the lower-left corner of the rectangle

(origin), and its width and height. x values for the left and right sides and y values for the top and bottom are calculated for each rectangle and compared in nested if-else decisions. The function returns a logical value of 1 if the rectangles intersect and 0 if they do not.

Scope output during simulation, which plots the return value against the sample time, confirms the intersecting rectangles for sample times 2, 3, and 4 .

After the simulation, the model coverage report appears in a browser window. After the summary in the report, the Details section of the model coverage report reports on each parts of the model.

The model coverage report for the MATLAB Function block shows that the block itself has no decisions of its own apart from its function.

The following sections examine the model coverage report for the example model in reverse function-block-model order. Reversing the order helps you make sense of the summary information at the top of each section.

18-25

18

Coverage Collection During Simulation

Coverage for the MATLAB Function run_intersect_test

Model coverage for the MATLAB Function block function run_intersect_test appears under the linked name of the function. Clicking this link opens the function in the editor.

Below the linked function name is a link to the model coverage report for the parent

MATLAB Function block that contains the code for run_intersect_test.

The top half of the report for the function summarizes its model coverage results.

The coverage metrics for run_intersect_test include decision, condition, and

MCDC coverage. You can best understand these metrics by examining the code for run_intersect_test

.

18-26

Model Coverage for MATLAB Functions

Lines with coverage elements are marked by a highlighted line number in the listing:

• Line 1 receives decision coverage on whether the top-level function run_intersect_test

is executed.

• Line 6 receives decision coverage for its if statement.

• Line 14 receives decision coverage on whether the local function rect_intersect is executed.

18-27

18

Coverage Collection During Simulation

• Lines 27 and 30 receive decision, condition, and MCDC coverage for their if statements and conditions.

Each of these lines is the subject of a report that follows the listing.

The condition right1 < left2 in line 30 is highlighted in red. This means that this condition was not tested for all of its possible outcomes during simulation. Exactly which of the outcomes was not tested is in the report for the decision in line 30.

The following sections display the coverage for each run_intersect_test decision line.

The coverage for each line is titled with the line itself, which if clicked, opens the editor to the designated line.

Coverage for Line 1

The coverage metrics for line 1 are part of the coverage data for the function run_intersect_test

.

The first line of every MATLAB function configured for code generation receives coverage analysis indicative of the decision to run the function in response to a call. Coverage for run_intersect_test

indicates that it executed at least once during simulation.

18-28

Coverage for Line 6

The Decisions analyzed table indicates that the decision in line 6, if isempty(x1), executed a total of eight times. The first time it executed, the decision evaluated to true

, enabling run_intersect_test to initialize the values of its persistent data.

The remaining seven times the decision executed, it evaluated to false. Because both possible outcomes occurred, decision coverage is 100%.

Model Coverage for MATLAB Functions

Coverage for Line 14

The Decisions Analyzed table indicates that the local function rect_intersect executed during testing, thus receiving 100% coverage.

Coverage for Line 27

The Decisions analyzed table indicates that there are two possible outcomes for the decision in line 27: true and false. Five of the eight times it was executed, the decision evaluated to false. The remaining three times, it evaluated to true. Because both possible outcomes occurred, decision coverage is 100%.

The Conditions analyzed table sheds some additional light on the decision in line 27.

Because this decision consists of two conditions linked by a logical OR (||) operation, only one condition must evaluate true for the decision to be true. If the first condition evaluates to true, there is no need to evaluate the second condition. The first condition, top1 < bottom2

, was evaluated eight times, and was true twice. This means that the second condition was evaluated only six times. In only one case was it true, which

18-29

18

Coverage Collection During Simulation brings the total true occurrences for the decision to three, as reported in the Decisions

analyzed table.

MCDC coverage looks for decision reversals that occur because one condition outcome changes from T to F or from F to T. The MC/DC analysis table identifies all possible combinations of outcomes for the conditions that lead to a reversal in the decision. The character x is used to indicate a condition outcome that is irrelevant to the decision reversal. Decision-reversing condition outcomes that are not achieved during simulation are marked with a set of parentheses. There are no parentheses, therefore all decisionreversing outcomes occurred and MCDC coverage is complete for the decision in line 27.

18-30

Coverage for Line 30

The line 30 decision, if (right1 < left2 || right2 < left1), is nested in the if statement of the line 27 decision and is evaluated only if the line 27 decision is false.

Model Coverage for MATLAB Functions

Because the line 27 decision evaluated false five times, line 30 is evaluated five times, three of which are false. Because both the true and false outcomes are achieved, decision coverage for line 30 is 100%.

Because line 30, like line 27, has two conditions related by a logical OR operator (||), condition 2 is tested only if condition 1 is false. Because condition 1 tests false five times, condition 2 is tested five times. Of these, condition 2 tests true two times and false

three times, which accounts for the two occurrences of the true outcome for this decision.

Because the first condition of the line 30 decision does not test true, both outcomes do not occur for that condition and the condition coverage for the first condition is highlighted with a rose color. MCDC coverage is also highlighted in the same way for a decision reversal based on the true outcome for that condition.

18-31

18

Coverage Collection During Simulation

Coverage for run_intersect_test

On the Details tab, the metrics that summarize coverage for the entire run_intersect_test

function are reported and repeated as shown.

18-32

The results summarized in the coverage metrics summary can be expressed in the following conclusions:

• There are eight decision outcomes reported for run_intersect_test in the line reports:

• One for line 1 (executed)

• Two for line 6 (true and false)

• One for line 14 (executed)

• Two for line 27 (true and false)

• Two for line 30 (true and false).

The decision coverage for each line shows 100% decision coverage. This means that decision coverage for run_intersect_test is eight of eight possible outcomes, or

100%.

• There are four conditions reported for run_intersect_test in the line reports. Lines 27 and 30 each have two conditions, and each condition has two condition outcomes (true and false), for a total of eight condition outcomes in run_intersect_test

. All conditions tested positive for both the true and false outcomes except the first condition of line 30 (right1 < left2). This means that condition coverage for run_intersect_test is seven of eight, or 88%.

Model Coverage for MATLAB Functions

• The MCDC coverage tables for decision lines 27 and 30 each list two cases of decision reversal for each condition, for a total of four possible reversals. Only the decision reversal for a change in the evaluation of the condition right1 < left2 of line 30 from true to false did not occur during simulation. This means that three of four, or

75% of the possible reversal cases were tested for during simulation, for a coverage of

75%.

Model Coverage for MATLAB Functions in an External File

Using the same model in “Model Coverage for MATLAB Function Blocks” on page

18-23, suppose the MATLAB functions run_intersect_test and rect_intersect

are stored in an external MATLAB file named run_intersect_test.m.

To collect coverage for MATLAB functions in an external file, on the Coverage Settings dialog box, on the Coverage tab, select Coverage for MATLAB files.

After simulation, the model coverage report summary contains sections for the top-level model and for the external function.

The model coverage report for run_intersect_test.m reports the same coverage data as if the functions were stored in the MATLAB Function block.

For a detailed example of a model coverage report for a MATLAB function in an external

file, see “External MATLAB File Coverage Report” on page 19-5.

Model Coverage for Simulink Design Verifier MATLAB Functions

If the MATLAB code includes any of the following Simulink Design Verifier functions configured for code generation, you can measure coverage:

18-33

18

Coverage Collection During Simulation

• sldv.condition

• sldv.test

• sldv.assume

• sldv.prove

For this example, consider the following model that contains a MATLAB Function block.

The MATLAB Function block contains the following code: function y = fcn(u)

% This block supports MATLAB for code generation.

sldv.condition(u > -30) sldv.test(u == 30) y = 1;

To collect coverage for Simulink Design Verifier MATLAB functions, on the Coverage

Settings dialog box, on the Coverage tab, select Simulink Design Verifier.

After simulation, the model coverage report listed coverage for the sldv.condition and sldv.test

functions. For sldv.condition, the expression u > -30 evaluated to true

51 times. For sldv.test, the expression u == 30 evaluated to true 51 times.

18-34

Model Coverage for MATLAB Functions

18-35

18

Coverage Collection During Simulation

For an example of model coverage data for Simulink Design Verifier blocks, see

“Simulink Design Verifier Coverage” on page 15-9.

18-36

Model Coverage for C and C++ S-Functions

Model Coverage for C and C++ S-Functions

Model coverage is supported for C/C++ S-Functions. The coverage results for S-Function blocks can be viewed in the same report as the rest of the model. For each S-Function block, the report links to a detailed coverage report for the C/C++ code in the block.

To generate coverage report for S-Functions:

1 When creating S-Functions, enable support for coverage.

2 When generating coverage report, enable support for S-Functions.

In this section...

“Make S-Function Compatible with Model Coverage” on page 18-37

“Generate Coverage Report for S-Function” on page 18-38

Make S-Function Compatible with Model Coverage

If you use the legacy_code function, S-Function Builder block or mex function to create your S-Functions, adapt your method appropriately to make the S-Function compatible with model coverage.

For more information on the three approaches, see “Creating C MEX S-Functions”.

• “S-Function Using legacy_code Function” on page 18-37

• “S-Function Using S-Function Builder” on page 18-38

• “S-Function Using mex Function” on page 18-38

S-Function Using legacy_code Function

1 Initialize a MATLAB structure with fields that represent Legacy Code Tool properties.

def = legacy_code( 'initialize' )

2

To enable model coverage, turn on the option def.Options.supportCoverage.

def.Options.supportCoverage = true;

3

Use the structure def in the usual way to generate an S-function. For an example, see “Coverage for S-Functions”.

18-37

18

Coverage Collection During Simulation

S-Function Using S-Function Builder

1 Copy an instance of the S-Function Builder block from the User-Defined

Functions library in the Library Browser into the your model.

2

Double-click the block to open the S-Function Builder dialog box.

3 On the Build Info tab, select Enable support for coverage.

S-Function Using mex Function

If you use the mex function to compile and link your source files, use the slcovmex function instead. The slcovmex function compiles your source code and also makes it compatible with coverage.

This function has the same syntax and takes the same options as the mex function.

In addition, you can provide some options relevant for model coverage. For more information, see slcovmex.

Generate Coverage Report for S-Function

1

Select Analysis > Coverage > Settings.

2 On the Coverage tab, select Coverage for S-Functions.

18-38

Model Coverage for C and C++ S-Functions

18-39

18

Coverage Collection During Simulation

When you run a simulation, the coverage report contains coverage metrics for C/C++ S-

Function blocks in your model. For each S-Function block, the report links to a detailed coverage report for the C/C++ code in the block.

Related Examples

• “View Coverage Results for C/C++ Code in S-Function Blocks”

More About

• “C/C++ S-Function”

18-40

View Coverage Results for C/C++ Code in S-Function Blocks

View Coverage Results for C/C++ Code in S-Function Blocks

This example shows how to view coverage results for the C/C++ code in S-Function blocks in your model. To view coverage results for the C/C++ code in the blocks:

• Enable support for S-Function coverage. For more information, see “Model Coverage for C and C++ S-Functions”.

• Run simulation and view the coverage report.

The coverage results for S-Function blocks can be viewed in the same report as the rest of the model. For each S-Function block, the report links to a detailed coverage report for the C/C++ code in the block.

To view the full code coverage report used in this example, follow the steps in “Coverage for S-Functions”.

1 In the coverage report, view the coverage metrics for the S-Function block.

For more information on the coverage report format, see “Top-Level Model Coverage

Report”.

2 Select the Detailed Report link. The code coverage report for the S-Function block opens.

18-41

18

Coverage Collection During Simulation

3 Select each of the links in Table Of Contents to navigate to various sections of the report.

18-42

Section Title

Analysis information

Tests

Summary

Details

Code

Purpose

Contains information such as time when model was created and last modified, and file size.

Contains information about the simulation such as start and end time.

Contains coverage information about the files and functions in the S-Function block. For each file and function, the percentage coverage is displayed. The coverage types relevant for the code are the following:

Coverage Type Acronym

“Cyclomatic Complexity” Complexity

“Condition Coverage (CC)” C1, C2, ...

“Decision Coverage (DC)” D1, D2, ...

“MCDC Coverage” MCDC

Percentage of statements covered

Stmt

Contains coverage information about the statements that receive condition, decision or MCDC coverage. The information is grouped by file and function.

Contains the C/C++ code. Statements that are not covered are highlighted in pink.

View Coverage Results for C/C++ Code in S-Function Blocks

4 In the Summary section, select each file or function name to see details of coverage for statements in the file or function.

5 The condition, decision or MCDC outcomes that were not tested during simulation are highlighted in pink. Within the details for a file or function, scroll down to note these cases and investigate them further.

18-43

18

Coverage Collection During Simulation

6 To obtain an overview of the statements that were not covered, navigate to the Code section. This section contains your code with the uncovered statements highlighted in pink.

18-44

More About

• “C/C++ S-Function”

Model Coverage for Stateflow Charts

Model Coverage for Stateflow Charts

In this section...

“How Model Coverage Reports Work for Stateflow Charts” on page 18-45

“Specify Coverage Report Settings” on page 18-46

“Cyclomatic Complexity” on page 18-46

“Decision Coverage” on page 18-47

“Condition Coverage” on page 18-50

“MCDC Coverage” on page 18-51

“Relational Boundary Coverage” on page 18-51

“Simulink Design Verifier Coverage” on page 18-51

“Model Coverage Reports for Stateflow Charts” on page 18-53

“Model Coverage for Stateflow State Transition Tables” on page 18-62

“Model Coverage for Stateflow Atomic Subcharts” on page 18-63

“Model Coverage for Stateflow Truth Tables” on page 18-66

“Colored Stateflow Chart Coverage Display” on page 18-71

How Model Coverage Reports Work for Stateflow Charts

To generate a Model Coverage report, select Analysis > Coverage > Settings and specify the desired options on the Reporting tab of the Coverage Settings dialog box. For

Stateflow charts, the Simulink Verification and Validation software records the execution of the chart itself and the execution of states, transition decisions, and individual conditions that compose each decision. After simulation ends, the model coverage reports on how thoroughly a model was tested. The report shows:

• How many times each exclusive substate is entered, executed, and exited based on the history of the superstate

• How many times each transition decision has been evaluated as true or false

• How many times each condition has been evaluated as true or false

Note: To measure model coverage data for a Stateflow chart, you must:

18-45

18

Coverage Collection During Simulation

18-46

• Have a Stateflow license.

• Have debugging/animation enabled for the chart.

Specify Coverage Report Settings

To specify coverage report settings, select Analysis > Coverage > Settings in the

Simulink Editor.

By selecting the Generate HTML Report option in the Coverage Settings dialog box, you can create an HTML report containing the coverage data generated during simulation of the model. The report appears in the MATLAB Help browser at the end of simulation.

By selecting the Generate HTML Report option, you also enable the selection of different coverages that you can specify for your reports. The following sections address only coverage metrics that affect reports for Stateflow charts. These metrics include decision coverage, condition coverage, and MCDC coverage.

Cyclomatic Complexity

Cyclomatic complexity is a measure of the complexity of a software module based on its edges, nodes, and components within a control-flow chart. It provides an indication of how many times you need to test the module.

The calculation of cyclomatic complexity is as follows:

CC = E - N + p where CC is the cyclomatic complexity, E is the number of edges, N is the number of nodes, and p is the number of components.

Within the Model Coverage tool, each decision is exactly equivalent to a single control flow node, and each decision outcome is equivalent to a control flow edge. Any additional structure in the control-flow chart is ignored since it contributes the same number of nodes as edges and therefore has no effect on the complexity calculation. Therefore, you can express cyclomatic complexity as follows:

CC = OUTCOMES - DECISIONS + p

Model Coverage for Stateflow Charts

For analysis purposes, each chart counts as a single component.

Decision Coverage

Decision coverage interprets a model execution in terms of underlying decisions where behavior or execution must take one outcome from a set of mutually exclusive outcomes.

Note: Full coverage for an object of decision means that every decision has had at least one occurrence of each of its possible outcomes.

Decisions belong to an object making the decision based on its contents or properties.

The following table lists the decisions recorded for model coverage for the Stateflow objects owning them. The sections that follow the table describe these decisions and their possible outcomes.

Object

Chart

State

Transition

Possible Decisions

If a chart is a triggered Simulink block, it must decide whether or not to execute its block.

If a chart contains exclusive (OR) substates, it must decide which of its states to execute.

If a state is a superstate containing exclusive (OR) substates, it must decide which substate to execute.

If a state has on event name actions (which might include temporal logic operators), the state must decide whether or not to execute the actions.

If a transition is a conditional transition, it must decide whether or not to exit its active source state or junction and enter another state or junction.

Chart as a Triggered Simulink Block Decision

If the chart is a triggered block in a Simulink model, the decision to execute the block is tested. If the block is not triggered, there is no decision to execute the block, and the measurement of decision coverage is not applicable (NA).

18-47

18

Coverage Collection During Simulation

Context

Active call

Chart Containing Exclusive OR Substates Decision

If the chart contains exclusive (OR) substates, the decision on which substate to execute is tested. If the chart contains only parallel AND substates, this coverage measurement is not applicable (NA).

Superstate Containing Exclusive OR Substates Decision

Since a chart is hierarchically processed from the top down, procedures such as exclusive

(OR) substate entry, exit, and execution are sometimes decided by the parenting superstate.

Note: Decision coverage for superstates applies only to exclusive (OR) substates. A superstate makes no decisions for parallel (AND) substates.

Since a superstate must decide which exclusive (OR) substate to process, the number of decision outcomes for the superstate is the number of exclusive (OR) substates that it contains. In the examples that follow, the choice of which substate to process can occur in one of three possible contexts.

Note: Implicit transitions appear as dashed lines in the following examples.

Example

States A and A1 are active.

Decisions That Occur

• The parent of states A and B must decide which of these states to process. This decision belongs to the parent. Since A is active, it is processed.

• State A, the parent of states

A1

and A2, must decide which of these states to process. This decision belongs to state A. Since

A1

is active, it is processed.

During processing of state A1, all outgoing transitions are tested. This decision belongs to the transition

18-48

Model Coverage for Stateflow Charts

Context Example

Implicit substate exit

A transition takes place whose source is superstate A and whose destination is state B.

Decisions That Occur and not to the parent state A. In this case, the transition marked by condition C2 is tested and a decision is made whether to take the transition to A2 or not.

If the superstate has two exclusive

(OR) substates, it is the decision of superstate A which substate performs the implicit transition from substate to superstate.

Substate entry with a history junction

A history junction records which substate was last active before the superstate was exited.

If that superstate becomes the destination of one or more transitions, the history junction decides which previously active substate to enter.

For more information, see “State Details Report Section” on page 18-56.

18-49

18

Coverage Collection During Simulation

18-50

State with On Event_Name Action Statement Decision

A state that has an on event_name action statement must decide whether to execute that statement based on the reception of a specified event or on an accumulation of the specified event when using temporal logic operators.

Conditional Transition Decision

A conditional transition is a transition with a triggering event and/or a guarding condition. In a conditional transition from one state to another, the decision to exit one state and enter another is credited to the transition itself.

Note: Only conditional transitions receive decision coverage. Transitions without decisions are not applicable to decision coverage.

Condition Coverage

Condition coverage reports on the extent to which all possible outcomes are achieved for individual subconditions composing a transition decision.

Note: Full condition coverage means that all possible outcomes occurred for each subcondition in the test of a decision.

For example, for the decision [A & B & C] on a transition, condition coverage reports on the true and false occurrences of each of the subconditions A, B, and C. This results in eight possible outcomes: true and false for each of three subconditions.

6

7

2

3

4

5

Outcome

1

A

T

T

T

T

F

F

F

B

T

T

F

F

T

T

F

C

T

F

T

F

T

F

T

Model Coverage for Stateflow Charts

Outcome

8

A

F

B

F

C

F

For more information, see “Transition Details Report Section” on page 18-59.

MCDC Coverage

The Modified Condition Decision Coverage (MCDC) option reports a test's coverage of occurrences in which changing an individual subcondition within a transition results in changing the entire transition trigger expression from true to false or false to true.

Note: If matching true and false outcomes occur for each subcondition, coverage is 100%.

For example, if a transition executes on the condition [C1 & C2 & C3 | C4 & C5], the MCDC report for that transition shows actual occurrences for each of the five subconditions (C1, C2, C3, C4, C5) in which changing its result from true to false is able to change the result of the entire condition from true to false.

Relational Boundary Coverage

If a transition in a Stateflow chart involves a relational operation, it receives relational boundary coverage. For more information, see “Relational Boundary Coverage”.

Simulink Design Verifier Coverage

You can use the following Simulink Design Verifier functions inside Stateflow charts:

• sldv.condition

• sldv.test

• sldv.assume

• sldv.prove

If you do not have a Simulink Design Verifier license, you can collect model coverage for a Stateflow chart containing these functions, but you cannot analyze the model using the

Simulink Design Verifier software.

18-51

18

Coverage Collection During Simulation

When you specify the Simulink Design Verifier coverage metric in the Coverage

Settings dialog box, the Simulink Verification and Validation software records coverage for these functions.

Each of these functions evaluates an expression expr, for example, sldv.test(expr), where expr is any valid Boolean MATLAB expression. Simulink Design Verifier coverage measures the number of time steps that the expression expr evaluates to true.

If expr is true for at least one time step, Simulink Design Verifier coverage for that function is 100%. Otherwise, the Simulink Verification and Validation software reports coverage for that function as 0%.

Consider a model that contains this Stateflow chart:

To collect coverage for Simulink Design Verifier functions, on the Coverage Settings dialog box, on the Coverage tab, select Simulink Design Verifier.

After simulation, the model coverage report lists coverage for the sldv.condition, sldv.assume

, sldv.prove, and sldv.test functions.

18-52

Model Coverage for Stateflow Charts

Model Coverage Reports for Stateflow Charts

• “Summary Report Section” on page 18-53

• “Subsystem and Chart Details Report Sections” on page 18-54

• “State Details Report Section” on page 18-56

• “Transition Details Report Section” on page 18-59

The following sections of a Model Coverage report were generated by simulating the sf_boiler

model, which includes the Bang-Bang Controller chart. The coverage metrics for Decision, Condition, and MCDC are enabled for this report.

Summary Report Section

The Summary section shows coverage results for the entire test and appears at the beginning of the Model Coverage report.

18-53

18

Coverage Collection During Simulation

18-54

Each line in the hierarchy summarizes the coverage results at that level and the levels below it. You can click a hyperlink to a later section in the report with the same assigned hierarchical order number that details that coverage and the coverage of its children.

The top level, sf_boiler, is the Simulink model itself. The second level, Bang-Bang

Controller, is the Stateflow chart. The next levels are superstates within the chart, in order of hierarchical containment. Each superstate uses an SF: prefix. The bottom level,

Boiler Plant model, is an additional subsystem in the model.

Subsystem and Chart Details Report Sections

When recording coverage for a Stateflow chart, the Simulink Verification and Validation software reports two types of coverage for the chart—Subsystem and Chart.

Subsystem — This section reports coverage for the chart:

Model Coverage for Stateflow Charts

Coverage (this object): Coverage data for the chart as a container object

Coverage (inc.) descendants: Coverage data for the chart and the states and transitions in the chart.

If you click the hyperlink of the subsystem name in the section title, the Bang-Bang

Controller block is highlighted in the block diagram.

Decision coverage is not applicable (NA) because this chart does not have an explicit trigger. Condition coverage and MCDC are not applicable (NA) for a chart, but apply to its descendants.

Chart — This section reports coverage for the chart:

Coverage (this object): Coverage data for the chart and its inputs

Coverage (inc.) descendants: Coverage data for the chart and the states and transitions in the chart.

If you click the hyperlink of the chart name in the section title, the chart opens in the

Stateflow Editor.

Decision coverage is listed appears for the chart and its descendants. Condition coverage and MCDC are not applicable (NA) for a chart, but apply to its descendants.

18-55

18

Coverage Collection During Simulation

18-56

State Details Report Section

For each state in a chart, the coverage report includes a State section with details about the coverage recorded for that state.

In the sf_boiler model, the state On resides in the box Heater. On is a superstate that contains:

• Two substates HIGH and NORM

• A history junction

• The function warm

Model Coverage for Stateflow Charts

The coverage report includes a State section on the state On.

18-57

18

Coverage Collection During Simulation

18-58

The decision coverage for the On state tests the decision of which substate to execute.

The three decisions are listed in the report:

• Under Substate executed, which substate to execute when On executes.

• Under Substate exited when parent exited, which substate is active when On exits. NORM is listed as never being active when On exits because the coverage tool sees the supertransition from NORM to Off as a transition from On to Off.

Model Coverage for Stateflow Charts

• Under Previously active substate entered due to history, which substate to reenter when On re-executes. The history junction records the previously active substate.

Because each decision can result in either HIGH or NORM, the total possible outcomes are 3 × 2 = 6. The results indicate that five of six possible outcomes were tested during simulation.

Cyclomatic complexity and decision coverage also apply to descendants of the On state.

The decision required by the condition [warm()] for the transition from HIGH to NORM brings the total possible decision outcomes to 8. Condition coverage and MCDC are not applicable (NA) for a state.

Note: Nodes and edges that make up the cyclomatic complexity calculation have no direct relationship with model objects (states, transitions, and so on). Instead, this calculation requires a graph representation of the equivalent control flow.

Transition Details Report Section

Reports for transitions appear under the report sections of their owning objects.

Transitions do not appear in the model hierarchy of the Summary section, since the hierarchy is based on superstates that own other Stateflow objects.

18-59

18

Coverage Collection During Simulation

18-60

The decision for this transition depends on the time delay of 40 seconds and the condition

[cold()]

. If, after a 40 second delay, the environment is cold (cold() = 1), the

Model Coverage for Stateflow Charts decision to execute this transition and turn the Heater on is made. For other time intervals or environment conditions, the decision is made not to execute.

For decision coverage, both true and false outcomes occurred. Because two of two decision outcomes occurred, coverage was full or 100%.

Condition coverage shows that only 4 of 6 condition outcomes were tested. The temporal logic statement after(40,sec) represents two conditions: the occurrence of sec and the time delay after(40,sec). Therefore, three conditions on the transition exist: sec, after(40,sec)

, and cold(). Since each of these decisions can be true or false, six possible condition outcomes exist.

The Conditions analyzed table shows each condition as a row with the recorded number of occurrences for each outcome (true or false). Decision rows in which a possible outcome did not occur are shaded. For example, the first and the third rows did not record an occurrence of a false outcome.

In the MC/DC report, all sets of occurrences of the transition conditions are scanned for a particular pair of decisions for each condition in which the following are true:

• The condition varies from true to false.

• All other conditions contributing to the decision outcome remain constant.

• The outcome of the decision varies from true to false, or the reverse.

For three conditions related by an implied AND operator, these criteria can be satisfied by the occurrence of these conditions.

18-61

18

Coverage Collection During Simulation conditions. Therefore, condition rows 1 and 3 are shaded. While condition 2 has been tested, conditions 1 and 3 have not and MCDC is 33%.

For some decisions, the values of some conditions are irrelevant under certain circumstances. For example, in the decision [C1 & C2 & C3 | C4 & C5] the left side of the | is false if any one of the conditions C1, C2, or C3 is false. The same applies to the right side result if either C4 or C5 is false. When searching for matching pairs that change the outcome of the decision by changing one condition, holding some of the remaining conditions constant is irrelevant. In these cases, the MC/DC report marks these conditions with an "x" to indicate their irrelevance as a contributor to the result.

These conditions appear as shown.

18-62

Consider the first matched pair. Since condition 1 is true in the True outcome column, it must be false in the matching False outcome column. This makes the conditions C2 and C3 irrelevant for the false outcome since C1 & C2 & C3 is always false if C1 is false.

Also, since the false outcome is required to evaluate to false, the evaluation of C4 & C5 must also be false. In this case, a match was found with C4 = F, making condition C5 irrelevant.

Model Coverage for Stateflow State Transition Tables

State transition tables are an alternative way of expressing modal logic in Stateflow.

Stateflow charts represent modal logic graphically, and state transition tables can represent equivalent modal logic in tabular form. For more information, see “Tabular

Expression of Modal Logic” in the Stateflow documentation.

Model Coverage for Stateflow Charts

Coverage results for state transition tables are the same as coverage results for equivalent Stateflow charts, except for a slight difference that arises in coverage of temporal logic. For example, consider the temporal logic expression after(4, tick) in the Mode Logic chart of the slvnvdemo_covfilt example model.

In chart coverage, the after(4, tick) transition represents two conditions: the occurrence of tick and the time delay after(4, tick). Since the temporal event tick is never false, the first condition is not satisfiable, and you cannot record 100% condition and MC/DC coverage for the transition after(4, tick).

In state transition table coverage, the after(4, tick) transition represents a single decision, with no subcondition for the occurrence of tick. Therefore, only decision coverage is recorded.

For state transition tables containing temporal logic decisions, as in the above example, condition coverage and MC/DC is not recorded.

Model Coverage for Stateflow Atomic Subcharts

In a Stateflow chart, an atomic subchart is a graphical object that allows you to reuse the same state or subchart across multiple charts and models.

When you specify to record coverage data for a model during simulation, the Simulink

Verification and Validation software records coverage for any atomic subcharts in your model. The coverage data records the execution of the chart itself, and the execution of states, transition decisions, and individual conditions that compose each decision in the atomic subchart.

Simulate the doc_atomic_subcharts_map_iodata example model and record decision coverage:

18-63

18

Coverage Collection During Simulation

1 Open the doc_atomic_subcharts_map_iodata model.

This model contains two Sine Wave blocks that supply input signals to the Stateflow chart. Chart contains two atomic subcharts—A and B—that are linked from the same library chart, also named A. The library chart contains the following objects:

18-64

2

In the Simulink Editor, select Analysis > Coverage > Settings

The Coverage Settings dialog box appears.

3 On the Coverage tab, select Coverage for this model:

doc_atomic_subcharts_map_iodata.

4 On the Reporting tab, select Generate HTML report.

5 Click OK to close the Coverage Settings dialog box.

6 Simulate the doc_atomic_subcharts_map_iodata model.

When the simulation completes, the coverage report opens.

The report provides coverage data for atomic subcharts A and B in the following forms:

• For the atomic subchart instance and its contents. Decision coverage is not applicable

(NA) because this chart does not have an explicit trigger.

Model Coverage for Stateflow Charts

• For the library chart A and its contents. The chart itself achieves 100% coverage on the input u1, and 88% coverage on the states and transitions inside the library chart.

Atomic subchart B is a copy of the same library chart A. The coverage of the contents of subchart B is identical to the coverage of the contents of subchart A.

18-65

18

Coverage Collection During Simulation

Model Coverage for Stateflow Truth Tables

• “Types of Coverage in Stateflow Truth Tables” on page 18-66

• “Analyze Coverage in Stateflow Truth Tables” on page 18-66

Types of Coverage in Stateflow Truth Tables

Simulink Verification and Validation software reports model coverage for the decisions the objects make in a Stateflow chart during model simulation. The report includes coverage for the decisions the truth table functions make.

For this type of truth table...

Stateflow Classic

MATLAB

The report includes coverage data for...

Conditions only.

Conditions and only those actions that have decision points.

Note: With the MATLAB for code generation action language, you can specify decision points in actions using control flow constructs, such as loops and switch statements.

Note: To measure model coverage data for a Stateflow truth table, you must have a

Stateflow license. For more information about Stateflow truth tables, see “Decision Logic” in the Stateflow documentation.

Analyze Coverage in Stateflow Truth Tables

If you have a Stateflow license, you can generate a model coverage report for a truth table.

Consider the following model.

18-66

The Stateflow chart contains the following truth table:

Model Coverage for Stateflow Charts

18-67

18

Coverage Collection During Simulation

18-68

When you simulate the model and collect coverage, the model coverage report includes the following data:

Model Coverage for Stateflow Charts

The Coverage (this object) column shows no coverage. The reason is that the container object for the truth table function—the Stateflow chart—does not decide whether to execute the ttable truth table.

The Coverage (inc. descendants) column shows coverage for the graphical function.

The graphical function has the decision logic that makes the transitions for the truth table. The transitions in the graphical function contain the decisions and conditions of the truth table. Coverage for the descendants in the Coverage (inc. descendants) column includes coverage for these conditions and decisions. Function calls to the truth table test the model coverage of these conditions and decisions.

18-69

18

Coverage Collection During Simulation

18-70

Note: See “How Stateflow Generates Content for Truth Tables” for a description of the graphical function for a truth table.

Coverage for the decisions and their individual conditions in the ttable truth table function are as follows.

Coverage

No model coverage for the default decision, D5

13% (1/8) decision coverage

3 of the 18 (17%) condition coverage

No (0/9) MCDC coverage

Missing coverage

Explanation

All logic that leads to taking a default decision is based on a false outcome for all preceding decisions. This means that the default decision requires no logic, so there is no model coverage.

The three constants that are inputs to the truth table (1, 0, 0) cause only decision D1 to be true. These inputs satisfy only one of the eight decisions (D1 through D4, T or F).

Because each condition can have an outcome value of T or F, three conditions can have six possible values. However, decision D4 has only decision coverage, not condition coverage or MCDC coverage, because it represents a decision with a single predicate.

Three decisions D1, D2, and D3 have condition coverage, because the set of inputs

(1, 0, 0) make only decision D1 true.

MCDC coverage looks for decision reversals that occur because one condition outcome changes from T to F or F to T. The simulation tests only one set of inputs, so the model reverses no decisions.

The red letters T and F indicate that model coverage is missing for those conditions. For decision D1, only the T decision is satisfied.

For decisions D2, D3, and D4, none of the conditions are satisfied.

Model Coverage for Stateflow Charts

Colored Stateflow Chart Coverage Display

The Model Coverage tool displays model coverage results for individual blocks directly in

Simulink diagrams. If you enable this feature, the Model Coverage tool:

• Highlights Stateflow objects that receive model coverage during simulation

• Provides a context-sensitive display of summary model coverage information for each object

Note: The coverage tool changes colors only for open charts at the time coverage information is reported. When you interact with the chart, such as selecting a transition or a state, colors revert to default values.

For details on enabling and selecting this feature in the Simulink window, see “Enable

Coverage Highlighting” in the Simulink Verification and Validation documentation.

Display Model Coverage with Model Coloring

Once you enable display coverage with model coloring, anytime that the model generates a model coverage report, individual chart objects receiving coverage appear highlighted with light green or light red.

1 Open the sf_car model.

2 Select Analysis > Coverage > Settings.

3 In the Coverage Settings dialog box, select Coverage for this model.

4 Click OK.

5 Simulate the model.

After simulation ends, chart objects with coverage appear highlighted.

18-71

18

Coverage Collection During Simulation

18-72

Object highlighting indicates coverage as follows:

• Light green for full coverage

• Light red for partial coverage

• No color for zero coverage

Note: To revert the chart to show original colors, select and deselect any objects.

6 Click selection_state in the chart.

The following summary report appears.

Model Coverage for Stateflow Charts

When you click a highlighted Stateflow object, the summarized coverage for that object appears in the Coverage Display Window. Clicking the hyperlink opens the section of the coverage report for this object.

Tip You can set the Coverage Display Window to appear for a block in response to a hovering mouse cursor instead of a mouse click in one of two ways:

• Select the downward arrow on the right side of the Coverage Display Window and select Focus.

• Right-click a colored block and select Coverage > Display details on

mouse-over.

18-73

Results Review

• “Types of Coverage Reports” on page 19-2

• “Top-Level Model Coverage Report” on page 19-12

• “Export Model Coverage Web View” on page 19-47

19

19

Results Review

Types of Coverage Reports

In the Coverage Settings dialog box, on the Report tab, if you select the Generate

HTML report option, the Simulink Verification and Validation software creates one or more model coverage reports after a simulation.

Report Type

“Top-Level Model Coverage Report” on page 19-12

“Model Summary Report” on page

19-3

“Model Reference Coverage Report” on page 19-4

“External MATLAB File Coverage

Report” on page 19-5

“Subsystem Coverage Report” on page 19-9

“Code Coverage Report” on page

19-11

Description

Provides coverage information for all model elements, including the model itself.

Provides links to coverage results for referenced models and external MATLAB files in the model hierarchy.

Created when the top-level model includes Model blocks or calls one or more external files.

Created for each referenced model in the model hierarchy; has the same format as the model coverage report.

Provides detailed coverage information about any external MATLAB file that the model calls. There is one report for each external file called from the model.

Model coverage report includes only coverage results for the subsystem, if you select one.

Provides coverage information for C/C++ code in

S-Function blocks.

HTML Report File Name

model_name_cov.html

model_name

_summary_cov.html

reference_model_name

_cov.html

MATLAB_file_name_cov.html

model_name_cov.html

; model_name

is the name of the top-level model

model_name_block_name_instance_n_cov.html

19-2

Types of Coverage Reports

Model Summary Report

If the top-level model contains Model blocks or calls external files, the software creates a model summary coverage report named model_name_summary_cov.html. The title of this report is Coverage by Model.

The summary report lists and provides links to coverage reports for Model block referenced models and external files called by MATLAB code in the model. For more

information, see “External MATLAB File Coverage Report” on page 19-5.

The following graphic shows an example of a model summary report. It contains links to the model coverage report (mExternalMfile), a report for the Model block (mExternalMfileRef), and three external files called from the model

(externalmfile,I externalmfile1, andexternalmfile2).

19-3

19

Results Review

19-4

Model Reference Coverage Report

If your top-level model references a model in a Model block, the software creates a separate report, named reference_model_name_cov.html, that includes coverage for

the referenced model. This report has the same format as the “Top-Level Model Coverage

Report” on page 19-12. Coverage results are recorded as if the referenced model was a

standalone model; the report gives no indication that the model is referenced in a Model block.

Types of Coverage Reports

External MATLAB File Coverage Report

If your top-level model calls any external MATLAB files, select Coverage for MATLAB

files on the Coverage tab of the Coverage Settings dialog box. The software creates a report, named MATLAB_file_name_cov.html, for each distinct file called from the model. When there are several calls to a given file from the model, the software creates only one report for that file, but it accumulates coverage from all the calls to the file. The external MATLAB file coverage report does not include information about what parts of the model call the external file.

The first section of the external MATLAB file coverage report contains summary information about the external file, similar to the model coverage report.

19-5

19

Results Review

19-6

Types of Coverage Reports

The Details section reports coverage for the external file and the function in that file.

The Details section also lists the content of the file, highlighting the code lines that have decision points or function definitions.

19-7

19

Results Review

19-8

Types of Coverage Reports

Coverage results for each of the highlighted code lines follow in the report. The following graphic shows a portion of these coverage results from the preceding code example.

Subsystem Coverage Report

In the Coverage Settings dialog box, when you select Coverage for this model, you can click Select Subsystem to request coverage for only the selected subsystem in the model. The software creates a model coverage report for the top-level model, but includes coverage results only for the subsystem.

However, if the top-level model calls any external files and you select Coverage for

MATLAB files in the Coverage Settings dialog box, the results include coverage for all external files called from:

• The subsystem for which you are recording coverage

19-9

19

Results Review

• The top-level model that includes the subsystem

If the subsystem parameter Read/Write Permissions is set to NoReadOrWrite, the software does not record coverage for that subsystem.

For example, in the fuelsys model, you click Select Subsystem, and select coverage for the feedforward_fuel_rate subsystem.

19-10

The report is similar to the model coverage report, except that it includes only results for the feedforward_fuel_rate subsystem and its contents.

Types of Coverage Reports

Code Coverage Report

For each S-Function block, the model coverage report links to a detailed code coverage report for the C/C++ code in the block.

For more information on how to navigate the report, see “View Coverage Results for C/C+

+ Code in S-Function Blocks”.

19-11

19

Results Review

Top-Level Model Coverage Report

The Simulink Verification and Validation software always creates a model coverage report for the top-level model named model_name_cov.html. The model coverage report contains several sections:

In this section...

“Coverage Summary” on page 19-12

“Details” on page 19-14

“Cyclomatic Complexity” on page 19-22

“Decisions Analyzed” on page 19-24

“Conditions Analyzed” on page 19-25

“MCDC Analysis” on page 19-26

“Cumulative Coverage” on page 19-27

“N-Dimensional Lookup Table” on page 19-30

“Block Reduction” on page 19-36

“Relational Boundary” on page 19-37

“Saturate on Integer Overflow Analysis” on page 19-41

“Signal Range Analysis” on page 19-42

“Signal Size Coverage for Variable-Dimension Signals” on page 19-44

“Simulink Design Verifier Coverage” on page 19-45

Coverage Summary

The coverage summary section contains basic information about the model being analyzed:

Model Information

Simulation Optimization Options

Coverage Options

19-12

Top-Level Model Coverage Report

The coverage summary has two subsections:

Tests — The simulation start and stop time of each test case and any setup commands that preceded the simulation. The heading for each test case includes any test case label specified using the cvtest command.

Summary — Summaries of the subsystem results. To see detailed results for a specific subsystem, in the Summary subsection, click the subsystem name.

19-13

19

Results Review

19-14

Details

The Details section reports the detailed model coverage results. Each section of the detailed report summarizes the results for the metrics that test each object in the model:

• “Filtered Objects” on page 19-15

• “Model Details” on page 19-15

• “Subsystem Details” on page 19-16

• “Block Details” on page 19-17

Top-Level Model Coverage Report

• “Chart Details” on page 19-18

• “Coverage Details for MATLAB Functions and Simulink Design Verifier Functions” on page 19-18

You can also access a model element Details subsection as follows:

1

Right-click a Simulink element.

2 In the context menu, select Coverage > Report.

Filtered Objects

The Filtered Objects section lists all the objects in the model that were filtered from coverage recording, and the rationale you specified for filtering those objects. If the filter rule specifies that all blocks of a certain type be filtered, all those blocks are listed here.

In the following graphic, several blocks, subsystems, and transitions were filtered. Two library-linked blocks, protected division and protected division1, were filtered because their block library was filtered.

Model Details

The Details section contains a results summary for the model as a whole, followed by a list of elements. Click the model element name to see its coverage results.

The following graphic shows the Details section for the sldemo_fuelsys example model.

19-15

19

Results Review

19-16

Subsystem Details

Each subsystem Details section contains a summary of the test coverage results for the subsystem and a list of the subsystems it contains. The overview is followed by sections for blocks, charts, and MATLAB functions, one for each object that contains a decision point in the subsystem.

The following graphic shows the coverage results for the Engine Gas Dynamics subsystem in the sldemo_fuelsys example model.

Top-Level Model Coverage Report

Block Details

The following graphic shows decision coverage results for the MinMax block in the

Mixing & Combustion subsystem of the Engine Gas Dynamics subsystem in the sldemo_fuelsys

example model.

The Uncovered Links element first appears in the Block Details section of the first block in the model hierarchy that does not achieve 100% coverage. The first Uncovered

Links element has an arrow that links to the Block Details section in the report of the

next block that does not achieve 100% coverage.

Subsequent blocks that do not achieve 100% coverage have links to the Block Details sections in the report of the previous and next blocks that do not achieve 100% coverage.

19-17

19

Results Review

Chart Details

The following graphic shows the coverage results for the Stateflow chart control_logic in the sldemo_fuelsys example model.

19-18

For more information about model coverage reports for Stateflow charts and their objects, see “Model Coverage for Stateflow Charts”.

Coverage Details for MATLAB Functions and Simulink Design Verifier Functions

By default, Simulink Verification and Validation records coverage for all MATLAB functions in a model. MATLAB functions are in MATLAB Function blocks, Stateflow charts, or external MATLAB files.

Top-Level Model Coverage Report

Note: For a detailed example of coverage reports for external MATLAB files, see

“External MATLAB File Coverage Report” on page 19-5.

To record Simulink Design Verifier coverage for sldv.* functions called by MATLAB functions, and any Simulink Design Verifier blocks, in the Coverage Settings dialog box, on the Coverage tab, select Simulink Design Verifier.

The following example shows coverage details for a MATLAB function, hFcnsInExternalEML

, that calls four Simulink Design Verifier functions. In this example, the code for hFcnsInExternalEML resides in an external file.

This example also shows Simulink Design Verifier coverage details for the following functions:

• sldv.assume

• sldv.condition

• sldv.prove

• sldv.test

In the coverage results, code that achieves 100% coverage is green. Code that achieves less than 100% coverage is red.

19-19

19

Results Review

19-20

Coverage for the hFcnsInExternalEML function and the sldv.* calls is:

• Line 1, the function declaration for hFcnsInExternalEMLis green because the simulation executes that function at least once. fcn calls hFcnsInExternalEML 11 times during simulation.

Top-Level Model Coverage Report

Line 4, sldv.assume(u1 > u2), achieves 0% coverage because u1 > u2 never evaluates to true.

• Line 5, sldv.condition(u1 == 0), achieves 100% coverage because u1 == 0 evaluates to true for at least one time step.

• Line 6, switch u1, achieves 25% coverage because only one of the four outcomes in the switch statement (case 0) occurs during simulation.

19-21

19

Results Review

• Line 17, sldv.test(y > u1); sldv.test (y == 4) achieves 50% coverage. The first sldv.test call achieves 100% coverage, but the second sldv.test call achieves

0% coverage.

19-22

For more information about coverage for MATLAB functions, see “Model Coverage for

MATLAB Functions” on page 18-20.

For more information about coverage for Simulink Design Verifier functions, see

“Simulink Design Verifier Coverage” on page 15-9.

Cyclomatic Complexity

You can specify that the model coverage report include cyclomatic complexity numbers in two locations in the report:

Top-Level Model Coverage Report

• The Summary section contains the cyclomatic complexity numbers for each object in the model hierarchy. For a subsystem or Stateflow chart, that number includes the cyclomatic complexity numbers for all their descendants.

• The Details sections for each object list the cyclomatic complexity numbers for all individual objects.

19-23

19

Results Review

Decisions Analyzed

The Decisions analyzed table lists possible outcomes for a decision and the number of times that an outcome occurred in each test simulation. Outcomes that did not occur are in red highlighted table rows.

The following graphic shows the Decisions analyzed table for the Saturate block in the Throttle & Manifold subsystem of the Engine Gas Dynamics subsystem in the sldemo_fuelsys

example model.

19-24

Top-Level Model Coverage Report

To display and highlight the block in question, click the block name at the top of the section containing the block’s Decisions analyzed table.

Conditions Analyzed

The Conditions analyzed table lists the number of occurrences of true and false conditions on each input port of the corresponding block.

19-25

19

Results Review

MCDC Analysis

The MC/DC analysis table lists the MCDC input condition cases represented by the corresponding block and the extent to which the reported test cases cover the condition cases.

19-26

Each row of the MC/DC analysis table represents a condition case for a particular input to the block. A condition case for input n of a block is a combination of input values. Input n

is called the deciding input of the condition case. Changing the value of input n alone changes the value of the block's output.

The MC/DC analysis table shows a condition case expression to represent a condition case. A condition case expression is a character string where:

Top-Level Model Coverage Report

• The position of a character in the string corresponds to the input port number.

• The character at the position represents the value of the input. (T means true; F means false).

• A boldface character corresponds to the value of the deciding input.

For example, FTF represents a condition case for a three-input block where the second input is the deciding input.

The Decision/Condition column specifies the deciding input for an input condition case.

The True Out column specifies the deciding input value that causes the block to output a true value for a condition case. The True Out entry uses a condition case expression, for example, FF, to express the values of all the inputs to the block, with the value of the deciding variable in bold.

Parentheses around the expression indicate that the specified combination of inputs did not occur during the first (or only) test case included in this report. In other words, the test case did not cover the corresponding condition case. The False Out column specifies the deciding input value that causes the block to output a false value and whether the value actually occurred during the first (or only) test case included in the report.

If you select Treat Simulink Logic blocks as short-circuited in the Coverage

Settings dialog box, MC/DC coverage analysis does not verify whether short-circuited inputs actually occur. The MC/DC analysis table uses an x in a condition expression (for example, TFxxx) to indicate short-circuited inputs that were not analyzed by the tool.

If you enable this feature and Logic blocks are short-circuited while collecting model coverage, you might not be able to achieve 100% coverage for that block.

Cumulative Coverage

On the Results tab, if you select Save cumulative results in workspace variable and on the Report tab, Cumulative runs, the results of each simulation are saved and recorded in the report.

In a cumulative coverage report, the results located in the right-most area in all tables reflect the running total value. The report is organized so that you can easily compare the additional coverage from the most recent run with the coverage from all prior runs in the session.

A cumulative coverage report contains information about:

19-27

19

Results Review

• Current Run — The coverage results of the simulation just completed.

• Delta — Percentage of coverage added to the cumulative coverage achieved with the simulation just completed. If the previous simulation's cumulative coverage and the current coverage are nonzero, the delta may be 0 if the new coverage does not add to the cumulative coverage.

• Cumulative — The total coverage collected for the model up to, but not including, the simulation just completed.

After running three test cases for the slvnv_autopilot_test_harness model, the

Summary report shows how much additional coverage the third test case achieved and the cumulative coverage achieved for the first two test cases.

19-28

The Decisions analyzed table for cumulative coverage contains three columns of data about decision outcomes that represent the current run, the delta since the last run, and the cumulative data, respectively.

Top-Level Model Coverage Report

The Conditions analyzed table uses column headers #n T and #n F to indicate results for individual test cases. The table uses Tot T and Tot F for the cumulative results. You can identify the true and false conditions on each input port of the corresponding block for each test case.

The MC/DC analysis #n True Out and #n False Out columns show the condition cases for each test case. The Total Out T and Total Out F column show the cumulative results.

19-29

19

Results Review

19-30

Note: You can calculate cumulative coverage for reusable subsystems and Stateflow constructs at the command line. For more information, see “Obtain Cumulative Coverage for Reusable Subsystems and Stateflow® Constructs”.

N-Dimensional Lookup Table

The following interactive chart summarizes the extent to which elements of a lookup table are accessed. In this example, two Sine Wave blocks generate x and y indices that access a 2-D Lookup Table block of 10-by-10 elements filled with random values.

Top-Level Model Coverage Report

In this model, the lookup table indices are 1, 2,..., 10 in each direction. The Sine Wave 2 block is out of phase with the Sine Wave 1 block by pi/2 radians. This generates x and y numbers for the edge of a circle, which you see when you examine the resulting Lookup

Table coverage.

19-31

19

Results Review

19-32

The report contains a two-dimensional table representing the elements of the lookup table. The element indices are represented by the cell border grid lines, which number

10 in each dimension. Areas where the lookup table interpolates between table values are represented by the cell areas. Areas of extrapolation left of element 1 and right of element 10 are represented by cells at the edge of the table, which have no outside border.

The number of values interpolated (or extrapolated) for each cell (execution counts) during testing is represented by a shade of green assigned to the cell. Each of six levels of green shading and the range of execution counts represented are displayed on one side of the table.

If you click an individual table cell, you see a dialog box that displays the index location of the cell and the exact number of execution counts generated for it during testing. The following example shows the contents of a color-shaded cell on the right edge of the circle.

Top-Level Model Coverage Report

The selected cell is outlined in red. You can also click the extrapolation cells on the edge of the table.

A bold grid line indicates that at least one block input equal to its exact index value occurred during the simulation. Click the border to display the exact number of hits for that index value.

The following example model uses an n-D Lookup Table block of 10-by-10-by-5 elements filled with random values.

19-33

19

Results Review

Both the x and y table axes have the indices 1, 2,..., 10. The z axis has the indices 10,

20,..., 50. Lookup table values are accessed with x and y indices that the two Sine Wave blocks generated, in the preceding example, and a z index that a Ramp block generates.

After simulation, you see the following lookup table report.

19-34

Instead of a two-dimensional table, the link Force Map Generation displays the following tables:

Top-Level Model Coverage Report

Lookup table coverage for a three-dimensional lookup table block is reported as a set of two-dimensional tables.

The vertical bars represent the exact z index values: 10, 20, 30, 40, 50. If a vertical bar is bold, this indicates that at least one block input was equal to the exact index value it represents during the simulation. Click a bar to get a coverage report for the exact index value that bar represents.

You can report lookup table coverage for lookup tables of any dimension. Coverage for four-dimensional tables is reported as sets of three-dimensional sets, like those in the preceding example. Five-dimensional tables are reported as sets of sets of threedimensional sets, and so on.

19-35

19

Results Review

Block Reduction

All model coverage reports indicate the status of the Simulink Block reduction parameter at the beginning of the report. In the following example, you set Force block

reduction off.

In the next example, you enabled the Simulink Block reduction parameter, and you did not set Force block reduction off.

Consider the following model where the simulation does not execute the MinMax1 block because there is only one input—the constant 3.

19-36

Top-Level Model Coverage Report

If you set Force block reduction off, the report contains no coverage data for this block because the minimum input to the MinMax1 block is always 1.

If you do not set Force block reduction off, the report contains no coverage data for reduced blocks.

Relational Boundary

On the Coverage tab, if you select the Relational Boundary coverage metric, the software creates a Relational Boundary table in the model coverage report for each model object that is supported for this coverage. The table applies to the explicit or implicit relational operation involved in the model object. For more information, see:

19-37

19

Results Review

• “Relational Boundary Coverage”.

• The Relational Boundary column in “Model Objects That Receive Coverage”.

The tables below show the relational boundary coverage report for the relation input1

<= input2

. The appearance of the tables depend on the operand data type.

• “Integers” on page 19-38

• “Fixed point” on page 19-39

• “Floating point” on page 19-39

Integers

If both operands are integers (or if one operand is an integer and the other a Boolean), the table appears as follows.

19-38

For a relational operation such as operand_1 <= operand_2:

• The first row states the two operands in the form operand_1 - operand_2.

• The second row states the number of times during the simulation that operand_1 operand_2

is equal to -1.

• The third row states the number of times during the simulation that operand_1 is equal to operand_2.

• The fourth row states the number of times during the simulation that operand_1 operand_2

is equal to 1.

Top-Level Model Coverage Report

Fixed point

If one of the operands has fixed-point type and the other operand is either a fixed point or an integer, the table appears as follows. LSB represents the value of the least significant bit. For more information, see “Precision”. If the two operands have different precision, the smaller value of precision is used.

For a relational operation such as operand_1 <= operand_2:

• The first row states the two operands in the form operand_1 - operand_2.

• The second row states the number of times during the simulation that operand_1 operand_2

is equal to -LSB.

• The third row states the number of times during the simulation that operand_1 is equal to operand_2.

• The fourth row states the number of times during the simulation that operand_1 operand_2

is equal to LSB.

Floating point

If one of the operands has floating-point type, the table appears as follows. tol represents a value computed using the input values and a tolerance that you specify. If you do not specify a tolerance, the default values are used. For more information, see

“Relational Boundary Coverage”.

19-39

19

Results Review

19-40

For a relational operation such as operand_1 <= operand_2:

• The first row states the two operands in the form operand_1 - operand_2.

• The second row states the number of times during the simulation that operand_1 operand_2

has values in the range [-tol..0].

• The third row states the number of times during the simulation that operand_1 operand_2

has values in the range (0..tol] during the simulation.

The appearance of this table changes according to the relational operator in the block.

Depending on the relational operator, the value of operand_1 - operand_2 equal to 0 is either:

• Excluded from relational boundary coverage.

• Included in the region above the relational boundary.

• Included in the region below the relational boundary.

Relational Operator

==

!=

<=

Report Format

[-tol..0)

(0..tol]

[-tol..0)

(0..tol]

[-tol..0]

(0..tol]

Explanation

0 is excluded.

0 is excluded.

0 is included in the region below the relational boundary.

Top-Level Model Coverage Report

Relational Operator

<

>=

>

Report Format

[-tol..0)

[0..tol]

[-tol..0)

[0..tol]

[-tol..0]

(0..tol]

Explanation

0 is included in the region above the relational boundary.

0 is included in the region above the relational boundary.

0 is included in the region below the relational boundary.

0 is included below the relational boundary for <= but above the relational boundary for

<

. This rule is consistent with decision coverage. For instance:

• For the relation input1 <= input2, the decision is true if input1 is less than or equal to input2. < and = are grouped together. Therefore, 0 lies in the region below the relational boundary.

• For the relation input1 < input2, the decision is true only if input1 is less than input2

. > and = are grouped together. Therefore, 0 lies in the region above the relational boundary.

Saturate on Integer Overflow Analysis

On the Coverage tab, if you select the Saturate on integer overflow coverage metric, the software creates a Saturation on Overflow analyzed table in the model coverage report. The software creates the table for each block with the Saturate on integer

overflow parameter selected.

The Saturation on Overflow analyzed table lists the number of times a block saturates on integer overflow, indicating a true decision. If the block does not saturate on integer overflow, the table indicates a false decision. Outcomes that do not occur are in red highlighted table rows.

The following graphic shows the Saturation on Overflow analyzed table for the MinMax block in the Mixing & Combustion subsystem of the Engine Gas Dynamics subsystem in the sldemo_fuelsys example model.

19-41

19

Results Review

To display and highlight the block in question, click the block name at the top of the section containing the block’s Saturation on Overflow analyzed table.

19-42

Signal Range Analysis

If you select Signal Range Coverage, the software creates a Signal Range Analysis section at the bottom of the model coverage report. This section lists the maximum and minimum signal values for each output signal in the model measured during simulation.

Access the Signal Range Analysis report quickly with the Signal Ranges link in the nonscrolling region at the top of the model coverage report, as shown below in the sldemo_fuelsys

example model report.

Top-Level Model Coverage Report

Each block is reported in hierarchical fashion; child blocks appear directly under parent blocks. Each block name in the Signal Ranges report is a link. For example, select the

EGO sensor

link to display this block highlighted in its native diagram.

19-43

19

Results Review

Signal Size Coverage for Variable-Dimension Signals

If you select Signal Size, the software creates a Variable Signal Widths section after the

Signal Ranges data in the model coverage report. This section lists the maximum and minimum signal sizes for all output ports in the model that have variable-size signals.

It also lists the memory that Simulink allocated for that signal, as measured during simulation. This list does not include signals whose size does not vary during simulation.

The following example shows the Variable Signal Widths section in a coverage report. In this example, the Abs block signal size varied from 2 to 5, with an allocation of 5.

19-44

Each block is reported in hierarchical fashion; child blocks appear directly under parent blocks. Each block name in the Variable Signal Widths list is a link. Clicking on the link highlights the corresponding block in the Simulink Editor. After the analysis, the variable-size signals have a wider line design.

Top-Level Model Coverage Report

Simulink Design Verifier Coverage

If you select Simulink Design Verifier, the analysis collects coverage data for all

Simulink Design Verifier blocks in your model.

For an example of how this works, open the sldvdemo_debounce_testobjblks model.

This model contains two Test Objective blocks:

• The True block defines a property that the signal have a value of 2.

• The Edge block, inside the Masked Objective subsystem, describes the property where the output of the AND block in the Masked Objective subsystem changes from 2 to 1.

The Simulink Design Verifier software analyzes this model and produces a harness model that contains test cases that achieve certain test objectives. To see if the original model achieves those objectives, simulate the harness model and collect model coverage data. The model coverage tool analyzes any decision points or values within an interval that you specify in the Test Objective block.

In this example, the coverage report shows that you achieved 100% coverage of the True block because the signal value was 2 at least once. The signal value was 2 in 6 out of 14 time steps.

The input signal to the Edge block achieved a value of True once out of 14 time steps.

19-45

19

Results Review

19-46

Export Model Coverage Web View

Export Model Coverage Web View

You can export a Model Coverage Web View for your model. A Web View is an interactive rendition of a model that you can view in a Web browser. A Model Coverage Web View includes model coverage highlighting and analysis information from the Coverage

Display Window, as described in “View Coverage Results in a Model”.

To generate a Model Coverage Web View, update coverage reporting settings for your model. In the Simulink Editor, select Analysis > Coverage > Settings. In the Coverage

Settings dialog box, in the Reporting tab, select Generate report and Model Web

View.

19-47

19

Results Review

19-48

When you simulate your model with these coverage settings enabled, the software generates a Model Coverage Web View that you can open in a browser. To see model

Export Model Coverage Web View coverage information for a block in a Model Coverage Web View, click that block. The model coverage data appears in the Informer pane, below the model.

For more information, see “Web Views” in the Simulink Report Generator documentation.

19-49

Excluding Model Objects From

Coverage

• “Coverage Filtering” on page 20-2

• “Coverage Filter Rules and Files” on page 20-3

• “Model Objects to Filter from Coverage” on page 20-4

• “Create, Edit, and View Coverage Filter Rules” on page 20-5

• “Coverage Filter Viewer” on page 20-10

• “Filter Model Objects to Refine Coverage Results” on page 20-12

20

20

Excluding Model Objects From Coverage

Coverage Filtering

In this section...

“What Is Coverage Filtering?” on page 20-2

“When to Use Coverage Filtering” on page 20-2

What Is Coverage Filtering?

Coverage filtering is excluding model objects from model coverage when you simulate your Simulink model. You specify which objects you want to be excluded from coverage recording.

After you specify the objects to exclude, when you simulate your model, Simulink

Verification and Validation software does not record coverage for filtered objects in your model.

When to Use Coverage Filtering

You use coverage filtering to facilitate a bottom-up approach to recording model coverage.

If you have a large model, there may be design elements that intentionally do not record

100% coverage. You might also have several design elements that do not record 100% coverage that must record 100% coverage. You can temporarily or permanently eliminate these elements from coverage recording to focus on a subset of objects for testing and modification.

This approach allows you to iterate more efficiently—focus on a small problem, fix it, and then move on to resolve the next small problem. Before recording coverage for the entire model, you can resolve missing coverage problems with individual parts of the model.

20-2

Coverage Filter Rules and Files

Coverage Filter Rules and Files

In this section...

“What Is a Coverage Filter Rule?” on page 20-3

“What Is a Coverage Filter File?” on page 20-3

What Is a Coverage Filter Rule?

A coverage filter rule is a rule that specifies a model object or set of objects to exclude from coverage recording:

Each coverage filter rule includes the following fields:

Name—Name or path of the object to be filtered from coverage

Type—Whether a specific object is filtered or all objects of a given type are filtered

Rationale—An optional description that explains why this object is filtered from coverage

What Is a Coverage Filter File?

A coverage filter file is a collection of coverage filter rules. Each rule specifies one or more objects to exclude from coverage recording.

To apply the coverage filter rules during coverage recording, you must first attach a coverage filter file to your model. After you attach the coverage filter file, when you simulate the model, the specified objects are excluded from coverage. You can attach a coverage filter file to several Simulink models. However, a model can have only one attached coverage filter file.

MATLAB saves coverage filter files in the MATLAB Current Folder, unless you specify a different folder. The default name for a coverage filter file is

<model_name>_covfilter.cvf

.

If you use the default file name and the coverage filter file exists on the MATLAB path, each time you open the model, you see the coverage filter rules, unless another coverage filter file is already attached to that model.

20-3

20

Excluding Model Objects From Coverage

Model Objects to Filter from Coverage

In your model, the objects that you can filter from coverage recording are:

• Simulink blocks that receive coverage, including MATLAB Function blocks

• Subsystems and their contents. When you exclude a subsystem from coverage recording, none of the objects inside the subsystem record coverage.

• Individual library-linked blocks or charts

• All reference blocks linked to a library

• Stateflow charts, subcharts, states, transitions, and events

For a complete list of model objects that receive coverage, see “Model Objects That

Receive Coverage”.

20-4

Create, Edit, and View Coverage Filter Rules

Create, Edit, and View Coverage Filter Rules

In this section...

“Create and Edit Coverage Filter Rules” on page 20-5

“Save Coverage Filter to File” on page 20-8

“Attach Coverage Filter File to Model” on page 20-8

“View Coverage Filter Rules in Your Model” on page 20-8

“Remove Coverage Filter Rules” on page 20-9

Create and Edit Coverage Filter Rules

• “Create a Coverage Filter Rule” on page 20-5

• “Add Rationale to a Coverage Filter Rule” on page 20-6

• “Create Additional Coverage Filter Rules” on page 20-7

Create a Coverage Filter Rule

To create a coverage filter rule:

1

In the Coverage Settings dialog box, enable model coverage.

2

In the model window, right-click a model object and select Coverage > Exclude.

The following table lists the Exclude menu options. Depending on which option you select, the Type field is automatically set for the coverage filter rule you selected; you cannot override the value in the Type field.

If you select Coverage > ...

Exclude this block

Exclude all blocks with type <block_type>

Exclude all blocks with type MATLAB

Function

Exclude all blocks with type Truth Table

Exclude subsystem with all dependents

The rule type is ...

by block path by block type by block type by block type by subsystem

20-5

20

Excluding Model Objects From Coverage

If you select Coverage > ...

Exclude referenced library: <library_name>

Exclude subsystem with all descendants

Exclude chart with all descendants

Exclude mask type <mask name>

Exclude state with all descendants

Exclude this transition

Exclude temporal event <event_name>

The rule type is ...

by library reference by subsystem by chart by mask type by state by transition by temporal event

Add Rationale to a Coverage Filter Rule

Optionally, you can add text that describes why you want to exclude that object or objects from coverage recording, and might be useful to others who review the coverage for your model. When you add a new coverage filter rule, the Coverage Filter Viewer opens. To add the rationale:

1

Double-click the Rationale field for the rule.

2 Delete the existing text.

3

Add the rationale for excluding this object.

The following graphic shows examples of text in the Rationale field.

20-6

Create, Edit, and View Coverage Filter Rules

Note: The Rationale field is the only coverage filter rule field that you can edit in the

Coverage Filter Viewer.

Create Additional Coverage Filter Rules

From the Coverage Filter Viewer, you can navigate back to the model to create as many coverage filter rules as you need. To return to the model window, click Add new rule by

right-clicking in the model.

For each rule that you add, the Coverage Filter Viewer opens so that you can specify a rationale for excluding that object from coverage.

20-7

20

Excluding Model Objects From Coverage

20-8

Save Coverage Filter to File

After you define the coverage filter rules, save the rules to a file so that you can reuse them with this model or with other models. By default, coverage filter files are named

<model_name>_covfilter.cvf

.

In the Coverage Filter Viewer:

1 In the File name field, specify a file name for the filter file or accept the default file name.

2 Click Apply to save the coverage filter rules to that file.

If you make multiple changes to the coverage filter rules, apply the changes to the coverage filter file each time.

Attach Coverage Filter File to Model

Attach a coverage filter file to your model so that each time you open the model, the coverage filter rules apply when you simulate your model.

In the Coverage Filter Viewer:

1

Select Attach file to model.

2 Click Apply.

Note: You can also attach a coverage filter file to your model in the Coverage Settings dialog box, on the Filter tab.

You can have only one coverage filter file attached to a model at a time. If you attach a different coverage filter file, the newly attached file replaces the previously attached file.

Two or more models can have the same coverage filter file attached. If a model has an attached filter file that contains coverage filter rules for specific objects in a different model, those rules are ignored during coverage recording.

View Coverage Filter Rules in Your Model

Whenever you define a coverage filter rule or remove an existing coverage filter rule, the

Coverage Filter Viewer opens. This dialog box lists all the coverage filter rules for your

model. For more information, see “Coverage Filter Viewer” on page 20-10.

Create, Edit, and View Coverage Filter Rules

To open the Coverage Filter Viewer, right-click anywhere in the model window and select

Coverage > Open Filter Viewer.

If you are inside a subsystem, you can view any coverage filter rule attached to the subsystem. To open the Coverage Filter Viewer, right-click any object inside the subsystem and select Coverage > Show filter parent.

Remove Coverage Filter Rules

• “Remove a Coverage Filter Rule” on page 20-9

• “Remove Multiple Coverage Filter Rules” on page 20-9

Remove a Coverage Filter Rule

To remove a model object from coverage filtering, in the Simulink Editor, right-click the object and select Coverage > Remove. The Coverage Filter Viewer opens. The coverage filter rule for the selected model object is no longer on the list of rules.

Remove Multiple Coverage Filter Rules

Use the Coverage Filter Viewer to remove multiple coverage filter rules at once:

1 To open the Coverage Filter Viewer, right-click anywhere in the model and select

Coverage > Open Filter Viewer.

2 Select all the rules that you want to remove.

3 Click Remove rule.

20-9

20

Excluding Model Objects From Coverage

Coverage Filter Viewer

In the Coverage Filter Viewer, you can:

• Review and manage the coverage filter rules for your Simulink model.

• Attach and detach coverage filter files for your model.

• Navigate to the model to create additional coverage filter rules.

20-10

Coverage Filter Viewer

To ...

Do this:

Navigate to the model to create coverage filter rules.

Navigate to a model object associated with a rule.

Delete a rule.

Save the current rules to a file.

Click Add new rule by right-clicking in

the model.

1 Select the rule.

2 Click View in model.

1

Select the rule.

2

Click Remove rule.

1

Enter a file name or browse to the file.

2

Click Apply.

Attach the current filter file to the model.

1 Clear the Attach file to model check box.

2 Click Apply.

Detach the current filter file from the model.

Attach a new filter file to the model.

1

2

Click Attach file to model.

Click Apply.

1 Click Browse.

2 Navigate to the desired filter file.

Close the Coverage Viewer and save the changes.

3 Click Open.

4 Click Attach file to model.

5 Click Apply.

Click OK.

20-11

20

Excluding Model Objects From Coverage

Filter Model Objects to Refine Coverage Results

In this section...

“About the Example Model” on page 20-12

“Simulate Example Model and Review Coverage” on page 20-12

“Filter a Stateflow Transition” on page 20-13

“Filter a Stateflow Event” on page 20-15

“Filter Library Reference Blocks” on page 20-19

“Filter a Subsystem” on page 20-20

“Filter a Specific Block” on page 20-21

About the Example Model

In this example, when you simulate the slvnvdemo_covfilt model, the model does not record 100% coverage. In subsequent steps, you filter certain objects from recording coverage. These steps allow you to focus on specific parts of the model to test for coverage.

The slvnvdemo_covfilt model is configured to record and report coverage during simulation for the following coverage metrics:

• Decision coverage

• Condition coverage

• Modified condition/decision coverage (MCDC)

Simulate Example Model and Review Coverage

To identify areas of your model that do not record 100% coverage, simulate the model and record coverage.

1 Open the example model: slvnvdemo_covfilt

2 Select Simulation > Run.

20-12

Filter Model Objects to Refine Coverage Results

When the simulation is complete, an HTML coverage report opens. This model does not record 100% coverage.

Filter a Stateflow Transition

In the Mode Logic Stateflow chart, the [!on] transition is never false because it evaluates only when the [on] transition is false. If you do not collect coverage for the

[!on]

transition, the chart behavior does not change, so you should filter the [!on] transition.

1 Open the Mode Logic chart.

20-13

20

Excluding Model Objects From Coverage

20-14

2 Right-click the [!on] transition and select Coverage > Exclude this transition.

The Coverage Filter Viewer opens with the new filter rule listed.

3

Click in the Rationale field and enter the reason for excluding this transition, for example, This transition is never evaluated.

4

Save this rule to a filter file with the default name, slvnvdemo_covfilt_covfilter.cvf

. Click Apply.

If you are using this filter for the first time, the file is created in your MATLAB

Current Folder. You can specify a different file name and location for your filter file.

5 Attach this filter file to the slvnvdemo_covfilt model. Click Attach file to model and click Apply.

6 Click OK to close the Coverage Filter Viewer.

7

Simulate the model again and review the results in the coverage report.

Under Filtered Objects, the report lists the [!on] transition as filtered from the coverage analysis.

Filter Model Objects to Refine Coverage Results

If you open the Mode Logic chart and click the transition, the Informer window displays filtering information and the Rationale text.

Filter a Stateflow Event

Events in Stateflow are a common cause for missing coverage in a chart, because they sometimes form an condition for coverage that can never be satisfied.

For example, in the Mode Logic chart, the temporal event tick is never false, as you can see from the coverage report.

20-15

20

Excluding Model Objects From Coverage

20-16

Filter Model Objects to Refine Coverage Results

As a result, you cannot record 100% condition and MCDC coverage for the transition after(4, tick)

.

To filter the temporal event tick from coverage analysis for this model:

1

Open the Mode Logic chart.

2 Right-click the after(4, tick) transition and select Coverage > Exclude

temporal event tick.

The Coverage Filter Viewer opens with the new filter rule listed.

3

Click in the Rationale field and enter explanatory text, for example, tick is never false

.

4

Select Attach file to model and click Apply to save this rule to the current filter.

20-17

20

Excluding Model Objects From Coverage

20-18

Click OK to close the Coverage Filter Viewer.

5 Simulate the model again and review the results.

The Objects filtered from coverage analysis section of the report lists the conditions of the event tick that are excluded, along with the corresponding

Rationale text you entered in the Coverage Filter Viewer.

Filter Model Objects to Refine Coverage Results

With the tick event filtered from coverage analysis, there is no longer a subcondition on the decision for the after(4, tick) transition. There are only two possible decision outcomes for the after(4, tick) transition.

Filter Library Reference Blocks

The slvnvdemo_covfilt model contains two instances of a library-linked subsystem in the library slvnvdemo_covfilt_lib:

• protected division

20-19

20

Excluding Model Objects From Coverage

• protected division1

The library subsystem is a protection against division by zero and might not be relevant in the coverage report. Exclude it from coverage for this model.

1

In the Simulink Editor, right-click either of the protected division reference blocks.

When you filter a library block, all instances of that block are filtered from coverage.

2

Select Coverage > Exclude reference library: slvnvdemo_covfilt_lib/

protected division.

The Coverage Filter Viewer opens with the new filter rule listed.

3

Click in the Rationale field for this new rule and enter text for excluding this transition, for example, Protection against division by zero.

4 Save this rule to the current filter. Click Apply.

5 Simulate the model again and review the results.

The Filtered Blocks section of the report lists both protected division reference blocks. No coverage is recorded for the two protected division subsystems.

In the Simulink Editor, the blocks filtered from coverage are colored grey.

20-20

Filter a Subsystem

The slvnvdemo_covfilt model uses a Constant block to drive the enable port for the

Switchable config subsystem. Because the constant is always 0, this subsystem never executes.

Filter Model Objects to Refine Coverage Results

Exclude the Switchable config subsystem from coverage.

1

In the Simulink Editor, right-click the Switchable config subsystem.

2

Select Coverage > Exclude subsystem with all descendants.

3

Click in the Rationale field for this new rule and enter text for excluding this transition, for example, Never executed.

4 Save this rule to the current filter. Click Apply.

5 Simulate the model again and review the results.

The Filtered Blocks section of the report lists the Switchable config subsystem. No coverage is recorded for the subsystem.

Filter a Specific Block

In the slvnvdemo_covfilt model, the rate signal can never be less than or equal to 0, which is the value of the Lower limit parameter of the Saturation block. This condition leads to missing coverage.

Exclude the Saturation block from coverage.

1 In the Simulink Editor, right-click the Saturation block.

2 Select Coverage > Exclude this block.

3 Click in the Rationale field for this new rule and enter text for excluding this transition, for example, Input never <= lower limit (0).

4

Save this rule to the current filter. Click Apply.

5

Simulate the model again and review the results.

The Filtered Blocks section of the report lists the Saturation block. Coverage for that block is omitted from the report.

20-21

21

Automating Model Coverage Tasks

• “Commands for Automating Model Coverage Tasks” on page 21-2

• “Create Tests with cvtest” on page 21-3

• “Run Tests with cvsim” on page 21-5

• “Retrieve Coverage Details from Results” on page 21-7

• “Obtain Cumulative Coverage for Reusable Subsystems and Stateflow® Constructs” on page 21-8

• “Create HTML Reports with cvhtml” on page 21-11

• “Save Test Runs to File with cvsave” on page 21-12

• “Load Stored Coverage Test Results with cvload” on page 21-13

• “Use Coverage Commands in a Script” on page 21-14

21

Automating Model Coverage Tasks

Commands for Automating Model Coverage Tasks

Using model coverage commands lets you automate the entire model coverage process with MATLAB scripts. You can use model coverage commands to set up model coverage tests, execute them in simulation, and store and report the results.

21-2

Create Tests with cvtest

Create Tests with cvtest

The cvtest command creates a test specification object. Once you create the object, you simulate it with the cvsim command.

The call to cvtest has the following default syntax: cvto = cvtest(root) root

is the name of, or a handle to, a Simulink model or a subsystem of a model. cvto is a handle to the resulting test specification object. Only the specified model or subsystem and its descendants are subject to model coverage.

To create a test object with a specified label (used for reporting results): cvto = cvtest(root, label)

To create a test with a setup command: cvto = cvtest(root, label, setupcmd)

You execute the setup command in the base MATLAB workspace, just prior to running the instrumented simulation. Use this command for loading data prior to a test.

The returned cvtest object, cvto, has the following structure.

Field id modelcov rootPath label setupCmd settings.condition

settings.decision

settings.

designverifier settings.mcdc

Description

Read-only internal data-dictionary ID

Read-only internal data-dictionary ID

Name of the system or subsystem for analysis

String for reporting results

Command executed prior to simulation

Set to 1 for condition coverage

Set to 1 for decision coverage

Set to 1 for coverage for Simulink Design

Verifier blocks.

Set to 1 for MCDC coverage

21-3

21

Automating Model Coverage Tasks

Field settings.overflowsaturation

settings.sigrange

settings.sigsize

settings.tableExec

modelRefSettings.enable

modelRefSettings.

excludeTopModel modelRefSettings.

excludedModels emlSettings.

enableExternal sfcnSettings.

enableSfcn options.

forceBlockReduction

Description

Set to 1 for saturate on integer overflow coverage

Set to 1 for signal range coverage

Set to 1 for signal size coverage.

Set to 1 for lookup table coverage

String specifying one of the following values:

• Off — Disables coverage for all referenced models

• all — Enables coverage for all referenced models

• filtered — Enables coverage for only referenced models not listed in the excludedModels

subfield

Set to 1 for excluding coverage for the top model

String specifying a comma-separated list of referenced models for which coverage is disabled when modelRefSettings.enable

specifies filtered

Set to 1 to enable coverage for external program files called by MATLAB functions in your model

Set to 1 to enable coverage for C/C++ S-

Function blocks in your model.

Set to 1 to override the Simulink Block

reduction parameter if it is enabled.

21-4

Run Tests with cvsim

Run Tests with cvsim

Use the cvsim command to simulate a test specification object.

The call to cvsim has the following default syntax: cvdo = cvsim(cvto)

This command executes the cvtest object cvto by simulating the corresponding model.

cvsim

returns the coverage results in the cvdata object cvdo. When recording coverage for multiple models in a hierarchy, cvsim returns its results in a cv.cvdatagroup

object.

You can also control the simulation in a cvsim command by setting model parameters for the Simulink sim command to apply during simulation:

• The following command executes the test object cvto and simulates the model using the default model parameters. The cvsim function returns the coverage results in the cvdata object cvdo and returns the simulation outputs in a

Simulink.SimulationOutput class

object simOut:

[cvdo,simOut] = cvsim(cvto)

• The following commands create a structure, paramStruct, that specifies the model parameters to use during the simulation. The first command specifies that the simulation collect decision, condition, and MCDC coverage for this model.

paramStruct.CovMetricSettings = 'dcm'; paramStruct.SimulationMode = 'rapid'; paramStruct.AbsTol = '1e-5'; paramStruct.SaveState = 'on'; paramStruct.StateSaveName = 'xoutNew'; paramStruct.SaveOutput = 'on'; paramStruct.OutputSaveName = 'youtNew';

Note: For a complete list of model parameters, see “Model Parameters” in the

Simulink documentation.

The following cvsim command executes the test object cvto and simulates the model using the model parameter values specified in paramStruct:

[cvdo,simOut] = cvsim(cvto,paramStruct);

21-5

21

Automating Model Coverage Tasks

You can also execute multiple test objects with the cvsim command. The following command executes a set of coverage test objects, cvto1, cvto2, ... using the default simulation parameters. cvsim returns the coverage results in a set of cvdata objects, cvdo1, cvdo2, ...

and returns the simulation outputs in simOut.

[cvdo1, cvdo2, ..., simOut] = cvsim(cvto1, cvto2, ...)

21-6

Retrieve Coverage Details from Results

Retrieve Coverage Details from Results

Simulink Verification and Validation provides commands that allow you to retrieve specific coverage information from the cvtest object after you have simulated your model and recorded coverage. Use these commands to retrieve the specified coverage information for a block, subsystem, or Stateflow chart in your model or for the model itself:

• complexityinfo — Cyclomatic complexity coverage

• conditioninfo — Condition coverage

• decisioninfo — Decision coverage

• mcdcinfo — Modified condition/decision (MCDC) coverage

• overflowsaturationinfo — Saturate on integer overflow coverage

• relationalboundaryinfo — Relational boundary coverage

• sigrangeinfo — Signal range coverage

• sigsizeinfo — Signal size coverage

• tableinfo — Lookup Table block coverage

• getCoverageinfo — Coverage for Simulink Design Verifier blocks

The basic syntax of these functions is: coverage = <coverage_type_prefix>info(cvdata_object, ...

object, ignore_descendants)

• coverage — Multipart vector containing the retrieved coverage results for object

• cvdata_object — cvdata object that you create when you call cvtest

• object — Handle to a model or object in the model

• ignore_descendants — Flag to ignore coverage results in subsystems, referenced models, and Stateflow charts

21-7

21

Automating Model Coverage Tasks

Obtain Cumulative Coverage for Reusable Subsystems and

Stateflow® Constructs

This example shows how to create and view cumulative coverage results for a model with a reusable subsystem.

Simulink® Verification and Validation™ provides cumulative coverage for multiple instances of identically configured:

• Reusable subsystems

• Stateflow™ constructs

To obtain cumulative coverage, you add the individual coverage results at the command line. You can get cumulative coverage results for multiple instances across models and test harnesses by adding the individual coverage results.

Open example model

At the MATLAB® command line, type: model = 'slvnvdemo_cv_mutual_exclusion' ; open_system(model);

21-8

This model has two instances of a reusable subsystem. The instances are named

Subsystem 1 and Subsystem 2.

Obtain Cumulative Coverage for Reusable Subsystems and Stateflow® Constructs

Get decision coverage for Subsystem 1

Execute the commands for Subsystem 1 decision coverage: testobj1 = cvtest([model '/Subsystem 1' ]); testobj1.settings.decision = 1; covobj1 = cvsim(testobj1);

Get decision coverage for Subsystem 2

Execute the commands for Subsystem 2 decision coverage: testobj2 = cvtest([model '/Subsystem 2' ]); testobj2.settings.decision = 1; covobj2 = cvsim(testobj2);

Add coverage results for Subsystem 1 and Subsystem 2

Execute the command to create cumulative decision coverage for Subsystem 1 and

Subsystem 2: covobj3 = covobj1 + covobj2;

Generate coverage report for Subsystem 1

Create an HTML report for Subsystem 1 decision coverage: cvhtml( 'subsystem1' ,covobj1)

The report indicates that decision coverage is 50% for Subsystem 1. The true condition for enable logical value is not analyzed.

Generate coverage report for Subsystem 2

Create an HTML report for Subsystem 2 decision coverage: cvhtml( 'subsystem2' ,covobj2)

The report indicates that decision coverage is 50% for Subsystem 2. The false condition for enable logical value is not analyzed.

Generate coverage report for cumulative coverage of Subsystem 1 and Subsystem 2

Create an HTML report for cumulative decision coverage for Subsystem 1 and Subsystem

2:

21-9

21

Automating Model Coverage Tasks cvhtml( 'cum_subsystem' ,covobj3)

Cumulative decision coverage for reusable subsystems Subsystem 1 and Subsystem 2 is

100%. Both the true and false conditions for enable logical value are analyzed.

21-10

Create HTML Reports with cvhtml

Create HTML Reports with cvhtml

Once you run a test in simulation with cvsim, results are saved to cv.cvdatagroup or cvdata

objects in the base MATLAB workspace. Use the cvhtml command to create an

HTML report of these objects.

The following command creates an HTML report of the coverage results in the cvdata object cvdo. The results are written to the file file in the current MATLAB folder.

cvhtml(file, cvdo)

The following command creates a combined report of several cvdata objects: cvhtml(file, cvdo1, cvdo2, ...)

The results from each object are displayed in a separate column of the HTML report.

Each cvdata object must correspond to the same root model or subsystem, or the function produces errors.

You can specify the detail level of the report with the value of detail, an integer between 0 and 3: cvhtml(file, cvdo1, cvdo2,..., detail)

Higher numbers for detail indicate greater detail. The default value is 2.

21-11

21

Automating Model Coverage Tasks

Save Test Runs to File with cvsave

Once you run a test with cvsim, save its coverage tests and results to a file with the cvsave

function: cvsave(filename, model)

Save all the tests and results related to model in the text file filename.cvt: cvsave(filename, cvto1, cvto2, ...)

Save the tests in the text file filename.cvt. Information about the referenced models is also saved.

You can save specified cvdata objects to file. The following example saves the tests, test results, and referenced models' structure in cvdata objects to the text file filename.cvt

: cvsave(filename, cvdo1, cvdo2, ...)

21-12

Load Stored Coverage Test Results with cvload

Load Stored Coverage Test Results with cvload

The cvload command loads into memory the coverage tests and results stored in a file by the cvsave command. The following example loads the tests and data stored in the text file filename.cvt:

[cvtos, cvdos] = cvload(filename)

The cvtest objects that are loaded are returned in cvtos, a cell array of cvtest objects. The cvdata objects that are loaded are returned in cvdos, a cell array of cvdata

objects. cvdos has the same size as cvtos, but can contain empty elements if a particular test has no results.

In the following example, if restoretotal is 1, the cumulative results from prior runs are restored:

[cvtos, cvdos] = cvload(filename, restoretotal)

If restoretotal is unspecified or 0, the model's cumulative results are cleared.

cvload Special Considerations

When using the cvload command, be aware of the following considerations:

• When a model with the same name exists in the coverage database, only the compatible results are loaded from the file. They reference the existing model to prevent duplication.

• When the Simulink models referenced in the file are open but do not exist in the coverage database, the coverage tool resolves the links to the models that are already open.

• When you are loading several files that reference the same model, only the results that are consistent with the earlier files are loaded.

21-13

21

Automating Model Coverage Tasks

Use Coverage Commands in a Script

The following script demonstrates some common model coverage commands.

This script:

• Creates two data files to load before simulation.

• Creates two cvtest objects, testObj1 and testObj2, and simulates them using the default model parameters. Each cvtest object uses the setupCmd property to load a data file before simulation.

• Enables decision, condition, and MCDC coverage.

• Retrieves the decision coverage results for the Adjustable Rate Limited subsystem.

• Uses cvhtml to display the coverage results for the two tests and the cumulative coverage.

• Compute cumulative coverage with the + operator and save the results mdl = 'slvnvdemo_ratelim_harness'; mdl_subsys = 'slvnvdemo_ratelim_harness/Adjustable Rate Limiter'; open_system(mdl); open_system(mdl_subsys); t_gain = (0:0.02:2.0)'; u_gain = sin(2*pi*t_gain); t_pos = [0;2]; u_pos = [1;1]; t_neg = [0;2]; u_neg = [-1;-1]; save('within_lim.mat','t_gain','u_gain','t_pos','u_pos', ...

't_neg', 'u_neg'); t_gain = [0;2]; u_gain = [0;4]; t_pos = [0;1;1;2]; u_pos = [1;1;5;5]*0.02; t_neg = [0;2]; u_neg = [0;0]; save('rising_gain.mat','t_gain','u_gain','t_pos','u_pos', ...

't_neg', 'u_neg'); testObj1 = cvtest(mdl_subsys); testObj1.label = 'Gain within slew limits'; testObj1.setupCmd = 'load(''within_lim.mat'');'; testObj1.settings.mcdc = 1; testObj1.settings.condition = 1; testObj1.settings.decision = 1; testObj2 = cvtest(mdl_subsys); testObj2.label = 'Rising gain that temporarily exceeds slew limit'; testObj2.setupCmd = 'load(''rising_gain.mat'');'; testObj2.settings.mcdc = 1; testObj2.settings.condition = 1; testObj2.settings.decision = 1;

[dataObj1,simOut1] = cvsim(testObj1); decision_cov1 = decisioninfo(dataObj1,mdl_subsys); percent_cov1 = 100 * decision_cov1(1) / decision_cov1(2) cc_cov2 = complexityinfo(dataObj1, mdl_subsys);

[dataObj2,simOut2] = cvsim(testObj2,[0 2]);

21-14

decision_cov2 = decisioninfo(dataObj2,mdl_subsys); percent_cov2 = 100 * decision_cov2(1) / decision_cov2(2) cc_cov2 = complexityinfo(dataObj1, mdl_subsys); cvhtml('ratelim_report',dataObj1,dataObj2); cumulative = dataObj1+dataObj2; cvsave('ratelim_testdata',cumulative); close_system('slvnvdemo_ratelim_harness',0);

Use Coverage Commands in a Script

21-15

Checking Systems with the Model Advisor

22

Checking Systems Interactively

• “Check Model and Subsystems” on page 22-2

• “Limit Model Checks” on page 22-3

• “Limit Model Checks By Excluding Gain and Outport Blocks” on page 22-11

• “Model Checks for DO-178C/DO-331 Standard Compliance” on page 22-16

• “Model Checks for IEC 61508, ISO 26262, and EN 50128 Standard Compliance” on page 22-20

• “Model Checks for MathWorks Automotive Advisory Board (MAAB) Guideline

Compliance” on page 22-23

• “Model Checks for Requirements Links” on page 22-28

22

Checking Systems Interactively

Check Model and Subsystems

You can use the Model Advisor to check a model or subsystem for adherence to modeling guidelines or standards. The Model Advisor includes checks that help you define and implement consistent design guidelines. Using model checks, you can apply guidelines across projects and development teams.

When you run the checks, the Model Advisor reviews your model for conditions and configuration settings that cause inaccurate or inefficient simulation and code generation of the system that the model represents. Depending on which products you have installed, the Model Advisor includes different checks.

For more information

Checking model compliance with the

DO-178C safety standard

Checking model compliance with theISO

26262, IEC 61508, or EN 50182 safety standards

®

Checking model compliance with

MathWorks Automotive Advisory Board

(MAAB) guidelines

Checking requirements links

Model Advisor

See

“Model Checks for DO-178C/DO-331

Standard Compliance” on page 22-16

“Model Checks for IEC 61508, ISO 26262, and EN 50128 Standard Compliance” on page 22-20

“Model Checks for MathWorks Automotive

Advisory Board (MAAB) Guideline

Compliance” on page 22-23

“Model Checks for Requirements Links” on page 22-28

“Consulting the Model Advisor”

Software is inherently complex and may not be completely free of errors. Model Advisor checks might contain bugs. MathWorks reports known bugs brought to its attention on its Bug Report system at http://www.mathworks.com/support/bugreports/. The bug reports are an integral part of the documentation for each release. Examine periodically all bug reports for a release as such reports may identify inconsistencies between the actual behavior of a release you are using and the behavior described in this documentation.

While applying Model Advisor checks to your model will increase the likelihood that your model does not violate certain modeling standards or guidelines, it is ultimately your responsibility to verify, using multiple methods, that the system being developed provides its intended functionality and does not include any unintended functionality.

22-2

Limit Model Checks

Limit Model Checks

In this section...

“What Is a Model Advisor Exclusion?” on page 22-3

“Model Advisor Exclusion Files” on page 22-3

“Create Model Advisor Exclusions” on page 22-4

“Review Model Advisor Exclusions” on page 22-6

“Manage Exclusions” on page 22-7

What Is a Model Advisor Exclusion?

To save time during model development and verification, you might decide to limit the scope of a Model Advisor analysis of your model. You can do this by excluding individual blocks from checks. You create a Model Advisor exclusion to exclude blocks in the model from selected checks. You can exclude all or selected checks from:

• Simulink blocks

• Stateflow charts

After you specify the blocks to exclude, when you use the Model Advisor to analyze your model, the software uses the exclusion information to exclude blocks from specified checks during the analysis. A Model Advisor exclusion file stores the block and check exclusion information.

You can also exclude blocks from checks that you write by using Model Advisor APIs. For more information, see “Exclude Blocks From Custom Checks”.

Note: If you “Comment Blocks”, they are excluded from both simulation and Model

Advisor analysis.

Model Advisor Exclusion Files

A Model Advisor exclusion file specifies a collection of blocks to exclude from specified checks during a Model Advisor analysis.

22-3

22

Checking Systems Interactively

To exclude blocks from specified checks during an analysis of your model, you first create exclusions and save them in an exclusion file. You can also use an existing Model Advisor exclusion file.

When you analyze a model with Model Advisor exclusions, the blocks in the exclusion file are excluded from the specified checks during the analysis. You can use an exclusion file with several models. However, a model can have only one exclusion file.

Unless you specify a different folder, the Model Advisor saves exclusion files in the current folder. The default name for an exclusion file is

<model_name>_exclusions.xml

.

If you create an exclusion file and save your model, you attach the exclusion file to your model. Each time that you open the model, the blocks and checks specified in the exclusion file are excluded from the analysis.

In the Model Advisor Exclusion Editor dialog box, you can view each exclusion. Each exclusion includes the information listed in the following table.

Field

Rationale

Type

Value

Check ID (s)

Description

A description of why this object is excluded from Model

Advisor checks.

Whether a specific block is excluded or all blocks of a given type are excluded.

Name of block or blocks that are excluded.

Names of checks for which the block exclusion applies.

Create Model Advisor Exclusions

You might want to exclude model blocks and checks from a Model Advisor analysis to save time during model development and verification. To create a Model Advisor exclusion:

1

In the model window, right-click a block and select Model Advisor. The following table lists the possible menu options. The following table lists what you can exclude and the corresponding menu options.

22-4

Limit Model Checks

To ...

Exclude the block from all checks.

Exclude all blocks of this type from all checks.

Exclude the block from selected checks.

Exclude all blocks of this type from selected checks.

Exclude the block from all failed checks. This option is available after a Model

Advisor analysis.

Exclude all blocks of this type from all failed checks.

This option is available after a Model Advisor analysis.

Exclude the block from a failed check. This option is available after a Model

Advisor analysis.

Exclude all blocks of this type from a failed check.

This option is available after a Model Advisor analysis.

Select Model Advisor > ...

Exclude block only > All Checks

Exclude all blocks with type <block_type> > All

Checks

Exclude block only > Select Checks.

• In the Check Selector dialog box, select the checks.

Click OK.

Exclude all blocks with type <block_type> >

Select Checks.

• In the Check Selector dialog box, select the checks.

Click OK.

Exclude block only > Only failed checks

Exclude all blocks with type <block_type> > Only failed checks

Exclude block only > <name of failed check>

Exclude all blocks with type <block_type> >

<name of failed check>

2 In the Model Advisor Exclusion Editor dialog box, click OK or Apply to create the exclusion and save the information to an exclusion file. If this exclusion is the first one, a Save Exclusion File as dialog box opens. In this dialog box, click Save to create a exclusion file with the default name <model_name>_exclusions.xml in

22-5

22

Checking Systems Interactively the current folder. Optionally, in the Save Exclusion File dialog box, you can select a different file name or location.

3 If you want to change the exclusion file name or location: a In the Model Advisor Exclusion Editor dialog box, select Change.

b In the Change Exclusion File dialog box, select Save as.

c

In the Save Exclusion File dialog box, navigate to the location that you want and enter a file name. Click Save.

d In the Model Advisor Exclusion Editor dialog box, select OK or Apply to create the exclusion and save the information to an exclusion file.

You can create as many Model Advisor exclusions as you want by right-clicking model blocks and selecting Model Advisor. Each time that you create an exclusion, the Model

Advisor Exclusion Editor dialog box opens. In this dialog box, in the Rationale field, you can specify a reason for excluding blocks or checks from the Model Advisor analysis. The rationale might be useful to others who review your model.

If you create an exclusion file and save your model, you attach the exclusion file to your model. Each time that you open the model, the blocks and checks specified in the exclusion file are excluded from the analysis.

Review Model Advisor Exclusions

You can review the exclusions associated with your model. After opening your model, you might want to view the exclusions defined for your model by an attached exclusion file.

To view exclusions information, either before or after an Model Advisor analysis:

• Right-click in the model window or right-click a block and select Model Advisor

> Open Model Advisor Exclusion Editor. The Model Advisor Exclusion Editor dialog box lists the exclusions for your model.

• On the Model Advisor toolbar, select Settings > Preferences. In the Model Advisor

Preferences dialog box, select Show Exclusion tab . In the right pane of the Model

Advisor window, select the Exclusions tab to display checks that are excluded from the Model Advisor analysis.

• In the model window, select Analysis > Model Advisor > Model Advisor to launch the Model Advisor.

1

On the Model Advisor window toolbar, select Highlighting > Highlight

Exclusions. By default, this menu option is selected.

22-6

Limit Model Checks

2

In the Model Advisor window, click the Enable highlighting toggle button ( ).

3 In the left pane of the Model Advisor window, select a check. The blocks excluded from the check appear in the model window, highlighted in gray with a black border.

After the Model Advisor completes an analysis, you can view exclusion information for individual checks in the:

• HTML report. In the Model Advisor window, make sure select the Show report

after run check box before the analysis.

• Model Advisor window. In the left pane of the Model Advisor window, select By

Product > Simulink > < name of check >. If the By Product folder is not displayed, select Show By Product Folder from the Settings > Preferences dialog box.

If the check ...

Has no exclusions rules applied.

The HTML report and Model Advisor window ...

State that no exclusions were applied to this check. This might happen if you exclude a block from a check that passes without an exclusion.

Does not support exclusions.

State that the check does not support exclusions. This might happen if you exclude a block from a check that does not support exclusions.

Is excluded from a block. Lists the check exclusion rules.

Manage Exclusions

• “Save Exclusions To a File” on page 22-8

• “Load an Exclusion File” on page 22-9

• “Detach an Exclusion File” on page 22-9

• “Remove an Exclusion” on page 22-9

• “Add a Rational to an Exclusion” on page 22-9

• “Programmatically Specify an Exclusion File” on page 22-9

To open the Model Advisor Exclusion Editor dialog box, either right-click in the model window or right-click a block and select Model Advisor > Open Model Advisor

Exclusion Editor.

22-7

22

Checking Systems Interactively

22-8

Note: The Rationale field is the only field that you can edit in the Model Advisor

Exclusion Editor.

Save Exclusions To a File

To save an exclusion to a file:

1 In the Model Advisor Exclusion Editor dialog box, click OK or Apply. If this exclusion is the first one, a Save Exclusion File as dialog box opens. In this dialog box, click Save to create an exclusion file with the default name

<model_name>_exclusions.xml

in the current folder. Optionally, in the Save

Exclusion File dialog box, you can select a different file name or location.

2

If you want to change the exclusion file name or location: a

In the Model Advisor Exclusion Editor dialog box, select Change.

b In the Change Exclusion File dialog box, select Save as.

c

In the Save Exclusion File dialog box, navigate to the location that you want and enter a file name. Click Save.

d In the Model Advisor Exclusion Editor dialog box, select OK or Apply to create the exclusion and save the information to an exclusion file.

Limit Model Checks

Load an Exclusion File

To load an existing exclusion file for use with your model:

1 In the Model Advisor Exclusion Editor dialog box, click Change.

2

In the Change Exclusion File Dialog box, click Load.

3

Navigate to the exclusion file that you want to use with your model. Select Open.

4 In the Model Advisor Exclusion Editor dialog box, click OK to associate the exclusion file with your model.

Detach an Exclusion File

To detach an exclusion file associated with your model:

1 In the Model Advisor Exclusion Editor dialog box, click Change.

2 In the Change Exclusion File Dialog box, click Detach.

3

In the Model Advisor Exclusion Editor dialog box, click OK to detach the exclusion file from your model.

Remove an Exclusion

To remove an exclusion:

1 In the Model Advisor Exclusion Editor dialog box, select the exclusions that you want to remove.

2 Click Remove Exclusion.

Add a Rational to an Exclusion

You can add text that describes why you excluded a particular block or blocks from selected checks during Model Advisor analysis. A description might be useful to others who review your model.

1

In the Model Advisor Exclusion Editor dialog box, double-click the Rationale field for the exclusion.

2 Delete the existing text.

3 Add the rationale for excluding this object.

Programmatically Specify an Exclusion File

You can use the MAModelExclusionFile method to programmatically specify the name of an exclusion file.

22-9

22

Checking Systems Interactively

1 Use get_param to obtain the model object. For example, for sldemo_mdladv: mo = get_param('sldemo_mdladv','Object')

2 Use MAModelExclusionFile to specify the name of an exclusion file. For example, to specify exclusion file my_exclusion.xml in S:\work: mo.MAModelExclusionFile = ['S:\work\','my_exclusion.xml']

3 Open the Model Advisor Exclusion Editor dialog box. The Exclusion File field contains the specified exclusion file and path.

22-10

Limit Model Checks By Excluding Gain and Outport Blocks

Limit Model Checks By Excluding Gain and Outport Blocks

This example shows how to exclude a gain block and all outport blocks from a Model

Advisor check during a Model Advisor analysis. By excluding individual blocks from checks, you limit the scope of the analysis and might save time during model development and verification.

1

At the MATLAB command line, type sldemo_mdladv.

2

From the model window, select Analysis > Model Advisor > Model Advisor to open the Model Advisor.

3 A System Selector — Model Advisor dialog box opens. Click OK.

4 If the By Product folder is not displayed in the Model Advisor window, select Show

By Product Folder from the Settings > Preferences dialog box.

5 In the left pane of the Model Advisor window, expand By Product > Simulink.

Select the Show report after run check box to see an HTML report of check results after you run the checks.

6 Run the selected checks by clicking the Run selected checks button. After the

Model Advisor runs the checks, an HTML report displays the check results in a browser window. The check Identify unconnected lines, input ports, and

output ports triggers a warning.

7 In the left pane of the Model Advisor window, select the check By Product >

Simulink > Identify unconnected lines, input ports, and output ports.

8

In the Model Advisor window, click the Enable highlighting button ( ).

• The model window opens. The blocks causing the Identify unconnected lines,

input ports, and output ports check warning are highlighted in yellow.

• The Model Advisor Highlighting window opens with a link to the Model Advisor window. In the Model Advisor window, you can find more information about the check results and how to fix the warning condition.

22-11

22

Checking Systems Interactively

9 After reviewing the check results, exclude the Gain2 block from all Model Advisor checks: a In the model window, right-click the Gain2 block and select Model Advisor >

Exclude block only > All Checks. b In the Model Advisor Exclusion Editor dialog box, double-click in the first row of the Rationale field, and enter Exclude gain block.

22-12 c Click OK to create the exclusion file.

d

In the Save Exclusion File as dialog box, click Save to create a exclusion file with the default name sldemo_mdladv_exclusions.

Limit Model Checks By Excluding Gain and Outport Blocks

10 After reviewing the check results, exclude all Outport blocks from the Identify unconnected lines, input ports, and output ports check: a In the model window, right-click the Out4 block and select Model Advisor >

Exclude all blocks of type Outport > Select checks.

b In the Check Selector dialog box, scroll down and select Identify unconnected lines, input ports, and output ports

. Click OK.

Alternately, to exclude all Outport blocks from the Identify unconnected lines, input ports, and output ports check, right-click the Out4 block and select Model

Advisor > Exclude all blocks of type Outport > Identify unconnected

lines, input ports, and output ports.

c

In the Model Advisor Exclusion Editor dialog box, click OK to also exclude all

Outport blocks from the Identify unconnected lines, input ports, and output

22-13

22

Checking Systems Interactively ports check. The sldemo_mdladv_exclusions file is updated with the Outport block exclusions.

11

In the left pane of the Model Advisor window, select By Product > Simulink and then:

• Select the Show report after run check box.

• Select Run Selected Checks to run a Model Advisor analysis.

12 After the Model Advisor completes the analysis, you can view exclusion information for the Identify unconnected lines, input ports, and output ports check in the:

• HTML report:

• Model Advisor window. In the left pane of the Model Advisor window, select

By Product > Simulink > Identify unconnected lines, input ports, and

output ports.

22-14

Limit Model Checks By Excluding Gain and Outport Blocks

• Model window. In the left pane of the Model Advisor window, select By Product

> Simulink > Identify unconnected lines, input ports, and output ports.

Then click the Enable highlighting button ( ).

13 Close sldemo_mdladv.

Related Examples

• “Select and Run Model Checks”

More About

• “Run Model Checks”

• “Highlight Model Check Results”

22-15

22

Checking Systems Interactively

Model Checks for DO-178C/DO-331 Standard Compliance

You can check that your model or subsystem complies with selected aspects of the

DO-178C safety standard by running the Model Advisor. Navigate to By Product >

Simulink Verification and Validation > Modeling DO-178C/DO-331 Checks and run the checks.

For information on the DO-178C Software Considerations in Airborne Systems and

Equipment Certification and related standards, see Radio Technical Commission for

Aeronautics (RTCA) .

The table lists the DO-178C/DO-331 checks, with applicable “High-Integrity System

Modeling” guidelines.

DO-178C/DO-331 Check

“Check safety-related optimization settings”

“Check safety-related diagnostic settings for solvers”

Applicable High-Integrity System Modeling

Guidelines

• “hisl_0018: Usage of Logical Operator block”

• “hisl_0045: Configuration Parameters >

Optimization > Implement logic signals as Boolean data (vs. double)”

• “hisl_0046: Configuration Parameters >

Optimization > Block reduction”

• “hisl_0048: Configuration Parameters

> Optimization > Application lifespan

(days)”

• “hisl_0052: Configuration Parameters >

Optimization > Data initialization”

• “hisl_0053: Configuration Parameters

> Optimization > Remove code from floating-point to integer conversions that wraps out-of-range values”

• “hisl_0054: Configuration Parameters

> Optimization > Remove code that protects against division arithmetic exceptions”

“hisl_0043: Configuration Parameters >

Diagnostics > Solver”

22-16

Model Checks for DO-178C/DO-331 Standard Compliance

DO-178C/DO-331 Check

“Check safety-related diagnostic settings for sample time”

“Check safety-related diagnostic settings for signal data”

“Check safety-related diagnostic settings for parameters”

“Check safety-related diagnostic settings for data used for debugging”

“Check safety-related diagnostic settings for data store memory”

“Check safety-related diagnostic settings for type conversions”

“Check safety-related diagnostic settings for signal connectivity”

“Check safety-related diagnostic settings for bus connectivity”

“Check safety-related diagnostic settings that apply to function-call connectivity”

“Check safety-related diagnostic settings for compatibility”

“Check safety-related diagnostic settings for model initialization”

“Check safety-related diagnostic settings for model referencing”

“Check safety-related model referencing settings”

“Check safety-related code generation settings”

“Check safety-related diagnostic settings for saving”

 

 

Applicable High-Integrity System Modeling

Guidelines

“hisl_0044: Configuration Parameters >

Diagnostics > Sample Time”

“hisl_0005: Usage of Product blocks”

 

“hisl_0302: Configuration Parameters >

Diagnostics > Data Validity > Parameters”

“hisl_0013: Usage of data store blocks”

“hisl_0309: Configuration Parameters >

Diagnostics > Type Conversion”

“hisl_0306: Configuration Parameters >

Diagnostics > Connectivity > Signals”

“hisl_0307: Configuration Parameters >

Diagnostics > Connectivity > Buses”

“hisl_0308: Configuration Parameters >

Diagnostics > Connectivity > Function calls”

“hisl_0301: Configuration Parameters >

Diagnostics > Compatibility”

“hisl_0304: Configuration Parameters

> Diagnostics > Data Validity > Model

Initialization”

 

“hisl_0310: Configuration Parameters >

Diagnostics > Model Referencing”

22-17

22

Checking Systems Interactively

DO-178C/DO-331 Check

 

Applicable High-Integrity System Modeling

Guidelines

“Check for blocks that do not link to requirements”

“Check state machine type of Stateflow charts”

“Check Stateflow charts for ordering of states and transitions”

“Check Stateflow debugging options”

“Check usage of lookup table blocks”

“Check for MATLAB Function interfaces with inherited properties”

“Check MATLAB Function metrics”

“hisf_0001: Mealy and Moore semantics”

“hisf_0002: User-specified state/transition execution order”

 

“hisf_0011: Stateflow debugging settings”

“himl_0002: Strong data typing at

MATLAB function boundaries”

“himl_0003: Limitation of MATLAB function complexity”

“Check MATLAB Code Analyzer messages” “himl_0004: MATLAB Code Analyzer recommendations for code generation”

“Check MATLAB code for global variables” “himl_0005: Usage of global variables in

MATLAB functions”

“Check for inconsistent vector indexing methods”

“Check for blocks not recommended for C/C

++ production code deployment”

“Check Stateflow charts for uniquely defined data objects”

 

“hisl_0021: Consistent vector indexing method”

“hisl_0061: Unique identifiers for clarity”

“Check usage of Math Operations blocks” • “hisl_0001: Usage of Abs block”

• “hisl_0002: Usage of Math Function blocks (rem and reciprocal)”

• “hisl_0004: Usage of Math Function blocks (natural logarithm and base 10 logarithm)”

• “hisl_0029: Usage of Assignment blocks”

“Check usage of Signal Routing blocks”  

22-18

Model Checks for DO-178C/DO-331 Standard Compliance

DO-178C/DO-331 Check

“Check usage of Logic and Bit Operations blocks”

“Check usage of Ports and Subsystems blocks”

“Display model version information”

Applicable High-Integrity System Modeling

Guidelines

• “hisl_0016: Usage of blocks that compute relational operators”

• “hisl_0017: Usage of blocks that compute relational operators (2)”

• “hisl_0018: Usage of Logical Operator block”

• “hisl_0006: Usage of While Iterator blocks”

• “hisl_0007: Usage of While Iterator subsystems”

 

• “hisl_0008: Usage of For Iterator

Blocks”

• “hisl_0009: Usage of For Iterator

Subsystem blocks”

22-19

22

Checking Systems Interactively

Model Checks for IEC 61508, ISO 26262, and EN 50128 Standard

Compliance

You can check that your model or subsystem complies with selected aspects of the following safety standards by running the Model Advisor:

• IEC 61508-3 Functional safety of electrical/electronic/programmable electronic safetyrelated systems - Part 3: Software requirements

• ISO 26262-6 Road vehicles - Functional safety - Part 6: Product development:

Software level

• EN 50128 Railway applications - Communications, signalling and processing systems

- Software for railway control and protection systems

To check compliance, run the checks in the applicable Model Advisor folders.

By Task > Modeling Standards for IEC 61508

By Task > Modeling Standards for ISO 26262

By Task > Modeling Standards for EN 50128

The table lists the IEC 61508, ISO 26262, and EN 50128 checks, with applicable “High-

Integrity System Modeling” guidelines.

IEC 61508, ISO 26262, and EN 50128 Checks Applicable High-Integrity System Modeling

Guidelines

“Display configuration management data”  

“Display model metrics and complexity report”

“Check for unconnected objects”  

 

“hisl_0024: Inport interface definition” “Check for root Inports with missing properties”

“Check for root Inports with missing range definitions”

“Check for root Outports with missing range definitions”

“Check for blocks not recommended for C/C

++ production code deployment”

 

“hisl_0025: Design min/max specification of input interfaces”

“hisl_0026: Design min/max specification of output interfaces”

22-20

Model Checks for IEC 61508, ISO 26262, and EN 50128 Standard Compliance

IEC 61508, ISO 26262, and EN 50128 Checks Applicable High-Integrity System Modeling

Guidelines

“Check usage of Stateflow constructs” • “hisf_0002: User-specified state/ transition execution order”

• “hisf_0009: Strong data typing

(Simulink and Stateflow boundary)”

• “hisf_0011: Stateflow debugging settings”

• “hisl_0061: Unique identifiers for clarity”

“Check state machine type of Stateflow charts”

“hisf_0001: Mealy and Moore semantics”

“Check usage of Math Operations blocks” • “hisl_0001: Usage of Abs block”

• “hisl_0029: Usage of Assignment blocks”

“Check usage of Signal Routing blocks”

“Check usage of Logic and Bit Operations blocks”

 

• “hisl_0016: Usage of blocks that compute relational operators”

• “hisl_0017: Usage of blocks that compute relational operators (2)”

• “hisl_0018: Usage of Logical Operator block”

“Check usage of Ports and Subsystems blocks”

“Check for inconsistent vector indexing methods”

“Check for model objects that do not link to requirements”

 

• “hisl_0006: Usage of While Iterator blocks”

• “hisl_0007: Usage of While Iterator subsystems”

• “hisl_0008: Usage of For Iterator

Blocks”

• “hisl_0009: Usage of For Iterator

Subsystem blocks”

“hisl_0021: Consistent vector indexing method”

22-21

22

Checking Systems Interactively

IEC 61508, ISO 26262, and EN 50128 Checks Applicable High-Integrity System Modeling

Guidelines

“Check for MATLAB Function interfaces with inherited properties”

“himl_0002: Strong data typing at

MATLAB function boundaries”

“Check MATLAB Function metrics” “himl_0003: Limitation of MATLAB function complexity”

“Check MATLAB Code Analyzer messages” “himl_0004: MATLAB Code Analyzer recommendations for code generation”

“Check MATLAB code for global variables” “himl_0005: Usage of global variables in

MATLAB functions”

22-22

Model Checks for MathWorks Automotive Advisory Board (MAAB) Guideline Compliance

Model Checks for MathWorks Automotive Advisory Board (MAAB)

Guideline Compliance

You can check that your model or subsystem complies with MathWorks Automotive

Advisory Board (MAAB) guidelines by running the Model Advisor. Navigate to By Task

> Modeling Standards for MAAB and run the checks.

The MAAB involves major automotive OEMs and suppliers in the process of evolving

MathWorks controls, simulation, and code generation products, including Simulink,

Stateflow, and Simulink Coder. An important result of the MAAB has been the “MAAB

Control Algorithm Modeling” guidelines.

The table lists the MAAB checks, with applicable MAAB Control Algorithm Modeling guidelines.

By Task >

Modeling

Standards for

MAAB subfolder

Naming

Conventions

MathWorks Automotive Advisory

Board (MAAB) Check

“Check file names”

“Check folder names”

“Check subsystem names”

“Check port block names”

Model

Architecture

Model

Configuration

Options

“Check character usage in signal labels”

“Check character usage in block names”

“Check for mixing basic blocks and subsystems”

“Check Implement logic signals as

Boolean data (vs. double)”

“Check model diagnostic parameters”

MAAB Control Algorithm Modeling

Guidelines, Version 3.0

ar_0001: Filenames ar_0002: Directory names jc_0201: Usable characters for

Subsystem names jc_0211: Usable characters for

Inport blocks and Outport blocks jc_0221: Usable characters for signal line names jc_0231: Usable characters for block names db_0143: Similar block types on the model levels jc_0011: Optimization parameters for Boolean data types jc_0021: Model diagnostic settings

22-23

22

Checking Systems Interactively

22-24

By Task >

Modeling

Standards for

MAAB subfolder

Simulink

MathWorks Automotive Advisory

Board (MAAB) Check

“Check for Simulink diagrams using nonstandard display attributes”

“Check font formatting”

MAAB Control Algorithm Modeling

Guidelines, Version 3.0

na_0004: Simulink model appearance

“Check positioning and configuration of ports”

“Check visibility of block port names”

“Check display for port blocks”

“Check whether block names appear below blocks”

“Check the display attributes of block names”

“Check position of Trigger and

Enable blocks”

“Check for nondefault block attributes”

“Check for matching port and signal names”

“Check Trigger and Enable block names”

“Check signal line labels”

“Check for propagated signal labels”

“Check for unconnected ports and signal lines”

“Check for prohibited blocks in discrete controllers” db_0043: Simulink font and font size db_0042: Port block in Simulink models na_0005: Port block name visibility in Simulink models jc_0081: Icon display for Port block db_0142: Position of block names jc_0061: Display of block names db_0146: Triggered, enabled, conditional Subsystems db_0140: Display of basic block parameters jm_0010: Port block names in

Simulink models jc_0281: Naming of Trigger Port block and Enable Port block na_0008: Display of labels on signals na_0009: Entry versus propagation of signal labels db_0081: Unconnected signals, block inputs and block outputs jm_0001: Prohibited Simulink standard blocks inside controllers

Model Checks for MathWorks Automotive Advisory Board (MAAB) Guideline Compliance

By Task >

Modeling

Standards for

MAAB subfolder

MathWorks Automotive Advisory

Board (MAAB) Check

Stateflow

MAAB Control Algorithm Modeling

Guidelines, Version 3.0

“Check for blocks not recommended for C/C++ production code deployment”

 

“Check for prohibited sink blocks” hd_0001: Prohibited Simulink sinks

“Check scope of From and Goto blocks” na_0011: Scope of Goto and From blocks

“Check usage of Switch blocks”

“Check usage of Relational

Operator blocks”

“Check for indexing in blocks”

“Check usage of buses and Mux blocks” jc_0141: Use of the Switch block jc_0131: Use of Relational Operator block db_0112: Indexing na_0010: Grouping data flows into signals db_0110: Tunable parameters in basic blocks jc_0111: Direction of Subsystem

“Check usage of tunable parameters in blocks”

“Check orientation of Subsystem blocks”

“Check usage of exclusive and default states in state machines”

“Check Transition orientations in flow charts”

“Check entry formatting in State blocks in Stateflow charts”

“Check return value assignments of graphical functions in Stateflow charts”

“Check default transition placement in Stateflow charts”

“Check for Strong Data Typing with Simulink I/O” db_0137: States in state machines db_0132: Transitions in flow charts jc_0501: Format of entries in a

State block jc_0511: Setting the return value from a graphical function jc_0531: Placement of the default transition db_0122: Stateflow and Simulink interface signals and parameters

22-25

22

Checking Systems Interactively

By Task >

Modeling

Standards for

MAAB subfolder

MathWorks Automotive Advisory

Board (MAAB) Check

MATLAB

Functions and Code

MAAB Control Algorithm Modeling

Guidelines, Version 3.0

“Check Stateflow data objects with local scope”

“Check usage of return values from a graphical function in

Stateflow charts”

“Check for MATLAB expressions in Stateflow charts”

“Check for pointers in Stateflow charts”

“Check for event broadcasts in

Stateflow charts”

“Check transition actions in

Stateflow charts”

“Check for bitwise operations in

Stateflow charts”

“Check for unary minus operations on unsigned integers in

Stateflow charts”

“Check for comparison operations in Stateflow charts”

“Check for equality operations between floating-point expressions in Stateflow charts”

“Check for mismatches between names of Stateflow ports and associated signals”

“Check input and output settings of MATLAB Functions” db_0125: Scope of internal signals and local auxiliary variables jc_0521: Use of the return value from graphical functions db_0127: MATLAB commands in

Stateflow jm_0011: Pointers in Stateflow jm_0012: Event broadcasts db_0151: State machine patterns for transition actions na_0001: Bitwise Stateflow operators jc_0451: Use of unary minus on unsigned integers in Stateflow na_0013: Comparison operation in

Stateflow jc_0481: Use of hard equality comparisons for floating point numbers in Stateflow db_0123: Stateflow port names na_0034: MATLAB Function block input/output settings

22-26

Model Checks for MathWorks Automotive Advisory Board (MAAB) Guideline Compliance

By Task >

Modeling

Standards for

MAAB subfolder

MathWorks Automotive Advisory

Board (MAAB) Check

“Check MATLAB Function metrics”

“Check MATLAB code for global variables”

MAAB Control Algorithm Modeling

Guidelines, Version 3.0

• na_0016: Source lines of

MATLAB Functions

• na_0018: Number of nested if/ else and case statement na_0024: Global Variables

22-27

22

Checking Systems Interactively

Model Checks for Requirements Links

To check that every requirements link in your model has a valid target in a requirements document, navigate to Analysis > Requirements Traceability > Check Consistency and run the Model Advisor checks:

• “Identify requirement links with missing documents”

• “Identify requirement links that specify invalid locations within documents”

• “Identify selection-based links having descriptions that do not match their requirements document text”

• “Identify requirement links with path type inconsistent with preferences”

For an example, see “Validate Requirements Links in a Model”.

22-28

23

Check Systems Programmatically

• “Checking Systems Programmatically” on page 23-2

• “Finding Check IDs” on page 23-3

• “Create a Function for Checking Multiple Systems” on page 23-4

• “Check Multiple Systems in Parallel” on page 23-6

• “Create a Function for Checking Multiple Systems in Parallel” on page 23-7

• “Archive and View Results” on page 23-9

• “Archive and View Model Advisor Run Results” on page 23-13

23

Check Systems Programmatically

Checking Systems Programmatically

The Simulink Verification and Validation product includes a programmable interface for scripting and for command-line interaction with the Model Advisor. Using this interface, you can:

• Create scripts and functions for distribution that check one or more systems using the

Model Advisor.

• Run the Model Advisor on multiple systems in parallel on multicore machines

(requires a Parallel Computing Toolbox™ license).

• Check one or more systems using the Model Advisor from the command line.

• Archive results for reviewing at a later time.

To define the workflow for running multiple checks on systems:

1 Specify a list of checks to run. Do one of the following:

• Create a Model Advisor configuration file that includes only the checks that you

want to run. For more information, see “Organize Checks and Folders Using the

Model Advisor Configuration Editor” on page 26-5.

• Create a list of check IDs. For more information on finding check IDs, see

“Finding Check IDs” on page 23-3.

2 Specify a list of systems to check.

3 Run the Model Advisor checks on the list of systems using the ModelAdvisor.run

function.

4

Archive and review the results of the run. For details, see “Archive and View

Results” on page 23-9.

23-2

Finding Check IDs

Finding Check IDs

An ID is a unique string that identifies a Model Advisor check. You find check IDs in the

Model Advisor, using check context menus.

To Find...

Check Title, ID, or location of the MATLAB source code

Check ID

Check IDs for selected checks in a folder

Do This...

1 On the model window toolbar, select Settings > Preferences.

2 In the Model Advisor Preferences dialog box, select Show Source

Tab.

3 In the right pane of the Model Advisor window, click the Source tab. The Model Advisor window displays the check Title, TitleId, and location of the MATLAB source code for the check.

1

In the left pane of the Model Advisor, select the check.

2

Right-click the check name and select Send Check ID to

Workspace. The ID is displayed in the Command Window and sent to the base workspace.

1

In the left pane of the Model Advisor, select the checks for which you want IDs. Clear the other checks in the folder.

2

Right-click the folder and select Send Check ID to Workspace.

An array of the selected check IDs are sent to the base workspace.

If you know a check ID from a previous release, you can find the current check ID using the ModelAdvisor.lookupCheckID function. For example, the check ID for

By Product > Simulink Verification and Validation > Modeling Standards >

DO-178C/DO-331 Checks > Check safety-related optimization settings prior to

Release 2010b was DO178B:OptionSet. Using the ModelAdvisor.lookupCheckID

function returns:

>> NewID = ModelAdvisor.lookupCheckID('DO178B:OptionSet')

NewID = mathworks.do178.OptionSet

Note: If the By Product folder is not displayed in the Model Advisor window, select

Show By Product Folder from the Settings > Preferences dialog box.

23-3

23

Check Systems Programmatically

Create a Function for Checking Multiple Systems

The following tutorial guides you through creating and testing a function to run multiple checks on any model. The function returns the number of failures and warnings.

1 In the MATLAB window, select New > Function.

2 Save the function as run_configuration.m.

3 In the MATLAB Editor, specify [output_args] as [fail, warn].

4 Rename the function run_configuration.

5 Specify input_args to SysList.

6

Inside the function, specify the list of checks to run using the example Model Advisor configuration file: fileName = 'slvnvdemo_mdladv_config.mat';

7 Call the ModelAdvisor.run function:

SysResultObjArray = ModelAdvisor.run(SysList,'Configuration',fileName);

8

Determine the number of checks that return warnings and failures: fail=0; warn=0; for i=1:length(SysResultObjArray)

fail = fail + SysResultObjArray{i}.numFail;

warn = warn + SysResultObjArray{i}.numWarn; end

The function should now look like this: function [fail, warn] = run_configuration( SysList)

%RUN_CONFIGURATION Check systems with Model Advsior

% Check systems given as input and return number of warnings and

% failures.

fileName = 'slvnvdemo_mdladv_config.mat' ; fail=0; warn=0;

SysResultObjArray = ModelAdvisor.run(SysList, 'Configuration' ,fileName); for i=1:length(SysResultObjArray)

fail = fail + SysResultObjArray{i}.numFail;

warn = warn + SysResultObjArray{i}.numWarn; end end

23-4

Create a Function for Checking Multiple Systems

9 Save the function.

10 Test the function. In the MATLAB Command Window, run run_configuration.m

on the sldemo_auto_climatecontrol/Heater Control subsystem:

[failures, warnings] = run_configuration(...

'sldemo_auto_climatecontrol/Heater Control');

11 Review the results. Click the Summary Report link to open the Model Advisor

Command-Line Summary report.

23-5

23

Check Systems Programmatically

Check Multiple Systems in Parallel

Checking multiple systems in parallel reduces the processing time required by the Model

Advisor to check multiple systems. If you have a Parallel Computing Toolbox license, you can check multiple systems in parallel on a multicore host machine. To enable parallel processing, use the ModelAdvisor.run function with ‘ParallelMode’ set to ‘On’.

By default, ‘ParallelMode’ is set to ‘Off’. When you use ModelAdvisor.run with

‘ParallelMode’

set to ‘On’, MATLAB automatically creates a parallel pool. For an

example, see “Create a Function for Checking Multiple Systems in Parallel” on page

23-7.

23-6

Create a Function for Checking Multiple Systems in Parallel

Create a Function for Checking Multiple Systems in Parallel

If you have a Parallel Computing Toolbox license and a multicore host machine, you can create the following function to check multiple systems in parallel:

1

Create the run_configuration function as described in “Create a Function for

Checking Multiple Systems” on page 23-4.

2 Save the function as run_fast_configuration.m.

3 In the Editor, change the name of the function to run_fast_configuration.

4 Add another input to the run_fast_configuration function so that the inputs are now:

SysList, numParallel

5 In the ModelAdvisor.run function, set 'ParallelMode' to 'On' . When you use

ModelAdvisor.run

with ‘ParallelMode’ set to ‘On’, MATLAB automatically creates a parallel pool.

SysResultObjArray = ModelAdvisor.run(SysList,'Configuration',fileName,...

'ParallelMode','On');

The function should now look like this: function [fail, warn] = run_fast_configuration(SysList, numParallel)

%RUN_FAST_CONFIGURATION Check systems in parallel with Model Advisor

% Check systems given as input in parallel on the number of cores

% specified as input. Return number of warnings and failures.

fileName = 'slvnvdemo_mdladv_config.mat' ; fail=0; warn=0;

SysResultObjArray = ModelAdvisor.run(SysList, 'Configuration' ,fileName, ...

'ParallelMode' , 'On' ); for i=1:length(SysResultObjArray)

fail = fail + SysResultObjArray{i}.numFail;

warn = warn + SysResultObjArray{i}.numWarn; end end

6

Save the function.

7 Test the function. In the MATLAB Command Window, create a list of systems:

SysList={'sldemo_auto_climatecontrol/Heater Control',...

'sldemo_auto_climatecontrol/AC Control', 'rtwdemo_iec61508'};

23-7

23

Check Systems Programmatically

8 Run run_fast_configuration on the list of systems, specifying numParallel to be the number of cores in your system. For example, the following command specifies two cores:

% Run on 2 cores

[failures, warnings] = run_fast_configuration(SysList, 2);

9 Review the results. Click the Summary Report link to open the Model Advisor

Command-Line Summary report.

23-8

Archive and View Results

Archive and View Results

You can archive and view the results of running the Model Advisor programmatically as described in the following sections:

In this section...

“Archive Results” on page 23-9

“View Results in Command Window” on page 23-9

“View Results in Model Advisor Command-Line Summary Report” on page 23-10

“View Results in Model Advisor GUI” on page 23-11

“View Model Advisor Report” on page 23-12

Archive Results

After you run the Model Advisor programmatically, you can archive the results for use at another time. The ModelAdvisor.run function returns a cell array of

ModelAdvisor.SystemResult

objects, one for each system run. If you save the objects, you can use them to view the results at a later time without rerunning the Model

Advisor. For details, see “Save and Load Process”.

For an example of archiving results, see “Archive and View Model Advisor Run Results” on page 23-13.

View Results in Command Window

When you run the Model Advisor programmatically, the system-level results of the run are displayed in the Command Window. For example, when you run the function that

you created in “Create a Function for Checking Multiple Systems” on page 23-4, the

following results are displayed:

Systems passed: 0 of 1

Systems with warnings: 1 of 1

Systems failed: 0 of 1

Summary Report

The Summary Report link provides access to the Model Advisor Command-Line

Summary report (see “View Results in Model Advisor Command-Line Summary Report” on page 23-10).

23-9

23

Check Systems Programmatically

You can review additional results in the Command Window by calling the

DisplayResults

parameter when you run the Model Advisor. For example, run the

Model Advisor as follows:

SysResultObjArray = ModelAdvisor.run('sldemo_auto_climatecontrol/Heater Control',...

'Configuration','slvnvdemo_mdladv_config.mat','DisplayResults','Details');

The results displayed in the Command Window are:

Running Model Advisor

Running Model Advisor on sldemo_auto_climatecontrol/Heater Control

============================================================

Model Advisor run: 29-Oct-2012 16:30:00

Configuration: slvnvdemo_mdladv_config.mat

System: sldemo_auto_climatecontrol/Heater Control

System version: 8.1

Created by: The MathWorks Inc.

============================================================

(1) Warning: Check model diagnostic parameters [check ID: mathworks.maab.jc_0021]

------------------------------------------------------------

(2) Warning: Check for fully defined interface [check ID: mathworks.iec61508.RootLevelInports]

------------------------------------------------------------

(3) Pass: Check for unconnected objects [check ID: mathworks.iec61508.UnconnectedObjects]

------------------------------------------------------------

(4) Pass: Check for blocks not recommended for C/C++ production code deployment

[check ID: mathworks.iec61508.PCGSupport]

------------------------------------------------------------

Summary: Pass Warning Fail Not Run

2 2 0 0

============================================================

Systems passed: 0 of 1

Systems with warnings: 1 of 1

Systems failed: 0 of 1

Summary Report

To display the results in the Command Window after loading an object, use the viewReport

function.

View Results in Model Advisor Command-Line Summary Report

When you run the Model Advisor programmatically, a Summary Report link is displayed in the Command Window. Clicking this link opens the Model Advisor Command-Line

Summary report. The following graphic is the report that the Model Advisor generates for run_configuration.

23-10

Archive and View Results

To view the Model Advisor Command-Line Summary report after loading an object, use the ModelAdvisor.summaryReport function.

View Results in Model Advisor GUI

In the Model Advisor window, you can view the results of running the Model Advisor programmatically using the viewReport function. In the Model Advisor window, you can review results, run checks, fix warnings and failures, and view and save Model

Advisor reports. For more information, see “Run Model Checks”.

Tip To fix warnings and failures, you must rerun the check in the Model Advisor window.

23-11

23

Check Systems Programmatically

View Model Advisor Report

For a single system or check, you can view the same Model Advisor report that you access from the Model Advisor GUI.

To view the Model Advisor report for a system:

• Open the Model Advisor Command-Line Summary report. In the Systems Run table, click the link for the Model Advisor report.

• Use the viewReport function.

To view individual check results:

• In the Command Window, generate a detailed report using the viewReport function with the DisplayResults parameter set to Details, and then click the Pass,

Warning, or Fail link for the check. The Model Advisor report for the check opens.

• Use the view function.

23-12

Archive and View Model Advisor Run Results

Archive and View Model Advisor Run Results

The following example guides you through archiving the results of running checks so that you can review them at a later time. To simulate archiving and reviewing, the steps in the tutorial detail how to save the results, clear out the MATLAB workspace (simulates shutting down MATLAB), and then load and review the results.

1 Call the ModelAdvisor.run function:

SysResultObjArray = ModelAdvisor.run({'sldemo_auto_climatecontrol/Heater Control'},...

'Configuration','slvnvdemo_mdladv_config.mat');

2 Save the SystResulObj for use at a later time: save my_model_advisor_run SysResultObjArray

3 Clear the workspace to simulate viewing the results at a different time: clear

4 Load the results of the Model Advisor run: load my_model_advisor_run SysResultObjArray

5

View the results in the Model Advisor: viewReport(SysResultObjArray{1},'MA')

23-13

Customizing the Model Advisor

24

Overview of Customizing the Model

Advisor

24

Overview of Customizing the Model Advisor

Model Advisor Customization

Using Model Advisor APIs and the Model Advisor Configuration Editor, you can:

• Create your own Model Advisor checks.

• Create custom configurations.

• Specify the order in which you make changes to your model.

• Create multiple custom configurations for different projects or modeling guidelines, and switch between these configurations in the Model Advisor.

• Deploy custom configurations to your users.

To

Create Model Advisor checks.

Format check results.

See

“Create Model Advisor Checks”

“Format Model Advisor Checks”

Create custom Model Advisor configurations.

Specify the order in which you make changes to your model.

“Organize and Deploy Model Advisor

Checks”

“Organize and Deploy Model Advisor

Checks”

Deploy custom configurations to your users. “Organize and Deploy Model Advisor

Checks”

Verify that models comply with modeling guidelines.

“Check Model Compliance”

Requirements for Customizing the Model Advisor

Before customizing the Model Advisor:

• If you want to create checks, know how to create a MATLAB script. For more information, see “Create Scripts” in the MATLAB documentation.

• Understand how to access model constructs that you want to check. For example, know how to find block and model parameters. For more information on using utilities

for creating check callbacks, see “Common Utilities for Authoring Checks” on page

25-37.

24-2

Create Model Advisor Checks

• “Create Model Advisor Checks Workflow” on page 25-2

• “Customization File Overview” on page 25-3

• “Quick Start Examples” on page 25-6

• “Create Check for Model Configuration Parameters” on page 25-16

• “Register Checks and Process Callbacks” on page 25-27

• “Define Custom Checks” on page 25-30

• “Create Callback Functions and Results” on page 25-37

• “Exclude Blocks From Custom Checks” on page 25-49

• “Model Advisor Code Examples” on page 25-52

25

25

Create Model Advisor Checks

Create Model Advisor Checks Workflow

1 On your MATLAB path, create a customization file named sl_customization.m.

In this file, create a sl_customization() function to register the custom checks that you create and optional process callbacks with the Model Advisor. For detailed

information, see “Register Checks and Process Callbacks” on page 25-27.

2

Define custom checks and where they appear in the Model Advisor. For detailed

information, see “Define Custom Checks” on page 25-30.

3

Specify what actions you want the Model Advisor to take for the custom checks by creating a check callback function for each custom check. For detailed information,

see “Create Callback Functions and Results” on page 25-37.

4

Optionally, specify what automatic fix operations the Model Advisor performs by

creating an action callback function. For detailed information, see “Action Callback

Function” on page 25-43.

5

Optionally, specify startup and post-execution actions by creating a process callback

function. For detailed information, see “Define Startup and Post-Execution Actions

Using Process Callback Functions” on page 25-28.

25-2

Customization File Overview

Customization File Overview

A customization file is a MATLAB file that you create and name sl_customization.m.

The sl_customization.m file contains a set of functions for registering and defining custom checks, tasks, and groups. To set up the sl_customization.m file, follow the guidelines in this table.

Function sl_customization()

Description

Registers custom checks, tasks, folders, and callbacks with the Simulink customization manager at startup (see

“Register Checks and Process

Callbacks” on page 25-27).

One or more check definitions Defines custom checks (see

“Define Custom Checks” on page 25-30).

When Required

Required for customizations to the Model Advisor.

Required for custom checks and to add custom checks to the By

Product folder.

Check callback functions

If the By Product folder is not displayed in the Model

Advisor window, select Show

By Product Folder from the

Settings > Preferences dialog box.

Required for custom checks. You must write one callback function for each custom check.

One or more calls to check input parameters

One or more calls to check list views

Defines the actions of the

custom checks (see “Create

Callback Functions and

Results” on page 25-37).

Specifies input parameters

to custom checks (see “Define

Check Input Parameters” on page 25-34).

Specifies calls to the Model

Advisor Result Explorer for

custom checks (see “Define

Model Advisor Result Explorer

Views” on page 25-35).

Optional.

Optional.

25-3

25

Create Model Advisor Checks

Function

One or more calls to check actions

Description

Specifies actions the software performs for custom checks (see

“Define Check Actions” on page

25-36 and “Action Callback

Function” on page 25-43).

One process callback function Specifies actions to be performed at startup and post-

execution time (see “Define

Startup and Post-Execution

Actions Using Process Callback

Functions” on page 25-28).

When Required

Optional.

Optional.

The following is an example of a custom configuration of the Model Advisor that has custom checks defined in custom folders and procedures. The selected check includes input parameters, list view parameters, and actions.

25-4

Customization File Overview

25-5

25

Create Model Advisor Checks

Quick Start Examples

In this section...

“Add Customized Check to By Product Folder” on page 25-6

“Create Customized Pass/Fail Check” on page 25-7

“Create Customized Pass/Fail Check with Fix Action” on page 25-11

Add Customized Check to By Product Folder

The following example shows how to add a customized check to a Model Advisor By

Product > Demo subfolder. In this example, the customized check does not check model elements.

1

In your working directory, create the sl_customization.m file, as shown below. This file registers and creates the check registration function defineModelAdvisorChecks

, which in turn registers the check callback function SimpleCallback. The function defineModelAdvisorChecks uses a

ModelAdvisor.Root

object to define the check interface.

function sl_customization(cm)

% --- register custom checks cm.addModelAdvisorCheckFcn(@defineModelAdvisorChecks);

% --- defineModelAdvisorChecks function function defineModelAdvisorChecks mdladvRoot = ModelAdvisor.Root; rec = ModelAdvisor.Check('exampleCheck'); rec.Title = 'Example of a customized check'; rec.TitleTips = 'Added customized check to Product Folder'; rec.setCallbackFcn(@SimpleCallback,'None','StyleOne'); mdladvRoot.publish(rec, 'Demo');

% --- creates SimpleCallback function function result = SimpleCallback(system); result={};

2 Close the Model Advisor and your model if either are open.

3 In the Command Window, enter: sl_refresh_customizations

4 From the MATLAB window, select New > Model to open a new Simulink model window.

25-6

Quick Start Examples

5 From the model window, select Analysis > Model Advisor > Model Advisor to open the Model Advisor.

6 A System Selector — Model Advisor dialog box opens. Click OK. The Model

Advisor window opens. It might take a few minutes.

7 If the By Product folder is not displayed in the Model Advisor window, select Show

By Product Folder from the Settings > Preferences dialog box.

8 In the left pane, expand the By Product folder to display the subfolders.

The customized check Example of a customized check appears in the By

Product > Demo subfolder.

See Also

• “Register Checks and Process Callbacks”

Create Customized Pass/Fail Check

The following example shows how to create a Model Advisor pass/fail check. In this example, the Model Advisor checks Constant blocks. If a Constant blocks value is numeric, the check fails.

25-7

25

Create Model Advisor Checks

1 In your working directory, update the sl_customization.m file, as shown below. This file registers and creates the check registration function defineModelAdvisorChecks

, which also registers the check callback function

SimpleCallback

. The function SimpleCallback creates a check that finds

Constant blocks that have numeric values. SimpleCallback uses the Model

Advisor format template.

function sl_customization(cm)

% --- register custom checks cm.addModelAdvisorCheckFcn(@defineModelAdvisorChecks);

% --- defineModelAdvisorChecks function function defineModelAdvisorChecks mdladvRoot = ModelAdvisor.Root; rec = ModelAdvisor.Check('exampleCheck'); rec.Title = 'Check Constant block usage'; rec.TitleTips = ['Fail if Constant block value is a number; Pass if' ...

' Constant block value is a letter']; rec.setCallbackFcn(@SimpleCallback,'None','StyleOne') mdladvRoot.publish(rec, 'Demo');

% --- SimpleCallback function that checks constant blocks function result = SimpleCallback(system) mdladvObj = Simulink.ModelAdvisor.getModelAdvisor(system); result = {}; all_constant_blk=find_system(system,'LookUnderMasks','all',...

'FollowLinks','on','BlockType','Constant'); blk_with_value=find_system(all_constant_blk,'RegExp','On','Value','^[0-9]'); ft = ModelAdvisor.FormatTemplate('ListTemplate'); ft.setInformation(['This check looks for constant blocks that'...

'use numeric values']); if ~isempty(blk_with_value)

ft.setSubResultStatusText(['Check has failed. The following '...

'Constant blocks have numeric values:']);

ft.setListObj(blk_with_value);

ft.setSubResultStatus('warn');

ft.setRecAction('Parameterize the constant block');

mdladvObj.setCheckResultStatus(false); else

ft.setSubResultStatusText(['Check has passed. No constant blocks'...

' with numeric values were found.']);

ft.setSubResultStatus('pass');

mdladvObj.setCheckResultStatus(true); end ft.setSubBar(0); result{end+1} = ft;

2

Close the Model Advisor and your model if either are open.

25-8

Quick Start Examples

3 It the Command Window, enter: sl_refresh_customizations

4 From the MATLAB window, select New > Model to open a new Simulink model window.

5 In the Simulink model window, create two Constant blocks named Const_One and

Const_1:

• Right-click the Const_One block, choose Constant Parameters, and assign a

Constant value of one.

• Right-click the Const_1 block, choose Constant Parameters, and assign a

Constant value of 1.

• Save your model as example2_qs

6

From the model window, select Analysis > Model Advisor > Model Advisor to open the Model Advisor.

7 A System Selector — Model Advisor dialog box opens. Click OK. The Model

Advisor window opens. It might take a few minutes.

8

If the By Product folder is not displayed in the Model Advisor window, select Show

By Product Folder from the Settings > Preferences dialog box.

9 In the left pane, click By Product > Demo > Check Constant block usage.

10

Click Run This Check. The Model Advisor check fails for the Const_1 block and displays a Recommended Action to parametrize the constant block.

25-9

25

Create Model Advisor Checks

25-10

11 Follow the Recommended Action to fix the failed Constant block. In the Model

Advisor dialog box:

• Double-click the example2_qs/Const_1 hyperlink.

• Change Constant Parameters > Constant value to two, or a nonnumeric value.

• Rerun the Model Advisor check. Both Constant blocks now pass the check.

See Also

• “Register Checks and Process Callbacks”

• ModelAdvisor.FormatTemplate class

Quick Start Examples

Create Customized Pass/Fail Check with Fix Action

The following example shows how to create a Model Advisor pass/fail check with a fix action. In this example, the Model Advisor checks Constant blocks. If a Constant block value is numeric, the check fails. The Model Advisor is also customized to create a fix action for the failed checks.

1 In your working directory, update the sl_customization.m file, as shown below.

This file contains three functions, each of which use the Model Advisor format template:

• defineModelAdvisorChecks — Defines the check, creates input parameters, and defines the fix action.

• simpleCallback — Creates the check that finds Constant blocks with numeric values.

• simpleActionCallback — Creates the fix for Constant blocks that fail the check.

function sl_customization(cm)

% --- register custom checks cm.addModelAdvisorCheckFcn(@defineModelAdvisorChecks);

% --- defineModelAdvisorChecks function function defineModelAdvisorChecks mdladvRoot = ModelAdvisor.Root; rec = ModelAdvisor.Check('exampleCheck'); rec.Title = 'Check Constant block usage'; rec.TitleTips = ['Fail if Constant block value is a number; Pass if '...

'Constant block value is a letter']; rec.setCallbackFcn(@SimpleCallback,'None','StyleOne')

% --- input parameters rec.setInputParametersLayoutGrid([1 1]); inputParam1 = ModelAdvisor.InputParameter; inputParam1.Name = 'Text entry example'; inputParam1.Value='VarNm'; inputParam1.Type='String'; inputParam1.Description='sample tooltip'; inputParam1.setRowSpan([1 1]); inputParam1.setColSpan([1 1]); rec.setInputParameters({inputParam1});

% -- set fix operation myAction = ModelAdvisor.Action; myAction.setCallbackFcn(@simpleActionCallback); myAction.Name='Fix Constant blocks'; myAction.Description=['Click the button to update all blocks with'...

25-11

25

Create Model Advisor Checks

'Text entry example']; rec.setAction(myAction); mdladvRoot.publish(rec, 'Demo');

% --- SimpleCallback function that checks constant blocks function result = SimpleCallback(system) mdladvObj = Simulink.ModelAdvisor.getModelAdvisor(system); result = {}; all_constant_blk=find_system(system,'LookUnderMasks','all',...

'FollowLinks','on','BlockType','Constant'); blk_with_value=find_system(all_constant_blk,'RegExp','On','Value','^[0-9]'); ft = ModelAdvisor.FormatTemplate('ListTemplate'); ft.setInformation(['This check looks for constant blocks that'...

' use numeric values']); if ~isempty(blk_with_value)

ft.setSubResultStatusText(['Check has failed. The following '...

'Constant blocks have numeric values:']);

ft.setListObj(blk_with_value);

ft.setSubResultStatus('warn');

ft.setRecAction('Parameterize the constant block');

mdladvObj.setCheckResultStatus(false);

mdladvObj.setActionEnable(true); else

ft.setSubResultStatusText(['Check has passed. No constant blocks'...

'with numeric values were found.']);

ft.setSubResultStatus('pass');

mdladvObj.setCheckResultStatus(true); end ft.setSubBar(0); result{end+1} = ft;

% --- creates SimpleActionCallback function that fixes failed check function result = simpleActionCallback(taskobj) mdladvObj = taskobj.MAObj; result = {}; system = getfullname(mdladvObj.System);

% Get the string from the input parameter box.

inputParams = mdladvObj.getInputParameters; textEntryEx = inputParams{1}.Value; all_constant_blk=find_system(system,'LookUnderMasks','all',...

'FollowLinks','on','BlockType','Constant'); blk_with_value=find_system(all_constant_blk,'RegExp','On','Value','^[0-9]'); ft = ModelAdvisor.FormatTemplate('TableTemplate');

% Define table col titles ft.setColTitles({'Block','Old Value','New Value'}) for inx=1:size(blk_with_value)

oldVal = get_param(blk_with_value{inx},'Value');

ft.addRow({blk_with_value{inx},oldVal,textEntryEx});

set_param(blk_with_value{inx},'Value',textEntryEx);

25-12

Quick Start Examples end ft.setSubBar(0); result = ft; mdladvObj.setActionEnable(false);

2 Close the Model Advisor and your model if either are open.

3 At the command prompt, enter: sl_refresh_customizations

4

From the Command Window, select New > Model to open a new model.

5 In the Simulink model window, create two Constant blocks named Const_One and

Const_1:

• Right-click the Const_One block, choose Constant Parameters, and assign a

Constant value of one.

• Right-click the Const_1 block, choose Constant Parameters, and assign a

Constant value of 1.

• Save your model as example3_qs.

6 From the model window, select Analysis > Model Advisor > Model Advisor to open the Model Advisor.

7

A System Selector — Model Advisor dialog box opens. Click OK. The Model

Advisor window opens. It might take a few minutes.

8 If the By Product folder is not displayed in the Model Advisor window, select Show

By Product Folder from the Settings > Preferences dialog box.

9

In the left pane, click By Product > Demo > Check Constant block usage.

10 Click Run This Check. The Model Advisor check fails for the Const_1 block. The

Model Advisor box has a Fix Constant blocks button in the Action section of the

Model Advisor dialog box.

25-13

25

Create Model Advisor Checks

25-14

11 In the Model Advisor Dialog box, enter a nonnumeric value in the Text entry

example parameter field in the Analysis section of the Model Advisor dialog box. In this example, the value is VarNm.

12

Click Fix Constant blocks. The Const_1 Constant block value changes from 1 to the nonnumeric value that you entered in step 10. The Result section of the dialog box lists the Old Value and New Value of the Const_1 block.

Quick Start Examples

13 In the Model Advisor dialog box, click Run This Check. Both constant blocks now pass the check.

See Also

• “Register Checks and Process Callbacks”

• ModelAdvisor.FormatTemplate class

• “Define Check Input Parameters” to add input parameters to Model Advisor checks

• ModelAdvisor.Action class to add fix actions to Model Advisor checks

25-15

25

Create Model Advisor Checks

Create Check for Model Configuration Parameters

In this section...

“Create Data File for Diagnostics Pane Configuration Parameter Check” on page

25-17

“Create Check for Diagnostics Pane Model Configuration Parameters” on page 25-19

“Data File for Configuration Parameter Check” on page 25-22

To verify the configuration parameters for your model, you can create a configuration parameter check.

Decide which configuration parameter settings to use for your model. For information, see:

• MathWorks Automotive Advisory Board (MAAB) Control Algorithm Modeling

Guideline “Model Configuration Options”.

• High-Integrity System Modeling Guideline “Configuration Parameter

Considerations”.

• Code Generation Guideline “Configuration Parameter Considerations”.

• “Configuring Model Parameters” in the Simulink Coder documentation.

• “Configuring Model Parameters” in the Embedded Coder documentation.

1 Create an XML data file containing the configuration parameter settings you want to check. You can use

Advisor.authoring.generateConfigurationParameterDataFile

or

manually create the file yourself. For an example, see “Create Data File for

Diagnostics Pane Configuration Parameter Check” on page 25-17.

2 Register the model configuration parameter check using an sl_customization.m

file. For an example, see “Create Check for Diagnostics Pane Model Configuration

Parameters” on page 25-19.

3

Run the check on your models.

After you create the check, you can deploy the check as described in “Organize and

Deploy Model Advisor Checks”.

25-16

Create Check for Model Configuration Parameters

Create Data File for Diagnostics Pane Configuration Parameter Check

This example shows how to create a data file for Diagnostics pane model configuration parameter check that warns when:

Algebraic loop is set to none

Minimize algebraic loop is not set to error

Block Priority Violation is not set to error

In the example, to create the data file, you use the

Advisor.authoring.generateConfigurationParameterDataFile

function.

1 At the command prompt, type vdp.

2 In the model window, select Simulation > Model Configuration Parameters. In the Diagnostics pane, set the configuration parameters as follows:

Algebraic loop to none

Minimize algebraic loop to error

Block Priority Violation to error

3 Use Advisor.authoring.generateConfigurationParameterDataFile to create a data file specifying configuration parameter constraints in the Diagnostics pane. Additionally, to create a check with a fix action, set FixValue to true. At the command prompt, type: model=’vdp’; dataFileName = ’ex_DataFile.xml’;

Advisor.authoring.generateConfigurationParameterDataFile(dataFileName, ...

model, 'Pane' , 'Diagnostics' , 'FixValues' , true);

4 In the Command Window, select ex_DataFile.xml. The data file opens in the

MATLAB editor. For information about the data file syntax, see “Data File for

Configuration Parameter Check” on page 25-22.

• The Minimize algebraic loop (command-line:

ArtificialAlgebraicLoopMsg

) configuration parameter tagging specifies a value of error with a fixvalue of error. When you run the configuration parameter check using ex_DataFile.xml, the check fails if the Minimize

algebraic loop setting is not error. The check fix action modifies the setting to error

.

• The Block Priority Violation (command-line:BlockPriorityViolationMsg) configuration parameter tagging specifies a value of error with a

25-17

25

Create Model Advisor Checks

25-18 fixvalue

of error. When you run the configuration parameter check using ex_DataFile.xml

, the check fails if the Block Priority Violation setting is not error. The check fix action modifies the setting to error.

5

In ex_DataFile.xml, edit the Algebraic loop (commandline:AlgebraicLoopMsg) parameter tagging so that the check warns if the value is none. Because you are specifying a configuration parameter that you do not want, you need a NegativeModelParameterConstraint. Additionally, to create a subcheck that does not have a fix action, remove the line with <fixvalue> tagging.

The tagging for the configuration parameter looks as follows:

<!-- Algebraic loop: (AlgebraicLoopMsg)-->

<NegativeModelParameterConstraint>

<parameter>AlgebraicLoopMsg</parameter>

<value>none</value>

</NegativeModelParameterConstraint>

6 In ex_DataFile.xml, delete the lines with tagging for configuration parameters that you do not want to check. The data file ex_DataFile.xml has tagging only for Algebraic loop, Minimize algebraic loop and Block Priority Violation.

ex_DataFile.xml

looks similar to:

<?xml version="1.0" encoding="utf-8"?>

<customcheck xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.w3schools.com

MySchema.xsd">

<checkdata>

<!-- Algebraic loop: (AlgebraicLoopMsg)-->

<NegativeModelParameterConstraint>

<parameter>AlgebraicLoopMsg</parameter>

<value>none</value>

</NegativeModelParameterConstraint>

<!--Minimize algebraic loop: (ArtificialAlgebraicLoopMsg)-->

<PositiveModelParameterConstraint>

<parameter>ArtificialAlgebraicLoopMsg</parameter>

<value>error</value>

<fixvalue>error</fixvalue>

</PositiveModelParameterConstraint>

<!--Block priority violation: (BlockPriorityViolationMsg)-->

<PositiveModelParameterConstraint>

<parameter>BlockPriorityViolationMsg</parameter>

<value>error</value>

<fixvalue>error</fixvalue>

</PositiveModelParameterConstraint>

</checkdata>

Create Check for Model Configuration Parameters

</customcheck>

7 Verify the data syntax with Advisor.authoring.DataFile.validate. At the command prompt, type:

dataFile = 'myDataFile.xml' ;

msg = Advisor.authoring.DataFile.validate(dataFile); if isempty(msg)

disp( 'Data file passed the XSD schema validation.' ); else

disp(msg); end

Create Check for Diagnostics Pane Model Configuration Parameters

This example shows how to create a check for Diagnostics pane model configuration parameters using a data file and an sl_customization file. The check uses the ex_DataFile.xml

data file created in “Create Data File for Diagnostics Pane

Configuration Parameter Check” on page 25-17. First, you register the check using an

sl_customization file. Using ex_DataFile.xml, the check warns when:

Algebraic loop is set to none

Minimize algebraic loop is not set to error

Block Priority Violation is not set to error

The check fix action modifies the Minimize algebraic loop and Block Priority

Violation settings to error.

1 Close the Model Advisor and your model if either are open.

2 Use the following sl_customization.m file to specify and register check Example:

Check model configuration parameters. The sl_customization.m files uses

Advisor.authoring.CustomCheck.checkCallback

to define the check. It uses

Advisor.authoring.CustomCheck.actionCallback

to set the fix action.

function sl_customization(cm)

% register custom checks.

cm.addModelAdvisorCheckFcn(@defineModelAdvisorChecks);

% register items to factory group.

cm.addModelAdvisorTaskFcn(@defineModelAdvisorGroups);

%% defineModelAdvisorChecks function defineModelAdvisorChecks

25-19

25

Create Model Advisor Checks

25-20

rec = ModelAdvisor.Check( 'com.mathworks.Check1' );

rec.Title = 'Example: Check model configuration parameters' ;

rec.setCallbackFcn(@(system)(Advisor.authoring.CustomCheck.checkCallback

...

(system)), 'None' , 'StyleOne' );

rec.TitleTips = 'Example check for model configuration parameters' ;

% --- data file input parameters

rec.setInputParametersLayoutGrid([1 1]);

inputParam1 = ModelAdvisor.InputParameter;

inputParam1.Name = 'Data File' ;

inputParam1.Value = 'ex_DataFile.xml' ;

inputParam1.Type = 'String' ;

inputParam1.Description = 'Name or full path of XML data file.' ;

inputParam1.setRowSpan([1 1]);

inputParam1.setColSpan([1 1]);

rec.setInputParameters({inputParam1});

% -- set fix operation

act = ModelAdvisor.Action;

act.setCallbackFcn(@(task)(Advisor.authoring.CustomCheck.actionCallback

...

(task)));

act.Name = 'Modify Settings' ;

act.Description = 'Modify model configuration settings.' ;

rec.setAction(act);

mdladvRoot = ModelAdvisor.Root;

mdladvRoot.register(rec);

%% defineModelAdvisorGroups function defineModelAdvisorGroups mdladvRoot = ModelAdvisor.Root;

% --- sample factory group 1 rec = ModelAdvisor.FactoryGroup( 'com.mathworks.Test.factoryGroup' ); rec.DisplayName= 'Example: My Group' ; rec.addCheck( 'com.mathworks.Check1' ); mdladvRoot.publish(rec);

3

Create the Example: Check model configuration parameters. At the command prompt, enter: sl_refresh_customizations

4 At the command prompt, type vdp.

5 In the model window, select Simulation > Model Configuration Parameters. In the Diagnostics pane, to trigger check warnings, set the configuration parameters as follows:

Algebraic loop to none

Minimize algebraic loop to warning

Block Priority Violation to warning

Create Check for Model Configuration Parameters

6 From the model window, select Analysis > Model Advisor > Model Advisor to open the Model Advisor.

7 In the left pane, select By Task > Example: My Group > Example: Check

model configuration parameters. In the right pane, Data File is set to ex_DataFile.xml

. To create ex_DataFile.xml, see “Create Data File for

Diagnostics Pane Configuration Parameter Check” on page 25-17.

8 Click Run This Check. The Model Advisor check warns that the configuration parameters are not set to the values specified in ex_DataFile.xml.

For configuration parameters with positive constraint tagging

(PositiveModelParameterConstraint), the recommended values are obtained from the value tagging. For configuration parameters with negative constraint tagging (NegativeModelParameterConstraint), the values not recommended are obtained from the value tagging.

Algebraic loop(AlgebraicLoopMsg) - the ex_DataFile.xml tagging does not specify a fix action for AlgebraicLoopMsg. The subcheck passes only when the setting is not set to none.

Minimize algebraic loop(ArtificialAlgebraicLoopMsg) - the ex_DataFile.xml

tagging specifies a subcheck with a fix action for

ArtificialAlgebraicLoopMsg

that passes only when the setting is error.

The fix action modifies the setting to error.

Block priority violation(BlockPriorityViolationMsg) - the ex_DataFile.xml

tagging specifies a subcheck with a fix action for

BlockPriorityViolationMsg

that does not pass when the setting is warning.

The fix action modifies the setting to error.

9 In the Action section of the Model Advisor dialog box, click Modify Settings. Model

Advisor updates the configuration parameters for Block priority violation and

Minimize algebraic loop.

10 Run By Task > Example: My Group > Example: Check model configuration

parameters. The check warns because Algebraic loop is set to none.

11 In the right pane of the Model Advisor window, use the Algebraic loop

(AlgebraicLoopMsg)

link to open the Simulation > Model Configuration

Parameters > Diagnostics. Set Algebraic loop to warning or error.

12 Run By Task > Example: My Group > Example: Check model configuration

parameters. The check passes.

25-21

25

Create Model Advisor Checks

25-22

Data File for Configuration Parameter Check

You use an XML data file to create a configuration parameter check. To create the data file, you can use Advisor.authoring.generateConfigurationParameterDataFile

or manually create the file yourself. The data file contains tagging that specifies check behavior. Each model configuration parameter specified in the data file is a subcheck.

The structure for the data file is as follows:

<?xml version="1.0" encoding="utf-8"?>

<customcheck xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.w3schools.com

MySchema.xsd">

<messages>

<Description>Description of check</Description>

<PassMessage>Pass message</PassMessage>

<FailMessage>Fail message</FailMessage>

<RecommendedActions>Recommended action</RecommendedActions>

</messages>

<checkdata>

<!--Command-line name of configuration parameter-->

<PositiveModelParameterConstraint>

<parameter>Command-line name of configuration parameter</parameter>

<value>Value that you want configuration parameter to have</value>

<fixvalue>Specify value for a fix action</fixvalue>

<dependson>ID of configuration parameter subcheck that must pass

before this subcheck runs</value>

</PositiveModelParameterConstraint>

<!-- Command-line name of configuration parameter-->

<NegativeModelParameterConstraint>

<parameter>Command-line name of configuration parameter</parameter>

<value>Value that you do not want configuration parameter to have</value>

<fixvalue>Specify value for a fix action</fixvalue>

<dependson>ID of configuration parameter subcheck that must pass

before this subcheck runs</value>

</NegativeModelParameterConstraint>

</checkdata>

</customcheck>

The <messages> tagging is optional.

Advisor.authoring.generateConfigurationParameterDataFile

does not generate <messages> tagging. The <messages> tagging contains:

• <Description> - Description of the check. Displayed in Model Advisor window.

Optional.

• <PassMessage> - Pass message displayed in Model Advisor window. Optional.

• <FailMessage> - Fail message displayed in Model Advisor window. Optional.

• <RecommendedActions> - Recommended actions displayed in Model Advisor window when check does not pass. Optional.

Create Check for Model Configuration Parameters

Within the <checkdata> tagging, the data file specifies two types of constraints:

• <PositiveModelParameterConstraint> - Specifies the configuration parameter setting that you want.

• <NegativeModelParameterConstraint> - Specifies the configuration parameter setting that you do not want.

Within the tagging for each of the two types of constraints, for each configuration parameter that you want to check, the data file has the following tags:

• parameter - Specifies the configuration parameter that you want to check. The tagging uses the command-line name for the configuration parameter. For example:

• <parameter>AlgebraicLoopMsg</parameter>

• <parameter>BlockPriorityViolationMsg</parameter>

• value - For PositiveModelParameterConstraint constraints, specifies the setting(s) that you want for the configuration parameter. For

NegativeModelParameterConstraint

, specifies the setting(s) you that do not want for the configuration parameter. You can specify more than one value tag. For example:

• PositiveModelParameterConstraint constraints that warn when the setting is not error:

<value>error</value>

• NegativeModelParameterConstraint constraints that warn when the setting is none or warning:

<value>none</value>

<value>warning</value>

• fixvalue - Specifies the setting to use when applying the Model Advisor fix action.

Optional. For example:

• Fix action to modify configuration parameter setting to error:

<fixvalue>error</fixvalue>

• Fix action to modify configuration parameter setting to warning:

<fixvalue>warning</fixvalue>

25-23

25

Create Model Advisor Checks

25-24

• dependson - Specifies a prerequisite subcheck. Optional. For example, to specify that configuration parameter subcheck ID_B must pass before configuration parameter subcheck ID_A is run, use this tagging:

<PositiveModelParameterConstraint id="ID_A">

<dependson>ID_B</value>

</PostitiveModelParameterConstraint>

Data file tagging specifying a configuration parameter

The following tagging specifies a subcheck for configuration parameter SolverType. If the configuration parameter is set to Fixed-Step, the subcheck passes.

<PositiveModelParameterConstraint id="ID_A">

<parameter>SolverType</parameter>

<value>Fixed-step</value>

</PostitiveModelParameterConstraint>

Data file tagging specifying configuration parameter with fix action

The following tagging specifies a subcheck for configuration parameter

AlgebraicLoopMsg

. If the configuration parameter is set to none or warning, the subcheck passes. If the subcheck does not pass, the check fix action modifies the configuration parameter to error.

<PositiveModelParameterConstraint id="ID_A">

<parameter>AlgebraicLoopMsg</parameter>

<value>none</value>

<value>warning</value>

<fixvalue>error</value>

</PostitiveModelParameterConstraint>

Data file tagging specifying configuration parameter with fix action and prerequisite check

The following tagging specifies a subcheck for configuration parameter SolverType.

The subcheck for SolverType runs only after the ID_B subcheck passes. If theID_B subcheck does not pass, the subcheck for SolverType does not run. The Model Advisor reports that the prerequisite constraint is not met.

If the SolverType subcheck runs and SolverType is set to Fixed-Step, the

SolverType

subcheck passes. If the subcheck runs and does not pass, the check fix action modifies the configuration parameter to Fixed-Step.

<PositiveModelParameterConstraint id="ID_A">

Create Check for Model Configuration Parameters

<parameter>SolverType</parameter>

<value>Fixed-step</value>

<fixvalue>Fixed-step</value>

<dependson>ID_B</value>

</PostitiveModelParameterConstraint>

Data file tagging specifying unwanted configuration parameter

The following tagging specifies a subcheck for configuration parameter SolverType. The subcheck does not pass if the configuration parameter is set to Fixed-Step.

<NegativeModelParameterConstraint id="ID_A">

<parameter>SolverType</parameter>

<value>Fixed-step</value>

</NegativeModelParameterConstraint>

Data file tagging specifying unwanted configuration parameter with fix action

The following tagging specifies a subcheck for configuration parameter SolverType. If the configuration parameter is set to Fixed-Step, the subcheck does not pass . If the subcheck does not pass, the check fix action modifies the configuration parameter to

Variable-Step

.

<NegativeModelParameterConstraint id="ID_A">

<parameter>SolverType</parameter>

<value>Fixed-step</value>

<fixvalue>Variable-step</value>

</NegativeModelParameterConstraint>

Data file tagging specifying unwanted configuration parameter with fix action and prerequisite check

The following tagging specifies a check for configuration parameter SolverType.

The subcheck for SolverType runs only after the ID_B subcheck passes. If theID_B subcheck does not pass, the subcheck for SolverType does not run. The Model Advisor reports that the prerequisite constraint is not met.

If the SolverType subcheck runs and SolverType is set to Fixed-Step, the subcheck does not pass. The check fix action modifies the configuration parameter to Variable-

Step

.

<NegativeModelParameterConstraint id="ID_A">

<parameter>SolverType</parameter>

<value>Fixed-step</value>

25-25

25

Create Model Advisor Checks

<fixvalue>Variable-step</value>

<dependson>ID_B</value>

</NegativeModelParameterConstraint>

25-26

Register Checks and Process Callbacks

Register Checks and Process Callbacks

In this section...

“Create sl_customization Function” on page 25-27

“Register Checks and Process Callbacks” on page 25-27

“Define Startup and Post-Execution Actions Using Process Callback Functions” on page

25-28

Create sl_customization Function

To add checks to the Model Advisor, on your MATLAB path, in the sl_customization.m

file, create the sl_customization() function.

Tip

• You can have more than one sl_customization.m file on your MATLAB path.

• Do not place an sl_customization.m file that customizes checks and folders in the Model Advisor in your root MATLAB folder or its subfolders, except for the

matlabroot/work

folder. Otherwise, the Model Advisor ignores the customizations that the file specifies.

The sl_customization function accepts one argument, a customization manager object, as in this example: function sl_customization(cm)

The customization manager object includes methods for registering custom checks and process callbacks. Use these methods to register customizations specific to your application, as described in the following sections.

Register Checks and Process Callbacks

To register custom checks and process callbacks, the customization manager includes the following methods:

25-27

25

Create Model Advisor Checks

25-28

• addModelAdvisorCheckFcn (@checkDefinitionFcn)

Registers the checks that you define in checkDefinitionFcn to the By Product folder of the Model Advisor.

The checkDefinitionFcn argument is a handle to the function that defines custom checks that you want to add to the Model Advisor as instances of the

ModelAdvisor.Check

class (see “Define Custom Checks” on page 25-30).

• addModelAdvisorProcessFcn (@modelAdvisorProcessFcn)

Registers the process callback function for the Model Advisor checks (see “Define

Startup and Post-Execution Actions Using Process Callback Functions” on page

25-28).

Caution The Model Advisor registers only one process callback function. If you have more than one sl_customization.m file on your MATLAB path, the Model Advisor registers the process callback function from the sl_customization.m file that has the highest priority.

If the By Product folder is not displayed in the Model Advisor window, select Show By

Product Folder from the Settings > Preferences dialog box.

Note: The @ sign defines a function handle that MATLAB calls. For more information, see “At — @” in the MATLAB documentation.

For a code example, see “Register Custom Checks and Process Callbacks” on page

25-52.

Define Startup and Post-Execution Actions Using Process Callback

Functions

The process callback function is an optional function that you use to configure the Model

Advisor and process check results at run time. The process callback function specifies actions that the software performs at different stages of Model Advisor execution:

• configure stage: The Model Advisor executes configure actions at startup, after checks and tasks have been initialized. At this stage, you can customize how the

Model Advisor constructs lists of checks and tasks by modifying Visible, Enable,

Register Checks and Process Callbacks and Value properties. For example, you can remove, rename, and selectively display checks and tasks in the By Task folder.

• process_results stage: The Model Advisor executes process_results actions after checks complete execution. You can specify actions to examine and report on the results returned by check callback functions.

If you create a process callback function, you must register it, as described in “Register

Checks and Process Callbacks” on page 25-27. The following sections provide model

information about defining your own process callback functions.

For a code example, see “Process Callback Function” on page 25-52.

Process Callback Function Arguments

The process callback function takes the following arguments.

Argument stage system checkCellArray taskCellArray

I/O Type

Input

Input

Input/Output

Input/Output

Data Type Description

Enumeration Specifies the stages at which process callback actions are executed. Use this argument in a switch statement to specify actions for the stages configure and process_results

.

Path

Cell array

Cell array

Model or subsystem that the

Model Advisor analyzes.

As input, the array of checks constructed in the check definition function.

As output, the array of checks modified by actions in the configure stage.

As input, the array of tasks constructed in the task definition function.

As output, the array of tasks modified by actions in the configure stage.

25-29

25

Create Model Advisor Checks

Define Custom Checks

In this section...

“About Custom Checks” on page 25-30

“Contents of Check Definitions” on page 25-30

“Display and Enable Checks” on page 25-32

“Define Where Custom Checks Appear” on page 25-33

“Check Definition Function” on page 25-34

“Define Check Input Parameters” on page 25-34

“Define Model Advisor Result Explorer Views” on page 25-35

“Define Check Actions” on page 25-36

About Custom Checks

You can create a custom check to use in the Model Advisor. Creating custom checks provides you with the ability to specify which conditions and configuration settings the

Model Advisor reviews.

You define custom checks in one or more functions that specify the properties of each instance of the ModelAdvisor.Check class. Define one instance of this class for each custom check that you want to add to the Model Advisor, and register the custom check

as described in “Register Checks and Process Callbacks” on page 25-27.

Tip You can add a check to multiple folders by creating a task. For more information, see

“Add Check to Custom or Multiple Folders Using Tasks” on page 26-15.

The following sections describe how to define custom checks.

Contents of Check Definitions

When you define a Model Advisor check, it contains the information listed in the following table.

25-30

Define Custom Checks

Contents

Check ID (required)

Handle to check callback function

(required)

Check name (recommended)

Check properties (optional)

Input Parameters (optional)

Action (optional)

Explore Result button (optional)

Description

Uniquely identifies the check. The Model

Advisor uses this id to access the check.

Function that specifies the contents of a check.

Creates a name for the check that the

Model Advisor displays.

Creates a user interface with the check.

When adding checks as tasks, the

Model Advisor uses the task properties instead of the check properties, except for

Visible

and LicenseName. For more information, see ModelAdvisor.Check

and ModelAdvisor.Task.

Tip When you add checks to the

Model Advisor as tasks, specify only the required properties of a check, because the task definition includes the additional properties. For example, you define the description of the check in the task definition using the

ModelAdvisor.Task.Description

property instead of the

ModelAdvisor.Check.TitleTips

property.

Adds input parameters that request input from the user. The Model Advisor uses the input to perform the check.

Adds automatic fixing action.

Adds the Explore Result button that the user clicks to open the Model Advisor

Result Explorer.

25-31

25

Create Model Advisor Checks

Display and Enable Checks

You can create a check and specify how it appears in the Model Advisor. You can define when to display a check, or whether a user can select or clear a check using the Visible,

Enable

, and Value properties of the ModelAdvisor.Check class.

Note: When adding checks to the Model Advisor as tasks, specify these properties in the

ModelAdvisor.Task

class. If you specify the properties in both ModelAdvisor.Check

and ModelAdvisor.Task, the ModelAdvisor.Task properties take precedence, except for the Visible and LicenseName properties. For more information, see

ModelAdvisor.Task

.

Modify the behavior of the Visible, Enable, and Value properties in a process callback

function (see “Define Startup and Post-Execution Actions Using Process Callback

Functions” on page 25-28). The following chart illustrates how these properties interact.

25-32

Define Custom Checks

Visible?

false

Do not display check or task true

Ignore

Enable

and Value properties

Enabled?

false Display check or task

Display check box at current

Value, but grayed out true

Display check or task with active check box

Define Where Custom Checks Appear

Specify where the Model Advisor places custom checks using the following guidelines:

• To place a check in a new folder in the Model Advisor root, use the

ModelAdvisor.Group

class. See “Define Custom Tasks” on page 26-14.

• To place a check in a new folder in the By Task folder, use the

ModelAdvisor.FactoryGroup

class. See “Define Custom Tasks” on page 26-14.

• To place a check in the By Product folder, use the ModelAdvisor.Root.publish

method. If the By Product folder is not displayed in the Model Advisor window, select Show By Product Folder from the Settings > Preferences dialog box.

25-33

25

Create Model Advisor Checks

25-34

Check Definition Function

The following is an example of a function that defines the custom checks associated with

the callback functions described in “Create Callback Functions and Results” on page

25-37. The check definition function returns a cell array of custom checks to be added

to the Model Advisor.

The check definitions in the example use the tasks described in “Define Custom Tasks” on page 26-14.

% Defines custom Model Advisor checks function defineModelAdvisorChecks

% Sample check 1: Informational check rec = ModelAdvisor.Check( 'mathworks.example.configManagement' ); rec.Title = 'Informational check for model configuration management' ; setCallbackFcn(rec, @modelVersionChecksumCallbackUsingFT, 'None' , 'StyleOne' ); rec.CallbackContext = 'PostCompile' ; mdladvRoot = ModelAdvisor.Root; mdladvRoot.register(rec);

% Sample check 2: Basic Check with Pass/Fail Status rec = ModelAdvisor.Check( 'mathworks.example.unconnectedObjects' ); rec.Title = 'Check for unconnected objects' ; setCallbackFcn(rec, @unconnectedObjectsCallbackUsingFT, 'None' , 'StyleOne' ); mdladvRoot = ModelAdvisor.Root; mdladvRoot.register(rec);

% Sample Check 3: Check with Subchecks and Actions rec = ModelAdvisor.Check( 'mathworks.example.optimizationSettings' ); rec.Title = 'Check safety-related optimization settings' ; setCallbackFcn(rec, @OptmizationSettingCallback, 'None' , 'StyleOne' );

% Define an automatic fix action for this check modifyAction = ModelAdvisor.Action; setCallbackFcn(modifyAction, @modifyOptmizationSetting); modifyAction.Name = 'Modify Settings' ; modifyAction.Description = [ 'Modify model configuration optimization' ...

' settings that can impact safety.' ]; modifyAction.Enable = true; setAction(rec, modifyAction); mdladvRoot = ModelAdvisor.Root; mdladvRoot.register(rec);

Define Check Input Parameters

With input parameters, the check author can request input from the user for a Model

Advisor check. Define input parameters using the ModelAdvisor.InputParameter

class inside a custom check function (see “Define Custom Checks” on page 25-30). You

Define Custom Checks must define one instance of this class for each input parameter that you want to add to a

Model Advisor check.

Note: You do not have to create input parameters for every custom check.

For a code example, see “Input Parameter Definition” on page 25-53.

Specify Input Parameter Layout

Specify the layout of input parameters in an input parameter definition. To place input parameters, use the following methods.

Method

ModelAdvisor.Check

setInputParametersLayoutGrid

ModelAdvisor.InputParameter

setRowSpan

ModelAdvisor.InputParameter

setColSpan

Description

Specifies the size of the input parameter grid.

Specifies the number of rows the parameter occupies in the Input Parameter layout grid.

Specifies the number of columns the parameter occupies in the Input Parameter layout grid.

For information on using these methods, see the ModelAdvisor.Check and

ModelAdvisor.InputParameter

class documentation.

Define Model Advisor Result Explorer Views

A list view provides a way for users to fix check warnings and failures using the Model

Advisor Result Explorer. Creating a list view allows you to :

• Add the Explore Result button to the custom check in the Model Advisor window.

• Provide the information to populate the Model Advisor Result Explorer.

For information on using the Model Advisor Results Explorer, see “Batch-Fix Warnings or Failures” in the Simulink documentation.

Define list views using the ModelAdvisor.ListViewParameter class inside a custom

check function (see “Define Custom Checks” on page 25-30). You must define one

25-35

25

Create Model Advisor Checks instance of this class for each list view that you want to add to a Model Advisor Result

Explorer window.

Note: You do not have to create list views for every custom check.

For a code example, see “List View Definition” on page 25-54.

Define Check Actions

An action provides a way for you to specify an action that the Model Advisor performs to fix a Model Advisor check. When you define an action, the Model Advisor window includes an Action box below the Analysis box.

You define actions using the ModelAdvisor.Action class inside a custom check

function (see “Define Custom Checks” on page 25-30). You must define:

• One instance of this class for each action that you want to take.

• One action callback function for each action (see “Action Callback Function” on page

25-43).

Note:

• Each check can contain only one action.

• You do not have to create actions for every custom check.

For a code example, see “Action Definition” on page 25-55.

25-36

Create Callback Functions and Results

Create Callback Functions and Results

In this section...

“About Callback Functions” on page 25-37

“Common Utilities for Authoring Checks” on page 25-37

“Simple Check Callback Function” on page 25-38

“Detailed Check Callback Function” on page 25-39

“Check Callback Function with Hyperlinked Results” on page 25-40

“Action Callback Function” on page 25-43

“Format Model Advisor Results” on page 25-44

About Callback Functions

A callback function specifies the actions that the Model Advisor performs on a model or subsystem, based on the check or action that the user runs. You must create a callback function for each custom check and action so that the Model Advisor can execute the function when a user runs the check. There are several types of callback functions:

• “Simple Check Callback Function” on page 25-38

• “Detailed Check Callback Function” on page 25-39

• “Check Callback Function with Hyperlinked Results” on page 25-40

• “Action Callback Function” on page 25-43

All types of callback functions provide one or more return arguments for displaying the results after executing the check or action. In some cases, return arguments are strings or cell arrays of strings that support embedded HTML tags for text formatting. Use the

Model Advisor Result Template API to format check results, as described in “Format

Model Advisor Results” on page 25-44. Limit HTML tags to be compatible with

alternate output formats.

Common Utilities for Authoring Checks

When you create a check, there are common Simulink utilities that you can use to make the check perform different actions. Following is a list of utilities and when to use them.

In the Utility column, click the link for more information about the utility.

25-37

25

Create Model Advisor Checks

Utility find_system get_param

/ set_param inspect evalin

“Simulink Identifier” (SID)

Stateflow API

Used for...

Getting handle or path to:

• Blocks

• Lines

• Annotations

When getting the object, you can:

• Specify a search depth

• Search under masks and libraries

Getting and setting system and block parameter values.

Getting object properties. First you must get a handle to the object.

Working in the base workspace.

Identifying Simulink blocks, model annotations or Stateflow objects. The SID is a unique number within the model, assigned by Simulink.

Programmatic access to Stateflow objects.

Simple Check Callback Function

Use a simple check callback function with results formatted using the Result Template

API to indicate whether the model passed or failed the check, or to recommend fixing an issue. The keyword for this callback function is StyleOne. The check definition requires

this keyword (see “Define Custom Checks” on page 25-30).

The check callback function takes the following arguments.

Argument system

I/O Type

Input

Description

Path to the model or subsystem analyzed by the Model

Advisor.

25-38

Create Callback Functions and Results

Argument result

I/O Type

Output

Description

MATLAB string that supports Model Advisor

Formatting API calls or embedded HTML tags for text

formatting.

For code examples see:

• “Basic Check with Pass/Fail Status” on page 25-58

• “Check With Subchecks and Actions” on page 25-60

• “Informational Check Callback Function” on page 25-56

Detailed Check Callback Function

Use the detailed check callback function to return and organize results as strings in a layered, hierarchical fashion. The function provides two output arguments so you can associate text descriptions with one or more paragraphs of detailed information. The keyword for the detailed callback function is StyleTwo. The check definition requires

this keyword (see “Define Custom Checks” on page 25-30).

The detailed callback function takes the following arguments.

Argument system

ResultDescription

ResultDetails

I/O Type

Input

Output

Output

Description

Path to the model or system analyzed by the Model Advisor.

Cell array of MATLAB strings that

supports Model Advisor Formatting

API calls or embedded HTML tags for

text formatting. The Model Advisor concatenates the ResultDescription string with the corresponding array of

ResultDetails

strings.

Cell array of cell arrays, each of which contains one or more strings.

Note: The ResultDetails cell array must be the same length as the

ResultDescription

cell array.

25-39

25

Create Model Advisor Checks

25-40

Here is an example of a detailed check callback function that checks optimization settings for simulation and code generation.

function [ResultDescription, ResultDetails] = SampleStyleTwoCallback(system)

ResultDescription ={};

ResultDetails ={}; model = bdroot(system); mdladvObj = Simulink.ModelAdvisor.getModelAdvisor(system); % get object mdladvObj.setCheckResultStatus(true); % init result status to pass

% Check Simulation optimization setting

ResultDescription{end+1} = ModelAdvisor.Paragraph([ 'Check Simulation ' ...

'optimization settings:' ]); if strcmp(get_param(model, 'BlockReduction' ), 'off' );

ResultDetails{end+1} = {ModelAdvisor.Text([ 'It is recommended to ' ...

'turn on Block reduction optimization option.' ],{ 'italic' })};

mdladvObj.setCheckResultStatus(false); % set to fail

mdladvObj.setActionEnable(true); else

ResultDetails{end+1} = {ModelAdvisor.Text( 'Passed' ,{ 'pass' })}; end

% Check code generation optimization setting

ResultDescription{end+1} = ModelAdvisor.Paragraph([ 'Check code generation ' ...

'optimization settings:' ]);

ResultDetails{end+1} = {}; if strcmp(get_param(model, 'LocalBlockOutputs' ), 'off' );

ResultDetails{end}{end+1} = ModelAdvisor.Text([ 'It is recommended to' ...

' turn on Enable local block outputs option.' ],{ 'italic' });

ResultDetails{end}{end+1} = ModelAdvisor.LineBreak;

mdladvObj.setCheckResultStatus(false); % set to fail

mdladvObj.setActionEnable(true); end if strcmp(get_param(model, 'BufferReuse' ), 'off' );

ResultDetails{end}{end+1} = ModelAdvisor.Text([ 'It is recommended to' ...

' turn on Reuse block outputs option.' ],{ 'italic' });

mdladvObj.setCheckResultStatus(false); % set to fail

mdladvObj.setActionEnable(true); end if isempty(ResultDetails{end})

ResultDetails{end}{end+1} = ModelAdvisor.Text( 'Passed' ,{ 'pass' }); end

Check Callback Function with Hyperlinked Results

This callback function automatically displays hyperlinks for every object returned by the check so that you can easily locate problem areas in your model or subsystem. The keyword for this type of callback function is StyleThree. The check definition requires

this keyword (see “Define Custom Checks” on page 25-30).

This callback function takes the following arguments.

Create Callback Functions and Results

Argument system

ResultDescription

ResultDetails

I/O Type

Input

Output

Output

Description

Path to the model or system analyzed by the Model Advisor.

Cell array of MATLAB strings that supports the Model Advisor Formatting

API calls or embedded HTML tags for text formatting.

Cell array of cell arrays, each of which contains one or more Simulink objects such as blocks, ports, lines, and Stateflow charts. The objects must be in the form of a handle or Simulink path.

Note: The ResultDetails cell array must be the same length as the

ResultDescription

cell array.

The Model Advisor automatically concatenates each string from ResultDescription with the corresponding array of objects from ResultDetails. The Model Advisor displays the contents of ResultDetails as a set of hyperlinks, one for each object returned in the cell arrays. When you click a hyperlink, the Model Advisor displays the target object highlighted in your Simulink model.

The following is an example of a check callback function with hyperlinked results. This example checks a model for consistent use of font type and font size in its blocks. It also contains input parameters, actions, and a call to the Model Advisor Result Explorer, which are described in later sections.

function [ResultDescription, ResultDetails] = SampleStyleThreeCallback(system)

ResultDescription ={};

ResultDetails ={}; mdladvObj = Simulink.ModelAdvisor.getModelAdvisor(system); mdladvObj.setCheckResultStatus(true); needEnableAction = false;

% get input parameters inputParams = mdladvObj.getInputParameters; skipFontCheck = inputParams{1}.Value; regularFontSize = inputParams{2}.Value; regularFontName = inputParams{3}.Value; if skipFontCheck

ResultDescription{end+1} = ModelAdvisor.Paragraph( 'Skipped.' );

ResultDetails{end+1} = {};

25-41

25

Create Model Advisor Checks

25-42 return end regularFontSize = str2double(regularFontSize); if regularFontSize<1 || regularFontSize>=99

mdladvObj.setCheckResultStatus(false);

ResultDescription{end+1} = ModelAdvisor.Paragraph([ 'Invalid font size. ' ...

'Please enter a value between 1 and 99' ]);

ResultDetails{end+1} = {}; end

% find all blocks inside current system allBlks = find_system(system);

% block diagram doesn't have font property

% get blocks inside current system that have font property allBlks = setdiff(allBlks, {system});

% find regular font name blocks regularBlks = find_system(allBlks, 'FontName' ,regularFontName);

% look for different font blocks in the system searchResult = setdiff(allBlks, regularBlks); if ~isempty(searchResult)

ResultDescription{end+1} = ModelAdvisor.Paragraph([ 'It is recommended to ' ...

'use same font for blocks for a uniform appearance in the model. ' ...

'The following blocks use a font other than ' regularFontName ': ' ]);

ResultDetails{end+1} = searchResult;

mdladvObj.setCheckResultStatus(false);

myLVParam = ModelAdvisor.ListViewParameter;

myLVParam.Name = 'Invalid font blocks' ; % pull down filter name

myLVParam.Data = get_param(searchResult, 'object' )';

myLVParam.Attributes = { 'FontName' }; % name is default property

mdladvObj.setListViewParameters({myLVParam});

needEnableAction = true; else

ResultDescription{end+1} = ModelAdvisor.Paragraph([ 'All block font names ' ...

'are identical.' ]);

ResultDetails{end+1} = {}; end

% find regular font size blocks regularBlks = find_system(allBlks, 'FontSize' ,regularFontSize);

% look for different font size blocks in the system searchResult = setdiff(allBlks, regularBlks); if ~isempty(searchResult)

ResultDescription{end+1} = ModelAdvisor.Paragraph([ 'It is recommended to ' ...

'use same font size for blocks for a uniform appearance in the model. ' ...

'The following blocks use a font size other than ' ...

num2str(regularFontSize) ': ' ]);

ResultDetails{end+1} = searchResult;

mdladvObj.setCheckResultStatus(false);

myLVParam = ModelAdvisor.ListViewParameter;

myLVParam.Name = 'Invalid font size blocks' ; % pull down filter name

myLVParam.Data = get_param(searchResult, 'object' )';

myLVParam.Attributes = { 'FontSize' }; % name is default property

Create Callback Functions and Results

mdladvObj.setListViewParameters

...

({mdladvObj.getListViewParameters{:}, myLVParam});

needEnableAction = true; else

ResultDescription{end+1} = ModelAdvisor.Paragraph([ 'All block font sizes ' ...

'are identical.' ]);

ResultDetails{end+1} = {}; end mdladvObj.setActionEnable(needEnableAction); mdladvObj.setCheckErrorSeverity(1);

In the Model Advisor, if you run Example task with input parameter and auto-

fix ability for the slvnvdemo_mdladv model, you can view the hyperlinked results.

Clicking the first hyperlink, slvnvdemo_mdladv/Input, displays the Simulink model with the Input block highlighted.

Action Callback Function

An action callback function specifies the actions that the Model Advisor performs on a model or subsystem when the user clicks the action button. You must create one callback function for the action that you want to take.

The action callback function takes the following arguments.

Argument taskobj result

I/O Type

Input

Output

Description

The ModelAdvisor.Task object for the check that includes an action definition.

MATLAB string that supports Model Advisor

Formatting API calls or embedded HTML tags for text

formatting.

For a code example, see “Action Callback Function” on page 25-43

Action Callback Function with Result Details

The following is an example of an action callback function that contains result details.

% Get Simulink.ModelAdvisor object

mdladvObj = taskobj.MAObj;

% get result of 'MyCheck'

myResult = mdladvObj.getCheckResult('MyCheck');

% if the check is in style three

[ResultDescription, ResultDetails] = myResult;

25-43

25

Create Model Advisor Checks

25-44

Format Model Advisor Results

• “Overview of Displaying Results” on page 25-44

• “Format Model Advisor Results” on page 25-44

• “Format Text” on page 25-45

• “Format Lists” on page 25-45

• “Format Tables” on page 25-45

• “Format Paragraphs” on page 25-47

• “Formatted Output” on page 25-47

Overview of Displaying Results

You can make the analysis results of your custom checks appear similar to each other with minimal scripting using the Model Advisor ModelAdvisor.FormatTemplate

class, as described in ModelAdvisor.FormatTemplate. For examples of callback

functions using the ModelAdvisor.FormatTemplate class, see “Simple Check Callback

Function” on page 25-38.

If this format template does not meet your needs, or if you want to format action results, use the Model Advisor Formatting API, as described in the following sections.

Format Model Advisor Results

Use the Model Advisor Formatting API to produce formatted outputs in the Model

Advisor. The following constructors of the ModelAdvisor class provide the ability to format the output. For more information on each constructor and associated methods, in the Constructor column, click the link.

Constructor

ModelAdvisor.Text

ModelAdvisor.Paragraph

ModelAdvisor.List

ModelAdvisor.LineBreak

ModelAdvisor.Table

ModelAdvisor.Image

Description

Formats element text.

Combines elements into paragraphs.

Creates a list of elements.

Adds a line break between elements.

Creates a table.

Adds an image to the output.

Create Callback Functions and Results

Format Text

Text is the simplest form of output. You can format text in many different ways. The default text formatting is:

• Empty

• Default color (black)

• Unformatted (not bold, italicized, underlined, linked, subscripted, or superscripted)

To change text formatting, use the ModelAdvisor.Text constructor. When you want one type of formatting for all text, use this syntax:

ModelAdvisor.Text(content, {attributes})

When you want multiple types of formatting, you must build the text.

t1 = ModelAdvisor.Text( 'It is ' ); t2 = ModelAdvisor.Text( 'recommended' , { 'italic' }); t3 = ModelAdvisor.Text( ' to use same font for ' ); t4 = ModelAdvisor.Text( 'blocks' , { 'bold' }); t5 = ModelAdvisor.Text( ' for a uniform appearance in the model.' ); result = [t1, t2, t3, t4, t5];

Add ASCII and Extended ASCII characters using the MATLAB char command. For more information, see the ModelAdvisor.Text class page.

Format Lists

You can create two types of lists: numbered and bulleted. The default list formatting is bulleted. Use the ModelAdvisor.List constructor to create and format lists (see

ModelAdvisor.List

). You can create lists with indented subsections, formatted as either numbered or bulleted.

subList = ModelAdvisor.List(); subList.setType( 'numbered' ) subList.addItem(ModelAdvisor.Text( 'Sub entry 1' , { 'pass' , 'bold' })); subList.addItem(ModelAdvisor.Text( 'Sub entry 2' , { 'pass' , 'bold' })); topList = ModelAdvisor.List(); topList.addItem([ModelAdvisor.Text( 'Entry level 1' ,{ 'keyword' , 'bold' }), subList]); topList.addItem([ModelAdvisor.Text( 'Entry level 2' ,{ 'keyword' , 'bold' }), subList]);

Format Tables

The default table formatting is:

• Default color (black)

• Left justified

25-45

25

Create Model Advisor Checks

• Bold title, row, and column headings

Change table formatting using the ModelAdvisor.Table constructor.

The following example code creates a subtable within a table.

table1 = ModelAdvisor.Table(1,1); table2 = ModelAdvisor.Table(2,3); table2.setHeading( 'Table 2' ); table2.setHeadingAlign( 'center' ); table2.setColHeading(1, 'Header 1' ); table2.setColHeading(2, 'Header 2' ); table2.setColHeading(3, 'Header 3' ); table1.setHeading( 'Table 1' ); table1.setEntry(1,1,table2);

25-46

The following example code creates a table with five rows and five columns containing randomly generated numbers. Use the MATLAB code in a callback function to create the table. The Model Advisor displays table1 in the results.

% ModelAdvisor.Table example matrixData = rand(5,5) * 10^5;

% initialize a table with 5 rows and 5 columns (heading rows not counting) table1 = ModelAdvisor.Table(5,5);

% set column headings for n=1:5

table1.setColHeading(n, [ 'Column ' , num2str(n)]); end

% set alignment of second column heading table1.setColHeadingAlign(2, 'center' );

% set column width of second column table1.setColWidth(2, 3);

% set row headings for n=1:5

Create Callback Functions and Results

table1.setRowHeading(n, [ 'Row ' , num2str(n)]); end

% set Table content for rowIndex=1:5 for colIndex=1:5

table1.setEntry(rowIndex, colIndex, ...

num2str(matrixData(rowIndex, colIndex)));

% set alignment of entries in second row if colIndex == 2

table1.setEntryAlign(rowIndex, colIndex, 'center' ); end end end

% overwrite content of cell 3,3 with a ModelAdvisor.Text

text = ModelAdvisor.Text( 'Example Text' ); table1.setEntry(3,3, text)

Format Paragraphs

You must handle paragraphs explicitly because most markup languages do not support line breaks. The default paragraph formatting is:

• Empty

• Default color (black)

• Unformatted, (not bold, italicized, underlined, linked, subscripted, or superscripted)

• Aligned left

If you want to change paragraph formatting, use the ModelAdvisor.Paragraph class.

Formatted Output

The following is the example from “Simple Check Callback Function” on page 25-38,

reformatted using the Model Advisor Formatting API.

25-47

25

Create Model Advisor Checks function result = SampleStyleOneCallback(system) mdladvObj = Simulink.ModelAdvisor.getModelAdvisor(system); if strcmp(get_param(bdroot(system), 'ScreenColor' ), 'white' )

result = ModelAdvisor.Text( 'Passed' ,{ 'pass' });

mdladvObj.setCheckResultStatus(true); else

msg1 = ModelAdvisor.Text( ...

[ 'It is recommended to select a Simulink window screen color' ...

' of white for a readable and printable model. Click ' ]);

msg2 = ModelAdvisor.Text( 'here' );

msg2.setHyperlink( 'matlab: set_param(bdroot,''ScreenColor'',''white'')' );

msg3 = ModelAdvisor.Text( ' to change screen color to white.' );

result = [msg1, msg2, msg3];

mdladvObj.setCheckResultStatus(false); end

25-48

Exclude Blocks From Custom Checks

Exclude Blocks From Custom Checks

This example shows how to exclude blocks from custom checks. To save time during model development and verification, you might decide to exclude individual blocks from custom checks in a Model Advisor analysis. By modifying the sl_customization.m

file to include the ModelAdvisor.Check.supportExclusion

and Simulink.ModelAdvisor.filterResultWithExclusion functions, you can exclude your custom checks from:

• Simulink blocks

• Stateflow charts

This example shows how to exclude blocks from a custom check.

1

At the command prompt, type slvnvdemo_mdladv.

2

In the model window, double-click View demo sl_customization.m.

3 To exclude the custom check Check Simulink block font from blocks during Model

Advisor analysis, make three modifications to the sl_customization.m file.

a Enable the Check Simulink block font check to support check exclusions by using the ModelAdvisor.Check.supportExclusion

property. You can now exclude the check from model blocks.

After rec.setInputParametersLayoutGrid([3 2]);, add rec.supportExclusion = true;

. The check 1 section of the function defineModelAdvisorChecks

now looks like:

% --- sample check 1 rec = ModelAdvisor.Check( 'com.mathworks.sample.Check1' ); rec.Title = 'Check Simulink block font' ; rec.TitleTips = 'Example style three callback' ; rec.setCallbackFcn(@SampleStyleThreeCallback, 'None' , 'StyleThree' ); rec.setInputParametersLayoutGrid([3 2]); rec.supportExclusion = true; b Use the Simulink.ModelAdvisor.filterResultWithExclusion function to filter model objects causing a check warning or failure with checks that have exclusions enabled. To do this, there are two locations in the sl_customization.m

file to modify, both in the [ResultDescription,

ResultDetails] = SampleStyleThreeCallback(system)

function:

25-49

25

Create Model Advisor Checks

• After both instances of searchResult = mdladvObj.filterResultWithExclusion(searchResult);

, add searchResult = setdiff(allBlks, regularBlks);

.

• In the first location, the function now looks like:

% find regular font name blocks regularBlks = find_system(allBlks,'FontName',regularFontName);

% look for different font blocks in the system searchResult = setdiff(allBlks, regularBlks); searchResult = mdladvObj.filterResultWithExclusion(searchResult); if ~isempty(searchResult)

• In the second location, the function now looks like:

% find regular font size blocks regularBlks = find_system(allBlks,'FontSize',regularFontSize);

% look for different font size blocks in the system searchResult = setdiff(allBlks, regularBlks); searchResult = mdladvObj.filterResultWithExclusion(searchResult); if ~isempty(searchResult)

4 Save the sl_customization.m file. If you are asked if it is ok to overwrite the file, click OK.

5 In the model window, double-click Launch Model Advisor.

6

If the By Product folder is not displayed in the Model Advisor window, select Show

By Product Folder from the Settings > Preferences dialog box.

7 In the left pane of the Model Advisor window, select the By Product > Demo >

Check Simulink block font check. In the right pane, select Run This Check. The check fails.

8

In the Model Advisor window, click the Enable highlighting button ( ). The blocks causing the Check Simulink block font check failure are highlighted in yellow.

9 In the model window, right-click the X block and select Model Advisor > Exclude

block only > Check Simulink block font.

10

In the Model Advisor Exclusion Editor, click OK to create the exclusion file.

Additionally, in the Save Exclusion File as dialog box, click Save to create an exclusion file with the default name slvnvdemo_mdladv_exclusions.xml.

25-50

Exclude Blocks From Custom Checks

11 In the model window, right-click the Input block and select Model Advisor >

Exclude block only > Check Simulink block font.

12 In the Model Advisor Exclusion Editor, click OK to update the exclusion file.

13 In the left pane of the Model Advisor window, select the By Product > Demo >

Check Simulink block font check. In the right pane, select Run This Check. The check now passes. In the right-pane of the Model Advisor window, you can see the

Check Exclusion Rules that the Model Advisor during the analysis.

14 Close slvnvdemo_mdladv.

Related Examples

• “Select and Run Model Checks”

“Limit Model Checks By Excluding Gain and Outport Blocks” on page 22-11

More About

“Limit Model Checks” on page 22-3

• “Run Model Checks”

• “Highlight Model Check Results”

• Simulink.ModelAdvisor

25-51

25

Create Model Advisor Checks

Model Advisor Code Examples

In this section...

“Register Custom Checks and Process Callbacks” on page 25-52

“Process Callback Function” on page 25-52

“Input Parameter Definition” on page 25-53

“List View Definition” on page 25-54

“Action Definition” on page 25-55

“Informational Check Callback Function” on page 25-56

“Basic Check with Pass/Fail Status” on page 25-58

“Check With Subchecks and Actions” on page 25-60

“Action Callback Function” on page 25-62

Register Custom Checks and Process Callbacks

The following code example registers custom checks and a process callback function: function sl_customization(cm)

% register custom checks cm.addModelAdvisorCheckFcn(@defineModelAdvisorChecks);

% register custom process callback cm.addModelAdvisorProcessFcn(@ModelAdvisorProcessFunction);

Note: If you add custom tasks and folders within the sl_customization.m file, include methods for registering the tasks and folders in the sl_customization function. For

more information, see “Register Tasks and Folders” on page 26-14.

Process Callback Function

The following code is an example of a process callback function that specifies actions in the configure stage, to make only custom checks visible. In the process_results stage, this function displays information at the command prompt for checks that do not pass.

% Process Callback Function

25-52

Model Advisor Code Examples

% Defines actions to execute at startup and post-execution function [checkCellArray taskCellArray] = ...

ModelAdvisorProcessFunction(stage, system, checkCellArray, taskCellArray) switch stage

% Specify the appearance of the Model Advisor window at startup case 'configure' for i=1:length(checkCellArray)

% Hide all checks that do not belong to custom folder if isempty(strfind(checkCellArray{i}.ID, 'mathworks.example' ))

checkCellArray{i}.Visible = false;

checkCellArray{i}.Value = false; end end

% Specify actions to perform after the Model Advisor completes execution case 'process_results' for i=1:length(checkCellArray)

% Print message if check does not pass if checkCellArray{i}.Selected && (strcmp(checkCellArray{i}.Title, ...

'Check Simulink window screen color' ))

mdladvObj = Simulink.ModelAdvisor.getModelAdvisor(system);

% Verify whether the check was run and if it failed if mdladvObj.verifyCheckRan(checkCellArray{i}.ID) if ~mdladvObj.getCheckResultStatus(checkCellArray{i}.ID)

% Display text in MATLAB Command Window

disp([ 'Example message from Model Advisor Process' ...

' callback.' ]); end end end end end

Input Parameter Definition

The following is an example of defining input parameters that you add to a custom check. You must include input parameter definitions inside a custom check definition

(see “Check Definition Function” on page 25-34). The following code, when included in a

custom check definition, creates three input parameters.

rec = ModelAdvisor.Check( 'com.mathworks.sample.Check1' ); rec.setInputParametersLayoutGrid([3 2]);

% define input parameters inputParam1 = ModelAdvisor.InputParameter; inputParam1.Name = 'Skip font checks.' ; inputParam1.Type = 'Bool' ; inputParam1.Value = false; inputParam1.Description = 'sample tooltip' ; inputParam1.setRowSpan([1 1]); inputParam1.setColSpan([1 1]); inputParam2 = ModelAdvisor.InputParameter;

25-53

25

Create Model Advisor Checks inputParam2.Name = 'Standard font size' ; inputParam2.Value= '12' ; inputParam2.Type= 'String' ; inputParam2.Description= 'sample tooltip' ; inputParam2.setRowSpan([2 2]); inputParam2.setColSpan([1 1]); inputParam3 = ModelAdvisor.InputParameter; inputParam3.Name= 'Valid font' ; inputParam3.Type= 'Combobox' ; inputParam3.Description= 'sample tooltip' ; inputParam3.Entries={ 'Arial' , 'Arial Black' }; inputParam3.setRowSpan([2 2]); inputParam3.setColSpan([2 2]); rec.setInputParameters({inputParam1,inputParam2,inputParam3});

The Model Advisor displays these input parameters in the right pane, in an Input

Parameters box.

25-54

List View Definition

The following is an example of defining list views. You must make the Explore Result button visible using the ModelAdvisor.Check.ListViewVisible property inside a custom check function, and include list view definitions inside a check callback function

(see “Detailed Check Callback Function” on page 25-39).

Model Advisor Code Examples

The following code, when included in a check definition function, adds the Explore

Result button to the check in the Model Advisor.

rec = ModelAdvisor.Check( 'com.mathworks.sample.Check1' );

% add 'Explore Result' button rec.ListViewVisible = true;

The following code, when included in a check callback function, provides the information to populate the Model Advisor Result Explorer.

mdladvObj = Simulink.ModelAdvisor.getModelAdvisor(system); mdladvObj.setCheckResultStatus(true);

% define list view parameters myLVParam = ModelAdvisor.ListViewParameter; myLVParam.Name = 'Invalid font blocks' ; % the name appeared at pull down filter myLVParam.Data = get_param(searchResult, 'object' )'; myLVParam.Attributes = { 'FontName' }; % name is default property mdladvObj.setListViewParameters({myLVParam});

Action Definition

The following is an example of defining actions within a custom check. You must include

action definitions inside a check definition function (see “Check Definition Function” on page 25-34).

The following code, when included in a check definition function, provides the information to populate the Action box in the Model Advisor.

rec = ModelAdvisor.Check( 'mathworks.example.optimizationSettings' );

% Define an automatic fix action for this check modifyAction = ModelAdvisor.Action; modifyAction.setCallbackFcn(@modifyOptmizationSetting); modifyAction.Name = 'Modify Settings' ; modifyAction.Description = [ 'Modify model configuration optimization' ...

' settings that can impact safety' ]; modifyAction.Enable = true; rec.setAction(modifyAction);

The Model Advisor, in the right pane, displays an Action box.

25-55

25

Create Model Advisor Checks

25-56

Informational Check Callback Function

The following code is an example of a callback function for a custom informational check that finds and displays the model configuration and checksum information. The informational check uses the Result Template API to format the check result.

An informational check includes the following items in the results:

• A description of what the check is reviewing.

• References to standards, if applicable.

An informational check does not include the following items in the results:

• The check status. The Model Advisor displays the overall check status, but the status is not in the result.

• A description of the status.

• The recommended action to take when the check does not pass.

• Subcheck results.

• A line below the results.

% Sample Check 1 Callback Function: Informational Check

% Find and display model configuration and checksum information

% Informational checks do not have a passed or warning status in the results

Model Advisor Code Examples function resultDescription = modelVersionChecksumCallbackUsingFT(system) resultDescription = []; system = getfullname(system); model = bdroot(system);

% Format results in a list using Model Advisor Result Template API ft = ModelAdvisor.FormatTemplate( 'ListTemplate' );

% Add See Also section for references to standards docLinkSfunction{1} = {[ 'IEC 61508-3, Table A.8 (5)' ...

' ''Software configuration management'' ' ]}; setRefLink(ft,docLinkSfunction);

% Description of check in results desc = 'Display model configuration and checksum information.' ;

% If running the Model Advisor on a subsystem, add note to description if strcmp(system, model) == false

desc = strcat(desc, [ '<br/>NOTE: The Model Advisor is reviewing a' ...

' sub-system, but these results are based on root-level settings.' ]); end setCheckText(ft, desc); mdladvObj = Simulink.ModelAdvisor.getModelAdvisor(system);

% If err, use these values mdlver = 'Error - could not retrieve Version' ; mdlauthor = 'Error - could not retrieve Author' ; mdldate = 'Error - could not retrieve Date' ; mdlsum = 'Error - could not retrieve CheckSum' ;

% Get model configuration and checksum information try

mdlver = get_param(model, 'ModelVersion' );

mdlauthor = get_param(model, 'LastModifiedBy' );

mdldate = get_param(model, 'LastModifiedDate' );

mdlsum = Simulink.BlockDiagram.getChecksum(model);

mdlsum = [num2str(mdlsum(1)) ' ' num2str(mdlsum(2)) ' ' ...

num2str(mdlsum(3)) ' ' num2str(mdlsum(4))];

mdladvObj.setCheckResultStatus(true); % init to true catch err

mdladvObj.setCheckResultStatus(false);

setSubResultStatusText(ft,err.message);

resultDescription{end+1} = ft; return end

% Display the results lbStr = '<br/>' ; resultStr = [ 'Model Version: ' mdlver lbStr 'Author: ' mdlauthor lbStr ...

'Date: ' mdldate lbStr 'Model Checksum: ' mdlsum]; setSubResultStatusText(ft,resultStr);

% Informational checks do not have subresults, supress line setSubBar(ft,false); resultDescription{end+1} = ft;

25-57

25

Create Model Advisor Checks

25-58

Basic Check with Pass/Fail Status

Here is an example of a callback function for a custom basic check that finds and reports unconnected lines, input ports, and output ports.

A basic check includes the following items in the results:

• A description of what the check is reviewing.

• References to standards, if applicable.

• The status of the check.

• A description of the status.

• Results for the check.

• The recommended actions to take when the check does not pass.

A basic check does not include the following items in the results:

• Subcheck results.

• A line below the results.

% Sample Check 2 Callback Function: Basic Check with Pass/Fail Status

% Find and report unconnected lines, input ports, and output ports function ResultDescription = unconnectedObjectsCallbackUsingFT(system) mdladvObj = Simulink.ModelAdvisor.getModelAdvisor(system);

% Initialize variables mdladvObj.setCheckResultStatus(false);

ResultDescription ={};

ResultStatus = false; % Default check status is 'Warning' system = getfullname(system); isSubsystem = ~strcmp(bdroot(system), system);

% Format results in a list using Model Advisor Result Template API

% Create a list template object ft = ModelAdvisor.FormatTemplate( 'ListTemplate' );

% Description of check in results if isSubsystem

checkDescStr = [ 'Identify unconnected lines, input ports, and ' ...

'output ports in the subsystem.' ]; else

checkDescStr = [ 'Identify unconnected lines, input ports, and ' ...

'output ports in the model.' ]; end setCheckText(ft,checkDescStr);

% Add See Also section with references to applicable standards checkStdRef = 'IEC 61508-3, Table A.3 (3) ''Language subset'' ' ; docLinkSfunction{1} = {checkStdRef}; setRefLink(ft,docLinkSfunction);

Model Advisor Code Examples

% Basic checks do not have subresults, supress line setSubBar(ft,false);

% Check for unconnected lines, inputs, and outputs sysHandle = get_param(system, 'Handle' ); uLines = find_system(sysHandle, ...

'Findall' , 'on' , ...

'LookUnderMasks' , 'on' , ...

'Type' , 'line' , ...

'Connected' , 'off' ); uPorts = find_system(sysHandle, ...

'Findall' , 'on' , ...

'LookUnderMasks' , 'on' , ...

'Type' , 'port' , ...

'Line' , -1);

% Use parents of port objects for the correct highlight behavior if ~isempty(uPorts) for i=1:length(uPorts)

uPorts(i) = get_param(get_param(uPorts(i), 'Parent' ), 'Handle' ); end end

% Create cell array of unconnected object handles modelObj = {}; searchResult = union(uLines, uPorts); for i = 1:length(searchResult)

modelObj{i} = searchResult(i); end

% No unconnected objects in model

% Set result status to 'Pass' and display text describing the status if isempty(modelObj)

setSubResultStatus(ft, 'Pass' ); if isSubsystem

setSubResultStatusText(ft,[ 'There are no unconnected lines, ' ...

'input ports, and output ports in this subsystem.' ]); else

setSubResultStatusText(ft,[ 'There are no unconnected lines, ' ...

'input ports, and output ports in this model.' ]); end

ResultStatus = true;

% Unconnected objects in model

% Set result status to 'Warning' and display text describing the status else

setSubResultStatus(ft, 'Warn' ); if ~isSubsystem

setSubResultStatusText(ft,[ 'The following lines, input ports, ' ...

'or output ports are not properly connected in the system: ' system]); else

setSubResultStatusText(ft,[ 'The following lines, input ports, or ' ...

'output ports are not properly connected in the subsystem: ' system]); end

% Specify recommended action to fix the warning

25-59

25

Create Model Advisor Checks

25-60

setRecAction(ft, 'Connect the specified blocks.' );

% Create a list of handles to problem objects

setListObj(ft,modelObj);

ResultStatus = false; end

% Pass the list template object to the Model Advisor

ResultDescription{end+1} = ft;

% Set overall check status mdladvObj.setCheckResultStatus(ResultStatus);

Check With Subchecks and Actions

Here is an example of a callback function for a custom check that finds and reports optimization settings. The check consists of two subchecks. The first reviews the Block

reduction optimization setting, and the second reviews the Conditional input branch

execution optimization setting.

A check with subchecks includes the following items in the results:

• A description of what the overall check is reviewing.

• A title for the subcheck.

• A description of what the subcheck is reviewing.

• References to standards, if applicable.

• The status of the subcheck.

• A description of the status.

• Results for the subcheck.

• Recommended actions to take when the subcheck does not pass.

• A line between the subcheck results.

% Sample Check 3 Callback Function: Check with Subchecks and Actions

% Find and report optimization settings function ResultDescription = OptmizationSettingCallback(system)

% Initialize variables system =getfullname(system); mdladvObj = Simulink.ModelAdvisor.getModelAdvisor(system); mdladvObj.setCheckResultStatus(false); % Default check status is 'Warning'

ResultDescription = {}; system = bdroot(system);

% Format results in a list using Model Advisor Result Template API

% Create a list template object for first subcheck ft1 = ModelAdvisor.FormatTemplate( 'ListTemplate' );

% Description of check in results setCheckText(ft1,[ 'Check model configuration for optimization settings that' ...

'can impact safety.' ]);

Model Advisor Code Examples

% Title and description of first subcheck setSubTitle(ft1, 'Verify Block reduction setting' ); setInformation(ft1, 'Check whether the ''Block reduction'' check box is cleared.' );

% Add See Also section with references to applicable standards docLinks{1} = {[ 'Reference DO-178B Section 6.3.4e - Source code ' ...

'is traceable to low-level requirements' ]};

% Review 'Block reduction' optimization setRefLink(ft1,docLinks); if strcmp(get_param(system, 'BlockReduction' ), 'off' )

% 'Block reduction' is cleared

% Set subresult status to 'Pass' and display text describing the status

setSubResultStatus(ft1, 'Pass' );

setSubResultStatusText(ft1, 'The ''Block reduction'' check box is cleared.' );

ResultStatus = true; else

% 'Block reduction' is selected

% Set subresult status to 'Warning' and display text describing the status

setSubResultStatus(ft1, 'Warn' );

setSubResultStatusText(ft1, 'The ''Block reduction'' check box is selected.' );

setRecAction(ft1,[ 'Clear the ''Optimization > Block reduction''' ...

' check box in the Configuration Parameters dialog box.' ]);

ResultStatus = false; end

ResultDescription{end+1} = ft1;

% Title and description of second subcheck ft2 = ModelAdvisor.FormatTemplate( 'ListTemplate' ); setSubTitle(ft2, 'Verify Conditional input branch execution setting' ); setInformation(ft2,[ 'Check whether the ''Conditional input branch execution''' ...

' check box is cleared.' ])

% Add See Also section and references to applicable standards docLinks{1} = {[ 'Reference DO-178B Section 6.4.4.2 - Test coverage ' ...

'of software structure is achieved' ]}; setRefLink(ft2,docLinks);

% Last subcheck, supress line setSubBar(ft2,false);

% Check status of the 'Conditional input branch execution' check box if strcmp(get_param(system, 'ConditionallyExecuteInputs' ), 'off' )

% The 'Conditional input branch execution' check box is cleared

% Set subresult status to 'Pass' and display text describing the status

setSubResultStatus(ft2, 'Pass' );

setSubResultStatusText(ft2,[ 'The ''Conditional input branch execution''' ...

'check box is cleared.' ]); else

% 'Conditional input branch execution' is selected

% Set subresult status to 'Warning' and display text describing the status

setSubResultStatus(ft2, 'Warn' );

setSubResultStatusText(ft2,[ 'The ''Conditional input branch execution''' ...

' check box is selected.' ]);

setRecAction(ft2,[ 'Clear the ''Optimization > Conditional input branch ' ...

'execution'' check box in the Configuration Parameters dialog box.' ]);

25-61

25

Create Model Advisor Checks

ResultStatus = false; end

ResultDescription{end+1} = ft2; % Pass list template object to Model Advisor mdladvObj.setCheckResultStatus(ResultStatus); % Set overall check status

% Enable Modify Settings button when check fails mdladvObj.setActionEnable(~ResultStatus);

Action Callback Function

The following is an example of an action callback function that fixes the optimization

settings that the Model Advisor reviews as defined in “Check With Subchecks and

Actions” on page 25-60.

% Sample Check 3 Action Callback Function: Check with Subresults and Actions

% Fix optimization settings function result = modifyOptmizationSetting(taskobj)

% Initialize variables result = ModelAdvisor.Paragraph(); mdladvObj = taskobj.MAObj; system = bdroot(mdladvObj.System);

% 'Block reduction' is selected

% Clear the check box and display text describing the change if ~strcmp(get_param(system, 'BlockReduction' ), 'off' )

set_param(system, 'BlockReduction' , 'off' );

result.addItem(ModelAdvisor.Text( ...

'Cleared the ''Block reduction'' check box.' ,{ 'Pass' }));

result.addItem(ModelAdvisor.LineBreak); end

% 'Conditional input branch execution' is selected

% Clear the check box and display text describing the change if ~strcmp(get_param(system, 'ConditionallyExecuteInputs' ), 'off' )

set_param(system, 'ConditionallyExecuteInputs' , 'off' );

result.addItem(ModelAdvisor.Text( ...

'Cleared the ''Conditional input branch execution'' check box.' , ...

{ 'Pass' })); end

For an example of an action callback function that updates all of the blocks in the model

with the font specified in the Input Parameter defined in “Input Parameter Definition” on page 25-53, review the customization source code in slvnvdemo_mdladv.

25-62

26

Create Custom Configurations by

Organizing Checks and Folders

• “Create Custom Configurations” on page 26-2

• “Create Configurations by Organizing Checks and Folders” on page 26-3

• “Create Procedural-Based Configurations” on page 26-4

• “Organize Checks and Folders Using the Model Advisor Configuration Editor” on page

26-5

• “Organize Customization File Checks and Folders” on page 26-12

• “Verify and Use Custom Configurations” on page 26-18

• “Model Advisor Code Examples” on page 26-20

26

Create Custom Configurations by Organizing Checks and Folders

Create Custom Configurations

You can use the Model Advisor APIs and Model Advisor Configuration Editor available with Simulink Verification and Validation to do the tasks listed in the following table.

To

Create custom configurations by organizing

Model Advisor checks and folders.

Specify the order in which you make changes to your model.

See

“Organize Checks and Folders Using the

Model Advisor Configuration Editor”

“Create a Procedural-Based Configuration” on page 27-5

Deploy custom configuration to your users. “How to Deploy Custom Configurations” on page 28-3

26-2

Create Configurations by Organizing Checks and Folders

Create Configurations by Organizing Checks and Folders

To customize the Model Advisor with MathWorks and custom checks, perform the following tasks:

1

Review the information in “Requirements for Customizing the Model Advisor” on page 24-2.

2 Optionally, author custom checks in a customization file. See “Create Model Advisor

Checks”.

3 Organize the checks into new and existing folders to create custom configurations.

See “Organize and Deploy Model Advisor Checks”.

a Identify which checks you want to include in your custom Model Advisor configuration. You can use MathWorks checks and/or custom checks.

b Create the custom configurations using either of the following:

• Model Advisor Configuration Editor - “Organize Checks and Folders Using the Model Advisor Configuration Editor” on page 26-5.

• A customization file - “Organize Customization File Checks and Folders” on page 26-12.

c

Verify the custom configuration. See “Verify and Use Custom Configurations” on page 26-18.

4 Optionally, deploy the custom configurations to your users. See “Organize and

Deploy Model Advisor Checks”.

5 Verify that models comply with modeling guidelines. See “Run Model Checks”.

26-3

26

Create Custom Configurations by Organizing Checks and Folders

Create Procedural-Based Configurations

You can create a procedural-based configuration that allows you to specify the order in which you make changes to your model. You organize checks into procedures using the procedures API. A check in a procedure does not run until the previous check passes.

A procedural-based configuration runs until a check fails, requiring you to modify the model to pass the check and proceed to the next check. Changes you make to your model to pass the checks therefore follow a specific order.

To create a procedural-based configuration, perform the following tasks:

1

Review the information in “Requirements for Customizing the Model Advisor” on page 24-2.

2 Decide on order of changes to your model.

3 Identify checks that provide information about the modifications you want to make to your model. For example, if you want to modify your model optimization settings, the Check optimization settings check provides information about the settings. You can use custom checks and checks provided by MathWorks.

4 Optionally, author custom checks in a customization file. See “Create Model Advisor

Checks”.

5 Organize the checks into procedures for a procedural-based configuration. See

“Create a Procedural-Based Configuration”.

a Create procedures using the procedure API. For detailed information, see

“Create Procedures Using the Procedures API” on page 27-2.

b

Create the custom configuration by using a customization file. See “Organize

Customization File Checks and Folders” on page 26-12.

c

Verify the custom configuration as described in “Verify and Use Custom

Configurations” on page 26-18.

6 Optionally, deploy the custom configurations to your users. For detailed information, see “Organize and Deploy Model Advisor Checks”.

7 Verify that models comply with modeling guidelines. For detailed information, see

“Run Model Checks”.

26-4

Organize Checks and Folders Using the Model Advisor Configuration Editor

Organize Checks and Folders Using the Model Advisor

Configuration Editor

In this section...

“Overview of the Model Advisor Configuration Editor” on page 26-5

“Start the Model Advisor Configuration Editor” on page 26-9

“Organize Checks and Folders Using the Model Advisor Configuration Editor” on page

26-10

Overview of the Model Advisor Configuration Editor

When you start the Model Advisor Configuration Editor, two windows open; the Model

Advisor Configuration Editor and the Model Advisor Check Browser. The Configuration

Editor window consists of two panes: the Model Advisor Configuration Editor hierarchy and the Workflow. The Model Advisor Configuration Editor hierarchy lists the checks and folders in the current configuration. The Workflow on the right shows the common workflow you use to create a custom configuration.

26-5

26

Create Custom Configurations by Organizing Checks and Folders

Model Advisor Configuration Editor

When you select a folder or check in the Model Advisor Configuration Editor hierarchy, the Workflow pane changes to display information about the check or folder. You can change the display name of the check or folder in this pane.

26-6

Organize Checks and Folders Using the Model Advisor Configuration Editor

The Model Advisor Check Browser window includes a read-only list of available checks. If you delete a check in the Model Advisor Configuration Editor, you can retrieve a copy of it from the Model Advisor Check Browser.

Tip If you use a process callback function in a sl_customization file to hide checks and folders, the Model Advisor Configuration Editor and Model Advisor Check Browser do not display the hidden checks and folders. For a complete list of checks and folders, remove process callback functions and update the Simulink environment (see “Update the Environment to Include Your sl_customization File”).

26-7

26

Create Custom Configurations by Organizing Checks and Folders

Model Advisor Check Browser

Using the Model Advisor Configuration Editor, you can perform the following actions.

To...

Create new configurations

Find checks and folders in the Model Advisor

Check Browser

Add checks and folders to the configuration

Remove checks and folders from the configuration

Reorder checks and folders

Select...

File > New

View > Check Browser

Edit > Copy

Edit > Paste

Edit > New folder

The check or folder and drag and drop

Edit > Delete

Edit > Cut

Edit > Move up

26-8

Organize Checks and Folders Using the Model Advisor Configuration Editor

To...

Rename checks and folders

Select...

Edit > Move down

The check or folder and drag and drop

The check or folder and edit Display Name in right pane.

Note: MathWorks folder display names are restricted. When you rename a folder, you cannot use the restricted display names.

Allow or gray out the check box control for checks and folders

Edit > Enable

Edit > Disable

Tip This capability is equivalent to enabling checks, described in “Display and Enable

Checks”.

Save the configuration as a MAT file for use and distribution

Set the configuration so it opens by default in the Model Advisor

Restore the MathWorks default configuration

Load and edit saved configurations

File > Save

File > Save As

File > Set Current Configuration as Default

File > Restore Default Configuration

File > Open

Start the Model Advisor Configuration Editor

Note:

• Before starting the Model Advisor Configuration Editor, verify that the current folder is writable. If the folder is not writable, you see an error message when you start the

Model Advisor Configuration Editor.

• The Model Advisor Configuration Editor uses the Simulink project (slprj) folder (for details about storing reports and other relevant information, see “Model Reference

Simulation Targets”) in the current folder. If this folder does not exist in the current folder, the Model Advisor Configuration Editor creates it.

26-9

26

Create Custom Configurations by Organizing Checks and Folders

26-10

1 To include custom checks in the new Model Advisor configuration, update the

Simulink environment to include your sl_customization.m file. For more information, see “Update the Environment to Include Your sl_customization File”.

2 Start the Model Advisor Configuration Editor.

To start the Model Advisor

Configuration Editor...

Programmatically

Do this:

At the MATLAB command line, enter

Simulink.ModelAdvisor.openConfigUI

. For more information, see the Simulink.ModelAdvisor

function reference page.

From the Model Advisor a

Start the Model Advisor.

b

Select Settings > Open Configuration Editor.

The Model Advisor Configuration Editor and Model Advisor Check Browser windows open.

3

Optionally, to edit an existing configuration in the Model Advisor Configuration

Editor window: a Select File > Open.

b

In the Open dialog box, navigate to the configuration file that you want to edit.

c

Click Open.

Organize Checks and Folders Using the Model Advisor Configuration

Editor

The following tutorial steps you through creating a custom configuration.

1 Open the Model Advisor Configuration Editor at the MATLAB command line by

entering Simulink.ModelAdvisor.openConfigUI . For more options, see “Start the Model Advisor Configuration Editor” on page 26-9.

2 In the Model Advisor Configuration Editor, in the left pane, delete the By Product and By Task folders, to start with a blank configuration.

3 Select the root node which is labeled Model Advisor Configuration Editor.

4 In the toolbar, click the New Folder button to create a folder.

5 In the left pane, select the new folder.

Organize Checks and Folders Using the Model Advisor Configuration Editor

6 In the right pane, edit Display Name to rename the folder. For the purposes of this tutorial, rename the folder to Review Optimizations.

7 In the Model Advisor Check Browser window, in the Find field, enter optimization

to find Simulink > Check optimization settings.

8 Drag and drop Check optimization settings into Review Optimizations.

9 In the Model Advisor Check Browser window, find Simulink Verification and

Validation > Modeling Standards > DO-178C/DO-331Checks > Check safety-

related optimization settings.

10 Drag and drop Check safety-related optimization settings into Review

Optimizations.

11 In the Model Advisor Configuration Editor window, expand Review

Optimizations.

12 Rename Check optimization settings to Check Simulink optimization

settings.

13 Select File > Save As to save the configuration.

14

Name the configuration optimization_configuration.mat.

15

Close the Model Advisor Configuration Editor window.

Tip To move a check to the first position in a folder:

1

Drag the check to the second position.

2 Right-click the check and select Move up.

26-11

26

Create Custom Configurations by Organizing Checks and Folders

Organize Customization File Checks and Folders

In this section...

“Customization File Overview” on page 26-12

“Register Tasks and Folders” on page 26-13

“Define Custom Tasks” on page 26-14

“Define Custom Folders” on page 26-16

“Customization Example” on page 26-17

Note: While you can organize checks and folders within a customization file, use the

Model Advisor Configuration Editor.

Customization File Overview

The sl_customization.m file contains a set of functions for registering and defining custom checks, tasks, and groups. To set up the sl_customization.m file, follow the guidelines in this table.

Function sl_customization()

Description

Registers custom checks, tasks, folders, and callbacks with the Simulink customization manager at startup (see

“Register Checks and Process

Callbacks”).

One or more check definitions Defines custom checks (see

“Define Custom Checks”).

One or more task definitions

Required or Optional

Required for customizations to the Model Advisor.

Defines custom tasks (see

“Define Custom Tasks” on page

26-14).

Required for custom checks and to add custom checks to the By

Product folder.

Required to add custom checks to the Model Advisor, except when adding the checks to the

By Product folder. Write one task for each check that you add to the Model Advisor.

26-12

Organize Customization File Checks and Folders

Function

One or more groups

Description

Defines custom groups (see

“Define Custom Tasks” on page

26-14).

One process callback function Specifies actions that Simulink performs at startup and postexecution time (see “Define

Startup and Post-Execution

Actions Using Process Callback

Functions”).

Required or Optional

Required to add custom tasks to new folders in the Model

Advisor, except when adding a new subfolder to the By

Product folder. Write one group definition for each new folder.

Optional.

If the By Product folder is not displayed in the Model Advisor window, select Show By

Product Folder from the Settings > Preferences dialog box.

Register Tasks and Folders

• “Create sl_customization Function” on page 26-13

• “Register Tasks and Folders” on page 26-14

Create sl_customization Function

To add tasks and folders to the Model Advisor, create the sl_customization.m

file on your MATLAB path. Then create the sl_customization() function in the sl_customization.m

file on your MATLAB path.

Tip

• You can have more than one sl_customization.m file on your MATLAB path.

• Do not place an sl_customization.m file that customizes the Model Advisor in your root MATLAB folder or its subfolders, except for the matlabroot/work folder.

Otherwise, the Model Advisor ignores the customizations that the file specifies.

The sl_customization function accepts one argument, a customization manager object, as in this example:

26-13

26

Create Custom Configurations by Organizing Checks and Folders

26-14 function sl_customization(cm)

The customization manager object includes methods for registering custom checks, tasks, folders, and process callbacks. Use these methods to register customizations specific to your application, as described in the sections that follow.

Register Tasks and Folders

The customization manager provides the following methods for registering custom tasks and folders:

• addModelAdvisorTaskFcn (@factorygroupDefinitionFcn)

Registers the tasks that you define in factorygroupDefinitionFcn to the By

Task folder of the Model Advisor.

The factorygroupDefinitionFcn argument is a handle to the function that defines the checks to add to the Model Advisor as instances of the

ModelAdvisor.FactoryGroup

class (see “Define Custom Tasks” on page 26-14).

• addModelAdvisorTaskAdvisorFcn (@taskDefinitionFcn)

Registers the tasks and folders that you define in taskDefinitionFcn to the folder in the Model Advisor that you specify using the ModelAdvisor.Root.publish

method or the ModelAdvisor.Group class.

The taskDefinitionFcn argument is a handle to the function that defines custom tasks and folders. Simulink adds the checks and folders to the Model Advisor as

instances of the ModelAdvisor.Task or ModelAdvisor.Group classes (see “Define

Custom Tasks” on page 26-14).

Note:

The @ sign defines a function handle that MATLAB calls. For more information, see “At — @” in the MATLAB documentation.

Define Custom Tasks

• “Add Check to Custom or Multiple Folders Using Tasks” on page 26-15

• “Create Custom Tasks Using MathWorks Checks” on page 26-15

• “Display and Enable Tasks” on page 26-15

• “Define Where Tasks Appear” on page 26-16

Organize Customization File Checks and Folders

Add Check to Custom or Multiple Folders Using Tasks

You can use custom tasks for adding checks to the Model Advisor, either in multiple folders or in a single, custom folder. You define custom tasks in one or more functions that specify the properties of each instance of the ModelAdvisor.Task class. Define one instance of this class for each custom task that you want to add to the Model Advisor.

Then register the custom task, as described in “Register Tasks and Folders” on page

26-13. The following sections describe how to define custom tasks.

To add a check to multiple folders or a single, custom folder:

1 Create a check using the ModelAdvisor.Check class, as described in “Define

Custom Checks”.

2

Register a task wrapper for the check, as described in “Register Tasks and Folders” on page 26-13.

3 If you want to add the check to folders that are not already present, register and create the folders using the ModelAdvisor.Group class.

4 Add a check to the task using the ModelAdvisor.Task.setCheck method.

5

Add the task to each folder using the ModelAdvisor.Group.addTask method and the task ID.

Create Custom Tasks Using MathWorks Checks

You can add MathWorks checks to your custom folders by defining the checks as custom tasks. When you add the checks as custom tasks, you identify checks by the check ID.

To find MathWorks check IDs:

1 In the Model Advisor, select View > Source tab.

2

Navigate to the folder that contains the MathWorks check.

3

In the right pane, click Source. The Model Advisor displays the Title, TitleID, and

Source information for each check in the folder.

4 Select and copy the TitleID of the check that you want to add as a task.

Display and Enable Tasks

The Visible, Enable, and Value properties interact the same way for tasks as they do for checks (see “Display and Enable Checks”).

26-15

26

Create Custom Configurations by Organizing Checks and Folders

26-16

Define Where Tasks Appear

You can specify where the Model Advisor places tasks within the Model Advisor using the following guidelines:

• To place a task in a new folder in the Model Advisor Task Manager, use the

ModelAdvisor.Group

class. See “Define Custom Folders” on page 26-16.

• To place a task in a new folder in the By Task folder, use the

ModelAdvisor.FactoryGroup

class. See “Define Custom Folders” on page

26-16.

Define Custom Folders

• “About Custom Folders” on page 26-16

• “Add Custom Folders” on page 26-16

• “Define Where Custom Folders Appear” on page 26-17

About Custom Folders

Use folders to group checks in the Model Advisor by functionality or usage. You define custom folders in:

• A factory group definition function that specifies the properties of each instance of the

ModelAdvisor.FactoryGroup

class.

• A task definition function that specifies the properties of each instance of the

ModelAdvisor.Group

class. For more information about task definition functions,

see “Add Check to Custom or Multiple Folders Using Tasks” on page 26-15.

Define one instance of the group classes for each folder that you want to add to the Model

Advisor.

Add Custom Folders

To add a custom folder:

1

Create the folder using the ModelAdvisor.Group or

ModelAdvisor.FactoryGroup

classes.

2

Register the folder, as described in “Register Tasks and Folders” on page 26-13.

Organize Customization File Checks and Folders

Define Where Custom Folders Appear

You can specify the location of custom folders within the Model Advisor using the following guidelines:

• To define a new folder in the Model Advisor Task Manager, use the

ModelAdvisor.Group

class.

• To define a new folder in the By Task folder, use the ModelAdvisor.FactoryGroup

class.

Note: To define a new folder in the By Product folder, use the

ModelAdvisor.Root.publish

method within a custom check. For more information, see “Define Where Custom Checks Appear”. If the By Product folder is not displayed in the Model Advisor window, select Show By Product Folder from the Settings >

Preferences dialog box.

Customization Example

The Simulink Verification and Validation software provides an example that shows how to customize the Model Advisor by adding:

• Custom checks

• Check input parameters

• Check actions

• Check list views to call the Model Advisor Result Explorer

• Custom tasks to include the custom checks in the Model Advisor

• Custom folders for grouping the checks

• Custom procedures

• A process callback function

The example also provides the source code of the sl_customization.m file that executes the customizations.

To run the example:

1

At the MATLAB command line, type slvnvdemo_mdladv.

2

Follow the instructions in the model.

26-17

26

Create Custom Configurations by Organizing Checks and Folders

Verify and Use Custom Configurations

In this section...

“Update the Environment to Include Your sl_customization File” on page 26-18

“Verify Custom Configurations” on page 26-18

Update the Environment to Include Your sl_customization File

When you start Simulink, it reads customization (sl_customization.m) files. If you change the contents of your customization file, update your environment by performing these tasks:

1 If you previously started the Model Advisor: a Close the model from which you started the Model Advisor b

Clear the data associated with the previous Model Advisor session by removing the slprj folder from your working folder.

2 At the MATLAB command line, enter: sl_refresh_customizations

3 Open your model.

4

Start the Model Advisor.

Verify Custom Configurations

To verify a custom configuration:

1

If you created custom checks, or created the custom configuration using the sl_customization

method, update the Simulink environment. For more

information, see “Update the Environment to Include Your sl_customization File” on page 26-18.

2 Open a model.

3

From the model window, start the Model Advisor.

4 Select Settings > Load Configuration. If you see a warning that the Model

Advisor report corresponds to a different configuration, click Load to continue.

5 In the Open dialog box, navigate to and select your custom configuration. For

example, if you created the custom configuration in “Organize Checks and

26-18

Verify and Use Custom Configurations

Folders Using the Model Advisor Configuration Editor” on page 26-10, select

optimization_configuration.mat

.

6 When the Model Advisor reopens, verify that the configuration contains the new folders and checks. For example, the Review Optimizations folder and the Check

Simulink optimization settings and Check safety-related optimization

settings checks.

7 Optionally, run the checks.

26-19

26

Create Custom Configurations by Organizing Checks and Folders

Model Advisor Code Examples

In this section...

“Register Custom Tasks and Folders” on page 26-20

“Task Definition Function” on page 26-20

“Group Definition” on page 26-21

Register Custom Tasks and Folders

The following code example registers custom tasks and folders: function sl_customization(cm)

% register custom factory group cm.addModelAdvisorTaskFcn(@defineModelAdvisorTasks);

% register custom tasks.

cm.addModelAdvisorTaskAdvisorFcn(@defineTaskAdvisor);

Note: If you add custom checks and process callbacks within the sl_customization.m

file, include methods for registering the checks and process callbacks in the sl_customization

function. For more information, see “Register Checks and Process

Callbacks”.

Task Definition Function

The following is an example of a task definition function. This function defines three tasks. The tasks are derived from the checks defined in “Check Definition Function”.

For an example of placing these tasks into a custom group, see “Group Definition” on page 26-21.

% Defines Model Advisor tasks and a custom folder

% Add checks to a custom folder using task definitions function defineTaskAdvisor mdladvRoot = ModelAdvisor.Root;

% Define task that uses Sample Check 1: Informational check

MAT1 = ModelAdvisor.Task( 'mathworks.example.task.configManagement' );

MAT1.DisplayName = 'Informational check for model configuration management' ;

MAT1.Description = 'Display model configuration and checksum information.' ; setCheck(MAT1, 'mathworks.example.configManagement' );

26-20

Model Advisor Code Examples mdladvRoot.register(MAT1);

% Define task that uses Sample Check 2: Basic Check with Pass/Fail Status

MAT2 = ModelAdvisor.Task( 'mathworks.example.task.unconnectedObjects' );

MAT2.DisplayName = 'Check for unconnected objects' ; setCheck(MAT2, 'mathworks.example.unconnectedObjects' );

MAT2.Description = [ 'Identify unconnected lines, input ports, and output ' ...

'ports in the model or subsystem.' ]; mdladvRoot.register(MAT2);

% Define task that uses Sample Check 3: Check with Subresults and Actions

MAT3 = ModelAdvisor.Task( 'mathworks.example.task.optimizationSettings' );

MAT3.DisplayName = 'Check safety-related optimization settings' ;

MAT3.Description = [ 'Check model configuration for optimization ' ...

'settings that can impact safety.' ];

MAT3.setCheck( 'mathworks.example.optimizationSettings' ); mdladvRoot.register(MAT3);

% Custom folder definition

MAG = ModelAdvisor.Group( 'mathworks.example.ExampleGroup' );

MAG.DisplayName = 'My Group' ;

% Add tasks to My Group folder addTask(MAG, MAT1); addTask(MAG, MAT2); addTask(MAG, MAT3);

% Add My Group folder to the Model Advisor under 'Model Advisor' (root) mdladvRoot.publish(MAG);

Group Definition

The following is an example of a group definition. The definition places the tasks defined

in “Task Definition Function” on page 26-20 inside a folder called My Group under

the Model Advisor root. The task definition function includes this group definition.

% Custom folder definition

MAG = ModelAdvisor.Group( 'mathworks.example.ExampleGroup' );

MAG.DisplayName= 'My Group' ;

% Add tasks to My Group folder

MAG.addTask(MAT1);

MAG.addTask(MAT2);

MAG.addTask(MAT3);

% Add My Group folder to the Model Advisor under 'Model Advisor' (root) mdladvRoot.publish(MAG);

The following is an example of a factory group definition function. The definition places the checks defined in “Check Definition Function” into a folder called Demo Factory

Group inside of the By Task folder.

function defineModelAdvisorTasks mdladvRoot = ModelAdvisor.Root;

% --- sample factory group

26-21

26

Create Custom Configurations by Organizing Checks and Folders rec = ModelAdvisor.FactoryGroup( 'com.mathworks.sample.factorygroup' ); rec.DisplayName= 'Demo Factory Group' ; rec.Description= 'Demo Factory Group' ; rec.addCheck( 'mathworks.example.configManagement' ); rec.addCheck( 'mathworks.example.unconnectedObjects' ); rec.addCheck( 'mathworks.example.optimizationSettings' ); mdladvRoot.publish(rec); % publish inside By Task

26-22

Create Procedural-Based Model

Advisor Configurations

27

• “Create Procedures” on page 27-2

• “Create a Procedural-Based Configuration” on page 27-5

27

Create Procedural-Based Model Advisor Configurations

Create Procedures

In this section...

“What Is a Procedure?” on page 27-2

“Create Procedures Using the Procedures API” on page 27-2

“Define Procedures” on page 27-2

What Is a Procedure?

A procedure is a series of checks. The checks in a procedure depend on passing the previous checks. If Check A is the first check in a procedure and Check B follows, the

Model Advisor does not run Check B until Check A passes. Checks A and B can be either custom or provided by MathWorks.

You create procedures with the ModelAdvisor.Procedure class API. You first add the checks to tasks, which are wrappers for the checks. The tasks are added to procedures.

See “Create Procedures Using the Procedures API” on page 27-2.

When creating procedural checks, be aware of potential conflicts with the checks. Verify that it is possible to pass both checks.

Create Procedures Using the Procedures API

You use the ModelAdvisor.Procedure class to create procedural checks.

1 Add each check to a task using the ModelAdvisor.Task.setCheck method. The task is a wrapper for the check. You cannot add checks directly to procedures. For

more information, see “Define Custom Tasks” on page 26-14.

2

Add each task to a procedure using the ModelAdvisor.Procedure.addTask

method.

Define Procedures

You define procedures in a procedure definition function that specifies the properties of each instance of the ModelAdvisor.Procedure class. Define one instance of the procedure class for each procedure that you want to add to the Model Advisor. Then register the procedure using the ModelAdvisor.Root.register method.

27-2

Create Procedures

Add Subprocedures and Tasks to Procedures

You can add subprocedures or tasks to a procedure. The tasks are wrappers for checks.

• Use the ModelAdvisor.Procedure.addProcedure method to add a subprocedure to a procedure.

• Use the ModelAdvisor.Procedure.addTask method to add a task to a procedure.

Define Where Procedures Appear

You can specify where the Model Advisor places a procedure using the

ModelAdvisor.Group.addProcedure

method.

Procedure Definition

The following code example adds procedures to a group:

%Create three procedures

MAP1=ModelAdvisor.Procedure('com.mathworks.sample.myProcedure1');

MAP2=ModelAdvisor.Procedure('com.mathworks.sample.myProcedure2');

MAP3=ModelAdvisor.Procedure('com.mathworks.sample.myProcedure3');

%Create a group

MAG = ModelAdvisor.Group('com.mathworks.sample.myGroup');

%Add the three procedures to the group addProcedure(MAG, MAP1); addProcedure(MAG, MAP2); addProcedure(MAG, MAP3);

%register the group and and procedures mdladvRoot = ModelAdvisor.Root; mdladvRoot.register(MAG); mdladvRoot.register(MAP1); mdladvRoot.register(MAP2); mdladvRoot.register(MAP3);

The following code example adds subprocedures to a procedure:

%Create a procedures

MAP = ModelAdvisor.Procedure('com.mathworks.example.Procedure');

%Create 3 sub procedures

MAP1=ModelAdvisor.Procedure('com.mathworks.example.procedure_sub1');

27-3

27

Create Procedural-Based Model Advisor Configurations

MAP2=ModelAdvisor.Procedure('com.mathworks.example.procedure_sub2');

MAP3=ModelAdvisor.Procedure('com.mathworks.example.procedure_sub3');

%Add sub procedures to procedure addProcedure(MAP, MAP1); addProcedure(MAP, MAP2); addProcedure(MAP, MAP3);

%register the procedures mdladvRoot = ModelAdvisor.Root; mdladvRoot.register(MAP); mdladvRoot.register(MAP1); mdladvRoot.register(MAP2); mdladvRoot.register(MAP3);

The following code example adds tasks to a procedure:

%Create three tasks

MAT1=ModelAdvisor.Task('com.mathworks.tasksample.myTask1');

MAT2=ModelAdvisor.Task('com.mathworks.tasksample.myTask2');

MAT3=ModelAdvisor.Task('com.mathworks.tasksample.myTask3');

%Create a procedure

MAP = ModelAdvisor.Procedure('com.mathworks.tasksample.myProcedure');

%Add the three tasks to the procedure addTask(MAP, MAT1); addTask(MAP, MAT2); addTask(MAP, MAT3);

%register the procedure and tasks mdladvRoot = ModelAdvisor.Root; mdladvRoot.register(MAP); mdladvRoot.register(MAT1); mdladvRoot.register(MAT2); mdladvRoot.register(MAT3);

27-4

Create a Procedural-Based Configuration

Create a Procedural-Based Configuration

In this example, you examine a procedural-based configuration.

1 At the MATLAB command line, type slvnvdemo_mdladv.

2 In the model window, select View demo sl_customization.m. The sl_customization.m

file opens in the MATLAB Editor window.

The file contains three checks created in the function defineModelAdvisorChecks

:

• ModelAdvisor.Check('com.mathworks.sample.Check1') - Checks

Simulink block fonts.

• ModelAdvisor.Check('com.mathworks.sample.Check2') - Checks

Simulink window screen color.

• ModelAdvisor.Check('com.mathworks.sample.Check3') - Checks model optimization settings.

Each check has a set of fix actions.

3 In the sl_customization.m file, examine the function defineTaskAdvisor.

• The ModelAdvisor.Procedure class API creates procedures My Procedure and My sub_Procedure:

% Define procedures

MAP = ModelAdvisor.Procedure('com.mathworks.sample.ProcedureSample');

MAP.DisplayName='My Procedure';

MAP_sub = ModelAdvisor.Procedure('com.mathworks.sample.sub_ProcedureSample');

MAP_sub.DisplayName='My sub_Procedure';

• The ModelAdvisor.Task class API creates tasks MAT4, MAT5, and MAT6. The

ModelAdvisor.Task.setCheck

method adds the checks to the tasks:

% Define tasks

MAT4 = ModelAdvisor.Task('com.mathworks.sample.TaskSample4');

MAT4.DisplayName='Check Simulink block font';

MAT4.setCheck('com.mathworks.sample.Check1'); mdladvRoot.register(MAT4);

MAT5 = ModelAdvisor.Task('com.mathworks.sample.TaskSample5');

MAT5.DisplayName='Check Simulink window screen color';

MAT5.setCheck('com.mathworks.sample.Check2'); mdladvRoot.register(MAT5);

27-5

27

Create Procedural-Based Model Advisor Configurations

MAT6 = ModelAdvisor.Task('com.mathworks.sample.TaskSample6');

MAT6.DisplayName='Check model optimization settings';

MAT6.setCheck('com.mathworks.sample.Check3'); mdladvRoot.register(MAT6);

• The ModelAdvisor.Procedure.addTask method adds task MAT4 to

My Procedure

and tasks MAT5 and MAT6 to My sub_Procedure. The

ModelAdvisor.Procedure.addProcedure

method adds My sub_Procedure to My Procedure:

% Add tasks to procedures:

% Add Task4 to MAP

MAP.addTask(MAT4);

% Now Add Task5 and Task6 to MAP_sub

MAP_sub.addTask(MAT5);

MAP_sub.addTask(MAT6);

% Include the Sub-Procedure in the Procedure

MAP.addProcedure(MAP_sub);

4

From the model window, select Analysis > Model Advisor > Model Advisor to open the Model Advisor.

5

A System Selector — Model Advisor dialog box opens. Click OK. The Model

Advisor window opens.

6 In the left pane, expand My Procedure > My sub_Procedure. The Check

Simulink block font check is in the My Procedure folder. My sub_Procedure contains

Check Simulink window screen color and Check model optimization settings.

27-6

7 In the left pane of the Model Advisor, select My Procedure. In the right pane of the Model Advisor, click Run All. The Model Advisor Check Simulink block font check fails. The Model Advisor does not check the remaining two checks in the My sub_Procedure folder. Running the checks in the My sub_Procedure folder depends on passing the Check Simulink block font check.

Create a Procedural-Based Configuration

8 In the Action section of the Model Advisor dialog box, click Fix block fonts.

9 In the left pane of the Model Advisor, select My Procedure. In the right pane of the

Model Advisor, click Run All. The Check Simulink block font check passes. The

Model Advisor runs the Check Simulink window screen color check. This check fails and the Model Advisor stops checking.

10 In the Action section of the Model Advisor dialog box, click Fix window screen

color.

11 In the left pane of the Model Advisor, select My sub_Procedure. In the right pane of the Model Advisor, click Run All. The Check Simulink window screen color check passes. The Model Advisor runs the Check model optimization settings check. This check warns.

12 In the Action section of the Model Advisor dialog box, click Fix model

optimization settings.

13 In the left pane of the Model Advisor, select Check model optimization settings.

In the right pane of the Model Advisor, click Run This Task. The Check model optimization settings check passes.

27-7

Deploy Custom Configurations

• “Overview of Deploying Custom Configurations” on page 28-2

• “How to Deploy Custom Configurations” on page 28-3

• “Manually Load and Set the Default Configuration” on page 28-4

• “Automatically Load and Set the Default Configuration” on page 28-5

28

28

Deploy Custom Configurations

Overview of Deploying Custom Configurations

In this section...

“About Deploying Custom Configurations” on page 28-2

“Deploying Custom Configurations Workflow” on page 28-2

About Deploying Custom Configurations

When you create a custom configuration, often you deploy the custom configuration to your development group. Deploying the custom configuration allows your development group to review models using the same checks.

After you create a custom configuration, you can use it in the Model Advisor, or deploy the configuration to your users. You can deploy custom configurations whether you created the configuration using the Model Advisor Configuration Editor or within the customization file.

Deploying Custom Configurations Workflow

When you deploy custom configurations, you:

1 Optionally author custom checks, as described in “Create Model Advisor Checks”.

2 Organize checks and folders to create custom configurations, as described in “Create

Custom Configurations”.

3

Deploy the custom configuration to your users, as described in “How to Deploy

Custom Configurations” on page 28-3.

28-2

How to Deploy Custom Configurations

How to Deploy Custom Configurations

To deploy a custom configuration:

1 Determine which files to distribute. You might need to distribute more than one file.

If You...

Created custom checks

Using the...

Customization file

Distribute...

• sl_customization.m

• Files containing check and action callback functions (if separate)

Configuration MAT file Organized checks and folders

Model Advisor

Configuration Editor

Customization file sl_customization.m

2

Distribute the files and tell the user to include these files on the MATLAB path.

3

Instruct the user to load the custom configuration. For more details, see “Manually

Load and Set the Default Configuration” on page 28-4 or “Automatically Load and Set the Default Configuration” on page 28-5.

28-3

28

Deploy Custom Configurations

Manually Load and Set the Default Configuration

When you use the Model Advisor, you can load any configuration. Once you load a configuration, you can set it so that the Model Advisor use that configuration every time you open the Model Advisor.

1 Open the Model Advisor.

2 Select Settings > Load Configuration.

3 In the Open dialog box, navigate to and select the configuration file that you want to edit.

4 Click Open.

Simulink reloads the Model Advisor using the new configuration.

5 Optionally, when the Model Advisor opens, set the current configuration as the default by selecting File > Set Current Configuration as Default.

28-4

Automatically Load and Set the Default Configuration

Automatically Load and Set the Default Configuration

When you use the Model Advisor, you can automatically set the default configuration by modifying an sl_customization.m file. For more information on creating the sl_customization.m

file, see “Register Checks and Process Callbacks” on page 25-27.

1

Place a configuration MAT file on your MATLAB path. For more information on

MAT files, see “Organize Checks and Folders Using the Model Advisor Configuration

Editor” on page 26-5

2

Modify your sl_customization.m file by adding the function: function [checkCellArray taskCellArray] = ModelAdvisorProcessFunction ...

(stage, system, checkCellArray, taskCellArray)

switch stage

case 'configure'

ModelAdvisor.setConfiguration('qeAPIConfigFilePath.mat'); end

In the function, replace qeAPIConfigFilePath.mat with the name of the configuration MAT file in step 1.

3 The sl_customization.m file is loaded every time you start the Model Advisor, using qeAPIConfigFilePath.mat as the default configuration. For more

information, see “Update the Environment to Include Your sl_customization File” on page 26-18.

Tip You can restore the MathWorks default configuration by selecting File > Restore

Default Configuration.

28-5

advertisement

Was this manual useful for you? Yes No
Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Download PDF

advertisement