DO Qualification Kit

Simulink® Code Inspector™

Tool Operational Requirements

R2015a, March 2015

How to Contact MathWorks
Latest news: www.mathworks.com
Sales and services: www.mathworks.com/sales_and_services
User community: www.mathworks.com/matlabcentral
Technical support: www.mathworks.com/support/contact_us
Phone: 508-647-7000

The MathWorks, Inc.

3 Apple Hill Drive
Natick, MA 01760-2098
DO Qualification Kit: Simulink® Code Inspector™ Tool Operational Requirements
© COPYRIGHT 2012–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
March 2012 New for Version 1.6 (Applies to Release 2012a)
September 2012 Revised for Version 2.0 (Applies to Release 2012b)
March 2013 Revised for Version 2.1 (Applies to Release 2013a)
September 2013 Revised for Version 2.2 (Applies to Release 2013b)
March 2014 Revised for Version 2.3 (Applies to Release 2014a)
October 2014 Revised for Version 2.4 (Applies to Release 2014b)
March 2015 Revised for Version 2.5 (Applies to Release 2015a)
Contents
1 Introduction ...................................................................................................................................... 1-1
1.1 Simulink Code Inspector Product Description ........................................................................ 1-2
2 Operational Requirements ................................................................................................................ 2-1
2.1 Code Inspector Report Operational Requirements .................................................................. 2-2
2.2 Code Inspection User Information ........................................................................................ 2-10
3 Installation ........................................................................................................................................ 3-1
4 Operational Environment ................................................................................................................. 4-1

v
vi
1 Introduction

This document comprises the Tool Operational Requirements (Reference DO-330 Section
10.3.1) for the following capabilities of the Simulink® Code Inspector™ verification product:

 Code inspection report

The document identifies:

 Features of the Simulink Code Inspector product.

 The environment in which the Simulink Code Inspector product is installed (Reference
DO-330, Sections 10.2.4 and 10.3.2).

This document is intended for use in the DO-330 tool qualification process for TQL-4 tools. The
applicant needs to:

 Review the Tool Operational Requirements for applicability in the project or program
under consideration.
 Configure the Tool Operational Requirements in the project or program’s configuration
management system.
 Complete the Tool Operational Requirements and make the document available for review.

For more information about the following products, see the MathWorks® Documentation
Center, R2015a:

 Simulink Code Inspector

 Simulink®
1.1 Simulink Code Inspector Product Description
Automate source code reviews for safety standards
Simulink® Code Inspector automatically compares generated code with its source model to
satisfy code-review objectives in DO-178 and other high-integrity standards. The code inspector
systematically examines blocks, state diagrams, parameters, and settings in a model to determine
whether they are structurally equivalent to operations, operators, and data in the generated code.
Simulink Code Inspector provides detailed model-to-code and code-to-model traceability
analysis. It generates structural equivalence and traceability reports that you can submit to
certification authorities to satisfy DO-178 software coding verification objectives.

Key Features
 Structural equivalence analysis and reports
 Bidirectional traceability analysis and reports
 Compatibility checker to restrict model, block, state diagrams, and coder usage to operations
typically used in high-integrity applications
 Tool independence from Simulink® code generators

Simulink Code Inspector carries out translation validation. Inputs to the Code Inspector are a
Simulink model and the C source code generated by the Embedded Coder® code generator for
the model. To be compatible with code inspection, the code generated by Embedded Coder
must comply with either the ANSI C89/C90 or ISO/IEC 9899:1990 standard.

The code inspector processes these two inputs into internal representations (IRs), called model
IR and code IR. These IRs are transformed into normalized representation’s to facilitate further
analysis. In this process, the model IR represents the expected pattern, and the code IR
constitutes the actual pattern to be verified. To verify the generated code, the Code Inspector
attempts to match the normalized model IR with the normalized code IR.

1-2
Figure 1 shows the architecture of Simulink Code Inspector.

Figure 1: Simulink Code Inspector Architecture

1-3
1-4
2 Operational Requirements
2.1 Code Inspector Report Operational Requirements
The Simulink® Code Inspector™ product includes the capability to generate a code inspection
report for a Simulink® model and its generated code. The report provides detailed analysis of
structural equivalence and bidirectional traceability between the model and the code generated
from the model.

