DO Qualification Kit

Software Model Standard

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: Software Model Standard
© COPYRIGHT 2014 – 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 2014 New for Version 2.3 (Applies to Release 2014a)
October 2014 Revised for Version 2.4 (Applies to Release 2014b)
March 2015 New for Version 2.5 (Applies to Release 2015a)
Document Title: Software Model Standard <Project>.

Document Number: <DocNo>

Revision: <Revision>

Project: <Project>

Approvals:

<Name 1>, Author Date

<Name 2>, Project Management Date

<Name 3>, Engineering Date

<Name 4>, Quality Engineering Date

 Change History

Rev. Modification / Description Date Author Checked

1.0 First release of Software Modeling
Standard (SWMS)
Contents
1 Introduction ...................................................................................................................................... 1-1
1.1 Applicable Documents ............................................................................................................ 1-2
Table 1 - Regulations and Standards ....................................................................................... 1-2
Table 2 - Company and Project Plans, Standards, and Documents ......................................... 1-2
Table 3 - Referenced Documents ............................................................................................ 1-2
2 Methods, Tools and Modeling Languages ....................................................................................... 2-1
Simulink .................................................................................................................................. 2-1
Stateflow ................................................................................................................................. 2-2
MATLAB ................................................................................................................................ 2-2
3 Style Guidelines and Complexity Restrictions ................................................................................. 3-1
3.1 Modeling Guidelines for High-Integrity Systems ................................................................... 3-2
3.2 Simulink Model Advisor DO-178C/DO-331 Checks.............................................................. 3-5
3.3 MathWorks Automotive Advisory Board ............................................................................... 3-6
3.4 Company-Specific Guidelines ................................................................................................. 3-7
4 Constraints on Modeling Tools ........................................................................................................ 4-1
4.1 Modeling Guidelines for High-Integrity Systems ................................................................... 4-2
4.2 Simulink Model Advisor DO-178C/DO-331 Checks.............................................................. 4-4
4.3 Company-Specific Constraints ................................................................................................ 4-5
5 Model Requirements and Traceability ............................................................................................. 5-1
6 Derived Requirements ...................................................................................................................... 6-1
7 Additional Model Elements ............................................................................................................. 7-1
8 Suitability of Technique ................................................................................................................... 8-1

vii
viii
1 Introduction

This document comprises the Software Model Standard as referenced by the Software
Development Plan (SDP), according to DO-331 MB.11.2 for the project <Project>. As specified
in DO-331MB.11.23, the Software Model Standard defines the modeling techniques for each
type of model.

This document defines all of the following:

 Methods and tools for developing the models.

 Modeling languages.
 Style guidelines and complexity restrictions for the use of the modeling languages and tools.
 Constraints on the use of the modeling tool(s).
 Method to identify and delimit the requirements contained in the model.
 Means to establish traceability between requirements and other life cycle data.
 Method to identify and delimit the derived requirements contained in the model.
 Method to provide derived requirements to the system processes.
 Means to identify each model element that does not contribute to the representation of a
software requirement or of the software architecture, and is not an input to a subsequent
software development process or activity.
 Rationale for the suitability of the technique for the type of information expressed by a
Specification Model or Design Model.

Within the project <Project>, this document is applicable for design models as specified in DO-
331MB.1.6.2.

You can use this document as a resource when creating a Software Model Standard document. If
you are updating an existing Software Model Standard document to support Model-Based
Design (MBD), you can use this document as a reference.

Note: With the exception of MATLAB®, Simulink®, and Stateflow®, this document does not
include definitions or information for modeling environments.
 1.1 Applicable Documents
Table 1 - Regulations and Standards
ID Document Title
DO-178C Software Considerations in Airborne Systems and Equipment Certification.
RTCA, Inc., 2011
DO-330 Software Tool Qualification Considerations.
RTCA, Inc., 2011
DO-331 Model-Based Development and Verification Supplement to DO-178C and DO-278A.
RTCA, Inc., 2011.
<List additional documents here, e.g. Advisory Circulars, EASA Certification Memos, etc.>

Table 2 - Company and Project Plans, Standards, and Documents

Document Document Title

<List additional documents>

Table 3 - Referenced Documents

ID Document Title
SLHI Simulink Modeling Guidelines for High-Integrity System, R2015a
MAAB MathWorks Automotive Advisory Board Control Algorithm Modeling Guidelines Using MATLAB,
Simulink, and Stateflow, R2015a
SLCG Simulink Modeling Guidelines for Code Generation, R2015a

SLUG Simulink User's Guide, R2015a

