Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Plausibility of Exclusions

All intrusive exclusions, i.e. built in the model, shall be listed and verified based on a valid System ID (SID). All fields shall be filled out, including Rule, SID, User, Date and Rationale.

Note

Please consider "EverCheck > User's Guide > Handling Violations of Safety Modeling Guidelines" for more information on handling project-specific deviations from modeling guidelines.

Rationale

• Workflow
• Verification and Validation
• Deviation Procedure

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Usage of Named Data

Usage of named data instead of literals i.e. 'magic numbers' is required. MATLAB variables true and false are recommended for Boolean constants.

Exceptions to this rule include the literals 0 and 1 in counters and relational operations as well as the functions false(), true(), zeros() and ones(). These may contain magic numbers for the initialization of array and vector signals.

Usage of Parameter Objects for Named Data

MATLAB variables are not sufficient for production models which require rich data specification. Simulink.Parameter objects provide such capability.

Inheritance of Output Data Type

To guarantee data consistency with a Simulink.Parameter object and with true/false variables, the block parameter "Output data type" shall be set to "Inherit: Inherit from 'Constant value'":

When using the literals 0 and 1, the block parameter "Output data type" shall be set to "Inherit: Inherit via back propagation".

Constant Block Naming

A Constant block is named after its data. If multiple instances of Constant blocks with data of the same name exist on one model level, an optional numeric suffix is allowed.

When using true/false Boolean variables and 0/1 literals in counters and relational operations the name of the Constant Block shall be "Constant" + optional numeric suffix.

Correct	Incorrect

Constant Block Appearance

All Constant blocks in a model shall be sized in such a way that their icon is completely visible and recognizable. In particular, any text displayed (e.g. tunable parameters) in the icon shall be readable. This guideline requires the resizing of Constant blocks.

To prevent clutter the names of Constant blocks shall be hidden using the "Format -> Hide Name" option:

Correct	Incorrect

Rationale

• Readability; Enables human inspection and maintenance
• Workflow; Ensures consistency and traceability of tunable parameters
• Ensures the correct signals are used in the wider system context
• Enforcement of low complexity
• Enforcement of strong typing
• Use of naming conventions
• Verification and Validation
• Code Generation

Parameters

Display irrelevant signals

By default, the bus signals which are not used within the test object are not displayed. The parameter "Display irrelevant signals" allows all interface signals to be displayed, including all irrelevant signals.

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Allow Variable Dimensions

By default, the interface dimensions of a test object need to be fixed. When working with reusable libraries it is possible that different dimensions are applicable in this case, setting "Allow Variable Dimensions" ignores interface dimensions being set to -1 (inherited).

Description

Interface Specification

The following interface properties of a test object need to be fully specified:

• Name
• Data Type
• Dimension
• Minimum
• Maximum
• Unit

Inputs are specified via the Inport blocks or by using the properties of the related Simulink.Signal objects.

Outputs are specified via the Outport blocks or by using the properties of the related Simulink.Signal objects.

Parameters are specified via the Simulink.Parameter objects or by using the Constant block properties.

Note

Parameters where Minimum is equal to Maximum are assumed to be Constants.

Persistent Data

Persistent data used in the test object is to be fully specified. This affects all blocks which create global data during code generation, such as Unit Delay or Data Store blocks.

Rationale

• Readability; Supports human inspection; Use of unambiguous graphical representation
• Workflow; Enables automatic fixed-point scaling
• Verification and Validation; Supports software integration and testing
• Enables interface test and analysis of boundary values
• Enables formal analysis to find "Dead Code" and "Divide by Zero" errors
• Allows detecting implicit downcasts and out of range values during simulation
• Enforcement of strong typing
• Enforcement of low complexity
• Code Generation
• Simulation

Parameters

Unit Type

The parameter "Unit Type" defines the reference name of the Simulink Mask which is defined for each verification unit. The name of this parameter can be changed to an arbitrary string.

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Check Signal Name Consistency

By default the name of the connected verification unit interfaces are checked for equality. If this is not applicable for a certain model, e.g. when using lots of generic libraries, disabling this parameter removes the name from being checked.

Description

Interface Consistency

The following unit interface properties specified via Inports and Outports create a match between the signal source and all direct signal destinations of the structure layer:

• Name
• Data Type
• Dimension
• Minimum
• Maximum
• Unit

This check limits the scope to the structure layer based on the parameter "Unit Type".

Rationale

• Readability
• Workflow
• Verification and Validation
• Code Generation
• Enforcement of strong typing
• Use of naming conventions

Parameters

Reference Libraries

The parameter "Reference Libraries" defines one or more Simulink libraries, which incorporate allowed blocks. To define multiple libraries, all of them should be entered separated by a comma.

For each block type the allowed properties can be specified in their block description fields. Here is an example for the Ground block:

Block {
ShowName off
AttributesFormatString ""
Tag ""
}

To define multiple block properties, all of them should be entered, separated by a comma. Here is an example for the Add block:

Block {
Inputs "2, ++, +-, +, 1"
}

To define combinations of allowed block properties enter each combination in a separate block and incorporate all of them into one of the referenced libraries. Here is an example for two combinations of an Inport block:

Block {
ShowName on
BackgroundColor "orange"
}

Block {
ShowName off
BackgroundColor "blue"
}

The allowed default block properties can be specified in the library description field. Here is an example:

  BlockDefaults {
  DropShadow "off"
  BackgroundColor "white"
  }

Note

To find out the block property names, set the required property in the model, open the *.mdl file as text, and search for the block. The properties will be listed in the required format.

Allowed Mask Types

The parameter "Allowed Mask Types" defines one or more Simulink mask types, which can be used to exclude masked subsystems from static analysis. To define multiple mask types, all of them should be entered separated by a comma.

List Supported Blocks

The parameter "List Supported Blocks" is for information purposes. The parameter allows the complete table of all allowed blocks to be listed along with their parameters.

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Subset of Supported Blocks

The test object uses a restricted subset of Simulink blocks. This check uses the definitions from the parameter "Reference Libraries".

Parameters of Supported Blocks

The test object uses blocks with a restricted subset of parameters. This check uses the definitions from the parameter "Reference Libraries".

Display of Unsupported Parameters

All blocks which are excluded from the subcheck "Parameters of Supported Blocks" explicitly display the unsupported parameters in the block's "AttributesFormatString". This check uses the definitions from the parameter "Reference Libraries".

List Supported Blocks

Displays the complete listing of all allowed blocks along with their parameters.

Note

This sub-check is only visible if the parameter "List Supported Blocks" is selected.

Rationale

• Readability; Supports human inspection
• Workflow; Ensures consistency and compatibility across all model units
• Simulation; Better simulation performance and decreased memory usage
• Code Generation; Enables the proper generation of production code
• Use of language subsets; Defines restricted subsets of the language
• Verification and Validation
• Enforcement of low complexity

Parameters

Allowed File Extensions

It is possible to ignore files ending in certain extensions. This parameter can contain a list of extensions, separated by a comma, which will be ignored by the check.

Allowed Library Extensions

The subcheck "Library Extensions" only allows certain file extensions for referenced libraries. This parameter contains a list of all allowed library extensions. Multiple extensions can be separated by a comma.

Allowed Identifier Length

All identifiers are checked for their length. By default, Simulink allows a maximum of 63 characters but certain compilers further restrict the name length. This field is to be set to the lowest identifier range of all tools in your toolchain.

Check All Directory Dependencies

Selecting this checkbox, not only the model directory, but the directories of all librarys found in the current model are checked for consistency to the identifier rules. Additionally all directory elements are checked instead of only the last one.

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Identifier Rules

Identifiers are the names of different items which shall:

• comply with the naming standard agreed for the project
• are valid as C language identifiers
• have no conflicts with other identifiers in the model
• have no conflicts with the modeling environment (e.g. MATLAB, Simulink, Stateflow), reserved names (e.g. abs, cos, sin, max), any C language reserved names (e.g. else, float, while, static) or any reserved names within the target tool chain (e.g. dSPACE RUN, STOP, START).

Note

To exclude files from this check add an exclusion to the model's root with this rule's ID. Then add the excluded file name followed by a colon to the beginning of the rationale string.

The identifiers conform to the following constraints:

Name

• starts with a letter
• ends with a letter or a number
• does not have blank spaces
• does not have carriage returns

Allowed Characters

a b c d e f g h i j k l m n o p q r s t u v w x y z

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

0 1 2 3 4 5 6 7 8 9 _

Underscores

• can be used to separate parts
• cannot have more than one consecutive underscore
• cannot start with an underscore
• cannot end with an underscore

Length

Each identifier has a length between 1 and 63 characters. This length can be configured by the parameter Allowed Identifier Length.

File and Directory Names

The names of the files and directories in the model's directory comply with the Identifier Rules.

As there are often restrictions enforced by the project or the tools used, this sub-check defines the following exceptions:

• Hidden directories preceded by a dot . like the version control directories .hg or .svn
• Temporary file names preceded by a tilde ~ like the office swap file ~$TestSpec.xls
• Files with the extensions specified in the Allowed File Extensions parameter

Library Extensions

The file extensions of referenced libraries are included in the Allowed Library Extensions parameter.

Signal and Parameter Names

The names of signal lines and used parameter objects residing inside the checked system comply with the Identifier Rules.

Stateflow Object Names

The names of all Stateflow objects comply with the Identifier Rules.

State Labeling in Stateflow

State labels consist of capital letters and underscores only.

Block, Library and Subsystem Names

The names of Simulink blocks, libraries and subsystems residing inside the checked system comply with the Identifier Rules.

Mask Types

The names of all used Simulink Mask types shall comply with the Identifier rules. This sub-check defines the following exceptions:

• All Mask Types defined in the default simulink block library are permitted

Rationale

• Readability; Ensures documented and understandable design, well-suited for inspection
• Code Generation; Ensures uniqueness of the first characters to support compilers and other tools
• Use of naming conventions; Ensures unmodified names to be used in generated C code
• Workflow

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Destination Block Labels

A label is displayed on any signal connected to predefined blocks. This can either be directly or by way of a basic block that performs a non-transformative operation. The checked blocks are as follows:

• Outport block
• Goto block
• Data Store Write block
• Bus Creator block
• Mux block
• Subsystem block
• Chart block

Source Block Labels

A label shall be displayed on a signal originating from predefined blocks. These blocks are:

• Inport block (conflicting name exception applies – see the following Note)
• From block (block icon exception applies – see the following Note)
• Subsystem block or Stateflow® chart block (block icon exception applies)
• Bus Selector block (the tool forces this to happen)
• Demux block
• Selector block
• Data Store Read block (block icon exception applies)
• Constant block (block icon exception applies)

Note

Block icon exception (only applicable when indicated): If the signal label is visible in the originating block icon display, the connected signal does not need to have the label displayed, only if the signal label is needed elsewhere due to a destination-based rule.

Note

Conflicting name exception: If an output port exists, which matches the signal name of the input port, it is allowed to add a suffix to the input port's name.

Port Block Names

All Inport and Outport blocks have names which are equal to the signal connected to them.

From and Goto Block Names

All From and Goto blocks have names which are equal to the signal connected to them.

Propagated Subsystem Output Signals

Every signal originating from a non-reusable subsystem has a propagated signal label.

Blocks with Propagated Signals

Signals originating from basic blocks may not propagate signal names. Exceptions from this rules are the following blocks:

• Inport block
• From block
• Bus Selector block
• Selector block

Propagated Signal Labels

All propagated signals have a valid label, i.e. the label may not be empty.

Rationale

• Readability
• Verification and Validation
• Workflow
• Code Generation
• Use of naming conventions

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Simulink Documentation

The graphical workspace for every model, subsystem and library is documented to facilitate understanding. The following information is provided as a free text annotation:

• Title on each page (Format: Arial, bold, 20 pt.)
• Outline description (Format: Arial, standard, 10 pt.)
• Requirement descriptions with the pattern "REQ: <ID>" (Format: Arial, bold, 10 pt.)

The information shall be placed in the upper area of the model so that it can be easily identified.

Correct:

An exception to this rule are all comments starting with %.

Stateflow Documentation

The graphical workspace for every Stateflow Chart and Subchart is documented to facilitate understanding. The following information shall be provided as a free text annotation:

• Title on each page (Format: Arial, bold, 20 pt.)
• Outline description (Format: Arial, standard, 10 pt.)
• Requirement descriptions with the pattern "REQ: <ID>" (Format: Arial, bold, 10 pt.)

An exception to this rule are all comments starting with %.

MATLAB Documentation

Every MATLAB function, MATLAB script and MATLAB function block is documented to facilitate understanding. The following information shall be provided as a comment:

• Function or Script name followed by a title
• Outline description

Correct:

	function MyMatlabFunction
	%MyMatlabFunction Title of function
	% Description of function

Rationale

• Readability; Allows model to be reviewed, maintained and reused
• Workflow; Allows pages to be easily identified when printed
• Verification and Validation
• Use of established design principles

Parameters

Allowed Data Types

The Check Parameter Allowed Data Types can be set to a user-defined comma-separated list of Simulink data types.

The following data types are set by default:

• double (continuous by nature)
• uint32, int32 (discrete by nature)
• boolean (produced by single bit operators)

Note

To allow all Fixed-Point data types, use fixdt.

Description

Restricted Set of Data Types

The model is checked for any use which is violating the Allowed Data Types.

Hard-Equality Comparisons for Continuous Data

No hard-equality comparisons (==, ~=) are allowed for continuous data. In Stateflow no expressions shall be used in hard-equality comparisons, as they are not type-safe. This affects the data types double and single.

Correct	Incorrect

Comparison Operations in Stateflow Charts

• Comparisons are only made between variables of the same data type. When using literals please consider the dot-notation (0.0) for comparison with floats, integer numbers for comparison with integers, and 0/1 or false/true for comparison with Booleans.
• If comparisons are made between variables of different data types, the variables need to be explicitly type cast to matching data types.

Correct	Correct

Using the same or explicitly type casted data types.

Incorrect	Incorrect

Comparison between variables of different data types.

Check Assignment Operations in Stateflow Charts

In assignments (LHS = RHS) the RHS statements shall have the same data types as the LHS variables. If this is not the case, the RHS statements need to be explicitly type cast to match the data types of the LHS variables.

Mathematical Operations

No mathematical operations (*, /, +, -) are allowed for Boolean data in Simulink and Stateflow.

Data Type Conversions

Use of the Data Type Conversion block needs to be justified for each instance.

Strong Data Typing in Stateflow

Ensure that the option Use Strong Data Typing with Simulink I/O is set for each Stateflow Chart.

Note

This option is only available when the setting Action Language of the Stateflow Chart is set to C.

Unsigned Unary Minus in Stateflow

Ensure that no unary minus operation is applied on unsigned Stateflow data.

Switch Block

The switch block criteria is to be set to u2 ~= 0 and is to be driven by a Boolean signal.

Multiport Switch Block

The signal driving the control input of Multiport Switch blocks (input 1) has one of the following integer types:

• int8, uint8
• int16, uint16
• int32, uint32

Rationale