The code inspection report contains the following major sections:

 Code Verification Results — Summary and detailed reports on verification of structural

equivalence between model and code elements. Categories include:

 Function Interface Verification

 Model To Code Verification
 Code To Model Verification
 Temporary Variable Usage
 Traceability Results — Summary and detailed reports on

 Model To Code Traceability

 Code To Model Traceability
Code inspection automatically compares generated code with its source model to satisfy code-
review objectives in DO-178C/DO-331 and other high-integrity standards. The code inspection
process builds an in-memory representation of the model that is independent of the code
generation process. The Simulink Code Inspector systematically examines blocks, parameters,
and settings in a model to determine whether they are structurally equivalent to operations,
operators, and data in the generated code, and generates reports that can be used to support
software certification.

2-2
Prior to code inspection, the Simulink Code Inspector provides compatibility checks to verify
model compatibility with code inspection. The model incompatibilities are either fatal or
nonfatal.

 Code generated from models with fatal incompatibilities cannot be verified. The user
is notified with a message and code inspection terminates.

 Code generated from models with nonfatal incompatibilities can be partially verified.
Although it might not be possible to fully verify the generated code, code inspection
continues.

The aspects of a Simulink model that are analyzed by code inspection include the following:

 Model and code compatibility

 Model interface
 Block behavior
 Stateflow® behavior
 MATLAB Function block behavior
 Block connectivity and execution order
 Data and file packaging
 Local variables
 Configuration parameters

The following table lists the Simulink Code Inspector capabilities that are supported by the DO
Qualification Kit. To claim certification credit, the user is responsible for determining the
applicability of the Simulink Code Inspector capabilities supported by the DO Qualification Kit
to their project.

