Model-Based Design For DO-178B R2008b

Model-Based Design for Safety Critical or
Mission Critical DO-178B Applications

Using MathWorks Software Release R2008b
March 3, 2009
The MathWorks Confidential Subject to NonDisclosure Agreement

This document is CONFIDENTIAL and cannot be disclosed, disseminated, or distributed
to parties outside The MathWorks or its subsidiaries without written permission from
The MathWorks, Inc.
The MathWorks, Inc.

3 Apple Hill Drive
Natick, MA 01760-2098
COPYRIGHT 2009 by The MathWorks, Inc.

MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, PolySpace and
xPC TargetBox are registered trademarks of The MathWorks, Inc.
1
2
Introduction ................................................................................................................. 5
DO-178B Software Lifecycle ..................................................................................... 7
2.1 Table A-1 Planning Process ................................................................................. 8
2.1.1
Software development and integral processes activities are defined ............ 8
2.1.2
Transition criteria, inter-relationships and sequencing among processes are
defined 10
2.1.3
Software life cycle environment is defined ................................................ 10
2.1.4
Additional considerations are addressed ..................................................... 10
2.1.5
Software development standards are defined ............................................. 11
2.1.6
Software plans comply with this document ................................................ 11
2.1.7
Software plans are coordinated ................................................................... 11
2.2 Table A-2 Software Development Process ........................................................ 12
2.2.1
High-level requirements are developed ...................................................... 12
2.2.2
Derived high-level requirements are developed ......................................... 13
2.2.3
Software architecture is developed ............................................................. 13
2.2.4
Low-level requirements are developed ....................................................... 13
2.2.5
Derived low-level requirements are developed .......................................... 13
2.2.6
Source code is developed ............................................................................ 13
2.2.7
Executable Object Code is produced and integrated in the target computer
14
2.3 Table A-3 Verification of Requirements Process .............................................. 15
2.3.1
Software high-level requirements comply with system requirements ........ 16
2.3.2
High-level requirements are accurate and consistent.................................. 16
2.3.3
High-level requirements are compatible with the target computer ............. 16
2.3.4
High-level requirements are verifiable ....................................................... 17
2.3.5
High-level requirements conform to standards ........................................... 17
2.3.6
High-level requirements are traceable to system requirements .................. 17
2.3.7
Algorithms are accurate .............................................................................. 17
2.4 Table A-4 Verification of Design Process ......................................................... 18
2.4.1
Low-level requirements comply with high-level requirements .................. 20
2.4.2
Low-level requirements are accurate and consistent .................................. 20
2.4.3
Low-level requirements are compatible with the target computer ............. 20
2.4.4
Low-level requirements are verifiable ........................................................ 20
2.4.5
Low-level requirements conform to standards ........................................... 21
2.4.6
Low-level requirements are traceable to high-level requirements .............. 21
2.4.7
Algorithms are accurate .............................................................................. 21
2.4.8
Software architecture is compatible with high-level requirements............. 22
2.4.9
Software architecture is consistent.............................................................. 22
2.4.10 Software architecture is compatible with the target computer.................... 22
2.4.11 Software architecture is verifiable .............................................................. 23
2.4.12 Software architecture conforms to standards .............................................. 23
2.4.13 Software partitioning integrity is confirmed ............................................... 23
2.5 Table A-5 Verification of Coding and Integration Process................................ 24
2.5.1
Source code complies with low-level requirements ................................... 24
Page 1
MathWorks Confidential subject to Non-Disclosure Agreement
Do not distribute
2.5.2
Source code complies with software architecture ....................................... 25
2.5.3
Source code is verifiable ............................................................................. 25
2.5.4
Source code conforms to standards............................................................. 25
2.5.5
Source code is traceable to low-level requirements .................................... 25
2.5.6
Source code is accurate and consistent ....................................................... 25
2.5.7
Output of software integration process is complete and correct ................. 25
2.6 Table A-6 Testing of Outputs of Integration Process ........................................ 26
2.6.1
Executable Object Code complies with high-level requirements ............... 27
2.6.2
Executable Object Code is robust with high-level requirements ................ 27
2.6.3
Executable Object Code complies with low-level requirements ................ 27
2.6.4
Executable Object Code is robust with low-level requirements ................. 28
2.6.5
Executable Object Code is compatible with target computer ..................... 28
2.7 Table A-7 Verification of Verification Process Results..................................... 29
2.7.1
Test procedures are correct ......................................................................... 29
2.7.2
Test results are correct and discrepancies explained .................................. 30
2.7.3
Test coverage of high-level requirements is achieved ................................ 30
2.7.4
Test coverage of low-level requirements is achieved ................................. 30
2.7.5
Test coverage of software structure (modified condition/decision) is
achieved .................................................................................................................... 30
2.7.6
Test coverage of software structure (decision coverage) is achieved ......... 30
2.7.7
Test coverage of software structure (statement coverage) is achieved ....... 31
2.7.8
Test coverage of software structure (data coupling and control) is achieved
31
2.8 Table A-8 Software Configuration Management Process.................................. 32
2.8.1
Configuration items are identified .............................................................. 32
2.8.2
Baselines and traceability are established ................................................... 33
2.8.3
Problem reporting, change control, change review, and configuration status
accounting are established ........................................................................................ 33
2.8.4
Archive, retrieval, and release are established ............................................ 33
2.8.5
Software load control is established ........................................................... 33
2.8.6
Software life cycle environment control is established .............................. 33
2.9 Table A-9 Software Quality Assurance Process ................................................ 34
2.9.1
Assurance is obtained that software development and integral processes
comply with approved software plans and standards ............................................... 34
2.9.2
Assurance is obtained that transition criteria for the software life cycle
processes are satisfied ............................................................................................... 34
2.9.3
Software conformity review is completed .................................................. 34
2.10
Table A-10 Certification Liaison Process ...................................................... 35
2.10.1 Communication and understanding between the applicant and the
certification authority is established ......................................................................... 35
2.10.2 The means of compliance is proposed and agreement with the Plan for
Software Aspects of Certification is obtained .......................................................... 35
2.10.3 Compliance substantiation is provided ....................................................... 35
3 Model Architecture Considerations .......................................................................... 36
3.1 Use of Atomic Subsystems ................................................................................ 36
Page 2
Do not distribute
3.2 Use of Model Reference ..................................................................................... 37

3.3 Input and Output Hardware Interfaces ............................................................... 40
3.4 Test Harnesses .................................................................................................... 42
4 Solver Considerations for Safety Critical or Mission Critical Systems .................... 44
5 Data Import/Export Considerations for Safety Critical or Mission Critical Systems47
6 Optimization Considerations for Safety Critical or Mission Critical Systems ......... 48
7 Model Diagnostic Considerations for Safety Critical or Mission Critical Systems . 52
7.1 Solver Diagnostics.............................................................................................. 52
7.2 Sample Time Diagnostics................................................................................... 55
7.3 Data Validity Diagnostics .................................................................................. 57
7.4 Type Conversion Diagnostics ............................................................................ 61
7.5 Connectivity Diagnostics ................................................................................... 63
7.6 Compatibility Diagnostics .................................................................................. 65
7.7 Model Reference Diagnostics ............................................................................ 66
7.8 Saving Diagnostics ............................................................................................. 69
8 Hardware Implementation Considerations for Safety Critical or Mission Critical
Systems ............................................................................................................................. 71
9 Simulation Target Considerations for Safety Critical or Mission Critical Systems . 72
9.1 Simulation Target ............................................................................................... 72
9.2 Symbols .............................................................................................................. 74
9.3 Custom Code ...................................................................................................... 76
10 Code Generator Considerations for Safety Critical or Mission Critical Systems ..... 78
10.1
Real-Time Workshop Software ................................................................... 78
10.2
Report ............................................................................................................. 81
10.3
Comments ....................................................................................................... 83
10.4
Symbols .......................................................................................................... 85
10.5
Custom Code .................................................................................................. 89
10.6
Debug.............................................................................................................. 91
10.7
Interface .......................................................................................................... 92
10.8
Code Style....................................................................................................... 95
10.9
Templates........................................................................................................ 96
10.10 Data Placement ............................................................................................... 97
10.11 Data Type Replacement.................................................................................. 98
10.12 Memory Sections ............................................................................................ 99
11 Block Selection Considerations for Safety Critical or Mission Critical Systems ... 100
11.1
General Guidelines ....................................................................................... 100
11.2
Specific Blocks of Concern .......................................................................... 100
12 Block Setting and Data Type Considerations for Safety Critical or Mission Critical
Systems ........................................................................................................................... 101
12.1
General Block Data Type Settings ............................................................... 101
12.2
Saturate on Integer Overflow Settings.......................................................... 104
12.3
Abs Block ..................................................................................................... 105
12.4
Data Store Blocks ......................................................................................... 106
12.5
For Iterator Subsystem.................................................................................. 106
12.6
Inport and Outport Blocks ............................................................................ 106
Page 3
Do not distribute
12.7
Math Function Block .................................................................................... 107
12.8
Merge Block ................................................................................................. 108
12.9
Product Block ............................................................................................... 108
12.10 Relational Operator Blocks .......................................................................... 109
12.11 Triggered Subsystem .................................................................................... 109
12.12 While Iterator Subsystem ............................................................................. 109
13 Stateflow Software Considerations for Safety Critical or Mission Critical Systems
110
13.1
Chart Settings ............................................................................................... 110
13.2
Stateflow Software Debugger Settings ...................................................... 111
13.3
Truth Table Settings ..................................................................................... 112
13.4
Chart Commenting ....................................................................................... 112
13.5
Transition Paths Crossing Parallel State Boundaries ................................... 113
13.6
Transition Paths Looping Out of the Parent of Source/Destination Objects 114
13.7
Transition Paths Passing Through a State .................................................... 114
13.8
Flow-Graph Backup ..................................................................................... 116
13.9
Recursive Graphical Functions ..................................................................... 117
14 Run-Time Library Considerations for Safety Critical or Mission Critical Systems118
14.1
Runtime Libraries ......................................................................................... 118
14.2
MISRA-C Violations .................................................................................... 118
Page 4
Do not distribute
1 Introduction
The purpose of this document is to provide approaches for applying the MathWorks
Model-Based Design products to safety critical or mission critical systems that must meet
DO-178B1 objectives for certification. Approaches presented in this document are
provided as recommendations, but are not the only methods that could be used in meeting
DO-178B objectives for certification. These guidelines may also be applied to safety
critical or mission critical systems that do not have to meet the objectives of DO-178B,
but this document does assume that the software lifecycle follows that standard.
Disclaimer: While adhering to the recommendations in this document will reduce

the risk that an error is introduced in the software development process and is not
detected, it is not a guarantee that the system being developed will be safe.
Conversely, if the recommendations in this document are not followed, it does not
mean that the system being developed will be unsafe.
DO-178B defines five software levels: A, B, C, D and E. Systems being developed to
levels A or B would certainly fall into the category of safety critical or mission critical,
because failures of these systems could result in loss of life. Systems being developed to
level C may result in increased crew workload and a reduction in safety and should
therefore provide a high degree of reliability. The recommendations in this document are
applicable to systems being developed to levels A, B and C.
This document does not discuss custom S-Functions, device drivers or Embedded
MATLAB functions that are produced by the developer using manual coding
techniques. Hand written code that is called by auto-generated code will have to meet all
of the lifecycle requirements of DO-178B. Considerations for Embedded MATLAB
functions may be added to this document in the future.
It is not the purpose of this document to provide modeling style guidelines. The MAAB
Style Guidelines document is available on MATLAB Central at the following link.
http://www.mathworks.com/support/solutions/data/1-4SHZMF.html?product=SL&solution=14SHZMF
The motivation of the MAAB Style Guidelines, as described in that document, is:
System integration without problems
Clean interfaces
Uniform appearance of models, code and documentation
Reusable models
1
Software Considerations in Airborne Systems and Equipment Certification, Document No. RTCA/DO178B, December 1, 1992, Prepared by SC-167
Page 5
Do not distribute
Readable models
Hassle-free exchange of models
Avoidance of legacies
A clean process
Professional documentation
Understandable presentations
Fast software changes
Cooperation with subcontractors
Handing over of (research or predevelopment) projects (to product development)
The MAAB Style Guidelines document is considered to be complementary to this

document and may be used as a starting point for defining modeling standards for a
safety critical or mission critical development program.
This document is current with MathWorks software Release R2008b.
Page 6
Do not distribute
2 DO-178B Software Lifecycle

The following processes make up the DO-178B software lifecycle:
Planning process
Software development process
Verification of requirements process
Verification of design process
Verification of coding and integration process
Testing of outputs of integration process
Verification of verification process results
Software configuration management process
Software quality assurance process
Certification liaison process
There are objectives that must be met for each of the lifecycle stages defined in DO-178B.
These objectives are summarized in Appendix A of DO-178B in the form of tables. The
following sections of this document summarize those tables and provide
recommendations on how the objectives may be met using a Model-Based Design
process. Additionally, the potential usage of available Model-Based Design tools in
achieving the objectives is also included.
Page 7
Do not distribute
2.1 Table A-1 Planning Process

The following table contains a summary of the planning process objectives from DO178B, including Description, applicable DO-178B reference sections and software levels
the objective is applicable to. The table also provides the potential impact to the process
when using Model-Based Design.
Description
Section
Software development and integral 4.1a

processes activities are defined.
4.3
Transition criteria, inter4.1b

relationships and sequencing among 4.3
processes are defined.
Software life cycle environment is

defined.
4.1c
Additional considerations are

addressed.
4.1d
Software development standards are 4.1e

defined.
Software plans comply with this

document.
4.1f
4.6
Software plans are coordinated.
4.1g
4.6
Software Process Impact when using

Levels
Model-Based Design
A, B, C, Must include Model-Based
D
Design as part of the
development process
A, B, C Must include Model-Based
Design transition and
sequencing relationships
A, B, C
Must include Model-Based

Design tools used in the
lifecycle processes
A, B, C, Must address any EASA
D
Certification Review Items
and/or FAA Issue Papers,
if applicable to the project
A, B, C Must include modeling
standards as part of the
development standards
A, B, C No impact as compared to
traditional development
A, B, C
No impact as compared to
traditional development
The following sections describe in more detail the potential impacts as compared to
traditional development, if applicable, for each planning process objective when using
Model-Based Design.
2.1.1 Software development and integral processes activities are

