Qualkitdo Slci Tor

DO Qualification Kit
Simulink Code Inspector

Tool Operational Requirements
R2015b, September 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 20122015 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 governments 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
September 2012
March 2013
September 2013
March 2014
October 2014
March 2015
September 2015
New for Version 1.6 (Applies to Release 2012a)

Revised for Version 2.0 (Applies to Release 2012b)
Revised for Version 2.1 (Applies to Release 2013a)
Revised for DO Qualification Kit Version 3.0 (Applies to Release 2015b)
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-11
3 Installation ........................................................................................................................................ 3-1
4 Operational Environment ................................................................................................................. 4-1
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 programs 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,
R2015b:

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 representations 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 codereview 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. The user is responsible for ensuring that the tool features they rely on to
eliminate, reduce or automate the process are sufficiently covered by Tool Operational
Requirements (reference DO-300 Section 6.2.1.aa).
2-3
Simulink Code Inspector Operational Requirements Summary

Requirement ID
Requirement
Example of
Detectable Condition
Limitations
If a model does not compile, code

inspection terminates with an error
message.
None
Model and Code Compatibility

MDLCOMPILE
INVSRCCODE
MDLFATAL
MDLNONFATAL
NONFATALCHOICE
If a model does not compile,

Simulink Code Inspector shall
consider the model invalid and post
an error message.
If the source code cannot be parsed,
consider the code invalid and post an
error message.
Simulink Code Inspector shall detect
if the model is fatally incompatible
with code inspection and terminate
the inspection.
if the model is nonfatally
incompatible with code inspection
and, by default, continue the
inspection.
Simulink Code Inspector shall allow
the user to terminate code inspection
for nonfatal incompatibilities.
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

nonfatally incompatible model and
user has selected the option to
terminate inspection for a nonfatally
incompatible model.
None
Simulink Code Inspector shall verify Model step function is missing.

that the model interface functions are
implemented in the generated code.
Simulink Code Inspector shall verify Root input data structure for a bus is
that the model interface data
missing.
structures are implemented in the
generated code.
None
Model Interface
MDLINTFUNCGEN
MDLINTDATAGEN
MDLINTFUNCSIG
MDLINTIOGEN
Simulink Code Inspector shall verify

that the model interface functions
have the expected signatures
that the expected input and output
data structures are implemented in
the generated code.
Model step function argument

sequence differs from function
prototype control specification.
External input for initialization
function was not initialized as
expected.
Arrays and built-in types

are supported for
inspection. For structures,
the name or tag is verified,
but not the structure fields.
None
Arrays and built-in types

are supported for
inspection. For structures,
the name or tag is verified,
but not the structure fields.
Block Behavior
2-4
Requirement ID
BLKCOMPS
Requirement

that code generated for a block
includes all components of
functionality.
BLKCOMPSEXP
that code generated for a block
includes only expected instances of
component functionality.
BLKCOMPSTRACE
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
that property settings in the code are
compliant with settings for
corresponding source blocks.
BLKCRL
that code generated for a block uses
functions and operations supported
for code inspection in the Code
Replacement Libraries (CRLs).
Example of
Limitations
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.
None for blocks supported

for inspection.*
A segment of code exists that does

not trace back to a block source.

for inspection.*
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.

for inspection.*
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.

for inspection.*

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, R2015b.
* For a list of blocks supported for code inspection, see Supported Block Constraints in the Simulink Code Inspector Tool
Stateflow Behavior
SFFLOWGRAPH
Simulink Code Inspector shall verify Stateflow does not generate a control
that the generated code execution
flow with more than 1 default
order and execution paths represent transition.
the execution order and execution
paths in the Stateflow Chart.
See Stateflow Charts in

the Simulink Code
Inspector Tool
2-5
Requirement ID
Requirement
Example of
SFSTATES

that the code generated for a state
represents the corresponding state in
the model, including entry, during,
and exit actions.
that the code generated for a
transition represents the
corresponding transition in the
model, including conditions and
actions.
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.
that the Stateflow data in the
generated code represents the model
data.
that the code generated for
function-call event represents
the function-call event in the
model.
graphical function represents the
graphical function in the model,
including the control flow.
Simulink function represents the
Simulink function in the model.
that the code generated for a truth
table represents the truth table in the
model.
Stateflow does not generate a control See Stateflow States in

flow with more than 1 default
the Simulink Code
transition.
Inspector Tool
SFTRANSITION
SFJUNCTION
SFDATA
SFEVENT
SFGRAPHFUNC
SFSLFUNC
SFTRUTHTABLE
Limitations
A condition action uses operator cos See Stateflow

and the generated code has operator Transitions in the
sin.
Tool Requirements,
R2015b.
An unconditional transition executing See Stateflow Junctions
last in the chart is executed first in the in the Simulink Code
generated code.
Inspector Tool
Output of Stateflow block with data