SLREF Simulink Reference, R2015a

ECUG Embedded Coder User's Guide, R2015a

SLCIREF Simulink Code Inspector Reference, R2015a

FPUG Fixed-Point Designer User's Guide, R2015a

FPREF Fixed-Point Designer Reference, R2015a

SFUG Stateflow User's Guide, R2015a

SFREF Stateflow Reference, R2015a

MCUG MATLAB Coder User´s Guide, R2015a

<List additional documents here.>

1-2
2 Methods, Tools and Modeling
Languages

This section specifies the methods, tools, and modeling languages for the development of design
models, according to (DO-331 MB.11.23.a and MB.11.23.b).

Simulink® products from MathWorks® are an accepted standard for Model-Based Design
(MBD). Simulink, Fixed-Point Designer™, and Stateflow® software support graphical modeling
with time-based block diagrams and event-based state machines. Embedded Coder software
supports code generation for embedded systems.

Simulink
Simulink is a software package that enables you to model, simulate, and analyze dynamic
systems. Embedded Coder is a software package that enables you to generate C code for
embedded platforms. Simulink uses block diagrams as a model-based programming language
(Simulink language). Block diagrams graphically consist of blocks and lines (signals).

 Simulink block diagrams define time-based relationships between signals and state variables.
The solution of a block diagram is obtained by evaluating these relationships over time. Time
starts at a user specified start time and ends at a user specified stop time. Each evaluation of
the relationships is referred to as a time step.
 Signals represent quantities that change over time and are defined for all points in time
between the block diagram’s start and stop time.
 A set of equations represented by blocks defines the relationships between signals and state
variables. Each block consists of a set of equations (block methods). These equations define a
relationship between the input signals, output signals, and the state variables. Inherent in the
definition of an equation is the notion of parameters, which are the coefficients found in the
equation.
 Simulink contains both virtual blocks and nonvirtual blocks, as described in the Simulink User's
Guide and Simulink Reference documents. In general, implementation is defined by nonvirtual
blocks, not virtual blocks. Examples of virtual blocks include DOC blocks, subsystems used to group
blocks together in a model, and some connections inside virtual subsystems, such as inports or outports.
The modeling standards for the project should define these types of virtual blocks as not contributing to
the implementation.
 The Simulink User's Guide and Simulink Reference documents provide detailed descriptions
of Simulink features.
 The Embedded Coder User's Guide document provides detailed descriptions of Simulink
features that apply to code generation for embedded systems, including a list of supported
blocks.
 The Simulink Code Inspector Reference document provides detailed descriptions of Simulink
features that apply to code inspection, including a list of supported blocks.
 The Fixed-Point Designer User's Guide and Fixed-Point Designer Reference documents
provide detailed description of Simulink's fixed-point features.

Stateflow
Stateflow is an environment for modeling and simulating combinatorial and sequential decision
logic in the form of state transition diagrams, flow charts, state transition tables, and truth tables.
A state transition diagram is a graphical representation of a finite state machine. States and
transitions form the basic building blocks of a sequential logic system. Another way to represent
sequential logic is a state transition table, which allows you to enter the state logic in tabular
form. Combinatorial logic can also be represented in a chart with flow charts and truth tables.

Stateflow charts can be blocks in a Simulink® model. The collection of these blocks in a
Simulink model is the Stateflow machine.

A Stateflow chart enables the representation of hierarchy, parallelism, and history. You can
organize complex systems by defining a parent and offspring object structure. A system with
parallelism can have two or more orthogonal states active at the same time. You can also specify
the destination state of a transition based on historical information.

 The Stateflow User's Guide and Stateflow Reference documents provide a description of
Stateflow features.
 The Simulink Code Inspector Reference document provides a description of Stateflow
features that apply to code inspection.

MATLAB
MATLAB® is a high-level language and interactive environment for numerical computation,
visualization, and programming.

 The MATLAB Coder User´s Guide provides a detailed description of MATLAB features that
apply to code generation, including a list of supported functions.

2-2
3 Style Guidelines and Complexity
Restrictions

This section describes the style guidelines and complexity restrictions for the use of MATLAB,
Simulink, and Stateflow, according to (DO-331 MB.11.23.c).

<The following guidelines provide a starting point for defining constraints on the use of
modeling tools within your project. The guidelines are available at the MathWorks
Documentation Center, R2015a. Tailor the following set of guidelines based on your planned
use of the tools and applicability to your project.>
3.1 Modeling Guidelines for High-Integrity Systems
Simulink Block Considerations – Math Operations

hisl_0001: Usage of Abs block