defined
Model-Based Design must be defined as one of the activities in the software development
process. Models may be defined as high level software requirements or as low level
software requirements or both. It is possible that library or model reference components
may be developed and defined as low level software requirements and that the models
Page 8
Do not distribute
that these components are used in to provide full functionality may be defined as high
level software requirements. Three different scenarios will be described in this section.
Scenario 1 Models developed at the system level are used to generate code
directly
Under this scenario, high level system requirements allocated to system design are
in the form of textual requirements. The models are developed during the system
design process and allocated to software. The models become both the high and
low level software requirements. The models must meet predefined standards and
must be adequately detailed such that code can be generated directly from the
models. As a part of the development process, a predefined set of library blocks
and/or reusable reference models may be designed for use by the systems
engineers. For this case the requirements for the library blocks and reference
models may be considered to be derived software requirements, since they do not
trace to the higher level requirements.
Under this scenario, the verification objectives from tables A-3 and A-4 would be
combined and applied to the single model.
Scenario 2 Models developed at the system level are not used directly to
generate code
Under this scenario, high level system requirements allocated to system design are
in the form of textual requirements. The models are developed during the system
design process and allocated to software. These models become the high level
software requirements but they are not detailed enough to generate code directly.
An example case of this type of model would be a Simulink diagram that used
continuous time blocks which are not appropriate for embedded real-time code.
The software engineering process would take these models and modify them and
add detail as necessary prior to code generation. These modified models would
then become the low level software requirements.
Under this scenario, the verification objectives from table A-3 would be applied
to the high level model and the objectives from table A-4 would be applied to the
low level model.
Scenario 3 System level textual requirements are allocated to software
Under this scenario, the system level requirements and design allocated to
software are in the form of textual high level software requirements. The models
are developed as part of the software engineering process and are detailed enough
to generate code. In this case the models are the low level software requirements.
Page 9
Do not distribute
Under this scenario, the verification objectives from table A-3 would be applied
to the high level textual requirements and the objectives from table A-4 would be
applied to the model.
Change control and configuration management of the models must be addressed in the
planning process.
2.1.2 Transition criteria, inter-relationships and sequencing among

processes are defined
The stage at which Model-Based Design begins must be defined, this will typically be at
the point where the higher level requirements (either system requirements or high level
software requirements) have been developed, configured and approved.
The stage at which code is generated must be defined, this will typically be at the point
that the models have been developed, configured and approved. The steps necessary to
approve the models as complete and correct must be defined and may include: reviews of
the model, simulation testing of the model, static analysis of the model and dynamic
analysis of the model.
2.1.3 Software life cycle environment is defined

Model-Based Design tools that will be used in the development and verification
processes must be defined. These may include tools such as MATLAB, Simulink,
Stateflow, Stateflow Coder, Real-Time Workshop, Real-Time Workshop
Embedded Coder, Simulink Verification and Validation, SystemTest, MATLAB
Report Generator and Simulink Report Generator software.
2.1.4 Additional considerations are addressed

If any Model-Based Design tools will be qualified, either as development or verification
tools, then each of the tools to be qualified must be identified and the tool qualification
activities must be defined.
It is typical for the Federal Aviation Administration (FAA) to provide an Issue Paper (IP),
or for European Aviation Safety Agency (EASA) to provide a Certification Review Item
(CRI), when Model-Based Design is used on a program. Items in the program-specific IP
and/or CRI will need to be addressed during planning. There may be requirements to
trace the models to higher level requirements and to trace the code to the models.
Verification of the models and executable object code against the higher level
requirements may also be addressed. For software levels A and B, independence of the
model developer and the test developer may need to be insured as part of the verification
against the higher level requirements. If an automated tool is used to verify the
executable object code against the model, then that tool may have to be shown to be
independent of the automatic code generator and compiler. The use of an automated tool
to verify the executable object code against the model does not eliminate the need to
Page 10
Do not distribute
verify the executable object code against the higher level requirements; it may only be
used to supplement the higher level requirements based tests.
2.1.5 Software development standards are defined

Because the models may be mapped to high level requirements, low level requirements or
both (see section 2.1.1), there will need to be modeling standards in place to satisfy the
requirements standards objectives. Compliance to the standards will have to be verified
through the use of tools and/or human reviews.
For Real-Time Workshop Embedded Coder, MISRA-C2 coding standards can be used,
with a few minor exceptions. Some constructs in the generated code, such as naming
conventions, can be controlled by the users in order to meet specific customer coding
standards. Compliance to the standards will have to be verified through the use of tools
and/or human reviews.
2.1.6 Software plans comply with this document

A Plan for Software Aspects of Certification must be developed, the same as for
traditional development programs.
2.1.7 Software plans are coordinated

The Plan for Software Aspects of Certification must be configured under change control
and approved by the applicable certification authorities as part of the program, as in a
traditional development process.
MISRA-C:2004 Guidelines for the use of the C language in critical systems, The Motor Industry
Software Reliability Association, dated October 2004.
Page 11
Do not distribute
2.2 Table A-2 Software Development Process

The following table contains a summary of the software development process objectives
from DO-178B, including Description, applicable DO-178B reference sections and
software levels the objective is applicable to. The table also provides the available
Model-Based Design tools that may be used in satisfying the objectives.
Description
Section
Software
Levels
Available Model-Based
Design Tools
High-level requirements are

developed.
5.1.1a
A, B, C, D Simulink software
Stateflow software
Derived high-level requirements 5.1.1b

are developed.
Stateflow software
Software architecture is
developed.
5.2.1a
Stateflow software
Low-level requirements are

developed.
5.2.1a
Stateflow software
Derived low-level requirements 5.2.1b

are developed.
Stateflow software
Source code is developed.
5.3.1a
A, B, C, D Real-Time Workshop
Embedded Coder software
Executable Object Code is

produced and integrated in the
target computer.
5.3.1a
A, B, C, D Embedded IDE Link CC

Embedded IDE Link
MU
Embedded IDE Link TS
Embedded IDE Link VS
traditional development, if applicable, for each software development process objective
2.2.1 High-level requirements are developed

If models are defined as high level software requirements, then Simulink and Stateflow
software may be used to develop the high level software requirements. The components
within these models (such as Simulink blocks or Stateflow objects) would then trace to
the appropriate system level requirements, which are developed in accordance with
Page 12
Do not distribute
ARP47543. The models should be developed in accordance with the modeling standards
defined during the planning process.
2.2.2 Derived high-level requirements are developed

If models are defined as high level software requirements, then any Simulink or Stateflow
components that do not trace to the system requirements would be identified as derived
requirements and these would be provided to the safety assessment process.
2.2.3 Software architecture is developed

Architecture of individual software modules may be defined by the Simulink and
Stateflow models, including sequencing and interfacing of the various elements within
the models. If model reference capability is used, then the model dependency viewer
may be used to document the architecture of the software modules that are integrated
using this capability.
The higher level architecture of how the Model-Based Design generated code interfaces
to other code within the system must be defined separately. This may include interface to
the real-time operating system (RTOS), calling sequence for the code generated from the
Model-Based Design and data interface to other code modules.
2.2.4 Low-level requirements are developed

If models are defined as low level software requirements, then Simulink and Stateflow
may be used to develop the low level software requirements. The components within
these models would then trace to the appropriate high level software requirements. The
models should be developed in accordance with the modeling standards defined during
the planning process.
If the models are defined as high level software requirements, and source code will be
generated directly from those models, then this objective does not apply.
2.2.5 Derived low-level requirements are developed

If models are defined as low level software requirements, then any Simulink or Stateflow
components that do not trace to the high level software requirements would be identified
as derived requirements and these would be provided to the safety assessment process.
If the models are defined as high level software requirements, then it is possible that
library components or reusable model reference functions may be considered to be
derived low level requirements.
2.2.6 Source code is developed

Real-Time Workshop Embedded Coder may be used to generate the source code from
the model. The source code can trace to the model components through the use of
3
Certification Considerations for Highly Integrated or Complex Aircraft Systems, Document No. SAE
ARP4754, dated November 1996, developed by SAE International.
Page 13
Do not distribute
appropriate commenting options described later in this document. The source code can be
generated in accordance with MISRA-C standards, with some exceptions, using
appropriate modeling standards.
2.2.7 Executable Object Code is produced and integrated in the

target computer
The generated source code may be compiled, linked and the executable object code
automatically downloaded to a target processor or DSP using Embedded IDE Link CC,
Embedded IDE Link MU, Embedded IDE Link TS, or Embedded IDE Link VS.
Alternatively, the generated source code may be compiled and linked using standard
compilers/linkers. Real-Time Workshop Embedded Coder may generate a make file
for use by the compiler or this may be developed manually. The executable object code
is then loaded onto the target computer.
Page 14
Do not distribute
2.3 Table A-3 Verification of Requirements Process

The following table contains a summary of the verification of requirements process
objectives from DO-178B, including Description, applicable DO-178B reference sections
and software levels the objective is applicable to. The table also provides the available
Description
Section
Software
Levels
Design Tools
Software high-level
requirements comply with
system requirements.
6.3.1a

accurate and consistent.
6.3.1b

compatible with the target
computer.
6.3.1c
A, B, C, D Simulink Verification
and Validation
Simulink Design Verifier
SystemTest
Report Generator
Model Reviews
A, B, C, D Simulink Verification
and Validation
SystemTest
Model Advisor
Report Generator
Model Reviews
A, B
Model Advisor
Report Generator
Model Reviews

verifiable.
6.3.1d
A, B, C
High-level requirements
conform to standards.
6.3.1e
A, B, C

traceable to system
requirements.
6.3.1f
A, B, C, D Requirements Management
Interface
Model Advisor
Report Generator
Model Reviews
Simulink Verification
and Validation
SystemTest
Model Advisor
Model Coverage
Report Generator
Model Reviews
Model Advisor
Report Generator
Model Reviews
Page 15
Do not distribute
Algorithms are accurate.
6.3.1g
A, B, C
and Validation
SystemTest
Model Advisor
Report Generator
Model Reviews
traditional development, if applicable, for each of the verification of requirements process
objectives when using Model-Based Design.
2.3.1 Software high-level requirements comply with system

requirements
If models are defined as high level software requirements, compliance with system
requirements may be accomplished using a combination of model reviews, model
analysis and simulation. Simulink Report Generator may be used to generate a model
review packet that includes a trace report to the system requirements. SystemTest and
Simulink Verification and Validation may be used to develop test cases based on the
system requirements and execute those test cases on the model to assist in verifying the
system requirements are satisfied. Simulink Design Verifier may be used to analyze the
model using Property Proving in order to assist in verifying certain system requirements
are satisfied.
2.3.2 High-level requirements are accurate and consistent

If models are defined as high level software requirements, accuracy and consistency may
be verified using a combination of model reviews and simulation. Simulink Report
Generator may be used to generate a model review packet that includes a trace report to
the higher level requirements. SystemTest and Simulink Verification and Validation may
be used to develop test cases based on the system requirements and execute those test
cases on the model to assist in verifying the accuracy and consistency. The Model
Advisor may be used to assist in verifying the diagnostic settings used by Simulink are
appropriate for simulation and also verifying the proper usage of certain Simulink blocks.
2.3.3 High-level requirements are compatible with the target

computer
If models are defined as high level software requirements, compatibility with target
hardware may be accomplished using a combination of model reviews and Model
Advisor checks. Simulink Report Generator may be used to generate a model review
packet that includes a trace report to the higher level requirements. The Model Advisor
may be used to assist in verifying the hardware interface settings used by Real-Time
Workshop Embedded Coder are appropriate for the target processor.
Page 16
Do not distribute
2.3.4 High-level requirements are verifiable

If models are defined as high level software requirements, verifiability may be
accomplished using a combination of model reviews and simulation. Simulink Report
be used to develop test cases from the system requirements and execute those test cases
on the model. During execution of these test cases, a Model Coverage Report, a
component of Simulink Verification and Validation, may be generated to assist in
verifying that all requirements are fully verified. The coverage report may assist in
finding conditions and decisions in the model that cannot be reached, thus indicating that
the requirements may not be fully verifiable. Simulink Design Verifier may be used to
identify untestable or unreachable model conditions and decisions using test case
generation, thus indicating that the high level requirements may not be fully verifiable.
The Model Advisor may be used to assist in verifying the proper usage of certain
Simulink blocks and data types.
2.3.5 High-level requirements conform to standards

If models are defined as high level software requirements, conformance to standards may
be accomplished using a combination of model reviews and Model Advisor checks.
Simulink Report Generator may be used to generate a model review packet that includes
a trace report to the higher level requirements. The Model Advisor may verify predefined model standards and may also be customized using an API to perform checks
defined by the user that may be unique for their application.
2.3.6 High-level requirements are traceable to system requirements

If models are defined as high level software requirements, traceability to system
requirements may be accomplished by model reviews that include a report generated by
the Requirements Management Interface, a component of Simulink Verification and
Validation. Simulink Report Generator may be used to generate a model review packet
that includes a trace report to the system requirements. The Model Advisor may be used
to assist in verifying that requirements links are consistent.
2.3.7 Algorithms are accurate

If models are defined as high level software requirements, accuracy of the algorithms
may be verified using a combination of model reviews and simulation. Simulink Report
be used to develop test cases from the system requirements and execute those test cases
on the model, thus assisting in verifying the accuracy of the algorithms within the model.
The Model Advisor may be used to assist in verifying the proper usage of certain
Page 17
Do not distribute
2.4 Table A-4 Verification of Design Process

The following table contains a summary of the verification of design process objectives
software levels the objective is applicable to. The table also provides the available
Description
Section
Software
Levels
Design Tools
and Validation
SystemTest
Report Generator
Model Reviews
and Validation
SystemTest
Report Generator
Model Reviews
Model Advisor
Report Generator
Model Reviews
Low-level requirements comply 6.3.2a

with high-level requirements.
A, B, C

accurate and consistent.
6.3.2b
A, B, C

computer.
6.3.2c
A, B

verifiable.
6.3.2d
A, B
Low-level requirements
conform to standards.
6.3.2e
A, B, C

traceable to high-level
requirements.
6.3.2f
A, B, C
and Validation
SystemTest
Model Advisor
Model Coverage
Report Generator
Model Reviews
Model Advisor
Report Generator
Model Reviews
Requirements Management
Interface
Model Advisor
Report Generator
Model Reviews
Page 18
Do not distribute
Description
Section
Software
Levels
Design Tools
Algorithms are accurate.
6.3.2g
A, B, C
compatible with high-level
requirements.
6.3.3a
A, B, C
and Validation
SystemTest
Model Advisor
Report Generator
Model Reviews
Report Generator
Model Dependency Viewer
Model Reviews
consistent.
6.3.3b
A, B, C
Model Advisor
Report Generator
Model Dependency Viewer
Model Reviews
10 Software architecture is
computer.
6.3.3c
A, B
Model Advisor
Report Generator
Model Reviews
11 Software architecture is
verifiable.
6.3.3d
A, B
Model Coverage
Model Advisor
Report Generator
Model Reviews
12 Software architecture conforms 6.3.3e

to standards.
A, B, C
Model Advisor
Report Generator
Model Reviews
13 Software partitioning integrity 6.3.3f

is confirmed.
A, B, C, D Not applicable
traditional development, if applicable, for each of the verification of design process
objectives when using Model-Based Design.
Page 19
Do not distribute
2.4.1 Low-level requirements comply with high-level requirements