type uint32_T traces to code that
assigns the block output to variable of
data type int8_T.
Output trigger type is Either edge
instead of function-call.
See Stateflow Data and

Events in the Simulink
Code Inspector Tool
See Stateflow Data and
Events in the Simulink
Code Inspector Tool
Stateflow graphical function property

InlineOption is set to Inline
but the generated code has a
function.
See Stateflow Graphical

Functions in the Simulink
Code Inspector Tool
Generated code does not inline the

correct Simulink function when
Simulink functions exist in both a
chart and a state within the chart.
When Decision 1 is true, Action 1
should execute. However, in the
generated code, Action 2 executes.
See Stateflow Simulink

Code Inspector Tool
See Stateflow Truth
Tables in the Simulink
Code Inspector Tool
MATLAB Function block behavior
2-6
Requirement ID
Requirement
Example of
Limitations
MLFUNCFLOW

that the generated code execution
order and execution paths represent
the execution order and execution
paths in the MATLAB function.
that the MATLAB function data in
the generated code represents the
model data.
that the code generated for
MATLAB function block operators
represents the current block
functionality.
that the code generated for userwritten functions in MATLAB
Function blocks represents the userwritten function in the model.
In a MATLAB Function block, a

variable is updated after it is
consumed. However, in the generated
code, it is updated before it is
consumed.
Output of MATLAB Function block
with data type uint32 traces to code
that assigns the block output to
variable of data type int32.
A statement in a MATLAB Function
block using a plus (+) operator traces
to code that performs a subtraction (-)
operation.
See Code in MATLAB

Code Inspector Tool
A statement in a user-defined
function inside a MATLAB function
block uses the second element in an
array. However, in the generated
code, the third element is used.
See MATLAB Function

Blocks in the Simulink
Code Inspector Tool
MLFUNCDATA
MLFUNCOPER
MLFUNUSER
See Data in MATLAB

Code Inspector Tool
See MATLAB Function
Blocks in the Simulink
Code Inspector Tool
Block Connectivity and Execution Order

BLKDATADEPEND
BLKDATADEFUSE
BLKINPUT

that the data dependency between
two block components is preserved
in the generated code.
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.
Simulink Code Inspector shall verify A variable buffer is written to by the None
that the data definition and use
operation of block A. It is written to
dependencies in the code reflect the again by the operation of block B
dependencies in the model.
before a destination block for block A
has read the first value.
Simulink Code Inspector shall verify A Gain block uses input from a
None
that the block input sources in the
muxed signal for input ports 1 and 2
code represent the block input
(in that order). The generated
sources in the model.
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]
2-7
Requirement ID
Requirement
Example of
Limitations
BLKINDEX

that the data selection in the code
represents the data selection in the
model.
that the code execution order is
consistent with model element
execution order.
If a model contains blocks that
execute at different sample rates,
that the code for each block is called
at the proper rate and in the proper
execution order.
A Gain block is fed by a Bus Selector

that selects field f1 from bus foobus.
The multiplication operation in the
code is on foobus.
Gain block A feeds a Unit Delay
block B. The update code of Unit
Delay block B appears before the
output code of Gain block A.
An Abs block is executing at a
sample rate of 10 Hz. However, in
the generated code, the Abs block
executes at 20 Hz.
None
Signal sig1 is specified with the

auto storage class. In the code,
sig1 is represented as a global
variable instead of an element of the
output data structure.
Signal sig1 is specified with the
ExportedGlobal storage class. In
the code, sig1 is represented as a
global variable.
None
BLKEXEORDER
BLKMULTIRATE
None
See the Solver Pane and

Diagnostics Pane:
Sample Time constraints
in the Simulink Code
Inspector Tool
Data and File Packaging

SIGOBJAUTO
SIGOBJGLOB
PARAMOBJAUTO
PARAMOBJTUNA

that signal objects with auto storage
classes in the code represent signal
objects with auto storage classes in
the model.
that signal objects that do not have
an
storage class in the code
represent signal objects that do not
have an auto storage class in the
model.
that parameter objects with storage
class auto in the code represent
parameter objects with storage class
auto in the model.
Parameter K is specified with the

auto storage class. In the code, the
literal value of the parameter is
represented as a global variable
instead of its literal value or an
element of the parameter data
structure.
Simulink Code Inspector shall verify Parameter K is specified with the
that parameter objects that do not
ExportedGlobal storage class. In
have an auto storage class in the
the code, the literal value of the
code represent parameter objects that parameter is represented as a global
do not have an auto storage class in variable.
the model. (For example, Simulink
Code Inspector will verify that
tunable parameters in the code
represent tunable parameters in the
model.)
Code inspection is
supported for Simulink
global and other storage
classes with Custom
Storage Class types set to
Unstructured.
None
Code inspection is
supported for Simulink
global and other storage
classes with Custom
Storage Class types set to
Unstructured.
2-8
Requirement ID
Requirement
Example of
Limitations
PARAMINLINE