• Readability
• Workflow
• Simulation
• Verification and Validation
• Code Generation; Ensure consistent and efficient modeling and code generation
• Enforcement of strong typing; Avoid floating-point issues with discrete data elements
• Avoid implementation specific and highly non-transparent overflow issues
• Ensure correct behavior across the full working range of the data value
• Ensure data type conversion transparency
• Enforcement of low complexity

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

List All Division Operations

By default, only divisions are listed where the divisor does not exclude zero. When "List All Division Operations" is activated, valid divisions are also displayed with their calculated functional and design ranges.

Description

Division in Simulink

The divisor signals in Simulink Product and Division blocks shall be precluded from becoming zero.

The functional ranges of the divisor signals shall exclude zero by using constants or modeling patterns in Simulink. The design ranges of the divisor signals shall be defined in Simulink if functional limitations are not necessary. In all other cases, divisions shall be modeled by using the Protected Division blocks.

Division in Stateflow

The divisor signals in Stateflow division operations shall be precluded from becoming zero.

The functional ranges of the divisor signals shall exclude zero by using constants or modeling patterns in Simulink. The design ranges of the divisor signals shall be defined in Stateflow if functional limitations are not necessary. In all other cases, a division shall be modeled by using Simulink blocks outside Stateflow.

Note

The source divisor signals are recursively traced back to determine its functional and design ranges. The following blocks are supported for tracing:

• Abs
• Bus Creator/Bus Selector
• Constant
• Discrete-Time Integrator
• Gain
• Inport
• Integrator
• Lookup Table
• Lookup Table (2-D)
• Lookup Table (n-D)
• MinMax
• Outport
• Relational Operator
• Rounding
• Saturate
• Sine Wave
• Sum/Subtract/Add
• Unary Minus
• Unit Delay

Rationale

• Workflow
• Verification and Validation
• Code Generation
• Use of defensive implementation techniques

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Gain blocks shall be used with scalar or vector constants only. Expressions and named data are prohibited, literals (i.e. [-1 1], 2.5, 0.3333 etc.) shall be used instead.

Correct		Incorrect

Rationale

• Review and Workflow; Ensures good readability of expressions with constant factors
• Verification and Validation
• Code Generation
• Use of established design principles
• Enforcement of strong typing; Ensures data type consistency

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Ports with Bus Objects

Ports associated with Bus Objects shall either inherit their dimensions (i.e. -1) or be set to 1.

Rationale

• Workflow
• Verification and Validation
• Code Generation
• Use of established design principles

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Unary Usage of Logical Operators

Unary usage of logical operators is permitted for the NOT operator only. For all other logical operators with the "Number of input ports" set to one, the dimension of the input signal shall be greater than one, i.e. a vector signal shall be used.

Rationale

• Workflow
• Verification and Validation
• Code Generation
• Use of established design principles

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Requirements Pattern

The parameter "Requirements Pattern" defines a specific pattern which helps find the requirements IDs in the model and code. The pattern can be a prefix, e.g. "REQ: " or it can be part of the Requirements ID, e.g. "_REQ_".

Example: REQ: AUU_235

Description

Requirements Traceability in Simulink

All related unit requirements shall be traceable to the unit design.

In Simulink, annotations shall be used (Format: Arial, bold, 10 pt., foreground: black, background: yellow).

Example: REQ: AUU_235

Requirements Traceability in Stateflow

In Stateflow, transition comments shall be used.

Example: /* REQ: AUU_235 */

Requirements Traceability in C

In S-Function C code comments shall be used.

Example: /* REQ: AUU_235 */

Note

To be able to trace C code comments standard S-Functions need to be used. These are generated with the Legacy Code tool. Additionally, all souces needed for the compilation need to be present, i.e. S-Function sources and compiled C sources.

Rationale

• Readability
• Workflow
• Verification and Validation
• Code Generation
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Check Selector Block Usage

The signals connected to the index ports of the Selector blocks shall be within the dimension ranges specified by the "Input port size".

Otherwise, a protection against "array out of bounds" errors shall be modelled by using the Saturation block.

Rationale

• Workflow
• Simulation
• Verification and Validation
• Code Generation
• Use of established design principles

Parameters

Unit Type

The parameter "Unit Type" defines the project-specific mask type for the verification unit.

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Check Inlined Code

By default the verification unit code generated by Embedded Coder shall be inlined to get consistent code generation results. If this is not needed or another code generator is used, the option can be deselected.

Description

Masked Subsystem

The verification unit shall be a masked subsystem with a mask type set to the parameter "Unit Type".

Subsystem Settings

In the verification unit the setting "Treat as atomic unit" shall be selected and the setting "Real-Time Workshop system Code" shall be set to "Inline". This ensures reusability and consistent code generation behavior.

Library Name

The verification unit shall be linked to a library. The library name shall have the suffix "_lib".

Rationale

• Workflow
• Code Generation
• Modular Development
• Use of established design principles

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Unconnected Input Ports

All input ports shall be connected to corresponding signal lines.

Unconnected Output Ports

All output ports shall be connected to corresponding signal lines.

Unconnected Signal Lines

All signal lines shall be connected to corresponding blocks.

Rationale

• Readability
• Workflow
• Verification and Validation
• Use of established design principles

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Calculations in block settings are prohibited.