hisl_0002: Usage of Math Function blocks (remainder and reciprocal)
hisl_0003: Usage of Square Root blocks
hisl_0028: Usage of Reciprocal Square Root blocks
hisl_0004: Usage of Math Function blocks (natural logarithm and base 10 logarithm)
hisl_0005: Usage of Product blocks
hisl_0029: Usage of Assignment block

Simulink Block Considerations – Ports & Subsystems

hisl_0006: Usage of While Iterator blocks

hisl_0007: Usage of While Iterator subsystems
hisl_0008: Usage of For Iterator Blocks
hisl_0009: Usage of For Iterator Subsystem blocks
hisl_0010: Usage of If blocks and If Action Subsystem blocks
hisl_0011: Usage of Switch Case blocks and Action Subsystem blocks
hisl_0012: Usage of conditionally executed subsystems
hisl_0024: Inport interface definition
hisl_0025: Design min/max specification of input interfaces
hisl_0026: Design min/max specification of output interfaces

Simulink Block Considerations – Signal Routing

hisl_0013: Usage of data store blocks

hisl_0015: Usage of Merge blocks
hisl_0021: Consistent vector indexing method
hisl_0022: Data type selection for index signals
hisl_0023: Verification of model and subsystem variants

3-2
Simulink Block Considerations – Logic and Bit Operations

hisl_0016: Usage of blocks that compute relational operators

hisl_0017: Usage of blocks that compute relational operators (2)
hisl_0018: Usage of Logical Operator block
hisl_0019: Usage of Bitwise Operator block
Stateflow Chart Considerations – Chart Properties

hisf_0001: Mealy and Moore semantics

hisf_0002: User-specified state/transition execution order
hisf_0009: Strong data typing (Simulink and Stateflow boundary)
Stateflow Chart Considerations – Chart Architecture

hisf_0003: Usage of bitwise operations

hisf_0004: Usage of recursive behavior
hisf_0007: Usage of junction conditions (maintaining mutual exclusion)
hisf_0010: Usage of transition paths (looping out of parent of source and destination objects)
hisf_0012: Chart comments
hisf_0013: Usage of transition paths (crossing parallel state boundaries)
hisf_0014: Usage of transition paths (passing through states)
hisf_0015: Strong data typing (casting variables and parameters in expressions)
MATLAB Function and MATLAB Code Considerations – MATLAB Functions

himl_0001: Usage of standardized MATLAB function headers

himl_0002: Strong data typing at MATLAB function boundaries
himl_0003: Limitation of MATLAB function complexity
himl_0005: Usage of global variables in MATLAB functions
MATLAB Function and MATLAB Code Considerations – MATLAB Code

himl_0004: MATLAB Code Analyzer recommendations for code generation

himl_0006: MATLAB code if / elseif / else patterns
himl_0007: MATLAB code switch / case / otherwise patterns

3-3
himl_0008: MATLAB code relational operator data types
himl_0009: MATLAB code with equal / not equal relational operators
himl_0010: MATLAB code with logical operators and functions
MISRA-C:2004 Compliance Considerations –Modeling Style

hisl_0061: Unique identifiers for clarity

hisl_0062: Global variables in graphical functions
hisl_0063: Length of user-defined function names to improve MISRA-C®:2004 compliance
hisl_0064: Length of user-defined type object names to improve MISRA-C:2004 compliance
hisl_0065: Length of signal and parameter names to improve MISRA-C:2004 compliance
hisl_0201: Define reserved keywords to improve MISRA-C:2004 compliance
hisl_0202: Use of data conversion blocks to improve MISRA-C:2004 compliance
MISRA-C:2004 Compliance Considerations –Block Usage

hisl_0020: Blocks not recommended for MISRA-C:2004 compliance

hisl_0101: Avoid invariant comparison operations to improve MISRA-C:2004 compliance
hisl_0102: Data type of loop control variables to improve MISRA-C:2004 compliance
Stateflow Chart Considerations

hisf_0064: Shift operations for Stateflow data to improve MISRA-C:2004 compliance

hisf_0065: Type cast operations in Stateflow to improve MISRA-C:2004 compliance
hisf_0211: Protect against use of unary operators in Stateflow Charts to improve MISRA-
C:2004 compliance
hisf_0212: Data type of Stateflow for loop control variables to improve MISRA-C: 2004
compliance
hisf_0213: Protect against divide-by-zero calculations in Stateflow charts to improve MISRA-C:
2004 compliance
MISRA-C:2004 Compliance Considerations –System Level

hisl_0401: Encapsulation of code to improve MISRA-C:2004 compliance