If models are defined as low level software requirements, compliance with high level
software requirements may be accomplished using a combination of model reviews,
model analysis and simulation. Simulink Report Generator may be used to generate a
model review packet that includes a trace report to the system requirements. SystemTest
and Simulink Verification and Validation may be used to develop test cases from the high
level requirements and execute those test cases on the model to assist in verifying the
high level requirements are satisfied. Simulink Design Verifier may be used to analyze
the model using Property Proving in order to assist in verifying certain high level
requirements are satisfied.
If the models are defined as high level software requirements, then code may be
generated directly from the high level requirements and this objective does not apply. See
DO-178B, Section 6.1.b for details.
2.4.2 Low-level requirements are accurate and consistent

If models are defined as low level software requirements, accuracy and consistency may
be used to develop test cases from the high level requirements and execute those test
cases on the model to assist in verifying the accuracy and consistency. The Model
Advisor may be used to assist in verifying the diagnostic settings used by Simulink are
appropriate for simulation and also verifying the proper usage of certain Simulink blocks.
2.4.3 Low-level requirements are compatible with the target computer

If models are defined as low level software requirements, compatibility with target
hardware may be accomplished using a combination of model reviews and Model
Advisor checks. Simulink Report Generator may be used to generate a model review
packet that includes a trace report to the higher level requirements. The Model Advisor
may be used to assist in verifying the hardware interface settings used by Real-Time
Workshop Embedded Coder are appropriate for the target processor.
2.4.4 Low-level requirements are verifiable

If models are defined as low level software requirements, verifiability may be
accomplished using a combination of model reviews and simulation. Simulink Report
Page 20
Do not distribute
cases on the model. During execution of these test cases, a Model Coverage Report, a
component of Simulink Verification and Validation, may be generated to assist in
verifying that all requirements are fully verified. The coverage report may assist in
finding conditions and decisions in the model that cannot be reached, thus indicating that
the design may not be fully verifiable. Simulink Design Verifier may be used to identify
untestable or unreachable model conditions and decisions using test case generation, thus
indicating that the low level requirements may not be fully verifiable. The Model
Advisor may be used to assist in verifying the proper usage of certain Simulink blocks
and data types.
2.4.5 Low-level requirements conform to standards

If models are defined as low level software requirements, conformance to standards may
be accomplished using a combination of model reviews and Model Advisor checks.
Simulink Report Generator may be used to generate a model review packet that includes
a trace report to the higher level requirements. The Model Advisor may be used to verify
pre-defined model standards and may also be customized using an API to perform checks
defined by the user that are unique for their application.
2.4.6 Low-level requirements are traceable to high-level requirements

If models are defined as low level software requirements, traceability to high level
software requirements may be accomplished using a combination of model reviews and
the Requirements Management Interface. Simulink Report Generator may be used to
generate a model review packet that includes a trace report to the high level software
requirements. The Model Advisor may be used to assist in verifying that requirements
links are consistent.
2.4.7 Algorithms are accurate

If models are defined as low level software requirements, accuracy of the algorithms may
Page 21
Do not distribute
cases on the model, thus assisting in verifying the accuracy of the algorithms within the
model. The Model Advisor may be used to assist in verifying the proper usage of certain
2.4.8 Software architecture is compatible with high-level

requirements
Compatibility of the software architecture within the models may be verified via model
reviews. Simulink Report Generator may be used to generate a model review packet and
the Model Dependency Viewer can show the architecture of reference models and library
blocks.
The higher level software architecture, which includes the RTOS and other code, may be
verified using traditional methods.
2.4.9 Software architecture is consistent

Consistency of the software architecture within the models may be verified via model
reviews. Simulink Report Generator may be used to generate a model review packet and
the Model Dependency Viewer can show the architecture of reference models and library
blocks. The Model Advisor may be used to assist in verifying the diagnostic settings
used by Simulink are appropriate for simulation and also verifying the proper usage of
certain Simulink blocks.
2.4.10
Software architecture is compatible with the target
computer
Target compatibility of the software architecture within the models may be verified via
model reviews. Simulink Report Generator may be used to generate a model review
packet. The Model Advisor, a component of Simulink Verification and Validation, may
be used to verify the hardware interface settings used by Real-Time Workshop Embedded
Coder are appropriate for the target processor.
Page 22
Do not distribute
2.4.11
Software architecture is verifiable
Verifiability may be accomplished using a combination of model reviews and simulation.

Simulink Report Generator may be used to generate a model review packet. SystemTest
and Simulink Verification and Validation may be used to develop test cases from the high
level requirements and execute those test cases on the model. During execution of these
test cases, a Model Coverage Report may be generated to assist in verifying that all
requirements are fully verified. The coverage report may assist in finding conditions and
decisions in the model architecture that cannot be reached, thus indicating that the
software architecture may not be fully verifiable.
2.4.12
Software architecture conforms to standards
Conformance to standards may be accomplished using a combination of model reviews

and Model Advisor checks. Simulink Report Generator may be used to generate a model
review packet. The Model Advisor may be used to verify pre-defined model standards
and may also be customized using an API to perform checks defined by the user that are
unique for their application.
2.4.13
Software partitioning integrity is confirmed
Because partitioning is outside of the scope of Model-Based Design, this may be verified
using traditional methods.
Page 23
Do not distribute
2.5 Table A-5 Verification of Coding and Integration Process

The following table contains a summary of the verification of coding and integration
process objectives from DO-178B, including Description, applicable DO-178B reference
sections and software levels the objective is applicable to. The table also provides the
available Model-Based Design tools that may be used in satisfying the objectives.
Description
Section
Software Available Model-Based

Levels
Design Tools
Source code complies with low- 6.3.4a

level requirements.
A, B, C
Source code complies with

software architecture.
6.3.4b
A, B, C
Source code is verifiable.
6.3.4c
A, B
Source code conforms to

standards.
6.3.4d
A, B, C
Source code is traceable to low- 6.3.4e

level requirements.
A, B, C
Source code is accurate and

consistent.
A, B, C
Output of software integration 6.3.5

process is complete and correct.
6.3.4f
A, B, C
HTML Code Generation

Report
Code Reviews
Report
Code Reviews
Report
Code Reviews
PolySpace products
Report
Code Reviews
PolySpace products
Report
Code Reviews
Model Advisor
Report
Code Reviews
PolySpace products
Not applicable
traditional development, if applicable, for each of the verification of coding and
integration process objective when using Model-Based Design.
2.5.1 Source code complies with low-level requirements

Compliance to low level requirements may be verified via code reviews. Real-Time
Workshop Embedded Coder produces an HTML code generation report that may assist
Page 24
Do not distribute
in code reviews by providing traceability from the code to the models, including
hyperlinks to the components in the models.
2.5.2 Source code complies with software architecture

Compliance to software architecture may be verified via code reviews. Real-Time
Workshop Embedded Coder produces an HTML code generation report that may assist
in code reviews by providing traceability from the code to the models, including
hyperlinks to the components in the models.
2.5.3 Source code is verifiable

Verifiability of the code may be verified via code reviews. Real-Time Workshop
Embedded Coder produces an HTML code generation report that may assist in code
reviews by providing traceability from the code to the models, including hyperlinks to the
components in the models. The PolySpace products can assist in the identification of
unreachable and therefore non-verifiable code. The PolySpace products have an
integration with Simulink.
2.5.4 Source code conforms to standards

Standards compliance may be verified using the PolySpace products MISRA-C checker.
This MISRA-C checker has an integration with Simulink.
2.5.5 Source code is traceable to low-level requirements

Traceability may be verified via code reviews. Real-Time Workshop Embedded Coder
produces an HTML code generation report that may assist in code reviews by providing
traceability from the code to the models, including hyperlinks to the components in the
models. The Model Advisor may be used to assist in verifying the commenting settings
used by Real-Time Workshop Embedded Coder are appropriate for tracing the source
code to the models.
2.5.6 Source code is accurate and consistent

Accuracy and consistency may be verified via code reviews. Real-Time Workshop
Embedded Coder produces an HTML code generation report that may assist in code
reviews by providing traceability from the code to the models, including hyperlinks to the
components in the models.
The PolySpace products have the capability to identify run-time errors such as potential
underflow, overflow, divide by zero, etc.
2.5.7 Output of software integration process is complete and correct

Because the integration process is outside of the scope of Model-Based Design, this may
be verified using traditional methods.
Page 25
Do not distribute
2.6 Table A-6 Testing of Outputs of Integration Process

The following table contains a summary of the testing of outputs of integration process
Description
Section
Software
Levels
Design Tools
Executable Object Code

complies with high-level
requirements.
6.4.2.1
6.4.3
A, B, C, D

robust with high-level
requirements.
6.4.2.2
6.4.3
A, B, C, D
Executable Object Code

complies with low-level
requirements.
6.4.2.1
6.4.3
A, B, C

robust with low-level
requirements.
6.4.2.2
6.4.3
A, B, C
SystemTest/Simulink
Verification and Validation
test cases reused on
executable object code
Embedded IDE Link CC
Embedded IDE Link
MU
SystemTest/Simulink
Verification and Validation
test cases reused on
executable object code
Embedded IDE Link
MU
generated test cases used
on executable object code
Embedded IDE Link
MU
generated test cases used
on executable object code
Embedded IDE Link
MU
Page 26
Do not distribute
Description
Section
Software
Levels
Design Tools

compatible with target
computer.
6.4.3a
A, B, C, D

Embedded IDE Link
MU
traditional development, if applicable, for each testing of outputs of integration process
objective when using Model-Based Design.
2.6.1 Executable Object Code complies with high-level requirements

The executable object code may be verified by re-using the same test cases that are used
to verify the models. During execution of the model verification tests, using SystemTest
and Simulink Verification and Validation, the inputs and outputs of each model under test
can be logged and saved for use in verifying the executable object code.
The executable object code may be tested on a target processor or DSP using Embedded
IDE Link CC, Embedded IDE Link MU, Embedded IDE Link TS, or Embedded
IDE Link VS.
2.6.2 Executable Object Code is robust with high-level requirements

Robustness tests should be developed against the models and may be done using
SystemTest and Simulink Verification and Validation. The robustness of the executable
object code may then be verified by re-using the same test cases that are used to verify
robustness of the models. During execution of the model verification tests, using
SystemTest and Simulink Verification and Validation, the inputs and outputs of each
model under test can be logged and saved for use in verifying the executable object code.
IDE Link VS.
2.6.3 Executable Object Code complies with low-level requirements

Simulink Design Verifier may be used to generate low level tests from the model. These
test cases can then be run on the model and the executable object code, and the results
compared to demonstrate that the executable object code complies with the low level
requirements.
Page 27
Do not distribute
IDE Link VS.
Alternatively, verification against the low level requirements may be eliminated, if it can
be shown that requirements based coverage and structural coverage are achieved using
the high level requirements based tests (i.e. software integration tests). The following
guidance is provided in section 6.4 of DO-178B:
If a test case and its corresponding test procedure are developed and executed for
hardware/software integration testing or software integration testing and satisfy
the requirements-based coverage and structural coverage, it is not necessary to
duplicate the test for low-level testing. Substituting nominally equivalent lowlevel tests for high-level tests may be less effective due to the reduced amount of
overall functionality tested.
2.6.4 Executable Object Code is robust with low-level requirements

Simulink Design Verifier may be used to generate robustness tests from the model.
These test cases can then be run on the model and the executable object code, and the
results compared to demonstrate that the executable object code is robust with the low
level requirements. For robustness test cases, the Test Condition blocks and Test
Objective blocks may be used to assist in the definition of test cases that exercise the
object code outside of normal boundary conditions.
IDE Link VS.
2.6.5 Executable Object Code is compatible with target computer

Because the compatibility of the executable object code to the hardware is outside of the
scope of Model-Based Design, this must be verified using traditional methods.
The executable object code may be evaluated for stack usage, memory usage and
execution time on a target processor or DSP using Embedded IDE Link CC, Embedded
IDE Link MU, Embedded IDE Link TS, or Embedded IDE Link VS.
Page 28
Do not distribute
2.7 Table A-7 Verification of Verification Process Results

The following table contains a summary of the verification of verification process results
Description
Section
Software
Levels
Design Tools
Test procedures are correct.
6.3.6b
A, B, C
Review of Simulink
Verification and
Validation test cases
Test results are correct and

discrepancies explained.
6.3.6c
A, B, C
Not applicable
Test coverage of high-level

requirements is achieved.
6.4.4.1
A, B, C, D
Test coverage of low-level

requirements is achieved.
6.4.4.1
A, B, C
Test coverage of software

6.4.4.2
structure (modified
condition/decision) is achieved.
6.4.4.2a
structure (decision coverage) is 6.4.4.2b
achieved.
6.4.4.2a
structure (statement coverage) is 6.4.4.2b
achieved.
6.4.4.2c
structure (data coupling and
control) is achieved.
and Validation
Model Coverage
and Validation
Model Coverage
Model Coverage and
traditional code
coverage tool
Model Coverage and
traditional code
coverage tool
Model Coverage and
traditional code
coverage tool
Not applicable
A, B
A, B, C
A, B, C
traditional development, if applicable, for each of the verification of verification process
results objective when using Model-Based Design.
2.7.1 Test procedures are correct

Correctness of the test procedures may be verified via reviews of the test procedures.
Simulink Verification and Validation may assist in test procedure reviews by providing
Page 29
Do not distribute
traceability from the test cases to the requirements, including hyperlinks to the
requirements in the higher level requirements document.
2.7.2 Test results are correct and discrepancies explained

Correctness of the test results may be verified via reviews of the test results. As an
alternative, it is possible to develop a processor in the loop test platform for the
executable object code that could be qualified as a verification tool in order to determine
pass/fail of the results.
2.7.3 Test coverage of high-level requirements is achieved

Test coverage of high level software requirements may be verified via reviews of the test
cases and traceability to the high level requirements. Simulink Verification and
Validation can be used to trace the test cases to the high level requirements, thus
providing the capability to assist in verifying that each requirement has appropriate test
cases associated with it.
2.7.4 Test coverage of low-level requirements is achieved

Test coverage of low level software requirements may be verified using the Simulink
Verification and Validation model coverage report during execution of the low level
requirements based tests. The model coverage report provides data to assist in proving
that low level requirements are fully covered during testing.
2.7.5 Test coverage of software structure (modified

condition/decision) is achieved
Modified condition/decision coverage of the software structure may be verified via a
commercial off the shelf structural coverage analysis tool. This analysis will be
accomplished during the execution of the requirements based tests described in 2.6.1.
If requirements based test cases are developed at the model level and reused for testing of
the executable object code, then the Model Coverage Tool may be used during
development of the requirements based test cases to help predict the effectiveness of
those test cases in providing structural coverage for the generated code.
2.7.6 Test coverage of software structure (decision coverage) is

achieved
Decision coverage of the software structure may be verified via a commercial off the
shelf structural coverage analysis tool. This analysis will be accomplished during the
execution of the requirements based tests described in 2.6.1.
Page 30
Do not distribute
2.7.7 Test coverage of software structure (statement coverage) is