Mathematical Operations

Mathematical operations shall not be used in block settings.

Vector Operations

Extraction of vector and array elements shall not be used in block settings.

Structure Elements

Structure elements or object properties shall not be used in block settings.

Function Calls

Functions calls or data type casting shall not be used in block settings.

Exceptions to this rule include the functions false(), true(), zeros(), ones(), bin2dec(), and hex2dec().

Rationale

• Readability
• Workflow; Increase compatibility with Design Verifier and Model Advisor
• Verification and Validation
• Enforcement of low complexity; Minimize complexity during automation, analysis and review
• Use of language subsets
• Use of established design principles
• Enforcement of strong typing; Avoid calculation differences based on variable definition and data type

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Control Flow Blocks

Control flow blocks (e.g. "if-then-else") shall not be nested more than one level deep.

Rationale

In general, Stateflow shall be used for implementing complex control flow structures.

• Usability
• Functionality
• Maintainability
• Enforcement of low complexity
• Use of established design principles

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Naming of Trigger and Enable Ports

The names of Trigger and Enable ports and the names of related input signals shall match.

Correct

Rationale

• Readability
• Use of naming conventions

Parameters

Unit Type

The parameter "Unit Type" defines the reference name of the Simulink Mask which shall be defined for each verification unit. The name of this parameter can be changed to an arbitrary string.

Verification Function

This parameter specifies an M function somewhere on the MATLAB path. The function shall have exactly one argument and one return value. The argument contains a list of all unit blocks found. The return value must be a two-column cell array containing all issues found. The first column may contain blocks which are then automatically checked for exclusions and are highlighted in the architecture tree. The second column contains a short description of the issue found.

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Architectural Structure

The hierarchical model architecture shall be displayed in a tree structure based on the predefined "Unit Type".

All issues found determined by the "Verification Function" are highlighted in this tree.

Rationale

• Modular Development
• Workflow
• Use of established design principles

Parameters

Project Wide Configuration

The parameter "Project Wide Configuration" defines a MATLAB file with a predefined Simulink configuration. Such a MATLAB file can be generated by exporting the Simulink model configuration as MATLAB file: Model Explorer > Configuration > Export... The file can be used as it is or it can be modified setting by setting. The removed settings will not be checked.

Description

Consistency of Model Configuration Settings

The model configuration settings shall comply with a project specific configuration. The following settings are addressed:

• Model Solver
• Model Optimizations
• Model Diagnosis
• Model Appearance
• etc.

This check uses the definitions from the parameter "Project Wide Configuration".

Rationale

• Readability; Supports human inspection
• Workflow; Supports version and configuration management
• Simulation; Ensures consistency and compatibility across all model units
• Verification and Validation
• Code Generation; Enables proper production code generation
• Enforcement of low complexity
• Use of established design principles

Description

Warnings During Model Update

Simulink runs model diagnostics on a model update and provides the warnings in the MATLAB command line. Such compile-time warnings shall be eliminated by fixing the model, or a rationale for each Warning-ID shall be provided.

Note

Rationale can be given by using the Warning-ID in the exclusion editor at model level.

Rationale

• Workflow; Ensures that diagnostic warnings are understood and fixed
• Code Generation
• Use of style guides

Parameters

Unit Type

Specifies the subsystems which are intended for code generation and verification. Only atomic subsystems whose MaskType match the entered Unit Type are reported. This parameter can be left empty to find all atomic subsystems.

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Grouped Signals in Interfaces

Grouped signals, i.e. Busses, shall not be used at the interface between Stateflow blocks and atomic subsystems which are intended for code generation and verification.

Rationale

• Readability
• Workflow
• Verification and Validation
• Code Generation
• Use of language subsets
• Enforcement of low complexity
• Use of established design principles

Parameters

Reference Libraries

The parameter "Reference Libraries" defines one or more Simulink libraries, which incorparate permitted blocks. To define multiple libraries, all of them shall be entered, separated by a comma. For each block type, the permitted sizes can be specified by placing the blocks into the library and resizing them as required:

• If no block is found in the referenced library for the given block type, the check will assume that all sizes are permitted.

• If one single block is found in the referenced library for the given block type, the check will assume that its sizes are defined as a reference.

• If multiple blocks are found in the referenced library for the given block type, the check will assume that the minimum and maximum size values are defined as reference size boundaries, i.e. the blocks of the given block type may vary within the reference size boundaries.

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

View Options

The Simulink view options shall conform to the following guidelines when the model is reviewed and released:

Block Display Options

The Simulink block display options shall conform to the following guidelines when the model is reviewed and released:

Signal Display Options

The Simulink signal display options shall conform to the following guidelines when the model is reviewed and released:

Inport Block Position

Ensures that any Inport block is placed on the left side of the block it is directly connected to. This makes sure that there are no left-flowing signals.

Outport Block Position

Ensures that any Outport block is placed on the right side of the block it is directly connected to. This makes sure that there are no left-flowing signals.

Trigger and Enable Block Position

Ensures that all Trigger and Enable blocks are placed on top of all other blocks within the same subsystem.

Usage of Relational Operator Block