2-3
Simulink Code Inspector — Operational Requirements Summary
Requirement ID Requirement
Model and Code Compatibility
MDLCOMPILE If a model does not compile,
Simulink Code Inspector shall
consider the model invalid and post
an error message.
INVSRCCODE If the source code cannot be parsed,
Simulink Code Inspector shall
consider the code invalid and post an
error message.
MDLFATAL Simulink Code Inspector shall detect
if the model is fatally incompatible
with code inspection and terminate
the inspection.
MDLNONFATAL Simulink Code Inspector shall detect
if the model is nonfatally
incompatible with code inspection
and, by default, continue the
inspection.
NONFATALCHOICE Simulink Code Inspector shall allow
the user to terminate code inspection
for nonfatal incompatibilities.
Model Interface
MDLINTFUNCGEN Simulink Code Inspector shall verify Model step function is missing.
that the model interface functions are
implemented in the generated code.
MDLINTDATAGEN Simulink Code Inspector shall verify Root input data structure for a bus is
that the model interface data
structures are implemented in the
generated code.
MDLINTFUNCSIG Simulink Code Inspector shall verify
that the model interface functions
have the expected signatures
MDLINTIOGEN Simulink Code Inspector shall verify
that the expected input and output
data structures are implemented in
the generated code.
Block Behavior
Example of Limitations
Detectable Condition
If a model does not compile, code None
inspection terminates with an error
message.
If source code cannot be parsed, code None
inspection terminates with an error
message.
Code inspection terminates when the None
model does not use an ert-based
system target file.
Code inspection continues when Sum None
block input and output ports do not
have the same data type.
Code inspection terminates for a None
nonfatally incompatible model and
user has speceted the option to
terminate inspection for a nonfatally
incompatible model.
None
Arrays and built-in types
missing. are supported for
inspection. For structures,
the name or tag is verified,
but not the structure fields.
Model step function argument None
sequence differs from function
prototype control specification.
External input for initialization Arrays and built-in types
function was not initialized as are supported for
expected. inspection. For structures,
the name or tag is verified,
but not the structure fields.
2-4
Requirement ID Requirement
BLKCOMPS Simulink Code Inspector shall verify
that code generated for a block
includes all components of
functionality.
BLKCOMPSEXP Simulink Code Inspector shall verify
that code generated for a block
includes only expected instances of
component functionality.
BLKCOMPSTRACE Simulink Code Inspector shall verify
that code segments trace back to
block component functionality and
that system logic code traces back to
system functionality.
BLKCOMPSCONFIG Simulink Code Inspector shall verify
that code for block component
functionality represents the current
block configuration.
BLKCOMPSSYSFUNC Simulink Code Inspector shall verify
that code for block component
functionality is in the corresponding
system function.
BLKCOMPSPROPS Simulink Code Inspector shall verify
that property settings in the code are
compliant with settings for
corresponding source blocks.
BLKCRL Simulink Code Inspector shall verify
that code generated for a block uses
functions and operations supported
for code inspection in the Code
Replacement Libraries (CRLs).
* For a list of blocks supported for code inspection, see “Supported Block Constraints” in the Simulink Code Inspector Tool
Requirements, R2015a.
Stateflow Behavior
SFFLOWGRAPH Simulink Code Inspector shall verify Stateflow does not generate a control
that the generated code execution
order and execution paths represent transition.
the execution order and execution
paths in the Stateflow Chart.
Example of
Detectable Condition
Code for a Unit Delay block does not None for blocks supported
include code for updating its state for inspection.*
variable.
Code includes two independent
addition operations that trace to the
same Sum block.
A segment of code exists that does
not trace back to a block source.
A Relational Operator block is
configured for an equal (==)
operation, but it traces to code that
applies a not equal (!=) operation.
The output code for a Unit Delay
block is in the start function of the
parent system.
A Gain block with an output data
type of double traces to code that
assigns the block output to variable of
type real32_T.
Code for Sqrt block does not use a
function or operation supported for
code inspection in the CRL.
flow with more than 1 default
Limitations
None for blocks supported
for inspection.*
None for blocks supported
for inspection.*
None for blocks supported
for inspection.*
None for blocks supported
for inspection.*
None for blocks supported
for inspection.*
For a list of functions and
operations supported for
code inspection, see
“Supported Functions and
Operations in Code
Replacement Libraries” in
the Simulink Code
Inspector Tool
Requirements, R2015a.
See “Stateflow Charts” in
the Simulink Code
Inspector Tool
Requirements, R2015a.
2-5
Requirement ID Requirement
SFSTATES Simulink Code Inspector shall verify
that the code generated for a state
represents the corresponding state in
the model, including entry, during,
and exit actions.
SFTRANSITION Simulink Code Inspector shall verify
that the code generated for a
transition represents the
corresponding transition in the
model, including conditions and
actions.
SFJUNCTION Simulink Code Inspector shall verify
that the code generated for a junction
represents the corresponding
junction in the model and includes
all transition paths into and out of
the junction.
SFDATA Simulink Code Inspector shall verify
that the Stateflow data in the
generated code represents the model
data.
SFEVENT Simulink Code Inspector shall verify
that the code generated for
function-call event represents
the function-call event in the
model.
SFGRAPHFUNC Simulink Code Inspector shall verify
that the code generated for a
graphical function represents the
graphical function in the model,
including the control flow.
SFSLFUNC Simulink Code Inspector shall verify
that the code generated for a
Simulink function represents the
Simulink function in the model.
MATLAB Function block behavior
MLFUNCFLOW Simulink Code Inspector shall verify
that the generated code execution
order and execution paths represent
the execution order and execution
paths in the MATLAB function.
Example of Limitations
Detectable Condition
Stateflow does not generate a control See “Stateflow States” in
flow with more than 1 default the Simulink Code
transition. Inspector Tool
Requirements, R2015a.
A condition action uses operator cos See “Stateflow
and the generated code has operator Transitions” in the
sin. Simulink Code Inspector
Tool Requirements,
R2015a.
An unconditional transition executing See “Stateflow Junctions”
last in the chart is executed first in the in the Simulink Code
generated code. Inspector Tool
Requirements, R2015a.
Output of Stateflow block with data See “Stateflow Data and
type uint32_T traces to code that Events” in the Simulink
assigns the block output to variable of Code Inspector Tool
data type int8_T. Requirements, R2015a.
Output trigger type is Either edge See “Stateflow Data and
instead of function-call. Events” in the Simulink
Code Inspector Tool
Requirements, R2015a.
Stateflow graphical function property See “Stateflow Graphical
InlineOption is set to Inline Functions” in the Simulink
but the generated code has a Code Inspector Tool
function. Requirements, R2015a.
Generated code does not inline the See “Stateflow Simulink
correct Simulink function when Functions” in the Simulink
Simulink functions exist in both a Code Inspector Tool
chart and a state within the chart. Requirements, R2015a.
In a MATLAB Function block, a See “Code in MATLAB
variable is updated after it is Functions” in the Simulink
consumed. However, in the generated Code Inspector Tool
code, it is updated before it is Requirements, R2015a.
consumed.
2-6
Requirement ID Requirement
MLFUNCDATA Simulink Code Inspector shall verify
that the MATLAB function data in
the generated code represents the
model data.
MLFUNCOPER Simulink Code Inspector shall verify
that the code generated for
MATLAB function block operators
represents the current block
functionality.
Block Connectivity and Execution Order
BLKDATADEPEND Simulink Code Inspector shall verify
that the data dependency between
two block components is preserved
in the generated code.
BLKDATADEFUSE Simulink Code Inspector shall verify
that the data definition and use
dependencies in the code reflect the
dependencies in the model.
BLKINPUT Simulink Code Inspector shall verify
that the block input sources in the
code represent the block input
sources in the model.
BLKINDEX Simulink Code Inspector shall verify
that the data selection in the code
represents the data selection in the
model.
BLKEXEORDER Simulink Code Inspector shall verify
that the code execution order is
consistent with model element
execution order.
Data and File Packaging
Example of Limitations
Detectable Condition
Output of MATLAB Function block See “Data in MATLAB
with data type uint32 traces to code Functions” in the Simulink
that assigns the block output to Code Inspector Tool
variable of data type int32. Requirements, R2015a.
A statement in a MATLAB Function See “MATLAB Function
block using a plus (+) operator traces Blocks” in the Simulink
to code that performs a subtraction (-) Code Inspector Tool
operation. Requirements, R2015a.
A Gain block generates a None
multiplication operation with one
operand as its parameter and another
operand as a variable not written to
by the source of the Gain block.
A variable buffer is written to by the None
operation of block A. It is written to
again by the operation of block B
before a destination block for block A
has read the first value.
A Gain block uses input from a None
muxed signal for input ports 1 and 2
(in that order). The generated
multiplication code for the Gain
block represents the block input
sources in a different order than
expected. For example,
[y1, y2] = [k2, k1] .* [u1 u2]
or
[y1, y2] = [k1, k2] .* [u2 u1]
instead of
[y1, y2] = [k1, k2] .* [u1 u2]
A Gain block is fed by a Bus Selector None
that selects field f1 from bus foobus.
The multiplication operation in the
code is on foobus.
Gain block A feeds a Unit Delay None
block B. The update code of Unit
Delay block B appears before the
output code of Gain block A.
2-7
Requirement ID Requirement Example of Limitations
Detectable Condition
SIGOBJAUTO Simulink Code Inspector shall verify Signal sig1 is specified with the None
that signal objects with auto storage auto storage class. In the code,
classes in the code represent signal sig1 is represented as a global
objects with auto storage classes in variable instead of an element of the
the model. output data structure.
SIGOBJGLOB Simulink Code Inspector shall verify Signal sig1 is specified with the Code inspection is
that signal objects that do not have ExportedGlobal storage class. In supported for Simulink
an storage class in the code the code, sig1 is represented as a global and other storage
represent signal objects that do not global variable. classes with Custom
have an auto storage class in the Storage Class types set to
model. Unstructured.
PARAMOBJAUTO Simulink Code Inspector shall verify Parameter K is specified with the None
that parameter objects with storage auto storage class. In the code, the
class auto in the code represent literal value of the parameter is
parameter objects with storage class represented as a global variable
auto in the model. instead of its literal value or an
element of the parameter data
structure.
PARAMOBJTUNA Simulink Code Inspector shall verify Parameter K is specified with the Code inspection is
that parameter objects that do not ExportedGlobal storage class. In supported for Simulink
have an auto storage class in the the code, the literal value of the global and other storage
code represent parameter objects that parameter is represented as a global classes with Custom
do not have an auto storage class in variable. Storage Class types set to
the model. (For example, Simulink Unstructured.
Code Inspector will verify that
tunable parameters in the code
represent tunable parameters in the
model.)
PARAMINLINE Simulink Code Inspector shall verify A Gain block has its Gain parameter None
that Inlined parameter values in the set to 3.0. The code uses the literal
code represent Inlined parameter value 4.0 in the multiplication
values in the model. operation.
Local Variables
LCLVARUSED Simulink Code Inspector shall Local variable tmp is defined but not None
verify that all local variables are used.
used.
LCLVARDEF Simulink Code Inspector shall Local variable tmp is used, but is not None
verify that all local variables are defined.
defined before initial use.
Configuration Parameters