achieved
Statement coverage of the software structure may be verified via a commercial off the
shelf structural coverage analysis tool. This analysis will be accomplished during the
execution of the requirements based tests described in 2.6.1.
2.7.8 Test coverage of software structure (data coupling and control)

is achieved
Because the data coupling and control is outside of the scope of code generated from
Model-Based Design, this may be verified using traditional methods. The test coverage
for data coupling and control would involve verification of the data interfaces to and from
the automatically generated code and also the calling sequence of the automatically
generated code in relation to other code modules.
Page 31
Do not distribute
2.8 Table A-8 Software Configuration Management Process

The following table contains a summary of the configuration management process
and software levels the objective is applicable to. The table also provides the potential
impact to the process when using Model-Based Design.
Description
Section
Software
Levels
Process Impact when

using Model-Based
Design
Configuration items are

identified.
7.2.1
A, B, C, D
Baselines and traceability are

established.
7.2.2
A, B, C, D
Problem reporting, change

control, change review, and
configuration status accounting
are established.
Archive, retrieval, and release
are established.
7.2.3,
A, B, C, D
7.2.4,
7.2.5, 7.2.6
No impact as compared
to traditional
development
Use of Requirements
Management Interface
and traditional baseline
establishment
to traditional
development
7.2.7
A, B, C, D
Software load control is

established.
7.2.8
A, B, C, D
Software life cycle environment 7.2.9

control is established.
A, B, C, D
to traditional
development
to traditional
development
to traditional
development
traditional development, if applicable, for each configuration management process
2.8.1 Configuration items are identified

For projects using Model-Based Design, the following artifacts may have to be
configured and identified throughout the project:
High Level Requirements (level above the models)

Models
Model Review packets/Trace Reports
Model advisor reports
Page 32
Do not distribute
Automatically Generated code

Model Test harnesses
Model Test scripts
SystemTest files
Model Test results reports
Model coverage reports
Object code structural coverage reports
These are in addition to or in substitute of traditional configured items.
2.8.2 Baselines and traceability are established

This is the same as for traditional projects. Part of the traceability may be covered by the
Requirements Management Interface.
2.8.3 Problem reporting, change control, change review, and

configuration status accounting are established
This is the same as for traditional projects.
2.8.4 Archive, retrieval, and release are established

This is the same as for traditional projects. The version of the Model-Based Design tools
used on the project may have to be archived.
2.8.5 Software load control is established

2.8.6 Software life cycle environment control is established

Page 33
Do not distribute
2.9 Table A-9 Software Quality Assurance Process

The following table contains a summary of the software quality assurance process
and software levels the objective is applicable to. The table also provides the potential
impact to the process when using Model-Based Design.
Description
Section
Software
Levels
Process Impact when

using Model-Based
Design
Assurance is obtained that

8.1a
software development and
integral processes comply with
approved software plans and
standards.
Assurance is obtained that
8.1b
transition criteria for the
software life cycle processes are
satisfied.
A, B, C, D
to traditional
development
A, B
to traditional
development
Software conformity review is 8.1c

completed.
8.3
A, B, C, D
to traditional
development
traditional development, if applicable, for each software quality assurance process
2.9.1 Assurance is obtained that software development and integral

processes comply with approved software plans and standards
2.9.2 Assurance is obtained that transition criteria for the software

life cycle processes are satisfied
2.9.3 Software conformity review is completed

Page 34
Do not distribute
2.10 Table A-10 Certification Liaison Process

The following table contains a summary of the certification liaison process objectives
software levels the objective is applicable to. The table also provides the potential impact
to the process when using Model-Based Design.
Description
Section
Software
Levels
Process Impact when

using Model-Based
Design
Communication and
understanding between the
applicant and the certification
authority is established.
9.0
A, B, C, D
to traditional
development
The means of compliance is

9.1
proposed and agreement with the
Plan for Software Aspects of
Certification is obtained.
A, B, C, D
to traditional
development
Compliance substantiation is
provided.
A, B, C, D
to traditional
development
9.2
traditional development, if applicable, for each certification liaison process objective
2.10.1
Communication and understanding between the applicant
and the certification authority is established
2.10.2
The means of compliance is proposed and agreement
with the Plan for Software Aspects of Certification is obtained
2.10.3
Compliance substantiation is provided
Page 35
Do not distribute
3 Model Architecture Considerations

This section contains recommendations with respect to model architecture considerations
when developing safety critical or mission critical systems. The architectural
considerations in this section are intended to ease the verification activities associated
with the code generated from the models.
3.1 Use of Atomic Subsystems

When creating models that use subsystems to break the models into separate viewable
pages, it is recommended that the subsystems be set to Treat as atomic unit. See the
subsystem parameters dialogue below.
When Treat as atomic unit is selected, the generated code for the subsystem is grouped
together and typically includes a starting and ending comment in the code file. Having a
block of code map directly to a page on the diagram simplifies the code review process.
If this option is not selected, then the generated code may be interleaved such that lines of
code trace to blocks across multiple pages on the diagram.
Selecting Treat as atomic unit also allows Simulink to check and report (as an error or
warning) if this group of blocks cannot be executed as a unit, e.g. function call across
subsystem boundary, or direct feedback loop, etc.
Page 36
Do not distribute
Real-Time Workshop system code should be set as Inline or Function. Use of

Auto or Reusable function can lead to confusion with respect to requirements
traceability in the generated code. If reusable functions are desired, then Model
Reference should be used to instantiate the reusable functions.
3.2 Use of Model Reference

The model reference feature allows a large model to be broken into smaller separately
configured units. This results in separate code files for each of the separate models.
There are many advantages to having these separately configured files:
Each model and its associated code can be verified as a separate component
When a reference model changes, only its code has to be reviewed
When a reference model changes, only its verification testing has to be
performed
Regression analysis is greatly simplified
Structural coverage analysis is simplified when using smaller models and code
Reference model code can be reused
When using Model Reference, especially with large teams, configuration management of
the reference models is very important. There are two best practice scenarios for
configuration management of the reference models that are described here.
Scenario 1 Model developer checks in the simulation target and embedded
target source code with the model into the configuration management system
Under this scenario the model developer creates a simulation target that will be
used by other model developers that call the referenced model. This target is
created in the form of a .mex32 executable file and would be checked into the
software configuration management tool along with the model. The model
developer would also generate the target source code and check this in with the
model. This ensures that all time and date stamps and the model checksums
match those for the generated code and simulation targets.
For this scenario, any user of the reference model would get the latest copy of the
model, source code and simulation target from the configuration management
system before using it. The Rebuild Option would be set to Never for all
reference models.
The advantage of using this scenario is that the model, source code and simulation
target could all be verified and approved in the software configuration
management system and locked down until such time as a change is necessary.
Additionally this would insure that all users of the reference model are working
from exactly the same files from the configuration management system.
Page 37
Do not distribute
Scenario 2 Model developer checks in only the model into the configuration
management system
Under this scenario, the model developer is only responsible for creation and
check-in of the model into the configuration management system. It would be the
responsibility of the user of the reference model to create a simulation target that
will be used by other model developers that call the referenced model. Another
developer would need to generate the target source code and check this in to the
software configuration management system.
For this scenario, any user of the reference model would get the latest copy of the
model target from the configuration management system before using it. The
Rebuild Option would be set to If Any Changes Detected for all reference models.
The advantage of using this scenario is that the model, source code and simulation
target could all be verified and approved in the software configuration
management system at different times in the development cycle and by different
groups. A disadvantage of this scenario is that insuring that all users of the
reference model are working from exactly the same files from the configuration
management system is much more difficult.
For either of the scenarios above, it is necessary to understand the reference model
dependencies and to determine when a change to one model may require a change to
another model or regeneration of the source code and simulation target for another model.
See the Model Reference documentation for a detailed description of this.
The use of model reference is analogous to the use of multiple code modules across a
large system. The Model Referencing Pane of the Configuration Parameters is shown
below:
Page 38
Do not distribute
Recommended model reference settings are outlined in the following table along with
rationale.
Diagnostic
Rebuild options
Recommended
Setting
Never or If
any changes
detected
Rationale
Allowing the code to rebuild may result
in the necessity to repeat the code review
and verification testing on the generated
code. By locking down the
configuration, verification activities are
minimized. It is preferable for a rebuild
to only occur when a model is checked
out of the configuration management
system. (See DO-178B, Section 6.3.1b &
6.3.2b)
An alternative is to perform local rebuilds
when changes have been detected. For
this case it is still necessary to verify that
the latest version of the model is on the
path.
Page 39
Do not distribute
Diagnostic
Never rebuild targets
diagnostics
Total number of instances

allowed per top model
Model dependencies
Pass scalar root inputs by

value
Minimize algebraic loop

occurrences
Recommended Rationale
Setting
Error if targets This setting will report errors if it detects
require rebuild time stamp inconsistencies between a
model and its associated code or
differences in checksums of global
parameters, etc. indicating that the
simulation target needs to be rebuilt.
Note: this setting only appears if Never is
selected as the Rebuild Option.
One or
If the referenced model is only intended
Multiple
to be used once in a single top level
model, then One should be selected. If
the model is intended to be used as a
reusable function called multiple times
by a top model or by more than one top
model, then Multiple should be selected.
As needed
This setting is used to include any .MAT
or .M files that contain data needed by
the reference model.
Off
In some cases the scalar value inputs to a
reference model can change during a time
step, resulting in unpredictable
operations. (See DO-178B, Section
6.3.3b)
Off
If this option is selected, then the Single
Output/Update function option is not
allowed. See section 10.7 (See DO178B, Section 6.3.3b)
3.3 Input and Output Hardware Interfaces

Input and output hardware interfaces should be developed and built separately from the
models used to generate the target code. The models can then use storage classes on root
inports and outports to interface to the software device drivers via variables in the
generated code. The advantages of doing this are:
The code generated from the model can be verified as a stand alone module
without the need to stimulate or record hardware (this does not eliminate the need
to perform hardware software integration testing, but it does eliminate the need to
achieve complete structural coverage during that testing).
Page 40
Do not distribute
The code generated from the model is nearly platform independent, only
Hardware Implementation characteristics in the Configuration Parameters need to
be reconfigured. This enables software reuse across multiple programs.
The hardware device driver code, which is typically generated by hand, can be
verified as a stand alone unit one time. This code is typically very stable and not
subject to change once it has been integrated onto the hardware platform. (The
models are typically subject to several changes during a project, so being able to
perform verification on only those changes reduces the verification costs
significantly)
If device drivers are embedded within models as S-Functions, then the use of test
harnesses and data logging to generate test cases for verification of the executable
object code becomes impossible.
The figure below shows an example of integration with a rate monotonic RTOS, such as
an ARINC 653 compliant operating system, for a simple system with three sample rates.
It is recommended to provide separate models for different sample rates and let the RTOS
take care of function call scheduling and buffering of data between the different sample
rates.
RTOS
Scheduling
Hardware
Input
Device
Drivers
Model A
(rate = x)
Model B
(rate = x/2)
Model C
(rate = x/4)
Hardware
Output
Device
Drivers
Data Buffers (with appropriate rate transitions)
Alternatively, if the preference is to generate code for device drivers in a more integrated
fashion, two approaches which can be considered are:
Using the Legacy Code Tool, a function call to a hand written device driver
function can be generated from the model. This function call passes data to/from
the model via function arguments.
Page 41
Do not distribute
Using the Simulink S-function API which provides the ability to generate
efficient and complete device driver code. It can be fully inlined with the
generated algorithmic code of the model.
If modeling device drivers in these ways, it is recommended that reference models be

used to package the code for models and that these be connected via inports and outports
to S-Function blocks that provide hardware device driver code within a single top level
model for the entire system.
The following figure represents an example of this architecture in the form of a top level
Simulink model for a simple system with two sample rates, having inputs and outputs at
both rates. In this example, rate transition blocks are used in the top level model to
perform data buffering.
Input S-function
(rate = x)
Reference Model A
(rate = x)
Rate
Trans
Input S-function
(rate = x/2)
Output S-function
(rate = x)
Rate
Trans
Reference Model B
(rate = x/2)
Output S-function
(rate = x/2)
3.4 Test Harnesses

Test harnesses should be developed and built separately from the models used to generate
the target code. Test harnesses should either be implemented in M code that invokes
simulation for the model under test or as Simulink models that include the model under
test as a reference model. The advantages of doing this are:
Changes to the test harness and test procedures will have no affect on the
generated code or the configured model to be tested.
Test independence cannot be easily demonstrated if a single model is used for the
target function and the test.
A separate test harness allows integration of multiple reference models for
performing system level tests and evaluations.
Test cases and procedures must be separately configured and reviewed.
Page 42
Do not distribute
Functional models and test harness can be developed in parallel with

independence.
Data can be logged at the inputs and outputs to the model under test from the test
harness so that these test cases can be reused to verify the executable object code.
Page 43
Do not distribute
4 Solver Considerations for Safety Critical or Mission

Critical Systems
This section contains recommendations with respect to model solver settings when
developing safety critical or mission critical systems. The Solver Pane of the
Configuration Parameters is shown below:
Recommended solver settings are outlined in the following table along with rationale.
Solver Setting
Start time
Recommended
Setting
0.0
Rationale
This setting must be 0.0 to generate
production code. Simulink software
allows non-zero start time for
simulation, but Real-Time Workshop
Embedded Coder target does not allow
non-zero start time.
Page 44
Do not distribute
Solver Setting
Stop time
Recommended
Setting
Any positive
value
Type
Fixed-step
Solver
Discrete (no
continuous
states)
Any positive
value
Fixed step size

(fundamental sample time)
Periodic sample time

constraint
Specified,
Ensure sample
time
independent or
Unconstrained
Sample time properties
[[Period, offset,
priority], .]
Rationale
The time in seconds of this setting must
be shorter than Application lifespan
(days) on Optimization pane. By
default, Application lifespan (days) is
inf. Any positive value is valid and this
setting has no effect on generated code.
Fixed-step solver is required for
embedded code generation.
Discrete is required for production code.
This setting is enabled only if

Unconstrained is selected for the
periodic sample time constraint. The
value should not be set as Auto.
For most models the sample time should
be Specified or Unconstrained in
order to define the rate that the
generated code is to run at. The
exception to this is for reference
models, for those that are intended to be
reusable functions that inherit their
sample time from the calling model
Ensure sample time independent
should be selected, and for those that
have a fixed sample time
Unconstrained should be specified.
This setting is appears only if
Specified is selected for the periodic
sample time constraint. Specify the
period, offset and priority of each
sample time in the model. Faster sample
times must have higher priority than
slower sample times. See the solver
Help documentation for how to set up
the sample time period, offset and
priority.
Page 45
Do not distribute
Solver Setting
Tasking mode for periodic
sample times
Recommended
Setting
SingleTasking
or MultiTasking
Higher priority value

indicates higher task
priority
On or Off
Automatically handle data