The first input of the Relational Operator block shall not be connected to a Constant block. The Constant block may be connected to the second input.

Block Sizes

The block sizes of the test object shall conform to predefined settings. This check uses the definitions from the parameter "Reference Libraries".

Font Defaults for New Models

The following font defaults are required for all new models:

Note

The font's name, size, weight and angle can be modified in File > Simulink Preferences > Font Defaults for New Models

Font Formatting

The fonts of all blocks, signals and annotations shall match the Font Defaults for New Models. An exception to this rule are subsystem titles, requirement descriptions and comments starting with %.

Port Name Visibility

Port names shall be visible for all graphical subsystem masks. Therefore the mask's "Icon Transparency" shall be set to "Opaque with ports" and the subsystem's setting "Show port labels" shall be set to "FromPortIcon". This ensures that the correct labels are displayed on top of all mask drawing commands.

The use of the mask command "port_label" is prohibited, as its label can be different from the underlying port name.

Rationale

• Readability; Allows models to be easily reviewed and maintained
• Workflow; Shows correct block connectivity and facilitates review
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Goto Block Connectivity

Every Goto block shall have one or more From blocks on the same model level.

From Block Connectivity

Every From block shall have exactly one matching Goto block on the same model level.

Rationale

• Usability
• Functionality
• Maintainability
• Use of established design principles

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Consistency of Block Parameters

For all Merge blocks the initial output value shall be specified and the setting "Allow unequal port widths" shall be switched off.

Cascading of Merge Blocks

Merge blocks shall not be cascaded, i.e. the output port of a Merge block shall not connect to another Merge block. I case where multiple signals shall be merged, the number of Merge inputs can be increased.

Reuse of Merge Inputs

The input signals of a Merge block shall not be reused for further calculations, i.e. the Merge block shall be the only sink for merged signals.

Rationale

• Readability
• Workflow
• Verification and Validation
• Use of established design principles

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Data Store Positioning

The Data Store Read and Data Store Write blocks shall be placed within the subsystem where the related Data Store Memory block exists.

Data Store Naming

The name of a Data Store block shall consist of its named data. If multiple instances of Data Store blocks with the same named data exist on one model level, an optional numeric suffix is allowed.

Rationale

• Simulation
• Code Generation
• Safety
• Enforcement of low complexity
• Use of established design principles

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Explicit Initialization in Simulink

Blocks in Simulink that have an initialization parameter (e.g. unit delays, integrators, output ports in conditionally executed subsystems) shall explicitly define the initialization value.

Explicit Initialization in Stateflow

Output data in Stateflow shall explicitly define the initialization value.

Rationale

• Readability
• Workflow
• Verification and Validation
• Code Generation
• Use of defensive implementation techniques

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Requirements Pattern

The parameter "Requirements Pattern" defines a specific pattern which helps finding the requirements IDs in the model and code. The pattern can be a prefix, e.g. "REQ: " or it can be part of the Requirements ID, e.g. "_REQ_".

Example: REQ: AUU_235

Description

Unique IDs of Requirements

All requirements IDs shall be uniquely used within a model, i.e. multiple instances are not allowed.

Rationale

• Readability
• Workflow
• Verification and Validation
• Code Generation
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

For fixed-point code generation power of two scaling (Binary point) shall be used.

Rationale

• Readability
• Workflow
• Verification and Validation
• Code Generation
• Enforcement of strong typing

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Internal Transitions

Only one internal transition shall be used within any state. The internal transition shall start at upper left state boundary. Such internal transition represents the during action of the state.

External Transitions

Only one external transition shall be used from any state. The second external state transition may be used for temporal logic only.

Rationale

• Review
• Verification
• Code Generation
• Enforcement of low complexity
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

A well-defined set of the Stateflow language shall be used, i.e. all cumbersome language objects and properties shall be avoided.

Truth Tables

Truth tables shall not be used.

State Transition Tables

State transition tables shall not be used.

MATLAB Functions

MATLAB functions shall not be used.

Simulink Functions

Simulink functions shall not be used.

History Junctions

History junctions shall not be used.

Transition Actions

Transition actions (/action) shall not be used.

State Actions

State actions (entry, during, exit) shall not be used.

External C-Code Functions

External C-Code functions shall not be used.

Boxes

Boxes shall not be used for state modeling and data storage. Boxes shall only contain text.

Rationale

• Readability
• Simulation
• Verification
• Code Generation
• Use of language subsets

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Stateflow Events

Local, directed and broadcast Stateflow events, including all implicit events shall not be used. Only two types of events are allowed:

• Output event
• Temporal logic

Usage of Temporal Logic

In all flow charts and graphical functions, temporal logic shall not be used. Temporal logic may be used in state charts only. Temporal logic implies exclusive states are required in which case a state chart shall be used.

Rationale

• Readability
• Verification
• Code Generation
• Enforcement of low complexity
• Use of language subsets

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Window Appearance

All Stateflow ojects shall use the pre-set "factory" color & style scheme.

Stateflow Zoom

The zoom factor of Stateflow windows shall be normal (100%).

Text Appearance

• All Stateflow text (except Title) shall use Arial standard 10pt font.
• All text of the state label shall be within the state boundary.