2-8
Requirement ID Requirement
SOLVERPANE Simulink Code Inspector shall detect Model specifies a single sample time,
configuration parameter settings on but the generated code has multirate
the Solver Pane that are not
compatible with code inspection.
DATAPANE Simulink Code Inspector shall detect
configuration parameter settings on
the Data Import/Export Pane that are
not compatible with code inspection.
OPTPANE Simulink Code Inspector shall detect
configuration parameter settings on
the Optimization Pane that are not
compatible with code inspection.
DIAGPANE Simulink Code Inspector shall detect
configuration parameter settings on
the Diagnostics Pane that are not
compatible with code inspection.
HWPANE Simulink Code Inspector shall detect
configuration parameter settings on
the Hardware Implementation Pane
that are not compatible with code
inspection.
MODREFPANE Simulink Code Inspector shall detect
configuration parameter settings on
the Model Referencing Pane that are
not compatible with code inspection.
CODEGENPANE Simulink Code Inspector shall detect
configuration parameter settings on
the Code Generation Pane that are
not compatible with code inspection.
Example of Limitations
Detectable Condition
See “Configuration
Parameter Constraints” in
code. the Simulink Code
Inspector Tool
Requirements, R2015a.
Configuration parameter See “Configuration
InitialState is set to ‘’, but the Parameter Constraints” in
generated code has code for initial the Simulink Code
state override. Inspector Tool
Requirements, R2015a.
Configuration parameter See “Configuration
StateBitSets is set to off, but Parameter Constraints” in
the generated code behaves as if this the Simulink Code
parameter is on. Inspector Tool
Requirements, R2015a.
Configuration parameter See “Configuration
UnderspecifiedInitializat Parameter Constraints” in
ionDetection is set to the Simulink Code
Simplified, but the generated Inspector Tool
code has code for Classic mode. Requirements, R2015a.
Configuration parameter See “Configuration
ProdBitPerShort is set to 16, Parameter Constraints” in
but the generated code uses 32. the Simulink Code
Inspector Tool
Requirements, R2015a.
A referenced model has None
ModelReferenceNumInstance
sAllowed set to Multi, but the
generated code for it has single-
instance code.
On Code Generation: Interface > See “Configuration
Data pane, configuration parameter Parameter Constraints” in
Interface is set to None, but the the Simulink Code
generated code has initialization code Inspector Tool
for error C-API interface. Requirements, R2015a.
2-9
2.2 Code Inspection User Information
For information about code inspection reports, see “Code Inspection Reports” in the Simulink
Code Inspector User’s Guide, R2015a.