hisl_0402: Use of custom #pragma to improve MISRA-C:2004 compliance
hisl_0403: Use of char data type improve MISRA-C:2004 compliance

3-4
3.2 Simulink Model Advisor DO-178C/DO-331
Checks
Apply the following checks documented in the "DO Qualification Kit Simulink ® Verification
and Validation™ DO-178C/DO-331 Checks and Model Advisor User Information":
Check for blocks that do not link to requirements
Check state machine type of Stateflow charts
Check Stateflow charts for ordering of states and transitions
Check usage of lookup table blocks
Check MATLAB Code Analyzer messages
Check MATLAB code for global variables
Check for inconsistent vector indexing methods
Check for blocks not recommended for C and C++ production code deployment
Check Stateflow charts for uniquely defined data objects
Check usage of Math Operations blocks
Check usage of Signal Routing blocks
Check usage of Logic and Bit Operations blocks
Check usage of Ports and Subsystems blocks
Check for MATLAB Function interfaces with inherited properties
Check MATLAB Function metrics
Display model version information

3-5
3.3 MathWorks Automotive Advisory Board
<The MathWorks Automotive Advisory Board (MAAB) guidelines support the readability,
reusability, and overall quality of Simulink models. Consider selecting dedicated MAAB
guidelines for this Chapter.>

3-6
3.4 Company-Specific Guidelines
<Please insert your own additional guidelines here. It is recommended to specify an additional
project specific subset of MATLAB, Simulink, and Stateflow elements and settings to be used for
design models.>

3-7
3-8
4 Constraints on Modeling Tools

This section describes the constraints on the use of the modeling tools MATLAB, Simulink, and
Stateflow (DO-331MB.11.23.d).

<Please use the Simulink Modeling Guidelines for High Integrity Systems when defining your
own subset of guidelines. The guidelines are available at the MathWorks Documentation Center,
R2015a. Delete the following guidelines if they are not applicable in your project>
4.1 Modeling Guidelines for High-Integrity Systems
<Describe the means of compliance to be used for this project; normally this will reference DO-
178. This section should also include references to TC, STC, TSO, Advisory Circulars, Special
Conditions, Etc.>

Configuration Parameter Considerations – Solver

hisl_0040: Configuration Parameters > Solver > Simulation time
hisl_0041: Configuration Parameters > Solver > Solver options
hisl_0042: Configuration Parameters > Solver > Tasking and sample time options

Configuration Parameter Considerations – Diagnostics

hisl_0043: Configuration Parameters > Diagnostics > Solver
hisl_0044: Configuration Parameters > Diagnostics > Sample Time
hisl_0301: Configuration Parameters > Diagnostics > Compatibility
hisl_0302: Configuration Parameters > Diagnostics > Data Validity > Parameters
hisl_0303: Configuration Parameters > Diagnostics > Data Validity > Merge block
hisl_0304: Configuration Parameters > Diagnostics > Data Validity > Model Initialization
hisl_0305: Configuration Parameters > Diagnostics > Data Validity > Debugging
hisl_0306: Configuration Parameters > Diagnostics > Connectivity > Signals
hisl_0307: Configuration Parameters > Diagnostics > Connectivity > Buses
hisl_0308: Configuration Parameters > Diagnostics > Connectivity > Function calls
hisl_0309: Configuration Parameters > Diagnostics > Type Conversion
hisl_0310: Configuration Parameters > Diagnostics > Model Referencing
hisl_0311: Configuration Parameters > Diagnostics > Stateflow

Configuration Parameter Considerations – Optimizations

hisl_0045: Configuration Parameters > Optimization > Implement logic signals as Boolean data
(vs. double)
hisl_0046: Configuration Parameters > Optimization > Block reduction
hisl_0048: Configuration Parameters > Optimization > Application lifespan (days)

4-2
hisl_0051: Configuration Parameters > Optimization > Signals and Parameters > Loop unrolling
threshold
hisl_0052: Configuration Parameters > Optimization > Data initialization
hisl_0053: Configuration Parameters > Optimization > Remove code from floating-point to
integer conversions that wraps out-of-range values
hisl_0054: Configuration Parameters > Optimization > Remove code that protects against
division arithmetic exceptions
hisl_0055: Prioritization of code generation objectives for high-integrity systems

Stateflow Chart Considerations – Chart Properties

hisf_0011: Stateflow debugging settings

MISRA-C:2004 Compliance Considerations –Configuration Settings

hisl_0060: Configuration parameters that improve MISRA-C:2004 compliance
hisl_0312: Specify target specific configuration parameters to improve MISRA-C:2004
compliance
hisl_0313: Selection of bitfield data types to improve MISRA-C:2004 compliance