Usage of Comments

All Stateflow comments shall:

• use C-like "/* */" symbols as delimiters;
• be drawn at the beginning of the label;
• be separated by new line from the rest of the text.

Transition Labels

All Stateflow transition labels shall:

• be visually associated to the corresponding transition;
• be placed to the right of vertical transitions;
• be placed on the top of horizontal transitions.

Rationale

• Readability
• Workflow
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Junction Size

The size of all Stateflow junctions shall be 14.

Default Path at Decision Points

All junctions, i.e. decision points, except for the terminating junctions, shall have exactly one unconditional transition, i.e. default path.

Terminating Junctions

• In a flow chart there shall be only one terminating junction.
• The terminating junction shall be the lowest junction of the flow chart.
• The terminating junction shall have only one incoming transition.
• The incoming transition of the terminating junction shall be unconditional.

Rationale

• Review
• Verification
• Code Generation
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Stateflow Port Names

The name of a Stateflow/MATLAB input or output shall be the same as the corresponding signal.

Note

An exception to this rule are reusable Stateflow blocks which may have different port names.

Rationale

• Readability
• Workflow
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Usage of Calibration Parameters

Calibration parameters, i.e. data store memory, shall not be used in Stateflow. All calibration data shall be explicitly passed as inputs to Stateflow. All observed data shall be explicitly passed as outputs from Stateflow.

Usage of Named Data

Usage of named data instead of literals, i.e. 'magic numbers', is required. The only exception from this rule is the usage of literals 0 and 1 in counters and relational operations. MATLAB variables "true" and "false" as well as "ones(n,m)" and "zeros(n,m)" are recommended for boolean constants.

Explicit Interface Definition

Stateflow interfaces shall have explicit definition of data type, dimension and ranges.

Scope of Signals and Variables

Internal signals, local auxiliary variables and events shall be defined on the chart level or below, i.e. no local data is allowed on the machine level. Parameters and constants are allowed at the machine level.

Correct	Incorrect

Local Data in Parallel States

The scope of internal data shall be restricted to one parallel state unless the same data is required in other parallel states.

Unused data and events

Unused data and events shall not exist in the Stateflow block. Note: Set configuration parameter "Diagnostics -> Stateflow -> Unused data and events" to "error".

Rationale

• Readability; Enables human inspection and maintenance
• Workflow; Ensures usage of correct signals in wider system context
• Verification and Validation
• Enforcement of strong typing

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

MATLAB Commands in Stateflow

The following rules apply to logic in Stateflow:

• MATLAB functions are not used.
• MATLAB instructions are not used.
• MATLAB operators are not used.
• Project-specific MATLAB functions are not used.

Incorrect

Rationale

• Readability
• Workflow
• Verification and Validation
• Code Generation
• Use of language subsets

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Conditions in Flowcharts

Condition expressions shall be drawn on the horizontal segments of flowcharts. Loop constructs are intentional exceptions to this rule.

Actions in Flowcharts

Transition actions shall be drawn on the vertical segments of flowcharts.

Default Transitions in Flowcharts

At every junction, except for the last junction of a flow diagram, exactly one unconditional transition begins. Every decision point (junction) shall have a default path.

Combinations of Conditions and Actions

Transitions shall either have a condition or a condition action. They may also be empty but shall not contain both a condition and an action.

Rationale

• Readability
• Workflow
• Verification and Validation
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Exclusive States in State Machines

At every level of a Stateflow hierarchy state machines shall have at least two exclusive states.

Assignment of Default States

At every level of a Stateflow hierarchy state machines shall have a singular initial state defined by a default transition.

Rationale

• Readability
• Workflow
• Verification and Validation
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Transition Action Patterns

Each transition action shall be put on a separate line. This implies that the following patterns are used for transition actions within Stateflow state machines:

State Machine Pattern	Equivalent Functionality	Description
	action;	One transition action
	action1; action2; action3;	Two or more transition actions. Multiple actions on one line are not allowed.

Rationale

• Readability
• Workflow
• Verification and Validation
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Straight Transition Lines

Stateflow transitions shall be drawn straight and exactly horizontal or vertical.

Correct

Inner flow charts may be used for modelling entry and during actions.

Rationale

• Readability; Supports human inspection
• Workflow
• Use of established design principles
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Check Stateflow Chart Properties

The following Stateflow chart properties shall be used:

Note

To ensure consistent behavior the "User specified state/transition execution order" is only disabled during modification if the execution order of the containing transitions is not changed.

Check Conflicting User Specified Execution Order

List all transitions with a user specified execution order that does not match the automatic execution order applied after "User specified state/transition execution order" is disabled.

Rationale

• Readability
• Simulation
• Verification
• Code Generation
• Use of established design principles

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Permitted Operations in Stateflow

Algebraic:

• a * b, Multiplication
• a + b, Addition
• a - b, Subtraction

Relational

• a > b, Comparison of the first operand greater than the second operand
• a < b, Comparison of the first operand less than the second operand
• a >= b, Comparison of the first operand greater than or equal to the second operand
• a <= b, Comparison of the first operand less than or equal to the second operand
• a == b, Comparison of equality of two operands
• a != b, Comparison of inequality of two operands