transfers between tasks
Off
Rationale
If Ensure sample time independent is
selected for a reference model, this
setting will not appear. This should be
set to SingleTasking if the model is
intended to run at a single rate or the
model is intended to run at multiple
rates in one task. Otherwise it should
be set to MultiTasking if the model is
intended to run at multiple rates.
setting will not appear. This option
determines whether the priority for
Sample time properties uses the lowest
values as highest priority or the highest
values as highest priority.
setting will not appear. Setting this to
On could result in rate transition code
being inserted without a model
requirement to trace to. This violates
traceability requirements. (See DO178B, Section 6.3.4e)
Page 46
Do not distribute
5 Data Import/Export Considerations for Safety Critical

or Mission Critical Systems
This section contains recommendations with respect to data import/export settings when
developing safety critical or mission critical systems. The Data Import/Export Pane of
the Configuration Parameters is shown below:
All settings for Data Import and Export should be set to Off for production code
generation. These settings may be used during simulation for debugging and evaluating
the performance of the models.
Page 47
Do not distribute
6 Optimization Considerations for Safety Critical or

Mission Critical Systems
This section contains recommendations with respect to model and code generator related
optimization settings when developing safety critical or mission critical systems. The
Optimization Pane of the Configuration Parameters is shown below:
The following table contains recommendations for some of the optimization settings
when safety critical code is to be generated from a model. The rationale for these settings
is included in the table. While it is understood that highly optimized code is generally
desirable for real-time systems, it must also be recognized that some optimizations can
have undesirable side effects that impact safety.
Page 48
Do not distribute
Optimization
Block reduction
optimization
Conditional input branch

execution
Implement logic signals as
Boolean data (vs double)
Signal storage reuse

Inline parameters
Application lifespan (days)
Parameter Structure
Enable local block outputs
Reuse block outputs
Ignore integer downcasts in
folded expressions
Inline invariant signals
Recommended
Setting
Off
Rationale
This setting can cause blocks to be

optimized out of the code when selected
on. This results in requirements with no
associated code and violates traceability
requirements. (See DO-178B, Section
6.3.4e)
On or Off
There are no safety implications
regarding the use of this optimization.
On
Strong data typing is recommended for
safety critical code. (See DO-178B,
Section 6.3.1e & 6.3.2e and MISRA-C
2004, Rule 12.6)
On or Off
On or Off
inf
Many aerospace products are powered
on continuously and timers/counters
should not assume a limited lifespan.
(See DO-178B, Section 6.3.1g & 6.
3.2g)
Hierarchical or
NonHierarchical regarding the use of this setting.
On or Off
On or Off
Off
This setting can cause typecast blocks to
be optimized out of the code when
selected to on. This results in
requirements with no associated code
and violates traceability requirements.
(See DO-178B, Section 6.3.1g & 6.
3.2g) This can also result in simulation
results not matching generated code
results.
On or Off
Page 49
Do not distribute
Optimization
Eliminate superfluous
temporary variables
Minimize data copies
between local and global
variables
Loop rolling threshold
Recommended
Setting
On or Off
On or Off
2 or greater
Use memcpy for vector

assignment
Memcpy threshold (bytes)
On or Off
Remove root level I/O zero

initialization
Off
Use memset to initialize

floats and doubles to zero
Remove internal state zero
initialization
On or Off
Optimize initialization code

for model reference
Remove code from
floating-point to integer
conversions that wraps outof-range values
On or Off
2 or greater
Off
On
Rationale
regarding the use of this setting.
regarding the use of this setting.
For safety critical code all variables
should be explicitly initialized. (See
DO-178B, Section 6.3.3b and MISRAC 2004, Rule 9.1) Note: an alternative
to this setting is to have separate hand
code that explicitly initializes all I/O
variables to zero.
For safety critical code all variables
should be explicitly initialized. (See
DO-178B, Section 6.3.3b and MISRAC 2004, Rule 9.1) ) Note: an alternative
to this setting is to have separate hand
code that explicitly initializes all state
variables to zero.
Overflows must be avoided for safety
critical code. Prevention of overflows
is discussed in the block setting
considerations section of this document.
(See DO-178B, Section 6.3.1g &
6.3.2g)
Setting this to off will add code that
wraps out of range values for blocks
with Saturate on Overflow set to off.
Un-reachable, and therefore un-testable,
code can result when setting this to off.
(See DO-178B, Section 6.4.4.3c and
MISRA-C 2004, Rule 14.1)
Page 50
Do not distribute
Optimization
Remove code that protects
against division arithmetic
exceptions
Recommended
Setting
Off
Use bitsets for storing state On or Off

configuration
Use bitsets for storing
On or Off
Boolean data
Compiler optimization level Optimizations
on or
Optimizations
off
Verbose accelerator builds
On or Off
Rationale
Division by zero exceptions must be
avoided in safety critical code. (See
DO-178B, Section 6.3.1g & 6.3.2g and

Page 51
Do not distribute
7 Model Diagnostic Considerations for Safety Critical

This section contains recommendations with respect to model diagnostic settings when
developing safety critical or mission critical systems. Each of the diagnostic setting
panes will be addressed individually.
7.1 Solver Diagnostics

The Solver Diagnostics Pane of the Configuration Parameters is shown below:
Recommended solver diagnostic settings are outlined in the following table along with
rationale. Many of the solver settings have no effect on the generated code, therefore
only a few of the settings are of concern for safety critical code generation.
Page 52
Do not distribute
Diagnostic
Setting
Algebraic loop
error
Simulink software will employ an
iterative non-linear equation solver when
it detects an algebraic loop. Since such
iterative algorithms are not suitable for
real time applications, it is preferable to
have the model developer break algebraic
loops by inserting unit delay blocks. (See
DO-178B, Section 6.3.3e)
Minimize algebraic loop
error
Simulink software may attempt to
eliminate certain artificial algebraic
loops caused due to model blocks, atomic
subsystems and enabled subsystems.
This will affect execution order, so it is
preferable to have the model developer
resolve this issue by altering the model so
that execution order is predictable, or to
at least verify that the automatic breaking
of the loop is acceptable. (See DO-178B,
Section 6.3.3e)
Block priority violation
error
When Simulink software detects
conflicting block priorities; it can affect
execution order so the model developer
needs to be notified. (See DO-178B,
Section 6.3.3b)
Min step size violation
warning or
This diagnostic has no effect on the
error
generated code.
Sample time hit adjusting
none, warning This diagnostic has no effect on the
or error
generated code.
Consecutive zero crossings warning or
This diagnostic has no effect on the
violation
error
generated code.
Unspecified inheritability of error
When Simulink detects that an Ssample times
Function has not been specified explicitly
for inherited sample time, the model
developer needs to correct the S-Function
in order to have predictable behavior.
(See DO-178B, Section 6.3.3e)
Solver data inconsistency
or error
generated code.
Page 53
Do not distribute
Diagnostic
Automatic solver parameter
selection
Extraneous discrete
derivative signals
State name clash
Setting
error
Simulink software may attempt to
modify the solver, step size or simulation
stop time automatically. This may affect
the operation of the generated code, so it
is preferable to have the model developer
manually correct the settings to the
desired values. (See DO-178B, Section
6.3.3e)
or error
generated code.
warning
Simulink ignores this setting during
simulation, but an error will occur during
code generation if a state name clashes
with another Simulink object name. (See
DO-178B, Section 6.3.3b)
Page 54
Do not distribute
7.2 Sample Time Diagnostics

The Sample Time Diagnostics Pane of the Configuration Parameters is shown below:
Recommended sample time diagnostic settings are outlined in the following table along
with rationale. All of these settings are considered important in the generation of safety
critical code.
Diagnostic
Source block specifies -1
sample time
Discrete used as continuous
Setting
error
Source blocks should have a specified
sample time to prevent incorrect
execution sequencing. (See DO-178B,
Section 6.3.3e)
error
This diagnostic will detect if a discrete
block input is a continuous signal, which
should not be used for embedded realtime code. (See DO-178B, Section
6.3.3e)
Page 55
Do not distribute
Diagnostic
Multitask rate transition
Single task rate transition
Multitask conditionally
executed subsystems
Tasks with equal priority
Enforce sample times

specified by signal
specification blocks
Setting
error
This diagnostic will detect if an invalid
rate transition exists in multitasking
mode, which should not be used for
embedded real-time code. (See DO178B, Section 6.3.3b)
none or error
This diagnostic will detect if a rate
transition exists in single tasking mode
which is okay for single tasking mode. If
the model is intended to convert to
multitasking model, set this diagnostic to
error.
error
This diagnostic will detect if a
conditionally executed multirate
subsystem (enabled subsystem, triggered
subsystem, function call subsystem)
operates in multitasking mode which can
lead to data corruption and unpredictable
behavior in real time environments allow
preemption. (See DO-178B, Section
6.3.3b)
none or error
This diagnostic will detect if two
asynchronous tasks have equal priority. If
real time target does not allow
preemption between tasks that have equal
priority, set this diagnostic to None,
otherwise, set it to Error. (See DO178B, Section 6.3.3b)
error
This diagnostic detects different sample
times specified in source and destination
blocks, thus indicating an over specified
sample time. (See DO-178B, Section
6.3.3e)
Page 56
Do not distribute
7.3 Data Validity Diagnostics

The Data Validity Diagnostics Pane of the Configuration Parameters is shown below:
Recommended data validity diagnostic settings are outlined in the following table along
with rationale. All of these settings, except for the debugging diagnostics, are considered
important for generation of safety critical code.
Diagnostic
Signals: Signal resolution
Setting
Explicit only
This provides predictable operation by
requiring the user to define each signal
and block setting that must resolve to
Simulink.Signal objects in the
workspace. (See DO-178B, Section
6.3.3b)
Page 57
Do not distribute
Diagnostic
Signals: Division by
singular matrix
Signals: Underspecified
data types
Signals: Signal range
checking
Signals: Detect overflow
Signals: Inf or NaN block

output
Signals: rt prefix for
identifiers
Parameters: Detect
downcast
Parameters: Detect
underflow
Parameters: Detect
overflow
Parameters: Detect
precision loss
Setting
error
Division by a singular matrix can result
in numeric exceptions when executing
the generated code. This is not
acceptable in safety critical systems. (See
DO-178B, Section 6.3.1g & 6.3.2g and
error
The model developer should insure that
all data types are correctly specified. (See
DO-178B, Section 6.3.1e & 6.3.2e)
error
Out of range data can result in incorrect
and unsafe behavior. (See DO-178B,
Section 6.3.1g & 6.3.2g)
error
Numeric overflows can result in incorrect
Section 6.3.1g & 6.3.2g)
error
Numeric exceptions are not acceptable in
safety critical systems. (See DO-178B,
Section 6.3.1g & 6.3.2g and MISRA-C
2004, Rule 21.1)
error
This prevents name clashing with signals
that Real-Time Workshop Embedded
Coder prefixes with rt (See DO-178B,
Section 6.3.1e & 6.3.2e)
error
A downcast to a lower signal range can
result in numeric overflows of
parameters, resulting in incorrect and
unsafe behavior. (See DO-178B, Section
6.3.1g & 6.3.2g)
error
The data type of the parameter does not
have sufficient resolution; therefore the
parameter value will be zero, instead of
the specified value. This could lead to
incorrect operation of the generated code.
(See DO-178B, Section 6.3.1g & 6.3.2g)
error
Numeric overflows can result in incorrect
Section 6.3.1g& 6.3.2g)
error
The data type of the parameter does not
have sufficient resolution; therefore the
parameter value will be different than the
specified value. This could lead to
Page 58
Do not distribute
Diagnostic
Parameters: Detect loss of
tunability
Data Store Memory Block:

Detect read before write
Detect write after read
Detect write after write
Multitask data store

Duplicate data store names
Merge Block: Detect

multiple driving blocks
executing at the same time
step
Model Initialization:
Underspecified
initialization detection
Setting
error
An expression with a tunable parameter
has been reduced to a numerical value;
therefore the parameter value will not be
tunable in the generated code. (See DO178B, Section 6.3.1g & 6.3.2g)
Enable all as
Reading data before it is written can
errors
result in use of un-initialized and stale
data. (See DO-178B, Section 6.3.3b)
Enable all as
Writing data after it is read can result in
errors
use of stale or incorrect data. (See DO178B, Section 6.3.3b)
Enable all as
Writing data twice in one time step can
errors
result in unpredictable data. (See DO178B, Section 6.3.3b)
error
Read or write data in different task in
multitask mode can result in corrupted or
unpredictable data. (See DO-178B,
Section 6.3.3b)
none, warning, This setting controls whether the model
or error
supports the semantic of two unique data
stores having the same Name. Since the
memory for the two instances is unique,
the initial values are distinctly and
uniquely applied in a predictable manner.
error
This setting is only enabled when the
setting for Underspecified Initialization
Detection is set to Classic (when the
latter setting is set to Simplified a
violation always results in an error). If
two or more inputs to a Merge block are
computed in the same time frame, the
output value may be non-deterministic.
(See DO-178B, Section 6.3.3b)
Simplified
An output of a conditionally executed
subsystem could have an un-initialized
output, resulting in non-deterministic
operation. (See DO-178B, Section 6.3.3b
and MISRA-C 2004, Rule 9.1)
Page 59
Do not distribute
Diagnostic
Model Initialization: Check
undefined subsystem initial
output

pre-activation output of
execution context

runtime output of execution
context
Debugging: Array bounds

exceeded
Debugging: Model
Verification block enabling
Setting
Off or on
Detection is set to Classic. This setting is
ignored when using the Simplified setting
for Underspecified Initialization
Detection.
Off or on
Detection.
Off or on
Detection.
none, warning This setting is only used for debugging
or error
custom S-Functions.
Disable All
Assertions should not used in embedded
code, these are intended for use in model
verification. Note: It is appropriate to set
this to Use local settings for simulation
and also in test harness models.
Page 60
Do not distribute
7.4 Type Conversion Diagnostics

The Type Conversion Diagnostics Pane of the Configuration Parameters is shown below:
Recommended type conversion diagnostic settings are outlined in the following table
along with rationale. Type conversion diagnostics are all considered to be important for
generation of safety critical code.
Diagnostic
Unnecessary type
conversions
Setting
warning
The unnecessary type conversion block
may be optimized out of the generated
code, resulting in a requirement with no
code. The model developer should
remove these unnecessary type
conversions. (See DO-178B, Section
6.3.1g & 6.3.2g)
Page 61
Do not distribute
Diagnostic
Vector/matrix block input
conversion
32 bit integer to single

precision float conversion
Setting
error
When Simulink software performs
automatic conversions between vector
and matrix dimensions, it is possible to
have an unintended operation or
unpredictable behavior occur. (See DO178B, Section 6.3.1g & 6.3.2g)
warning
This conversion can result in a loss of
precision due to truncation of the least
significant bits for large integer values.
Page 62
Do not distribute
7.5 Connectivity Diagnostics