For a list of blocks supported for code inspection, see “Supported Block Constraints” in the
Simulink Code Inspector Tool Requirements, R2015a.

For information about model configuration, block, Stateflow, and MATLAB function
constraints when using the Simulink Code Inspector to inspect code, see the following sections
in the Simulink Code Inspector Tool Requirements, R2015a:

 “Model Configuration Constraints”

 “Block Constraints”
 “Stateflow Constraints”
 “MATLAB Function Block Constraints”

For traceability between the operational requirements and tool requirements, see

qualkitdo_slci_tor_tr_trace.xlsx

To access these documents, on the MATLAB command line, type qualkitdo to open the
Artifacts Explorer. The documents are in Simulink Code Inspector > r2015a.

2-10
3 Installation

To use the Simulink® Code Inspector™ product, install the following MathWorks® products:

 MATLAB®
 Simulink®
 Simulink Code Inspector

To generate model code for inspection, install the following MathWorks products:

 MATLAB® Coder™
 Simulink® Coder™
 Embedded Coder®

Instructions for installing the products are available at the MathWorks Documentation Center,
R2015a:

Installation
3-2
4 Operational Environment

The DO Qualification Kit product supports the following operating environments for the
Simulink® Code Inspector™ product:

 Personal computer
 One of the following operating systems:
 Microsoft® Windows®
 Linux®1
 MATLAB® Software
 Simulink® Software
 Simulink Code Inspector software

1
Linux® is a registered trademark of Linus Torvalds.