that Inlined parameter values in the
code represent Inlined parameter
values in the model.
A Gain block has its Gain parameter None

set to 3.0. The code uses the literal
value 4.0 in the multiplication
operation.
Local Variables
LCLVARUSED

verify that all local variables are
used.
LCLVARDEF
verify that all local variables are
defined before initial use.
Configuration Parameters
Local variable tmp is defined but not None

used.
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
code.
compatible with code inspection.
DATAPANE

configuration parameter settings on
the Data Import/Export Pane that are
not compatible with code inspection.
OPTPANE

the Optimization Pane that are not
DIAGPANE

the Diagnostics Pane that are not
HWPANE

the Hardware Implementation Pane
that are not compatible with code
inspection.
the Model Referencing Pane that are
See Configuration
Parameter Constraints in
the Simulink Code
Inspector Tool
Configuration parameter
See Configuration
InitialState is set to , but the Parameter Constraints in
the Simulink Code
generated code has code for initial
Inspector Tool
state override.
See Configuration
StateBitSets is set to off, but Parameter Constraints in
the generated code behaves as if this the Simulink Code
Inspector Tool
parameter is on.
See Configuration
UnderspecifiedInitializat Parameter Constraints in
the Simulink Code
ionDetection is set to
Inspector Tool
Simplified, but the generated
code has code for Classic mode. Requirements, R2015b.
See Configuration
ProdBitPerShort is set to 16,
the Simulink Code
but the generated code uses 32.
Inspector Tool
A referenced model has
None
ModelReferenceNumInstance
sAllowed set to Multi, but the
generated code for it has singleinstance code.
MODREFPANE
Local variable tmp is used, but is not None

defined.
2-9
Requirement ID
Requirement
Example of
Limitations
CODEGENPANE

the Code Generation Pane that are
On Code Generation: Interface >

Data pane, configuration parameter
Interface is set to None, but the
generated code has initialization code
for error C-API interface.
See Configuration
the Simulink Code
Inspector Tool
2-10
2.2 Code Inspection User Information

For information about code inspection reports, see Code Inspection Reports in the Simulink
Code Inspector Users Guide, R2015b.
For a list of blocks supported for code inspection, see Supported Block Constraints in the
Simulink Code Inspector Tool Requirements, R2015b.
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, R2015b:
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.
2-11
2-12
3 Installation
To use the Simulink Code Inspector product, install the following MathWorks products:
MATLAB
Simulink
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,
R2015b:
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
Linux1
MATLAB Software
Simulink Software
Simulink Code Inspector software
Linux is a registered trademark of Linus Torvalds.

Qualkitdo Slci Tor

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Qualkitdo Slci Tor

Caricato da

Copyright:

Formati disponibili

DO Qualification Kit

Simulink Code Inspector

How to Contact MathWorks

Sales and services:

The MathWorks, Inc.

COPYRIGHT 20122015 by The MathWorks, Inc.

New for Version 1.6 (Applies to Release 2012a)

Code inspection report

The document identifies:

Features of the Simulink Code Inspector product.

Simulink Code Inspector

1.1 Simulink Code Inspector Product Description

Structural equivalence analysis and reports

Figure 1 shows the architecture of Simulink Code Inspector.

Figure 1: Simulink Code Inspector Architecture

2.1 Code Inspector Report Operational Requirements

Function Interface Verification

Traceability Results Summary and detailed reports on

Model To Code Traceability

Model and code compatibility

Simulink Code Inspector Operational Requirements Summary

If a model does not compile, code

Model and Code Compatibility

If a model does not compile,

If source code cannot be parsed, code None

Code inspection terminates for a

Simulink Code Inspector shall verify Model step function is missing.

Simulink Code Inspector shall verify

Model step function argument

Arrays and built-in types

Arrays and built-in types

Simulink Code Inspector shall verify

None for blocks supported

A segment of code exists that does

None for blocks supported

A Relational Operator block is

None for blocks supported

A Gain block with an output data

None for blocks supported

None for blocks supported

For a list of functions and

See Stateflow Charts in

Simulink Code Inspector shall verify

Stateflow does not generate a control See Stateflow States in

A condition action uses operator cos See Stateflow

Output of Stateflow block with data

See Stateflow Data and

Stateflow graphical function property

See Stateflow Graphical

Generated code does not inline the

See Stateflow Simulink

MATLAB Function block behavior

Simulink Code Inspector shall verify

In a MATLAB Function block, a

See Code in MATLAB

See MATLAB Function

See Data in MATLAB

Block Connectivity and Execution Order

Simulink Code Inspector shall verify

A Gain block generates a

Simulink Code Inspector shall verify

A Gain block is fed by a Bus Selector

Signal sig1 is specified with the

See the Solver Pane and