The Connectivity Diagnostics Pane of the Configuration Parameters is shown below:
Recommended connectivity diagnostic settings are outlined in the following table along
with rationale.
Diagnostic
Signal label mismatch
Unconnected block input

ports
Unconnected block output
ports
Setting
error
This message is only for virtual signals
and has no effect on the generated code,
but signal label mismatches could lead to
confusion during model reviews. (See
DO-178B, Section 6.3.1e & 6.3.2e)
error
Code cannot be generated for
unconnected block inputs. (See DO178B, Section 6.3.1e & 6.3.2e)
error
Dead code can result from unconnected
block outputs. (See DO-178B, Section
6.3.1e & 6.3.2e and MISRA-C 2004,
Rule 14.1)
Page 63
Do not distribute
Diagnostic
Unconnected line
Unspecified bus object at

root Outport block
Element name mismatch
Mux blocks used to create

bus signals
Bus signal treated as vector
Invalid function-call
connection
Context-dependent inputs
Setting
error
Code cannot be generated for
unconnected lines. (See DO-178B,
Section 6.3.1e & 6.3.2e)
error
In order for a bus signal to cross a model
boundary, it must be defined as a Bus
Object to insure compatibility with higher
level models that use this model as a
reference model. (See DO-178B, Section
6.3.3b and MISRA-C 2004, Rule 16.6)
error
This diagnostic is necessary to prevent
the use of incompatible busses into a bus
capable block such that the output names
would be inconsistent. (See DO-178B,
Section 6.3.3b)
error
automatic conversion of a muxed signal
to a bus; it is possible to have an
unintended operation or unpredictable
behavior occur. (See DO-178B, Section
6.3.3b) The user can use the Model
Advisor or the sl_replace_mux utility
function to replace all mux blocks used as
bus creators with a bus creator block.
error
automatic conversion of a bus signal to a
vector; it is possible to have an
unintended operation or unpredictable
behavior occur. (See DO-178B, Section
6.3.3b) The user can use the
Simulink.BlockDiagram.addBusToVector
utility function to insert Bus to Vector
blocks in the appropriate places to
eliminate this problem.
error
An invalid use of a function call
subsystem has been detected and
operation of the generated code may be
incorrect. (See DO-178B, Section 6.3.3b)
Enable All
Unpredictable data coupling has been
detected between a function call
subsystem and its inputs. (See DO-178B,
Section 6.3.3b)
Page 64
Do not distribute
7.6 Compatibility Diagnostics

The Compatibility Diagnostics Pane of the Configuration Parameters is shown below:
Recommended compatibility diagnostic settings are outlined in the following table along
with rationale. Compatibility diagnostics are considered to be important for generation of
safety critical code if custom S-Functions are being used in the models.
Diagnostic
Setting
S-Function upgrades needed error
An S-Function written for a previous
version may not be compatible with the
current version and could result in
Page 65
Do not distribute
7.7 Model Reference Diagnostics

The Model Reference Diagnostics Pane of the Configuration Parameters is shown below:
Recommended model referencing diagnostic settings are outlined in the following table
along with rationale. Of course these recommendations are only appropriate if model
referencing is being used in the Model-Based Design.
Page 66
Do not distribute
Diagnostic
Model block version
mismatch
Port and parameter

mismatch
Model configuration
mismatch
Setting
none
This diagnostic is used to determine that
the model calling the model reference
block is not using the same version of
model as the referenced model on the
path. The user should be getting the
latest version from the software
configuration management system, rather
than using an older version, which could
lead to incorrect simulation results and
mismatches between simulation and
target code operation. (See DO-178B,
Section 6.3.3b)
error
the model calling the model reference
block has an incorrect graphical interface
to the version of model code as the
referenced model on the path. This could
lead to unconnected lines and ports and
unexpected simulation results. (See DO178B, Section 6.3.3b and MISRA-C
2004, Rule 16.6)
warning
the referenced model on the path has an
incompatible configuration for a
referenced model or that it has a different
configuration than the parent model.
Some diagnostics for reference models
are not supported in simulation mode, so
setting this to error can cause simulations
not to run. Some differences in
configurations could lead to incorrect
simulation results and mismatches
between simulation and target code
operation, so warnings should be
generated and reviewed. (See DO-178B,
Section 6.3.3b)
Page 67
Do not distribute
Diagnostic
Invalid root Inport/Outport
block connection
Unsupported data logging
Setting
error
When Simulink detects an illegal
Inport/Outport connection in a referenced
model; it may automatically insert hidden
blocks into the model to correct the
problem. These hidden blocks lead to
code with no traceable requirements,
which violates DO-178B. Setting this
diagnostic to error, forces the model
developer to manually correct the
reference model. (See DO-178B, Section
6.3.3b and MISRA-C 2004, Rule 16.6)
error
This diagnostic applies to To Workspace
or Scope blocks that are logging signals
in a referenced model. Since these
blocks are ignored for embedded code
and only used for debugging, a warning
or error should occur, indicating that an
inappropriate block is in the referenced
model. (See DO-178B, Section 6.3.1d &
6.3.2d)
Page 68
Do not distribute
7.8 Saving Diagnostics

The Saving Diagnostics Pane of the Configuration Parameters is shown below:
Recommended saving diagnostic settings are outlined in the following table along with
rationale.
Diagnostic
Block diagram contains
disabled library links
Setting
error
This diagnostic is used to determine if
there are any broken library links at the
time the model is saved. Saving with
disabled library links may result in the
model being inconsistent with the library
the next time it is opened. (See DO178B, Section 6.3.3b)
Page 69
Do not distribute
Diagnostic
Block diagram contains
parameterized library links
Setting
error
This diagnostic is used to determine if
there are any non-mask parameters used
within library links at the time the model
is saved. Saving with parameterized
library links may result in the model
being inconsistent with the library block.
Page 70
Do not distribute
8 Hardware Implementation Considerations for Safety

Critical or Mission Critical Systems
This section contains recommendations with respect to hardware implementation related
settings when developing safety critical or mission critical systems. The Hardware
Implementation Pane of the Configuration Parameters is shown below:
The embedded hardware settings must be set to match the operation of the target
compiler and hardware. The emulation hardware must be set to None for target code
generation. This latter setting would only be used for prototyping on hardware that is
different from the actual production target.
Page 71
Do not distribute
9 Simulation Target Considerations for Safety Critical

This section contains recommendations with respect to Simulation Target related settings
when developing safety critical or mission critical systems. Each of the Simulation
Target setting panes of concern will be addressed individually.
9.1 Simulation Target

The main Simulation Target Pane of the Configuration Parameters is shown below:
Page 72
Do not distribute
Recommended Simulation Target option settings are outlined in the following table along
with rationale.
Option
Enable
debugging/animation
Echo expressions without

semicolons
Enable overflow detection
(with debugging)
Simulation target build

mode
Setting
on
In order to provide diagnostic coverage
specified in sections 13.2 and 13.3 during
simulation, the Enable
debugging/animation setting must be
checked. This will not affect the
embedded code, only the simulation
code.
Off or on
This setting has no effect on safety and is
only used during simulation.
on
This setting should be set so that any
numeric overflows are reported during
simulation. Numeric overflows can
result in incorrect and unsafe behavior.
(See DO-178B, Section 6.4.2.2 & 6.4.3)
Incremental
Method of building of simulation code
build,
has no effect on safety and does not
Rebuild all,
affect the generation of the embedded
Make without code.
generating
code,
Clean all, or
Clean objects
Page 73
Do not distribute
9.2 Symbols
The Symbols Pane for Simulation Target of the Configuration Parameters is shown
below:
Page 74
Do not distribute
Recommended Symbols option settings are outlined in the following table along with
rationale.
Option
Reserved names
Recommended
Setting
Empty or any
valid reserved
name
expression
that does not
contain a
Real-Time
Workshop
keyword
Rationale
The reserved names correspond to
functions or variables that may be
contained in custom code. Real-Time
Workshop will mangle any names that
may conflict with reserved names in the
generated code.
Page 75
Do not distribute
9.3 Custom Code

The Custom Code Pane for Simulation Target of the Configuration Parameters is shown
below:
Page 76
Do not distribute
Recommended Custom Code option settings are outlined in the following table along
with rationale.
Option
Source File
Header File
Initialize Function
Terminate Function
Include directories
Source Files
Libraries
Recommended
Setting
Empty or any
valid custom
code
Empty or any
valid include
directories,
source file
names or
library names
to be included
in the
compiled code
Rationale
Insertion of custom code into the autogenerated code should have no safety
impact. It is up to the modeler to
document the requirements for this code
and to provide verification of this code.
Compilation of custom code along with
the auto-generated code should have no
safety impact. It is up to the modeler to
Page 77
Do not distribute
10 Code Generator Considerations for Safety Critical or

This section contains recommendations with respect to Real-Time Workshop software
settings when developing safety critical or mission critical systems. Each of the RealTime Workshop setting panes of concern will be addressed individually.
10.1 Real-Time Workshop Software

The main Real-Time Workshop Pane of the Configuration Parameters is shown below:
Recommended Real-Time Workshop option settings are outlined in the following table
along with rationale.
Page 78
Do not distribute
Option
System target file
Language
Compiler optimization
level
TLC options
Generate makefile
Make command
Template makefile
Recommended
Setting
ERT based
Rationale
Use 'ert.tlc' or a target derived from ERT

identified by the system target file
containing the line
'rtwgensettings.DerivedFrom = 'ert.tlc'.
This is the only appropriate type of target
for embedded real-time systems.
C or C++
This setting affects the file extension
name, .C versus .CPP and the inclusion
of extern C declarations. The setting
used must be determined based on the
compiler being used and the language (C
or C++) of the code which will be
interfaced to.
Optimizations
This setting determines the compiler
off,
optimization level for building the
Optimizations
executable object code. See the Realon, or Custom Time Workshop documentation for
details on the use of this setting.
Normally this is left blank. See the
Target Language Compiler
documentation for details about when to
use this setting.
On or Off
This setting determines whether a
makefile for building the executable is
generated along with the source code.
See the Real-Time Workshop
documentation for details on
automatically generating the makefile.
make_rtw
This setting should not need to be
changed. See the Real-Time Workshop
documentation for details on
automatically generating the makefile.
my_custom_tmf This setting is only needed when
Generate makefile is set to on. You can
specify a custom template makefile if
you want to compile the generated code
as part of the build process. See the RealTime Workshop documentation for
details on automatically generating the
makefile.
Page 79
Do not distribute
Option
Ignore custom storage
classes
Recommended
Setting
On or Off
Ignore test point signals
On or Off
Generate code only
On or Off
Rationale
If custom storage classes are to be used
in the generated code, this option must be
Off. It may be necessary to set this
option to On for simulation targets, if
they do not support custom storage
classes.
This option is used to determine if test
points in the model are to be inserted as
variables that are accessible in the
generated code. If this option is set to
on, then test pointed signals can be
treated as temporary variables and may
not be accessible in the generated code.
This option is used to determine if only
source code is generated, or if the
executable is also built form the source
code. If this is set to Off, then typically,
Generate makefile must be set to On
and Make command and Template
makefile must have valid values
defined. Alternatively, the
PostCodeGenCommand parameter can
be used in conjunction with the buildInfo
object to dynamically interface to an
IDE-based tool chain for compilation.
documentation for details on using this
approach.
Page 80
Do not distribute
10.2 Report
The Report Pane of the Configuration Parameters is shown below:
Recommended Report option settings are outlined in the following table along with
rationale.
Page 81
Do not distribute
Option
Create code generation
report
Recommended
Setting
On
Launch report
automatically
On or Off
Code-to-model
On
Model-to-code
On
Eliminated / virtual blocks
On
Traceable Simulink blocks
On
Traceable Stateflow objects
On
Traceable Embedded
MATLAB functions
On
Rationale
The code generation report will be used
to perform code reviews and to show
traceability from code to requirements.
(See DO-178B, Section 6.3.4)
This setting determines whether or not
the code generation code report is opened
automatically at code generation time.
The report can also be opened from the
model explorer at any time.
The code to model navigation can assist
in the performance of code reviews and
to show traceability from code to
6.3.4)
The model to code navigation can assist
in the performance of code reviews and
to show traceability from requirements to
code. (See DO-178B, Section 6.3.4)
Showing eliminated and virtual blocks
can assist in the performance of code
reviews and to show traceability from
requirements to code. (See DO-178B,
Section 6.3.4)
Showing traceable Simulink blocks can
assist in the performance of code reviews
and to show traceability from
Section 6.3.4)
Showing traceable Stateflow objects can
assist in the performance of code reviews
and to show traceability from
Section 6.3.4)
Showing traceable Embedded MATLAB
functions can assist in the performance of
code reviews and to show traceability
from requirements to code. (See DO178B, Section 6.3.4)
Page 82
Do not distribute
10.3 Comments
The Comments Pane of the Configuration Parameters is shown below:
Recommended Real-Time Workshop Comments option settings are outlined in the

following table along with rationale.
Option
Include comments
Simulink block comments
Show eliminated statements
Verbose comments for

SimulinkGlobal storage
class
Setting
On
This setting provides good traceability
between the code and the model. (See
On
On
On
Page 83
Do not distribute
Option
Simulink block descriptions
Stateflow object
descriptions
Simulink data object

descriptions
Requirements in block
comments
Custom comments (MPT

objects only)
Setting
On or Off
This option will comment the code with
Simulink block descriptions that are
entered in the model. Entry of block
descriptions is optional at the model
level.
On or Off
Stateflow object descriptions that are
entered in the model. Entry of object
level.
On or Off
Simulink data object descriptions that
are entered in the model. Entry of data
object descriptions is optional at the
model level.
On
between the code and the high level
6.3.4e)
On or Off
MPT object descriptions that are entered
in the model. Entry of MPT object
level.
Page 84
Do not distribute
10.4 Symbols
The Symbols Pane of the Configuration Parameters is shown below:
Recommended Real-Time Workshop Symbols option settings are outlined in the

Option
Global variables
Setting
$R$N$M
This setting can be used to set up naming
styles in the generated code. $M is
required in order to avoid name
collisions. See the Real-Time
Workshop Embedded Coder
documentation for Specifying Identifier
Formats.
Page 85
Do not distribute
Option
Global types
Field names of global types
Subsystem methods
Local temporary variables
Local block output

variables
Constant macros
Setting
$N$R$M
Formats.
$N$M
Formats.
$R$N$M$F
Formats.
$N$M
Formats.
rtb_$N$M
Formats.
$R$N$M
Formats.
Page 86
Do not distribute
Option
Minimum mangle length
Maximum identifier length
Generate scalar inlined