Logical

• a && b, Logical AND of two operands
• a || b, Logical OR of two operands

Bitwise

• a >> b, Shift operand a right by b bits
• a << b, Shift operand a left by b bits
• a & b, Bitwise AND of two operands
• a ^ b, Bitwise XOR of two operands
• a | b, Bitwise OR of two operands

Unary

• !a, Logical NOT of a
• -a, Negative of a
• a++, Increment a
• a--, Decrement a

Assignment

• a = expression, Simple assignment
• a += expression, Equivalent to a = a + expression
• a -= expression, Equivalent to a = a - expression
• a *= expression, Equivalent to a = a * expression
• a |= expression, Equivalent to a = a | expression (bit operation)
• a &= expression, Equivalent to a = a & expression (bit operation)
• a ^= expression, Equivalent to a = a ^ expression (bit operation)

Operators in Conditions

Stateflow conditions shall contain only logical (incl. logical NOT) and relational operators

Mixed Operators in Actions

Individual Stateflow actions shall contain only one type of operator (i.e. only addition or only subtraction etc.)

Legacy Code

C library functions and MATLAB functions besides typecasting shall not be used in Stateflow.

Bit Operations

Stateflow Option "Enable C-like bit Operations" shall be switched on.

Rationale

• Simulation
• Code Generation
• Safety
• Enforcement of low complexity
• Use of language subsets
• Use of defensive implementation techniques

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Format of Entries in State Blocks

A new line shall be:

• Started after the entry (en), during (du), and exit (ex) statements.
• Started after the completion of an assignment statement ";".

Correct	Incorrect	Incorrect
	Failed to start a new line after en, du and ex	Failed to start a new line after the completion of an assignment statement ";".

Rationale

• Readability
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Return Value Assignment from Graphical Functions

The return value from a graphical function shall be set in only one place.

Correct	Incorrect

Rationale

• Workflow
• Code Generation
• Use of established design principles

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Return Value Usage from Graphical Functions

The return value from a graphical function shall not be used directly in a comparison operation.

Correct	Incorrect
An intermediate variable holding the value of GetCurrent() is used in the conditional expression.	Return value of the function GetCurrent() is used directly in the conditional expression.

Rationale

• Workflow
• Code Generation
• Use of established design principles

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Placement of Default Transition

Default transitions shall be connected to the upper part of the state or a junction.

Placement of Default State

Default transitions shall be connected to states or junctions positioned in the far upper left within the same chart level.

Unguarded Path to a State

Default transitions shall have an unguarded path to a state.

Note

The Simulink setting "Diagnostics->Stateflow->No unconditional default transitions" shall be set to "error".

Crossing State Boundaries

The default transition shall not cross any state boundaries, i.e. default transitions shall be established internally for each chart level.

Single Instance Default Transition

Exactly one default transition shall exist on each hierarchical chart level, i.e. multiple default transitions are not permitted on the same chart level. Super-states containing other states shall also comply with this rule.

Rationale

• Readability
• Workflow
• Verification and Validation
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Unconditional Transitions

Each junction (except terminating) shall have exactly one unconditional tansition.

Conditional Transitions

Each junction (except terminating) shall have no more then one conditional transition, i.e. multiple conditions shall be cascaded.

Order of Transitions

At each junction the conditional transitions shall be tested prior to the unconditional transition, i.e. conditional transition shall have number 1 in execution order.

Rationale

• Review
• Verification
• Code Generation
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Bitwise Stateflow Operators

The bitwise Stateflow operators (&, |, and ^) shall not be used in Stateflow charts unless you want bitwise operations. To enable bitwise operations, select File > Chart Properties > Enable C-bit operations.

Correct

Use && and || for Boolean operation.

Correct

Use & and | for bit operation.

Incorrect

Use & and | for Boolean operation.

Rationale

• Readability
• Verification and Validation
• Code Generation
• Use of defensive implementation techniques

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Pointers in Stateflow

In a Stateflow diagram, pointers to custom code variables are not allowed.

Rationale

• Readability
• Workflow
• Verification and Validation
• Code Generation
• Enforcement of low complexity
• Use of language subsets
• Use of defensive implementation techniques

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Event Broadcasts

The following rules apply to event broadcasts in Stateflow:

• Directed event broadcasts are the only type of event broadcasts allowed.
• The send syntax or qualified event names are used to direct the event to a particular state.
• Multiple send statements shall be used to direct an event to more than one state.

Example Using Send Syntax	Example Using Qualified Event Names

Rationale

• Readability
• Workflow
• Verification and Validation
• Code Generation
• Use of unambiguous graphical representation

Parameters

Check Linked Libraries

By default, the active libraries within the test object are not checked. The parameter "Check Linked Libraries" allows all subsystems within the test object to be checked, including all active libraries.

Description

Documentation Traceability

To ensure all Simulink documentation can be found in the generated C code, annotation texts need to be added to the description field of their associated blocks.

Note

As there is no official interface offered from MathWorks for accessing annotation connections, connection changes are only detected after the model is saved.

Rationale

• Readability
• Workflow
• Code Generation
• Use of naming conventions