4-3
4.2 Simulink Model Advisor DO-178C/DO-331
Checks
Apply the following checks documented in "DO Qualification Kit Simulink® Verification and
Validation™ DO-178C/DO-331 Checks and Model Advisor User Information":

Check safety-related optimization settings

Check safety-related diagnostic settings for solvers
Check safety-related diagnostic settings for sample time
Check safety-related diagnostic settings for signal data
Check safety-related diagnostic settings for parameters
Check safety-related diagnostic settings for data used for debugging
Check safety-related diagnostic settings for data store memory
Check safety-related diagnostic settings for type conversions
Check safety-related diagnostic settings for signal connectivity
Check safety-related diagnostic settings for bus connectivity
Check safety-related diagnostic settings that apply to function-call connectivity
Check safety-related diagnostic settings for compatibility
Check safety-related diagnostic settings for model initialization
Check safety-related diagnostic settings for model referencing
Check safety-related model referencing settings
Check safety-related code generation settings
Check safety-related diagnostic settings for saving
Check Stateflow debugging settings

4-4
4.3 Company-Specific Constraints
<Please insert your own additional constraints here. It is recommended to specify an additional
project specific subset of settings to be used for design models (e.g. settings regarding the
project specific target platform).>

4-5
4-6
5 Model Requirements and
Traceability

This section describes the method to identify and delimit the requirements contained in the
model and the means to establish traceability between requirements and other lifecycle data
(DO-331MB.11.23.e).

As defined in DO-331 MB.1.6.2, design models contain the software architecture and the
software low-level requirements. Low-level requirements are expressed by the subset of
MATLAB, Simulink, and Stateflow, as defined in Chapter 3 Style Guidelines and Complexity
Restrictions. See Chapter 7 Additional Model Elements for model elements that do not express
requirements.

Use the Simulink Verification and Validation Requirements Management Interface (RMI) to
trace between the design model and the requirements the model was developed from. Single
blocks or a combination of blocks can express and link to requirements.

Traceability between the design model and the generated code is established by comments
contained in the generated source code. The comments provide links to the design model
element.

To facilitate review, a traceability report is generated with the data between the design model
and the requirements from which the model was developed. The traceability between the design
model and the generated source code is automatically checked using the Simulink Code
Inspector™ and by reviewing the generated Code Inspector Report.
5-2
6 Derived Requirements

This section describes the method to identify and delimit the derived requirements contained in
the model. It also describes the method to provide derived requirements to the system processes,
including the system safety assessment process (DO-331MB.11.23.f).

Note: Derived requirements can be part of a design model or they can be treated like regular
requirements outside of a design model. The following information refers to derived
requirements contained in a design model.

Derived requirements that are contained in a design model will be marked by <Please insert
your strategy here> to clearly identify them as derived requirements and to provide them to the
safety assessment process. A combination of model review and model coverage analysis (as
defined in DO-331 Section 6.7) is used to verify that all derived requirements were properly
marked and analyzed. As described in DO-331 Table MB.6-1, additional test cases will be
created, based on the derived requirements contained in the design model. The additional test
cases have to be executed on the executable object code. An analysis of the results from model
coverage analysis and structural coverage analysis will verify that all derived requirements are
identified correctly.

Note: You can create test cases for derived requirements using Simulink Design Verifier ™.
6-2
7 Additional Model Elements

This section describes the means to identify each model element that does not contribute to the
representation of a software requirement or of the software architecture, and is not an input to a
subsequent software development process or activity. For example, a comment block (DO-
331MB.11.23.g).

In addition to Chapter 3 Style Guidelines and Complexity Restrictions, the following model
elements are part of a design model, but will not be subject to code generation:

<Please list all additional elements of your design model that are not subject to code generation
in here (e.g. annotations, Model Info block, DocBlock and so on).>

A model review will be performed to verify the correct use of the additional model elements and
the absence of undefined elements.
7-2
8 Suitability of Technique

This section provides a rationale for the suitability of the technique for the type of information
expressed by a Design Model (DO-331MB.11.23.h).

<Please adapt the following paragraph to your industry domain specific needs.>

Block diagrams are a well-established way of describing flow and logic-based applications for
control and monitoring systems. State charts and flow charts are a basic notation form in
information technology and other industries.

MATLAB, Simulink, and Stateflow are long-time standard tools among a wide variety of
industries. The tools documentation is available at the MathWorks Documentation Center.
People involved in a software development project can use the documentation to understand the
content of a design model.