parameters as
Signal naming
Parameter naming
#define naming
Setting
4
This provides a value that makes it
unlikely that parameter and signal names
will change during code generation when
the model has changed. This will assist
in minimizing code differences between
file versions, thus decreasing the effort to
perform code reviews. (See DO-178B,
Section 6.3.1e & 6.3.2e)
31 or greater
The maximum identifier length should be
set based on the maximum allowed by
the compiler being used (although
MISRA-C 2004, Rule 5.1 recommends a
maximum length of 31 for portability).
The longer this length can be the easier it
will be to trace the identifiers to the
model. (See DO-178B, Section 6.3.1e &
6.3.2e)
Literals or
This option determines whether inlined
Macros
parameters are inserted as Literals (i.e.
numeric value) or as Macros (i.e. variable
name)
None, Force
upper case,
styles in the generated code. See the
Force lower
Module Packing Features document to
case or
determine how to use this setting to
Custom Mcustomize signal naming.
function
None, Force
upper case,
Force lower
case or
Custom Mcustomize parameter naming.
function
None, Force
upper case,
Force lower
case or
Custom Mcustomize #define naming.
function
Page 87
Do not distribute
Option
Use the same reserved
names as Simulation Target
Reserved names
Setting
Off or on
When this setting is off the code
generator uses the reserved names
identified on this pane. When this setting
is on the code generator uses the reserved
names on the Simulation Target Symbols
Pane.
Empty or any This setting is only enabled if Use The
valid reserved Same Reserved Names As Simulation
name
Target is set to Off. The reserved names
expression
correspond to functions or variables that
that does not
may be contained in custom code. Realcontain a
Time Workshop will mangle any names
Real-Time
that may conflict with reserved names in
Workshop
the generated code.
keyword
Page 88
Do not distribute
10.5 Custom Code

The Custom Code Pane of the Configuration Parameters is shown below:
Recommended Real-Time Workshop Custom Code option settings are outlined in the
Option
Use the same custom code
settings as Simulation
Target
Setting
Off or on
When this setting is off the code
generator uses the custom code identified
on this pane. When this setting is on the
code generator uses the custom code on
the Simulation Target Custom Code
Pane.
Page 89
Do not distribute
Option
Source File
Header File
Initialize Function
Terminate Function
Include directories
Source Files
Libraries
Recommended
Setting
Empty or any
valid custom
code
Empty or any
valid include
directories,
source file
names or
library names
to be included
in the
compiled code
Rationale
Insertion of custom code into the autogenerated code should have no safety
impact. It is up to the modeler to
Compilation of custom code along with
the auto-generated code should have no
safety impact. It is up to the modeler to
Page 90
Do not distribute
10.6 Debug
The Debug Pane of the Configuration Parameters is shown below:
Debugging will normally be turned off, but may be used when developing custom TLC
files. The Debugging has no direct effect on the safety of the code. If artifacts of the code
generation log are desired, select the Verbose build option and capture the output
generated to the MATLAB command window.
Page 91
Do not distribute
10.7 Interface
The Interface Pane of the Configuration Parameters is shown below:
Recommended Real-Time Workshop Interface option settings are outlined in the

Option
Target floating-point math
environment
Utility function generation
Setting
ANSI-C, ISO- This setting is determined by the target
C or GNU
system math libraries. Note: Before
setting this option, verify that your
compiler supports the library you want to
use.
Auto or
Shared
documentation for a description of how
location
to use this setting.
Page 92
Do not distribute
Option
Support floating point
numbers
Support non-finite numbers
Support complex numbers

Support absolute time
Support continuous time
Support non-inlined SFunctions
GRT compatible call

interface
Single output/update
function
Terminate function required
Generate reusable code
Setting
On or Off
Normally this will be set to On, unless
the target processor only supports fixed
point, then it should be set to Off to
insure hardware compatibility. (See DO178B Section 6.3.1c, 6.3.2c & 6.3.3c)
Off
Support of non-finite numbers is
inappropriate for real-time safety critical
systems. (See DO-178B Section 6.3.1c &
6.3.2c)
On or Off
Set as appropriate for you application.
Off
Support of absolute time is inappropriate
for real-time safety critical systems. (See
DO-178B Section 6.3.1c & 6.3.2c)
Off
Support of continuous time is
6.3.2c)
Off
This option would require supporting
non-finite numbers which is
6.3.2c)
Off
This option is not appropriate for realtime embedded systems. (See DO-178B
Section 6.3.1c & 6.3.2c)
On
Having a single call to the output and
update functions simplifies the interface
to the RTOS and simplifies verification
of the auto-generated code. (See DO178B Section 6.3.1c & 6.3.2c)
Off
Terminate function is only used for
dynamic memory de-allocation, which is
not appropriate for real-time safety
critical systems. ((See DO-178B Section
6.3.1c & 6.3.2c and MISRA-C 2004,
Rule 20.4)
On or Off
This option affects the style of the code
interface. If the auto-generated code is
intended to be reused multiple times in
the same executable with different data
sets for each use, then this option must be
set to On. If the code is only to be used
once, then this option may be On or Off.
Page 93
Do not distribute
Option
Suppress error status in
real-time model data
structure
Create Simulink (SFunction) block
Enable portable word sizes
MAT-file data logging
Interface
Setting
On
Not selecting this option will produce
extra code that may be unreachable and
therefore un-testable in the generated
code. (See DO-178B, Section 6. 3.1c &
6.3.2c and MISRA-C 2004, Rule 14.1)
On or Off
This option creates an S-Function
wrapper for the generated code so that it
can be tested during simulation using a
test harness. The generated model code
is unaffected by this option, only an
additional S-function interface file
(<modelname>_sf.c) is created.
Alternatively, model reference can be
used to test the code generated for a
Model block during a simulation,
however the target code for the Model
block will need to be generated
separately from the simulation code.
On or Off
This option allows the generated code to
be compiled for use with the S-Function
wrapper described above in this table,
even if the word size of the host machine
is different from the word size of the
target computer defined in the Hardware
Implementation pane of the
Configuration Parameters.
Off
This option adds extra code to log test
point to a MAT file, which would not be
supported by the embedded target
platform. (See DO-178B Section 6.3.1c
& 6.3.2c) This option should only be
used in test harnesses, not in models used
for embedded target code generation.
None
This option allows extra interface code to
be generated to support signal
observation and parameter tuning on the
target platform. Any of the three options:
C-API, External Mode or ASAP2 may be
used during development, but it is
recommended that this software be
removed for the final production version.
Page 94
Do not distribute
10.8 Code Style

The Templates Pane of the Configuration Parameters is shown below:
Recommended Real-Time Workshop Code Style option settings are outlined in the
Option
Parentheses level
Recommended
Setting
Maximum
(MISRA C
compliance)
Preserve operand order in

expression
On
Preserve condition
expression in if statement
On
Rationale
This setting forces the use of parentheses
and avoids the reliance on C precedence
rules. (See DO-178B Section 6.3.1c &
6.3.2c and MISRA-C 2004, Rule 12.1)
Page 95
Do not distribute
10.9 Templates
The Templates Pane of the Configuration Parameters is shown below:
Templates are used only to insert program specific header information into the source and
header files. These have no direct effect on the safety of the generated code, but must be
verified to be acceptable by the system developer.
Page 96
Do not distribute
10.10 Data Placement

The Data Placement Pane of the Configuration Parameters is shown below:
Data placement options affect the style of the generated code. These have no direct effect
on the safety of the generated code, but must be verified to be acceptable by the system
developer.
Page 97
Do not distribute
10.11 Data Type Replacement

The Data Type Replacement Pane of the Configuration Parameters is shown below:
Data Type Replacement allows developers to replace the standard Real-Time Workshop
data type identifiers with there own custom data type identifiers. For safety, it is
recommended that data type replacement not be used. Currently, replacement names do
not fully participate in RTW name conflicts check. There could be conflicts between
replacement name and other symbols, e.g. function, variable, etc. If that happens, code
wont compile correctly or will be incorrect if compiles. However, all default type names
are reserved words, so this is not an issue if default type names are used.
Page 98
Do not distribute
10.12 Memory Sections

The Memory Sections Pane of the Configuration Parameters is shown below:
Memory Sections allows developers to map the generated code to specific memory
sections or memory types in the target. These have no direct effect on the safety of the
generated code, but must be verified to be acceptable by the system developer.
Page 99
Do not distribute
11 Block Selection Considerations for Safety Critical or

The following sections outline block selection considerations for safety critical or
mission critical systems. This section only considers the basic Simulink Block Library; it
does not address optional block sets or optional embedded targets.
11.1 General Guidelines

Simulink provides a block support table indicating the blocks that are appropriate for
real-time production code. This table can be accessed using the Help -> Block Support
Table menu from a Simulink model. Alternately this can be opened from the Simulink
Block Library by opening the Model Wide Utilities group and then opening Block
Support Table. This table includes caveats and notes that provide guidance on selecting
blocks for code generation.
All blocks marked with note Not recommended for production code and Consider
using the Embedded MATLAB block instead, must be avoided for real-time safety
critical code. All blocks marked with note Ignored for code generation are ignored
during code generation and these blocks should not be included in production code
models, but may be used during debugging of the models or within test harnesses.
All caveats, must be strictly followed when using blocks that have been identified as such.
See section 12 for other block specific considerations for safety critical code generation.
11.2 Specific Blocks of Concern

The following table provides a list of blocks that are acceptable for production code but
are not recommended for safety critical code and the rationale for avoiding these blocks.
Block to Avoid
Random Number
Uniform Random Number
Band-Limited White Noise
Rationale
Random number generation may be nondeterministic and is difficult to verify.
Random number generation may be nondeterministic and is difficult to verify.
White noise generation may be nondeterministic and is difficult to verify.
Page 100
Do not distribute
12 Block Setting and Data Type Considerations for

Safety Critical or Mission Critical Systems
The following sections outline some recommended settings for specific blocks when
developing safety critical or mission critical systems. This section only considers the
basic Simulink Block Library; it does not address optional block sets.
12.1 General Block Data Type Settings

Most blocks have a Signal Attributes pane. For all operations other than fixed point
arithmetic, it is recommended to set Output Data Type is to use Inherit: Same as
input or Inherit: Same as first input. For blocks with multiple inputs, the checkbox
selection Require all inputs to have the same data type should always be selected on,
except for fixed point arithmetic operations. (See MISRA-C 2004, Rule 10.1, 10.2, 10.3
& 10.4) Figure 12-1 shows the recommended settings.
Figure 12-1
For fixed point operations the Accumulator Data Type and Output Data Type should
be set using the data type assistant. This will enable the settings for Mode, Sign,
Scaling, Word length, Slope, Bias and Lock Output Scaling Against Changes
by the Autoscaling Tool. It is highly recommended that for fixed point operations that
the output scaling be displayed as a block attribute so that the proper output scaling can
Page 101
Do not distribute
be verified during model reviews. Figure 12-2 shows the recommended settings for fixed
point.
Figure 12-2
Page 102
Do not distribute
Some blocks have a Parameter Attributes pane. For all operations other than fixed
point arithmetic, it is recommended to set Parameter Data Type is to use Inherit: Same
as input as shown in Figure 12-3. For fixed point operations the Parameter Data Type
should be set to using the data type assistant as shown in Figure 12-4. (See MISRA-C
2004, Rule 10.1, 10.2, 10.3 & 10.4)
Figure 12-3
Figure 12-4
Page 103
Do not distribute
For all logical and relational operator blocks the Output Data Type should always be
set to Boolean as shown in Figure 12-5. (See MISRA-C 2004, Rule 12.6)
Figure 12-5
12.2 Saturate on Integer Overflow Settings

When the input data type to a block is 8 or 16 bit signed or unsigned integer or fixed
point, Saturate on integer overflow should be selected to on when the block has this
setting option enabled. See Figure 12-2 for an example of this set to on. Overflows are
very likely when using 8 or 16 bit integers which can lead to undesirable operation in the
code. (See DO-178B, Section 6.4.2.2 & 6.4.3 and MISRA-C 2004, Rule 12.11) When
performing multiple additions or subtractions with 8 or 16 bit integers, a good approach
is to up cast to 32 bit integers. Perform the additions and subtractions using the 32 bit
integer, then downcast back to the original data type. Overflow will generally be
impossible during the addition and subtraction operations, and can only occur in the final
downcast.
When the input data type to a block is 32 bit signed or unsigned integer, Saturate on
integer overflow selection should be carefully considered on a case by case basis when
the block has this setting option enabled. Overflows are not very likely when using 32 bit
integers, but overflows can lead to undesirable operation in the code (See DO-178B,
Section 6.4.2.2 & 6.4.3 and MISRA-C 2004, Rule 12.11). In many cases it will not be
possible to overflow a 32 bit integer, which could lead to un-reachable and therefore untestable code (See DO-178B, Section 6.4.4.3c and MISRA-C 2004, Rule 14.1).
For fixed point operations Saturate on Integer Overflow should always be set on
because overflows could lead to sign changes that may lead to unsafe conditions. (See
DO-178B, Section 6.4.2.2 & 6.4.3)
Page 104
Do not distribute
When performing type casts, Saturate on integer overflow selection should be carefully
considered on a case by case basis, but is absolutely required when performing downcasts,
such as from 32 bit to 16 bit. If Inherit via back propagation type casting is used, then
Saturate on integer overflow should also be set on, as shown in Figure 12-6, because
this could result in down casting. (See DO-178B, Section 6.4.2.2 & 6.4.3 and MISRA-C
2004, Rule 10.1, 10.2 10.3 & 10.4)
Figure 12-6
12.3 Abs Block

Boolean and unsigned integer data types should not be used as inputs to the absolute
value block. Use of these data types will result in either no code for the block or data
copy code for the block, and may indicate that the data type of the block is incorrect. (See
DO-178B, Section 6.3.1g & 6.3.2g)
When signed integer data types are input to the absolute value block, Saturate on Integer
Overflow should always be set on because overflows will occur for full scale negative
input values, leading to incorrect sign of the output that may lead to unsafe conditions.
(See DO-178B Section 6.3.1g & 6.3.2g and MISRA-C 2004, Rule 21.1)
Page 105
Do not distribute
12.4 Data Store Blocks

Use of Data Store blocks can result in unexpected execution order and data behavior
across different sample times or different models. If Data Store blocks are going to be
used in safety critical systems, then the following rules are recommended:
All data store diagnostics should be set to warning or error

Data stores whose reads and writes occur across model and atomic subsystem
boundaries should be avoided when possible because Simulinks sorting
algorithm does not take into account data coupling between models and atomic
subsystems due to access of common data stores
Data stores should not be used to write and read data at different rates since this
can result in un-predictable data between the different rates. In order to avoid this ,
rate transition blocks may be used prior to data store writes or after data store
reads to provide deterministic data coupling in multi-rate systems
The use of Data Store blocks can have significant effects on the software verification
effort, especially in the area of data coupling and control. Models and subsystems which
use only inports and outports to pass data result in clean, deterministic and verifiable
interfaces in the generated code. (See DO-178B, Section 6.3.3b)
12.5 For Iterator Subsystem

When using For Iterator subsystems, it is recommended that variable iteration values be
avoided (See DO-178B, Section 6.4.2.2d and MISRA-C 2004, Rule 13.6). The use of
variable for loops can lead to unpredictable execution time and in the case of external
iteration variables, infinite loops may occur.
Methods to avoid variable for loops are:
Set Iteration Limit Source to internal

If Iteration Limit Source is set to external, use a Constant, Probe or Width
block as source
Avoid setting Set Next I (Iteration Variable) Externally
When using For Iterator subsystems it is recommended that sample time dependent
blocks such as integrators, filters and transfer functions not be used within these
subsystems because they will not function properly with an inherited sample time.
12.6 Inport and Outport Blocks

When using the Inport and Outport blocks at the top level of a model, the following
settings should be explicitly specified, as shown in Figure 12-7, rather than using the
auto selection:
Port dimensions
Sample time
Page 106
Do not distribute
Data type
Signal type
Sampling mode
Figure 12-7
A Model Advisor check exists that can verify these settings. (See DO-178B, Section
6.3.1b & 6.3.2b)
12.7 Math Function Block

When using the sqrt function, negative real inputs must be considered in the expected
results. The sqrt function will output the negative value of the square root of the absolute
value of the input for a negative input value. This could lead to undesirable results in the
generated code, if it is not accounted for. (See DO-178B, Section 6.4.2.2a)
Page 107
Do not distribute
The math functions log, log10 and rem rely on non-finite number support, which may
result in numeric exceptions in the generated code. It is recommended that these math
functions not be used. (See DO-178B, Section 6.4.2.2 & 6.4.3 and MISRA-C 2004, Rule
21.1) If these functions are necessary in the design then a custom hand coded S-Function
with built-in protection against non-finite numbers may be used in place of these math
functions. For log and log10 functions, if precision is not an issue, then a lookup table
may be used in place of these math functions.
When using the math function reciprocal, it is possible to get a divide by zero, resulting
in inf as an output. When using this function, the divisor input must be protected from
going to zero. (See DO-178B, Section 6.4.2.2 & 6.4.3 and MISRA-C 2004, Rule 21.1)
12.8 Merge Block

The merge block output will be representative of the most recently computed inputs.
This block must be used with great care because the output is dependent upon the
execution order of the input computations. There are two acceptable use cases for the
merge block:
1) Merge two vector signals of different lengths into a single vector whose length is
the sum of the input vectors
2) Merge the outputs of conditionally executed subsystems so that the output of the
merge block represents the last executed subsystem.
When use case 2 is implemented, the conditionally executed subsystems should be set up
to be mutually exclusive in all cases. This is necessary to provide predictable behavior of
the merge block output (See DO-178B, Section 6.3.3b). Methods to insure predictability
are:
1) Use Enabled Subsystem inputs whose enable logic provides exclusive execution
of the subsystems
2) Use Action Subsystem inputs that are all enabled from the same If-Else block
which provides exclusive execution of the subsystems
3) Use Action Subsystem inputs that are all enabled from the same Switch-Case
block which provides exclusive execution of the subsystems
12.9 Product Block

When using the product block with divisor inputs, it is possible to get a divide by zero,
resulting in inf as an output. When using this block, all divisor inputs must be protected
from going to zero. (See DO-178B, Section 6.4.2.2 & 6.4.3 and MISRA-C 2004, Rule
21.1)
When using the product block as a matrix inverse or as a matrix divide, it is possible to
get a divide by a singular matrix, resulting in inf as an output. When using this block, all
divisor inputs must be protected from singular input matrixes. (See DO-178B, Section
6.4.2.2 & 6.4.3 and MISRA-C 2004, Rule 21.1)
Page 108
Do not distribute
12.10 Relational Operator Blocks

When any type of relational operator block, including Relational Operator, Compare To
Constant, Compare to Zero and Detect Change blocks, is used on floating point signals,
the == and ~= operators should not be used. Because of floating point precision
issues, the use of these operators on floating point signals is unreliable. (See DO-178B,
Section 6.4.2.2 & 6.4.3 and MISRA-C 2004, Rule 13.3)
12.11 Triggered Subsystem

When using Triggered subsystems it is recommended that sample time dependent blocks
such as filters and transfer functions not be used within these subsystems because they
will not function properly with an inherited sample time.
12.12 While Iterator Subsystem

When using While Iterator subsystems, it is recommended that the number of iterations
be limited (See DO-178B, Section 6.4.3c and MISRA-C 2004, Rule 21.1). The use of
unlimited number of iterations can lead to infinite loops in the real-time code which will
lead to execution time overruns.
In order to avoid potential infinite loops the While Iterator parameter Maximum Number
of Iterations should always be set to a positive integer value. Additionally, it is
recommended that the Show Iteration Number Port be selected and that the iteration
value be observed during simulation to determine if the maximum number of iterations is
being reached. In cases where the maximum number of iterations is reached, the output
values of the While Iterator Subsystem should be verified to be correct.
When using While Iterator subsystems it is recommended that sample time dependent
blocks such as filters and transfer functions not be used within these subsystems because
they will not function properly with an inherited sample time.
Page 109
Do not distribute
13 Stateflow Software Considerations for Safety

Critical or Mission Critical Systems
This section contains recommendations with respect to Stateflow settings and usage when
developing safety critical or mission critical systems.
13.1 Chart Settings

The Chart Properties dialogue is shown below:
State Machine Type allows the user to select between Classic, Mealy or Moore
semantic rules. Here is a brief comparison of the semantics:
Classic: Provides full set of Stateflow semantics (see Stateflow Semantics)

Mealy: State machine in which output is a function of inputs and state
Moore: State machine in which output is a function only of state
Page 110
Do not distribute
Mealy and Moore charts use a subset of Stateflow semantics which can provide state
charts which may be easier to understand and use in safety critical systems. For more
information, see Building Mealy and Moore Charts in Stateflow in the help
documentation for Stateflow.
Use Strong Data Typing with Simulink I/O should be checked because strong data
typing is recommended for safety critical code. (See MISRA-C 2004, Rule 10.1, 10.2,
10.3 & 10.4)
User specified state/transition execution order should be checked. In this mode, the
model developer has complete control of the order in which parallel states are executed
and transitions originating from a source are tested for execution. It is also recommended
that under the Chart View Menu, Show Transition Execution Order always is set to on
so that the transition testing order is always visible. (See DO-178B, Section 6.3.1b &
6.3.2b)
13.2 Stateflow Software Debugger Settings

The Stateflow Debugger dialogue is shown below:
State Inconsistency should be checked. An unconditional default-path is required at

every level of hierarchy where there are multiple XOR states. This will prevent runtime
state inconsistency errors (See DO-178B, Section 6.3.4f). See Debugging State
Page 111
Do not distribute
Inconsistencies in the Stateflow Help Documentation for a complete description and

example.
Transition Conflict should be checked. It checks whether there are two equally valid
transition paths from the same source at any step in the simulation. See Debugging
Conflicting Transitions in the Stateflow Help Documentation for a complete description
and example. Charts with conflicting transitions will result in unreachable, and therefore
un-testable, code. (See DO-178B, Section 6.4.4.3c and MISRA-C 2004, Rule 14.1)
Data Range should be checked. It checks whether the minimum and maximum values
you specified for a data in its properties dialog are exceeded. It also checks whether
fixed-point data overflows its base word size. See Debugging Data Range Violations in
the Stateflow Help Documentation for a complete description and example. Numeric
overflows can result in incorrect and unsafe behavior. (See DO-178B, Section 6.4.2.2 &
6.4.3)
Detect Cycles should be checked. It checks whether a step or sequence of steps
indefinitely repeats itself due to a recursive event broadcast. See Debugging Cyclic
Behavior in the Stateflow Help Documentation for a complete description and example.
Recursion can lead to unpredictable execution time and also may result in stack
overflows. (See DO-178B, Section 6.3.4f and MISRA-C 2004, Rule 16.2)
13.3 Truth Table Settings

Each Truth Table has settings for Under-specified and Over-specified. Both of these
settings should be set to Error for all truth tables. An over-specified truth table contains a
decision that will never be executed because it is already specified in a previous decision
in the Condition Table. Over-specified truth tables will result in unreachable, and
therefore un-testable, code (See DO-178B, Section 6.4.4.3c and MISRA-C 2004, Rule
14.1). An underspecified truth table lacks one or more possible decisions that might
require an action to avoid undefined behavior in the application (See DO-178B, Section
6.3.4f).
13.4 Chart Commenting

Unlike Simulink blocks in a diagram, Stateflow components are not all uniquely named.
This can lead to difficulty in tracing the code back to the block diagram. To enhance
traceability it is recommended that all states, transitions and truth tables contain uniquely
identifiable comments. These comments will then be inserted into the generated code,
thus providing traceability back to the model. These comments can be added manually to
the charts, or it is also possible to build a script that would add a uniquely identifiable
trace tag to each component of concern. (See DO-178B, Section 6.3.4e)
Page 112
Do not distribute
13.5 Transition Paths Crossing Parallel State Boundaries

Transitions crossing from one parallel state to another should be avoided as they result in
diagrams that are hard to understand. An example is shown in the following chart. (See
DO-178B, Section 6.3.1e, 6.3.2e & 6.3.3e)
Page 113
Do not distribute
13.6 Transition Paths Looping Out of the Parent of

Source/Destination Objects
Transitions looping out of their logical parent (parent of the source and destination
objects) are typically unintentional and cause the parent to deactivate and activate (See
DO-178B, Section 6.3.1e, 6.3.2e & 6.3.3e). These must be avoided. An example is shown
in the following chart.
13.7 Transition Paths Passing Through a State

Transition paths going into a state and coming back out without ending up on a sub-state
are confusing and have no benefit whatsoever. These should be avoided. (See DO-178B,
Section 6.3.1e, 6.3.2e & 6.3.3e)
Page 114
Do not distribute
Page 115
Do not distribute
13.8 Flow-Graph Backup

Flow-graphs with backup semantics are harder to understand and cause unintentional
repeated execution of condition-actions. These should be avoided. (See DO-178B,
Section 6.3.1e, 6.3.2e & 6.3.3e)
For example, in the following diagram, a3 will get executed twice if
c1=1,c2=1,c3=1,c4=0. This is typically unintentional and unexpected by the user.
In contrast, a3 gets executed at most once, in the following diagram which does not
have the backup.
Page 116
Do not distribute
13.9 Recursive Graphical Functions

Recursive graphical functions must be avoided. Recursive software routines are not
appropriate for safety critical real-time systems because they can lead to unpredictable
execution time and could even lead to stack overflows. An example of a recursive
graphical function is shown in the following diagram. (See DO-178B, Section 6.3.4f and
Page 117
Do not distribute
14 Run-Time Library Considerations for Safety Critical

This section contains recommendations with respect to runtime library usage when
developing safety critical or mission critical systems. Real-Time Workshop Embedded
Coder generates code that calls custom runtime library code. All runtime libraries are
auto-generated as needed. These runtime libraries are used for various functions that are
not supplied with standard ANSI-C, ISO-C or GNU runtime libraries.
14.1 Runtime Libraries

All of the runtime libraries get auto-generated by Real-Time Workshop Embedded Coder
on an as needed basis. The location of the generated files can be controlled from the
Interface Pane of the Configuration Parameters Dialog. Various header and code files for
the library functions may be generated. Some of these libraries may be in the form of
function macros, and others may be in the form of C functions.
When using model reference, these functions will be put into a shared directory (see
Real-Time Workshop documentation for details) for use by all model generated code. If
Real-Time Workshop detects that a particular library function already exists in the shared
location, it will not generate that function again.
All function macros should be verified when testing the auto-generated code that uses
each of the macros. Functions implemented as code may be tested and verified
independently of the individual usage of the functions in the code generated for the
models.
14.2 MISRA-C Violations

The use of function like macros, which are used by Real-Time Workshop Embedded
Coder, is a violation of a MISRA Advisory Rule. MISRA-C 2004, Rule 19.7, advises
against the use of function like macros and recommends functions instead. However, this
is not a mandatory rule.
For release R2008b, not all of the runtime library functions are MISRA-C compliant. If
MISRA-C is to be used for the coding standards for a Model-Based Design process, then
modifications to some of these files may be required to bring the runtime libraries into
compliance with MISRA-C rules that are selected for the application. The violation of
advisory rule 19.7 is an example of non-compliance for the runtime libraries. This does
not represent all of the possible MISRA-C violations.
To request MISRA-C compliance information for Real-Time Workshop Embedded
Coder, use the following link:
Page 118
Do not distribute
http://www.mathworks.com/support/solutions/data/1-1IFP0W.html
Page 119
Do not distribute
This page left blank intentionally.
Page 120
Do not distribute

Model-Based Design For DO-178B R2008b

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Model-Based Design For DO-178B R2008b

Uploaded by

Copyright:

Available Formats

Model-Based Design for Safety Critical or

Mission Critical DO-178B Applications

The MathWorks Confidential Subject to NonDisclosure Agreement

The MathWorks, Inc.

COPYRIGHT 2009 by The MathWorks, Inc.

3.2 Use of Model Reference ..................................................................................... 37

Disclaimer: While adhering to the recommendations in this document will reduce

The MAAB Style Guidelines document is considered to be complementary to this

2 DO-178B Software Lifecycle

2.1 Table A-1 Planning Process

Software development and integral 4.1a

Transition criteria, inter4.1b

Software life cycle environment is

Additional considerations are

Software development standards are 4.1e

Software plans comply with this

Software plans are coordinated.

Software Process Impact when using

Must include Model-Based

2.1.1 Software development and integral processes activities are

2.1.2 Transition criteria, inter-relationships and sequencing among

2.1.3 Software life cycle environment is defined

2.1.4 Additional considerations are addressed

2.1.5 Software development standards are defined

2.1.6 Software plans comply with this document

2.1.7 Software plans are coordinated

2.2 Table A-2 Software Development Process

High-level requirements are

Derived high-level requirements 5.1.1b

Low-level requirements are

Derived low-level requirements 5.2.1b

Source code is developed.

Executable Object Code is

A, B, C, D Embedded IDE Link CC

2.2.1 High-level requirements are developed

2.2.2 Derived high-level requirements are developed

2.2.3 Software architecture is developed

2.2.4 Low-level requirements are developed

2.2.5 Derived low-level requirements are developed

2.2.6 Source code is developed

2.2.7 Executable Object Code is produced and integrated in the

2.3 Table A-3 Verification of Requirements Process

High-level requirements are

High-level requirements are

High-level requirements are

High-level requirements are

Algorithms are accurate.

2.3.1 Software high-level requirements comply with system

2.3.2 High-level requirements are accurate and consistent

2.3.3 High-level requirements are compatible with the target

2.3.4 High-level requirements are verifiable

2.3.5 High-level requirements conform to standards

2.3.6 High-level requirements are traceable to system requirements

2.3.7 Algorithms are accurate

2.4 Table A-4 Verification of Design Process

Low-level requirements comply 6.3.2a

Low-level requirements are

Low-level requirements are

Low-level requirements are

Low-level requirements are

Algorithms are accurate.

12 Software architecture conforms 6.3.3e

13 Software partitioning integrity 6.3.3f