Mathworks DO QUALIFICATION KIT 1 Model-Based Design

Download

DO Qualification Kit 1

Model-Based Design Workflow for DO-178B

How to Contact The MathWorks

www.mathworks. comp.soft-sys.matlab Newsgroup www.mathworks.com/contact_TS.html Technical Support

suggest@mathworks.com Product enhancem ent suggestions

bugs@mathwo doc@mathworks.com Documentation error reports service@mathworks.com Order status, license renewals, passcodes

info@mathwo

com

rks.com

Web

Bug reports

Sales, prici

ng, and general information

508-647-7000 (Phone)

508-647-7001 (Fax)

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

For contact information about worldwide offices, see the MathWorks Web site.

DO Qualification Kit Model-Based Design Workflow for DO-178B

The software described in this document is furnished under a license agreement. The software may be used or copied only under the terms of the license agreement. No part of this manual may be photocopied or reproduced in any form without prior written consent from The MathW orks, Inc.

FEDERAL ACQUISITION: This provision applies to all acquisitions of the Program and Documentation by, for, or through the federal government of the United States. By accepting delivery of the Program or Documentation, the government hereby agrees that this software or documen tation qualifies as commercial computer software or commercial computer software documentation as such terms are used or defined in FAR 12.212, DFARS Part 227.72, and DFARS 252.227-7014. Accordingly, the terms and conditions of this Agreement and only those rights specified in this Agreement, shall pertain to and govern theuse,modification,reproduction,release,performance,display,anddisclosureoftheProgramand Documentation by the federal government (or other entity acquiring for or through the federal government) and shall supersede any conflicting contractual terms or conditions. If this License fails to meet the government’s needs or is inconsistent in any respect with federal procurement law, the government agrees to return the Program and Docu mentation, unused, to The Mat hWorks, Inc.

Trademarks

MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See

www.mathworks.com/trademarks for a list of additional trademarks. Other product or brand

names may be trademarks or registered trademarks of their respective holders.

Patents

The MathWorks products are protected by one or more U.S. patents. Please see

www.mathworks.com/patents for more information.

Revision History

September 2010 Online only New for Version 1.3 (Release 2010b)

DO-178B Software Life Cycle

DO-178B Software Life C ycle Overview .............. 1-2

Contents

Model-Based Design Workflow in DO-178B

Planning Process

Software Development and Integral Processes Activities are

Defined

Transition Criteria, Inter-Relationships, and Sequencing

Among Processes are Defined Software Life-Cycle Environment Is Defin ed Additional Considerations are Addressed Software D ev elo pment Standards are Defined Software Plans Comply with DO-178B Software Plans are Coordinated

Software Development Process

High-Level Requirem ents are Developed Derived High-Level Requirements are Developed Software Architecture Is Developed Low-Level Requirements are Developed Derived Low -Level Requirem ents are Developed Source Code Is Developed Executable Object Code Is Produced and Integrated in the

Target Computer

.................................. 1-5

....................................... 1-6

..................... 1-7

...................... 1-9

..................... 1-10

................... 1-11

........................... 1-12

................................ 1-12

........... 1-3

........... 1-8

.............. 1-8

.......... 1-8

................ 1-9

.............. 1-11

....... 1-11

............... 1-11

........ 1-12

Verification of Requirements Process

Software High-Level Requiremen ts Comply with System

Requirements High-Level Require ments Are Accurate and Consistent High-Level Requirements Are Compatible with the Target

Computer High-Level Require ments Are Verifiable High-Level Requirem ents Conform to Standards

.................................. 1-14

...................................... 1-15

............... 1-13

.............. 1-16

........ 1-17

.. 1-15

iii

High-Level Requirements Are Traceable to System

Requirements

Algorithms Are Accurate

.................................. 1-17

........................... 1-18

Verification of Design Process

Low-Level Requirements Comply with High-Level

Requirements Low-Level Requirements Are Accurate and Consistent Low-Level Requirements Are Compatible with the Target

Computer Low-Level Requirements Are Verifiable Low-Level Requirements Conform to Standards Low-Level Requirements Are TraceabletoHigh-Level

Requirements Algorithms Are Accurate Software Architecture Is Compatible with High-Level

Requirements Software Architecture Is Consistent Software Architecture Is Compatible with the Target

Computer Software Architecture Is Verifiable Software Architecture Conforms to Standards Software Partitioning Integrity Is Confirmed

Verification of Coding and Integration Process

Source Code Complies with Low-Level Requirements Source Code Complies with Software Architecture Source Code Is Verifiable Source Code Conforms to Standards Source Code Is Traceable to Low-Level Requirements Source Code Is Accurate and Consistent Output of Software Integration Process Is Complete and

Correct

........................................ 1-32

.................................. 1-20

...................................... 1-22

.................................. 1-24

.................................. 1-26

...................................... 1-27

...................... 1-19

............... 1-23

........ 1-23

........................... 1-25

.................. 1-26

................... 1-27

.......... 1-28

........... 1-28

........................... 1-30

.................. 1-31

............... 1-31

... 1-21

...... 1-29

.... 1-30

....... 1-30

.... 1-31

iv Contents

Testing of Outputs of Integration Process

Executable Object Code Complie s with High-Level

Requirements Executable Object Code Is Robust with High-Level

Requirements Executable Object Code Complies with Low-Level

Requirements Executable Object Code Is Robust with Low-Level

Requirements

.................................. 1-34

.................................. 1-35

.................................. 1-36

.................................. 1-37

............ 1-33

Executable Object Code Is Compatible with Target

Computer

...................................... 1-38

Verification of Verification Process Results

Test Procedures Are Correct Test Results Are Correct and Discrepancies Explained Test Cove rage of High-Level Requirements Is Achieved Test Coverage of Low-Level Requirements Is Achieved Test Coverage of Software Structure (Modified

Condition/Decision) Is Achieved

Test Coverage of Software Structure (Decision Coverage) Is

Achieved

Test Coverage of Software Structure ( Statement Coverage)

Is Achieved

Test Coverage of Software Structure (Data Coupling and

Control) Is Achieved

Software Configuration Management Process

Configuration Items Are Identified Baselines and Traceability Are Established Problem Reporting, Change Control, Change Review, and

Configuration Status Accounting Are Established Archive, Retrieval, and Release Are Established Software Load Control Is Established Software Life Cycle Environment Control Is Established

Software Quality Assurance Process

Assurance Is Obtained That Software Development and

Integral Processes Comply with Approved Software

Plans and Standards Assurance Is Obtained That Transition Criteria for the

Software Life Cycle Processes are Satisfied Software Conformity Review Is Completed

...................................... 1-41

.................................... 1-42

......................... 1-40

.................... 1-41

............................. 1-42

................... 1-44

................. 1-45

................ 1-46

............................. 1-46

.......... 1-39

........ 1-43

............ 1-44

........ 1-45

.......... 1-47

............. 1-47

... 1-40

.. 1-40

... 1-41

..... 1-44

.. 1-45

Certification Liaison Process

Communication and Understanding Between the Applicant

and the Certifica tion Authority Is Established The Means of Compliance Is Proposed and Agreement

with the Plan for Software Aspects of Certification is

Obtained Compliance Substantiation Is Provided

...................................... 1-49

....................... 1-48

........ 1-48

................ 1-49

Abbreviations

Abbreviations ..................................... A-2

References

Normative R

eferences

.............................

Index

B-2

vi Contents

DO-178B Software Life Cycle

• “DO-178B Software Life Cycle Overview” on page 1-2

• “Model-Based Design Workflow in DO-178B” on page 1-3

• “Planning Process” on page 1-5

• “Software Development Process” on page 1-10

• “Verification of Requirements Process” on page 1-13

• “Verification of Design Process” on page 1-19

• “Verification of Coding and Integration Process” on page 1-29

• “Testing of Outputs of Integration Process” on page 1-33

• “Verification of Verification Proce ss Results” on page 1-39

• “Software Configuration Management Process” on page 1-43

• “Software Quality Assurance Process” on page 1-46

• “Certification Liaison Process” on page 1-48

1 DO-178BSoftwareLifeCycle

DO-178B Software Life Cycle Overview

The DO-178B software life cycle consists of the following processes:

• Planning

• Software development

• Verification of requirements

• Verification of design

• Verification of coding and integration

• Testing of outputs of integration

• Verification of verification results

• Software configuration management

• Software quality assurance

• Certification liaison process

1-2

There are objectives that must be met for each of the life cycle stages in DO-178B. In Appendix A of DO-178B, these objectives are summarized in tables. This document summarizes those tables and provides recommendations on meeting the objectives using a Model-Based Design process. Available M o del-Based Design tools that can be used in achieving the objectives are also included.

Model-BasedDesignWorkflowinDO-178B

Model-Based Design Workflow in DO-178B

The following diagram shows a Model-Based Design workflow that addresses the d evelopment and verification activities i n a DO-178B software life cycle.

High-level

veriﬁcation

Low-level

veriﬁcation

Code

Coding

Compiling

Requirements

validation

Model

veriﬁcation

Model

conformance

Requirements Model Source code Object code

Modeling

Model traceability Code traceability

Development artifact

Software development activity

Veriﬁcation, validation, or tracing activity

conformance

The following table lists the MathWorks®products and capabilities that can be used in each step of the workflow as Model-Based Design tools.

Workflow Step Available Products and Capabilities for Model-Based Design

uirements

Req

lidation

Modeling

Man

mulink

ual review

,Stateflow

1-3

1 DO-178BSoftwareLifeCycle

Workflow Step Available Products and Capabilities for Model-Based Design

Model traceability

Simulink Interface (RMI), Simulink Description report*

Model conformance Simulink — Model Advisor checks, Real-Time Workshop®— Model

Advisor checks, Simulink Verification and Validation — Model Advisor checks, Simulink Verification and Validation — DO-178B checks*

Model verification SystemTest™ — Limit Check element*, Simulink®Design Verifier™

— Property Proving, Simulink Verification and Validation — M odel Coverage*, Simulink Report Generator — System Design Description report*

Coding Real-Time Workshop®Embedded Coder™

Code traceability Real-Time Workshop Embedded Coder — Traceability Report

Code conformance Polyspace®Products for C/C++*

Code verification Real-Time Workshop Embedded Coder — Code Generation Report

Verification and Validation™ — Requirements Management

Report Generator™ — System Design

Compiling

Embedded IDE Link™

Low-level verification SystemTest — Limit Check element*, Simulink Design Verifier — Test

Generation, Embedded IDE Link, Polyspace Products for C/C++*

High-level verification SystemTest — Limit Check element*, Embedded IDE Link, Polyspace

Products for C/C++*

*The DO Qualification Kit product may be used to support DO-178B tool qualification.

1-4

Planning Process

The following table contains a summary of the planning process objectives from DO-178B, including the objective, applicable DO-178B reference sections, and software levels applicable to the objective. The table also describes the potential impact to the process when using Model-Based Design.

Table A-1: Planning Process

Planning Process

Objective

Software de and integra activities

Transition criteria, inter-relationships and sequencing among processes are defined.

Software life cycle environment is defined.

Additional considerations are addressed.

Software development standards are defined.

Software plans comply with DO-178B.

Software plans are coordinated.

l processes

are defined.

velopment

Sections

4.1a, 4.3

4.1b, 4.3

4.1c

4.1d

4.1e

4.1f, 4.6 A, B, C

1g, 4.6

Software Levels

A, B, C, D

A, B, C

A, B, C, D If applicable to the project and

A, B, C As part of the development

A, B, C

Model-Based Design Process Impact

Must include Model-Based Design as part of the development process.

Must include Model-Based Design transition and sequencing relationships.

Must include Model-Based Design tools in the life cycle p rocess es.

tool qualification, must address any EASA Certification Review Items and FAA Issue Papers. DO Qualification Kit product available for tool qua lification.

standards, must include modeling standards.

No impact

1-5

1 DO-178BSoftwareLifeCycle

The following sections describe in more detail the potential impacts for each planning process objective when using Model-Based Design, if applicable, as compared to traditional development

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 or low-level software requirements, or both. Library or model reference components may be developed and defined as low-level software requirements. The models that use these components to provide full functionality may be defined as high-level software requirements. The following scenarios describe three possible software development processes:

• Scenario 1 – Models developed at the system level are used to generate

code directly

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 so that code can be generated

directly from the models. As a part of t he development process, a predefined

set of library blocks and reusable reference models may b e designed for

systems engineers. These requirements for the library blocks and reference

modelsmaybeconsideredtobederivedsoftwarerequirements,because

they do not trace to the higher-level requirements.

1-6

Under this scenario, the verification objectives from tables A-3 and A-4 are

combined and applied to the single model.

• Scenario 2 – Models developed at the system level are not used directly

to generate code

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 of this type of model is a Simulink

diagram that uses continuous blocks which are not appropriate for

embedded real-time code. The software engineering process takes these

Planning Process

models, modifies them, and adds details as necessary prior to code

generation. These modified models then become the low-level software

requirements.

Under this scenario, the verification objectives from table A-3 are applied

to the high-level model, and the objectivesfromtableA-4areappliedto

the low-level model.

• Scenario 3 – System-level textual requirements are allocated to software

The system-level requirements and design allocated to software a re 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. These models are the low-level software requirements.

Under this scenario, the verification objectives from table A-3 are applied

to the high-level textual requirements, and the objectives from table A-4

are applied to the model.

Address change control and configuration management of the models during the planning process.

Transition Criteria, Inter-Relationships, and Sequencing Among Processes are Defined

When Model-Based Design begins, it must be defined. This stage is when the higher-level requirements (either system requirements or high-level softw are requirements) are developed, configured, and approved.

When code is generated, the code must be define d. This stage is when the models have been developed, configured, and approved. The steps to approve the models as complete and correct must be defined and may include model:

• Reviews

• Simulation testing

• Static analysis

• Dynamic analysis

1-7

1 DO-178BSoftwareLifeCycle

Software Life-Cycle Environment Is Defined

Model-Based Design tools used in the development and verification processes must be defined. The tools may include the MATLAB Stateflow Coder, Polyspace products for C/C++, Simulink Verification an d Validation, Simulink Design Verifier, SystemTest, and Simulink Report Generator products.

Additional Considerations are Addressed

If any Model-Based Design tools are qualified as development or verification tools, each of the tools to be qualified must be identified and the tool qualification activities must be defined. The DO Qualification Kit product may be used in the qualification of MathWorks verification tools.

When Model-Based Design is used o n a program, the Federal Aviation Administration (FAA) provides an Issue Paper (IP), or, for the European Aviation Safety Agency (EAS A) , a Certification Review Item (CR I). Items in the program-specific IP and CRI must be addressed during planning. There may be requirements to trace the models to higher-level requirements andtotracethecodetothemodels. Verificationofthemodelsand executable object code against the higher-level requirements may also be addressed. For software levels A and B, independence of the model and test developers may need to be ensured as part of the verification against the higher-level requi rem e nts. If an automated tool verifies 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 verification of the executable object code against the higher-level requirements. The automated verification tool may only be used to supplement the higher-level requirements-based tests.

Coder™, Real-Time Workshop, Real-Time Workshop Embedded

, Simulink, Stateflow,

1-8

Software Development Standards are Defined

Becausethemodelsmaybemappedtohigh-level or low-level requirements, or both (see “Software Development an d Integral Processes Activities are Defined” on page 1-6), modeling standards must be in place to satisfy the requirements s tandards objectives. Compliance to the standards have to be verified through the use of tools and human reviews.

Planning Process

For the Real-Time Workshop Em be dded Coder tool, MISRA C

coding standards can be used, with a few minor exceptions. Some constructs in the generated code, such as naming conventions, can be controlled by users to meet specific customer coding standards. Compliance to the standards must be verified through tools and human reviews.

Software Plans Comply with DO-178B

A Plan for Software Aspects of Certification (PSAC) must be developed, the same as for traditional development programs.

Software Plans are Coordinated

The Plan for Software Aspects of Certification (PSAC) must be configured under change control and approved by the applicable certification authorities as part of the program, as in a traditional development process.

he Motor Industry Software Reliability Association. MISRA-C:2004 Guidelines for the

1.T use of the C language in critical systems. MIRA Limited, 2004.

1-9

1 DO-178BSoftwareLifeCycle

Software Development Process

Thefollowingtablecontainsasummaryof the software development process objectives from DO-178B, including the objective, applicable DO-178B reference sections, and software levels applicable to the objective. The table also describes the available Model-Based Design tools for satisfying the objectives.

Table A-2 Software Development Process

Objective

High-level requirements are developed.

Derived high-level requirements are developed.

Software architecture is developed.

Low-level requirements are developed.

Derived low-level requirements are developed.

Source code is developed.

Executable Object Code is produced and integrated in the target computer.

The following sections describe in more detail the potential impacts for each software development process objective when using Model-Based Design, if applicable, as compared to traditional development.

Sections

5.1.1a

5.1.1b

5.2.1a

5.2.1b

5.3.1a

Software Levels

A, B, C, D Simulink, Stateflow

A, B, C, D

Available Products for Model-Based Design

Real-Time Workshop, Real-Time Workshop Embedded Coder, Stateflow Coder

Embedded IDE Link

1-10

Software Development Process

High-Level Requ

If models are def and Stateflow pr requirements. blocks or State requirements should be deve during the pla

Derived High

If models ar Stateflow c identified provided t

Software A

Architec and State element model de softwar

ture of individual software modules may be defined by the Simulink

flow models, including sequencing and interfacing of the various

s w ithin the models. If model reference capability is used, then the

pendency viewer may be used to document the architecture of the

e m odules that are integrated using this capability.

ined as high-level software requirements, then the Simulink

oducts may be used to develop the high-level software

The components within these models, such as Simulink

flow objects, would then trace to the appropriate system-level

, which are developed in accordance with ARP4754

loped in accordance with the modeling standards defined

nning process.

-Level Requirements are Developed

e defined as high-level software requirements, any Simulink or

omponents that do not trace to the system requirements would be as derived requirements. These derived requirements would be o the safety assessment process.

rchitecture Is Developed

irements are Developed

.Themodels

The hig code in This ma calli data i

Low-

If mo and S requ the

AE International. Certification Considerations for Highly-Integrated O r Complex

2.S Aircraft Systems, 1996.

her-level architecture of how the Model-Based Design generated

terfaces to other code within the system must be defined separately.

yincludeaninterfacetothereal-timeoperatingsystem(RTOS),

ng sequence for the code generated from the Model-Based Design, and

nterface to other code modules.

Level Requirements are Developed

dels are defined as low-level software requirements, then the Simulink

tateflow products may be used to dev elop the low-level software

irements. The components within these models would then trace to

appropriate high-level s oftw are requirements. The models should be

1-11

1 DO-178BSoftwareLifeCycle

developed in accordance with the modeling standards defined during the planning process.

If the models are defined as h igh-level software requirements and source code is generated directly from those models, this objective does not apply.

Derived Low-Level Requirements are Developed

If models are defined as low-level s of tware requirements, then any Simulink or Stateflow components that do not tracetothehigh-levelsoftware requirements would be identified as derived requirements. These derived requirements would be p rovided to the safety assessment process.

If the models are defined as high-level software requirements, library components or reusable model reference functions may be considered to be low-level derived requirements.

Source Code Is Developed

Real-Time Workshop Embedded Coder and Stateflow Coder products may be used to generate the source code from the model. The source code can trace to the model components through the use of appropriate commenting options. The source code can be generated in accordance with MISRA C standards, with some exceptions, using appropriate modeling standards.

1-12

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 the Embedded IDE Link product.

Alternatively, the generated source code may be compiled and linked using standard compilers and linkers. The make file that the compiler uses may be generated by the Real-Time Workshop Embedded Coder product or developed manually. The executable object code is then loaded onto the target computer.

Verification of Requirements Process

The following tab le contains a summary of the verification of requirements process objectives from DO-178B, including the objective, applicable DO-178B reference sections, and software levels applicable to the objective. The table also provides the available Model-Based Design tools that ma y be used in satisfying the objectives.

Table A-3 Verification of Requirements Process

Verifica tion of Requirements Process

Objective

Software high-level requirements comply with system requirements.

High-level requirements are accurate and consistent.

High-level requirements are compatible with the target computer.

High-level requirements are verifiable.

High-level requirements conform to standards.

Sections

6.3.1a

6.3.1b

6.3.1c

6.3.1d

.1e

6.3

Software Levels

A, B, C, D Simulink Verification and

A, B Simulink Verification and

A, B, C Simulink Verification and

Available Products for Model-Based Design

Validation, Simulink Design Verifier, SystemTest, Simulink Report Generator, DO Qualification Kit

Validation, SystemTest, Simulink Report Generator, DO Qualification Kit

Validation, Sim ulink Report Generator, DO Qualification Kit

Validation, Simulink Design Verifier, SystemTest, Simulink Report Generator, DO Qualification Kit

Validation, Sim ulink Report Generator, DO Qualification Kit

1-13

1 DO-178BSoftwareLifeCycle

Table A-3 Verification of Requirements Process (Continued)

Objective

High-level requirements are traceable to system requirements.

Algorithms are accurate.

Sections

6.3.1f A, B, C, D Simulink Verification and

6.3.1g

The following sections describe in more detail the potential impacts for each of the verification of requirements process objectives when using Model-Based Design, if applicable, as compared to traditional development.

Software Levels

A, B, C Simulink Verification and

Available Products for Model-Based Design

Validation, Sim ulink Report Generator, DO Qualification Kit

Validation, SystemTest, Simulink Report Generator, DO Qualification Kit

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. The Simulink Report Generator product may be used to generate a System Design Description report that includes a trace report to the system requirements. The SystemTest and Simulink Verification and Validation products may be used to develop test cases based on the system requirements, and execute those test cases on the model to assist in verifying that the system requirements are satisfied. The Simulink Design Verifier product may be u sed to prove properties of the model to assist in verifying certain system requirements are satisfied.

1-14

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• When used for pass and fail determination, the Limit Check element in the

SystemTest product.

• System Design Description report in the Simulink Report Generator

product.

Verifica tion of Requirements Process

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 o f model reviews and simulation. The Simulink Report Generator product may be used to generate a System Design Description report that includes a trace report to the higher-level requirements. The SystemTest and Simulink Verification and Validation products may be used to develop and execute test cases based on the system requirements to assist in verifying the accuracy and consistency. The Model Advisor may be used to assist in verifying that the diagnostic settings used by the Simulink product are appropriate for simulation and also to verify the proper usage of certain Simulink blocks.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• When used for pass and fail determination, the Limit Check element in the

SystemTest product.

• DO-178B checks in the Simulink Verification and Validation product.

• System Design Description report in the Simulink Report Generator

product.

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. The Simulink Report Generator product may be used to generate a System Design Description report that includes a trace report to the higher-level requirements. The Model Advisor may be used to assist in verifying that the hardware interface settings used by the Real-Time Workshop Embedded Coder product are appropriate for the target processor.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

1-15

1 DO-178BSoftwareLifeCycle

• DO-178B checks in the Simulink Verification and Validation product.

• System Design Description report in the Simulink Report Generator

product.

High-Level Requirements Are Verifiable

If models are defined as high-level software requ i rements, verification m ay be accomplished using a combination of model reviews and simulation. The Simulink Report Generator product may be used to generate a System Design Description report that includes a trace report to the higher-level requirements. The SystemTest and Simulin k Verification and Validation products may 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 Simulink Verification and Validation model coverage report may be generated to assist in verifying that all requirem ents are fully verified. The coverage report may assist in finding conditions and decisions in the model that cannot be reached, indicating that the requirements may not be fully verifiable. The Simulink Design Verifier product maybeusedtoidentifyuntestable or unreachable model conditions and decisions using test case generation, indicating that the high-level requirements may not be fully verifiable. The ModelAdvisormaybeusedtoassistinverifyingtheproperusageofcertain Simulink blocks and data types.

1-16

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• When used for pass and fail determination, the Limit Check element in the

SystemTest product.

• DO-178B checks in the Simulink Verification and Validation product.

• Model coverage in the Simulink Verification and Validation product.

• System Design Description report in the Simulink Report Generator

product.

Verifica tion of Requirements Process

High-Level Requirements Conform to Standards

If models a r e defined as high-level software requirements, conformance to standards may be accomplished using a combination of model reviews and Model Advisor checks. The Simulink Report Generator product may be used to generate a System Desig n Description report that includes a trace report to the higher-level requirements. The Model Advisor may verify predefined model standards, and may be customized using an API to perform checks defined by the user that may be unique to their application.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• DO-178B checks in the Simulink Verification and Validation product.

• Custom checks added by the user, but the user is responsible for defining

the Tool Operational Requirem ents, Test C ases, Procedures, and Expected Results for those custom checks.

• System Design Description report in the Simulink Report Generator

product.

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 (RMI), a capability of the Simulink Verification and Validation product. The Simulink Report Generator product may be used to generate a System Design Description report that includes a trace report to the system requirements. The Model Advisor may be used to assis t in verifying that requirements links are consistent, and can identify model components that do not trace to requirements.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• DO-178B checks in the Simulink Verification and Validation product.

1-17

1 DO-178BSoftwareLifeCycle

• System Design Description report in the Simulink Report Generator

product.

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. The Simulink Report Generator product may be used to generate a System Design Description report that includes a trace report to the higher-level requirements. The SystemTest and Simulink Verification and Validation products may be used to develop test cases from the system requirements and execute those test cases on the model, 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 Simulink blocks and data types.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

1-18

• When used for pass and fail determination, the Limit Check element in the

SystemTest product.

• DO-178B checks in the Simulink Verification and Validation product.

• System Design Description report in the Simulink Report Generator

product.

Verification of Design Process

The following table contains a summary of the verification of desi gn process objectives from DO-178B, including the objective, applicable DO-178B reference sections, and software levels applicable to the objective. The table also describes the available Model-Based Design tools for satisfying the objectives.

Table A-4 Verification of Design Process

Verification of Design Process

Objective

Low-level requirements comply with high-level requirements.

Low-level requirements are accurate and consistent.

Low-level requirements arecompatiblewiththe target computer.

Low-level requirements are verifiable.

Low-level requirements conform to standards.

Low-level requirements are traceable to high-level requireme n ts .

Sections

6.3.2a

6.3.2b

6.3.2c

6.3.2d

.2e

6.3

6.3.2f A, B, C Simulink Verification a n d

Software Levels

A, B, C Simulink Verification and

A, B Simulink Verificatio n and

A, B, C Simulink Verification and

Available Products for Model-Based Design

Validation, Simulink Design Verifier, SystemTest, Simulink Report G enerator, DO Q ualification Kit

Validation, SystemTest, Simulink Report G enerator, DO Q ualification Kit

Validation, Simulink Report Generator, DO Qualificatio n Kit

Validation, Simulink Design Verifier, SystemTest, Simulink Report G enerator, DO Q ualification Kit

Validation, Simulink Report Generator, DO Qualificatio n Kit

1-19

1 DO-178BSoftwareLifeCycle

Table A-4 Verification of Design Process (Continued)

Objective

Algorithms are accurate.

Software architecture is compatible with high-level requireme n ts .

Software architecture is consistent.

Software architecture is compatible with the target computer.

Software architecture is verifiable.

Software architecture conforms to standards.

Software partitioning integrity is confirmed.

Sections

6.3.2g

6.3.3a

6.3.3b

6.3.3c

6.3.3d

6.3.3e

6.3.3f A, B, C, D

Software Levels

A, B, C Simulink Verification and

A, B, C Simulink Report Generator

A, B, C Simulink Verification and

A, B Simulink Verificatio n and

A, B, C Simulink Verification and

Available Products for Model-Based Design

Validation, SystemTest, Simulink Report G enerator, DO Q ualification Kit

Validation, Simulink Report Generator, DO Qualificatio n Kit

pplicable

Not a

1-20

following sections describe in more detail the potential impacts for each of

The

verification of design process objectives when using Model-Based Design,

the

pplicable, as compared to traditional development.

if a

w-Level Requirements Comply with High-Level

quirements

models are def ined as low-level software requirements, compliance with

igh-level s oftw are requirements may be accomplished using a combination

Verification of Design Process

of model reviews, model analysis, and simulation. The Simulink Report Generator product may be used to generate a System Design Description report that includes a trace report to the system requirements. The SystemTest and Simul in k Verification and Va li dation products may be used to develo p test cases from the high-level requirements and execute those test cases on the model to assist in verifying that the high-lev el requirements are satisfied. The Simulink Design Verifier product may be used to prove properties of the model in order to assist in verifying certain high-level requirements are satisfied.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• When used for pass and fail determination, the Limit Check element in the

SystemTest product.

• System Design Description report in the Simulink Report Generator

product.

If the models are defined as high-level software requirements, code may be generated directly from the high-level requirements, and this objective does not apply. For details, see DO-178B, Section 6.1.b.

Low-Level Requirements Are Accurate and Consistent

If models are defined as low-level software requirements, accuracy and consistency may be verified using a combination o f model reviews and simulation. The Simulink Report Generator product may be used to generate a System Design Description report that includes a trace report to the higher-level requirements. The SystemTest and Simulink Verification and Validation products may be used to develop test cases from the high-level requirements, a nd execute those test cases on the model to assist in verifying the accuracy and consistency. The ModelAdvisormaybeusedtoassistin verifying the diagnostic settings used by the Simulink product are appropriate for simulation, and also to verify the proper usage of certain Simulink blocks.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

1-21

1 DO-178BSoftwareLifeCycle

• When used for pass and fail determination, the Limit Check element in the

SystemTest product.

• DO-178B checks in the Simulink Verification and Validation product.

• System Design Description report in the Simulink Report Generator

product.

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. The Simulink Report Generator product may be used to generate a System Design Description report that includes a trace report to the higher-level requirements. The Model Advisor may be used to assist in verifying that the hardware interface settings used by the Real-Time Workshop Embedded Coder product are appropriate for the target processor.

1-22

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• DO-178B checks in the Simulink Verification and Validation product.

• System Design Description report in the Simulink Report Generator

product.

Verification of Design Process

Low-Level Requirem ents Are Verifiable

If models are defined as low-level software requirements, verifiability may be accomplished using a combination of model reviews and simulation. The Simulink Report Generator product may be used to generate a System Design Description report that includes a trace report to the higher-level requirements. The SystemTest and Simulin k Verification and Validation products may be use d to develop test cases from the high-level re quireme nts, and execute those test cases on the model. During execution of these test cases, a Simulink Verification and Valida tion model coverage report may be generated to assist in verifying that all requirements are fully verified. T he coverage report may assist in finding conditions and decisions in the model that cannot be reached, indicating that the design may not be fully verifiable. The Simulink Design Verifier product maybeusedtoidentifyuntestable or unreachable model conditions and decisions using test case generation, indicating that the low-level requirements may not be fully verifiable. The ModelAdvisormaybeusedtoassistinverifyingtheproperusageofcertain Simulink blocks and data types.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• When used for pass and fail determination, the Limit Check element in the

SystemTest product.

• DO-178B checks in the Simulink Verification and Validation product.

• Model coverage in the Simulink Verification and Validation product.

• System Design Description report in the Simulink Report Generator

product.

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

1-23

1 DO-178BSoftwareLifeCycle

Model Advisor checks. The Simulink Report Generator product may be used to generate a System Desig n Description report that includes a trace report to the higher-level requirements. The Model Advisor may be used to verify predefined model standards and may also be customized to perform checks defined by the user that are unique for their application.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• DO-178B checks in the Simulink Verification and Validation product.

• Custom checks added by the user, but the user is responsible for defining

the Tool Operational Requirem ents, Test C ases, Procedures, and Expected Results for those custom checks.

• System Design Description report in the Simulink Report Generator

product.

1-24

If the models are defined as high-level software requirements, then code may be generated directly from the high-level requiremen ts and this objective does not apply. For details, see DO-178B, Section 6.1.b.

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 (RMI). The Simulink Report Generator product maybeusedtogenerateaSystemDesign Description report 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.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• DO-178B checks in the Simulink Verification and Validation product.

Verification of Design Process

• System Design Description report in the Simulink Report Generator

product.

Algorithms Are Accurate

If models are defined as low-level software requirements, accuracy of the algorithms may be verified using a combination of model reviews and simulation. The Simulink Report Generator product may be used to generate a System Design Description report that includes a trace report to the higher-level requirements. The SystemTest and Simulink Verification and Validation products may be used to develop test cases from the high-level requirements, and execute those test cases on the model, 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 Simulink blocks and data types.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• When used for pass and fail determination, the Limit Check element in the

SystemTest product.

• System Design Description report in the Simulink Report Generator

product.

1-25

1 DO-178BSoftwareLifeCycle

Software Architecture Is Compatible with High-Level Requirements

Compatibility of the software archite cture within the models m ay be verified using model reviews. The Simulink Report Generator product may be used to generate a System Design Description repo rt. The Model Dependency Viewer in the Simulink product can show the architecture of reference models and library blocks.

The System Design Description report capability in the Simulink Report Generator product may be qualified as a verif ication tool using the DO Qualification Kit product.

The higher-level softw are architecture, which includes the real-time operating system (RTOS) and other code, may be verified using traditional methods.

Software Architecture Is Consistent

Consistency of the software architecture within the models may be verified using model reviews. The Simulink Report Generator product may be used to generate a System Design Description repo rt. The Model Dependency Viewer in the Simulink product can show the architecture of reference models and library blocks. The Model Advisormaybeusedtoassistinverifying the diagnostic settings used by the Simulink product are appropriate for simulation, and also to verify the proper use of certai n Simulink blocks.

1-26

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• DO-178B checks in the Simulink Verification and Validation product.

• System Design Description report in the Simulink Report Generator

product.

The higher-level software architecture, which includes the RTOS and other code, may be verified using traditional methods.

Verification of Design Process

Software Architecture Is Compatible with the Target Computer

Target compatibility of the software architecture within the models may be verified using model reviews. The Simulink Report Generator product may be used to generate a System Design Description report. The Model Advisor may be used to verify that the hardware interface settings used by the Real-Time Workshop Embedded Coder product are appropriate for the target processor.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• DO-178B checks in the Simulink Verification and Validation product.

• System Design Description report in the Simulink Report Generator

product.

The higher-level software architecture, which includes the RTOS and other code, may be verified using traditional methods.

Software Architecture Is Verifiable

Verification of the software architecture may be accomplished using a combination of model reviews and simulation. The Simulink Report Generator product may be used to generate a Sy stem Design Description report. The SystemTest and Simul in k Verification and Va li dation products 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 condi tions and decisions in the model architecture that cannot be reached, indicating that the software architecture may not be fully verifiable.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

• When used for pass and fail determination, the Limit Check element in the

SystemTest product.

1-27

1 DO-178BSoftwareLifeCycle

• Model coverage in the Simulink Verification and Validation product.

• System Design Description report in the Simulink Report Generator

product.

The higher-level software architecture, which includes the RTOS and other code, may be verified using traditional methods.

Software Architecture Conforms to Standards

Conformance to standards may be accomplished using a combination of model reviews and Model Advisor checks. The Simulink Report Generator p roduct may be used to generate a System Design Description report. The Model Advisor may be used to verify predefined model standards, and may also be customized to perform checks defined by the user that are unique for their application.

The following capabilities may be qualifie d as a verification t ool using the DO Qualification Kit product:

1-28

• DO-178B checks in the Simulink Verification and Validation product.

• Custom checks added by the user, but the user is responsible for defining

the Tool Operational Requirem ents, Test C ases, Procedures, and Expected Results for those custom checks.

• System Design Description report in the Simulink Report Generator

product.

The higher-level software architecture, which includes the RTOS and other code, may be verified using traditional methods.

Software Partitioning Integrity Is Confirmed

Because partitioning is outside of the scope of Model-Based Design, partitioning may be verified using traditional meth ods.

Verific ation of Coding and Integration Process

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 the objective, applicable DO-178B reference sections, and software levels applicable to the objective. The table also describes the available Model-Based Design tools for satisfying the objectives.

Table A-5 Verification of Coding and Integration Process

Objective

Source code complies with low-level requirements.

Source code complies with software architecture.

Source code is verifiable.

Source stand

Source code is traceable to low-level requirements.

Source code is accurate and consistent.

ntegration process is

omplete a nd correct.

code conforms to

ards.

tput of software

Sections

6.3.4a

6.3.4b

6.3.4c

6.3.4d

6.3.

6.3.4f A, B, C

6.3.5

Software Levels

A, B, C

A, B

A, B, C

B, C

Available Products for Model-Based Design

Real-Time Workshop Embedded Coder

Real-Time Workshop Embedded Coder, Polyspace, DO Qualification Kit

Real-Ti Coder, P Kit

Real-Time Workshop Embedded Coder, Polyspace, DO Qualification Kit

Real-Time Workshop Embedded Coder, Simulink Verification and Validation, DO Qualification Kit

Rea Co Ki

Not applicable

me Workshop Embedded

olyspace, DO Qualification

l-Time Workshop Embedded

der, Polyspace, DO Qualification

1-29

1 DO-178BSoftwareLifeCycle

The following sections describe in more detail the potential impacts for each of the verifica t ion of coding and inte gration process obj ectives when us in g Model-Based Design, if applicable, as compared to traditional development.

Source Code Complies with Low-Level Requirements

Compliance to low -level requirements may be verified using code reviews. The Real-Time Workshop Embedded Coder product produces a code generation report that may assist in code reviews by providing traceability from the code to the models, including hyperlinks to the objects in the models.

Source Code Complies with Software Architecture

Compliance to software architecture may be verified using code reviews. The Real-Time Workshop Embedded Coder product produces a code generation report that may assist in code reviews by providing traceability from the code to the models, including hyperlinks to the objects in the models. The Polyspace products for C /C++ can assist in the identif ica tion of data -f low and control-flow errors.

1-30

The Polyspace products for C/C++ may be qualified as a verification tool using the DO Q ualification Kit product.

Source Code Is Verifiable

Verifiability of the code may be verified using code reviews. The Real-Time Workshop Embedded Coder product produces a code generation report that may assist in code reviews by providing traceability from the code to the models, including hyperlinks to the objects in the models. The Polyspace products for C/C++ can assist in the identification of unreachable, and therefore nonverifiable, code.

The Polyspace products for C/C++ work with the Simulink product, allowing errorsidentifiedinthecodetobetraced to the corresponding model blocks.

The Polyspace products for C/C++ may be qualified as a verification tool using the DO Q ualification Kit product.

Verific ation of Coding and Integration Process

Source Code Conforms to Standards

Standards compliance of source code may be verified using the MISRA C checker in the Polyspace products for C/C++. The MISRA C checker works with the Simulink product.

The Polyspace products for C/C++ may be qualified as a verification tool using the DO Q ualification Kit product.

Source Code Is Traceable to Low-Level Requirements

Traceability of source code to low-level requirements may be verified using code reviews. The Real-Time W orksh op Embedded Coder product produces a code generation report that may assist in code reviews by providing traceability from the code to the models, including hyperlinks to the objects in the models. The Model Advisor may be used to assist in verifying the commenting settings used by the Real-Time Workshop Embedded Coder product are appropriate for tracing the source code to the models.

The DO-178B checks in the Simulink Verification and V alidation product may be qualified as a verification tool using the DO Qualification Kit product.

Source Code Is Accurate and Consistent

Accuracy and consistency of source code may be verified using code reviews. The Real-Time Workshop Embedded Coder product produces a code generation report that may assist in code reviews by providing traceability from the code to the models, including hyperlinks to the objects in the models.

The Polyspace products for C/C++ have the capability to id entify run-time errors, such as potential underflow, overflow, divide by zero, etc. The Polyspace products for C/C++ also have the capability to detect uninitialized variables and constants.

The Polyspace products for C/C++ may be qualified as a verification tool using the DO Q ualification Kit product.

1-31

1 DO-178BSoftwareLifeCycle

Output of Software Integration Process Is Complete and Correct

Because the integration process is outside of the scope of Model-Based Design, the integration process may be verified using traditional methods.

1-32

Testing of Outputs of Integration Process

Thefollowingtablecontainsasummaryofthe testing of outputs of integration process objectives from DO-178B, including the objective, applicable DO-178B reference sections, and software levels applicable to the objective. The table also describes the available Model-Based Design tools for satisfying the objectives.

Table A-6 Testin g of Ou tp uts of Integration Process

Testing of Outputs of Integration Process

Objective

Executable Object Code complies with high-level requirements.

Executable Object Code is robust with high-level requirements.

Executable Object Code complies with low-level requirements.

Executable Object Code is robust with low-level requirements.

Executable Object Code is compatible with target computer.

Sections

6.4.2.1,

6.4.3

6.4.2.2,

6.4.3

6.4.2.1

6.4.3

6.4.2.

6.4.3

The following sections describe in more detail the potential impacts for each testing of outputs of integration process objective when using Model-Based Design, if applicable, as compared to traditional development.

Software Levels

A, B , C, D SystemTest, Embedded

A, B, C SystemTest, Simulink Design

A, B , C, D

Available Products for Model-Based D esign

IDE Link, Polyspace, DO Qualification Kit

Verifier, Embedded IDE Link, Polyspace, DO Qualification Kit

Embedded IDE Link

1-33

1 DO-178BSoftwareLifeCycle

Executable Obje Requirements

Theexecutableo areusedtoveri using the Syst test can be log

The executabl the Embedded execute thes

When used fo capability tool using t

The Polysp verifying by the Pol dynamic t

The Poly

• Uniniti

• Parame

the source code using abstract interpretation. Some errors detected

yspace products for C/C++ may not be detected during traditional esting.

space products for C/C++ helptoexhaustivelyidentify:

alized variables

bject code m ay be verified by reusing the same test cases that

fy the models. During execution of the model verification tests,

emTest product, the inputs and outputs of each model under

ged and saved for use in verifying the executable object code.

e object code may be tested on a target processor or DSP using

IDE Link product. The SystemTest product may be used to

e tests and compare the test results to expected results.

r pass and fail determination, the Limit Check element

within the SystemTest product may be qualified as a verification

he DO Qualification Kit product.

ace products for C/C++ may also be used to satisfy this objective by

ter passing errors

ct Code Complies with High-Level

1-34

• Data co

• Inadeq

• Detec

The P

• Inco

• Inc

or o

• Glo

rruption, especially global data

uate, end-to-end numerical resolution

tion of arithmetic faults

tion of violation of array limits

olyspace products for C/C++ help to partially identify:

rrect initialization of variables and constants

orrect initialization of variables and constants leading to an underflow

verflow

bal data corruption of shared variables w ithout protection mechanism

Testing of Outputs of Integration Process

• Incorrect sequencing of events and operations

• Detection of loops leading to run-time error

• Detection of incorrect logic decision leading to irrefutable dead code or

run-time errors

The Polyspace products for C/C++ may be qualified as a verification tool using the DO Q ualification Kit product.

Executable Object Code Is Robust with High-Level Requirements

Robustness tests should be developed against the models and may be done using the SystemTest product. The robustness of the executable object codemaybeverifiedbyreusingthesametestcasesthatareusedtoverify robustness of the models. During execution of the model verification tests, using the SystemTest product, 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 the Embedded IDE Link product. The SystemTest product may be used to execute these tests and compare the test results to expected results.

When used for pass and fail determination, the Limit Check element capability within the SystemTest product may be qualified as a verification tool using the DO Qualification Kit product.

ThePolyspaceproductsforC/C++mayalsobeusedtosatisfythisobjectiveby verifying the source code using abstract interpretation. Some of the errors detected by the Polyspace products for C/C++ may not be de te cted during traditional dynamic testing.

The Polyspace products for C/C++ help to partially identify:

• Incorrect initialization of variables and constants

• Incorrect initialization of variables and constants leading to an underflow

or overflow

• Detection of loops leading to run-time error

1-35

1 DO-178BSoftwareLifeCycle

• Detection of overflows

• Detection of certain run-time errors

The Polyspace products for C/C++ may be qualified as a verification tool using the DO Q ualification Kit product.

Executable Object Code Complies with Low-Level Requirements

The Simulink Design Verifier product m a y be used to generate low-level tests from the model. These test cases can be runonthemodelandtheexecutable object code, and the results compared. The comparison is used to demonstrate that the executable object code complies with the low-level requirements.

When used for pass and fail determination, the Limit Check element capability within the SystemTest product may be qualified as a verification tool using the DO Qualification Kit product.

1-36

The Polyspace products for C/C++ help to exhaustively identify:

• Uninitia lized variables

• Parameter passing errors

• Data corruption, especially global data

• Inadequate, end-to-end numerical resolution

• Detection of arithmetic faults

• Detection of violation of array limits

The Polyspace products for C/C++ help to partially identify:

Testing of Outputs of Integration Process

• Incorrect initialization of variables and constants

• Incorrect initialization of variables and constants leading to an underflow

or overflow

• Global data corruption of shared variables without protection mechanism

• Incorrect sequencing of events and operations

• Detection of loops leading to run-time error

• Detection of incorrect logic decision leading to irrefutable dead code or

run-time errors

The Polyspace products for C/C++ may be qualified as a verification tool using the DO Q ualification Kit product.

Alternatively, verification against the low-level requirements may be eliminated, if requirements base d coverage and structural coverage are achieved using the high-level requirements based tests (for example, software integration tests). The followi ng 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 low-level tests for high-level tests may be less effective due to the reduced amount of overall functionality tested.

Executable Object Code Is Robust with Low-Level Requirements

The Simulink Design Verifier product may be used to generate robustness tests from the model. These test cases can be run on the model and the executable object code, and the results compared. The comparison demonstratesthattheexecutableobjectcodeisrobustwiththelow-level requirements. For robustness test cases, Tes t Condition and Test Objective blocks may be used to assist in the definition o f test cases that exercise the object code outside of normal boundary conditions.

1-37

1 DO-178BSoftwareLifeCycle

When used for pass and fail determination, the Limit Check element capability within the SystemTest product may be qualified as a verification tool using the DO Qualification Kit product.

The Polyspace products for C/C++ help to partially identify:

• Incorrect initialization of variables and constants

• Incorrect initialization of variables and constants leading to an underflow

or overflow

1-38

• Detection of loops leading to run-time error

• Detection of overflows

• Detection of certain run-time errors

The Polyspace products for C/C++ may be qualified as a verification tool using the DO Q ualification Kit products.

Executable Object Code Is Compatible with Target Computer

The executable object code may be evaluated for stack usage, memory usage, and execution time on a target processor or DSP using the Embedded IDE Link product.

Other aspects of hardware compatibility such as interrupt handling, resource contention, hardware interfaces, partitioning, etc., must be verified using traditional methods.

Verification of Verification Process Results

The following table contai ns a summ ary of the verification of verification process results objectives from DO-178B, including the objective, applicable DO-178B reference sections, and software levels applicable to the objective. The table also describes the available Model-Based Des ig n tools that may be used in satisfying the objectives.

Table A-7 Verification of Verification Process Results

Verification of Verification Process Results

Objective

Test procedures are correct. 6.3.6b

Test results are correct and discrepancies explained.

Test coverage of high-level requirements is achieved.

Test coverage of low-level requirements is achieved.

Test coverage of software structure (modified condition/decision) i s achieved.

Test coverage of software structure (decision coverage) is achieved.

Test coverage of software structure (statement coverage) is achieved.

Test coverage of software structure (data coupling and control) is achieved.

Sections

6.3.6c

6.4.4.1

6.4.4.2

6.4.4.2a,

6.4.4.2b

6.4.4.2a,

6.4.4.2b

6.4.4.2c

Software Levels

A, B, C Simulink Verification and

A, B, C SystemTest

A, B, C, D Simulink Verification and

A, B, C Simulink Verification and

A, B

A, B, C

Available Products for Model-Based Design

Validation

Not ap

Not a

Not

plicable

pplicable

applicable

t applicable

1-39

1 DO-178BSoftwareLifeCycle

The following sections describe in more detail the potential impacts for each of the verification of verification process results objective when using Model-Based Design, if applicable, as compared to traditional development.

Test Procedures Are Correct

Correctness of the test procedures from the higher-level requirements may be verified by reviewing the test procedures. The Simulink Verification and Validation product may assist in test procedure reviews by providing traceability from the test cases to the requirements, including hyperlinks to the requirements in the higher-level requirements document.

Completeness of the test cases generated by the Simulink Design Verifier product may be verified by executing the test cases on the Simulink model while measuring model coverage d uring simulation. The expected results produced by Simulink may be verified by reviewing the results.

The model coverage capability in the Simulink Verification and Validation product may be qualified as a verification tool using the DO Qualification Kit product.

1-40

Test Results Are Correct and Discrepancies Explained

Correctness of the test results may be verified by reviewing the test results. As an alternative, 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 and fail status of the results.

Test Coverage of High-Level Requirements Is Achieved

Test coverage of high-level software requirements may be verified by reviewing the test cases and traceability to the high-level requirements. The Simulink Verification and Validation product can be u sed to trace the test cases to the high-level requirements,providingthecapability to assist in verifying that each requirement has associated test cases.

Verification of Verification Process Results

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.

The model coverage capability in the Simulink Verification and Validation product may be qualified as a verification tool using the DO Qualification Kit product.

Test Coverage of Software Structure (Modified Condition/Decision) Is Achieved

Modified condition and decision coverage of the software structure m ay be verified using a commercial, off-the-shelf structural coverage analysis tool. This analysis is accomplished during the execution of the requirements based tests described in “Executable Object Code Complies with High-Level Requirements” on page 1-34.

If requirements-base d test cases are developed at the model level and reused for testing of the executable object code, the model coverage capability of the Simulink Verification and Validation product may be used during development of the requirements based test cases. Using the capability helps predict the effectiveness of the test cases in providing structural coverage for the generated code.

Test Coverage of Software Structure (Decision Coverage) Is Achieved

Decision coverage of the software structure may be verified using a commercial, off-the-shelf structural coverage analysis tool. This analysis is accomplished during the e xecution of the requirements based tests described in “Executable Object Code Complies with High-Level Requirements” on page 1-34.

If requirements-base d test cases are developed at the model level and reused for testing of the executable object code, the model coverage capability may be used during development of the requirements based test cases. Using the

1-41

1 DO-178BSoftwareLifeCycle

tool helps predict the effectiveness of the test cases in providing structural coverage for the generated code.

Test Coverage of Software Structure (Statement Coverage) Is Achieved

Statement coverage of the software structure may be verified using a commercial, off-the-shelf structural coverage analysis tool. This analysis is accomplished during the e xecution of the requirements based tests described in “Executable Object Code Complies with High-Level Requirements” on page 1-34.

If requirements-base d test cases are developed at the model level and reused for testing of the executable object code, then the model cov erage capability may be used during development of the requirements based test cases. Using the tool helps predict the effectiveness of the test cases in providing structural coverage for the generated code.

1-42

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 using Model-Based Design, data coupling and control may be verified using traditional methods. The test coverage for data coupling and control involves verification of the data interfaces to and from the automatically generated code and the calling sequence of the automatically generated code in relation to other code modules.

Software Configuration Management Process

Thefollowingtablecontainsasummary of the configuration management process objectives from DO-178B, including the objective, applicable DO-178B reference sections, and software levels applicable to the objective. The table also describes the potential impact to the process when using Model-Based Design.

Table A-8 Softw are Configuration Man age m ent Process

Objective

Configuration items are identified.

Baselines and traceability are established.

Problem reporting, change control, change review, and configuration status accounting are established.

Archive, retrieval, and release are established.

ware load control

Soft

tablished.

is es

twarelifecycle

Sof

ironment control

env

stablished.

is e

Sections

7.2.1

7.2.2

7.2.3, 7

7.2.5, 7

7.2.7

7.2.8

7.2.9

.2.6

.2.4,

Software Levels

A, B, C, D

A, B, C, D Use of Requirements Management

A, B, C, D

C, D

A, B,

,C,D

A, B

Model-Based Design Process Impact

No impact

Interface (RMI) and traditional baseline establishment

No impact

No imp

No impact

act

The following sections describe in more detail the potential impacts for each configuration management process objective when using Model-Based Design, if applicable, as compared to traditional development.

1-43

1 DO-178BSoftwareLifeCycle

Configuration Items Are Identified

For projects using Model-Based Design, throughout the project, the following artifacts m ay have to be configured and identified:

• High-level requirements (level above the models)

• Models

• System Design Description and trace reports

• Model Advisor reports

• Automatically generated code

• Model test harnesses

• Model test scripts

• SystemTest files

• Model test results reports

• Model coverage reports

1-44

• Object code structural coverage reports

These artifacts are in addition to, or substitute for, traditional configured items.

Baselines and Traceability Are Established

Establishing baselines and traceability is the same as for traditional projects. Part of the traceability may be covered by the Requirements Management Interface (RMI).

Problem Reporting, Change Control, Change Review, and Configuration Status Accounting Are Established

Establishing problem reporting, change control, change review, and configuration status accounting is the same as for traditional projects.

Software Configuration Management Process

Archive, Retrie

Establishing ar projects. The ve have to be archi

chive, retrieval, and release is the same as for traditional

rsion of the Model- Ba sed Design tools used on the project may

ved.

Software Load

Establishing

Software Lif Establishe

Establishi traditiona

software load control is the same as for traditional projects.

eCycleEnvironmentControlIs

ng software life cycle environment control is the same as for l projects.

val, and Release Are Established

Control Is Established

1-45

1 DO-178BSoftwareLifeCycle

Software Quality Assurance Process

Thefollowingtablecontainsasummaryof the software quality assurance process objectives from DO-178B, including the objective, applicable DO-178B reference sections, and software levels applicable to the objective is applicable to. The table also describes the potential impact to the process when using Model-Based Design.

Table A-9 Software Quality Assurance Process

Objective

Assurance is obtained that software development and integral processes comply with approved software plans and standards.

Assurance is obtained that transition criteria for the software life cycle processes are satisfied.

Software conformity review is completed.

The following sections describe in more detail the potential impacts for each software quality assurance process objective when using Model-Based Design, if applicable, as compared to traditional development.

Assurance Is Obtained That Software Development and Integral Processes Comply with Approved Software Plans and Standards

Obtaining assurance that software development and integral processes comply with approved software plans and standards is the same as for traditional projects.

Sections

8.1a

8.1b

8.1c, 8

Software Levels

A, B, C, D

A, B

A, B, C, D

Model-Based De sign Process Impact

No impact

1-46

Software Quality Assurance Process

Assurance Is Obtained That Transition Criteria for the Software Life Cycle Processes are Satisfied

Obtaining assurance that transition criteria for the software life cycle processes are satisfied is the same as for traditional projects.

Software Conformity Review Is Completed

Completing software conformity review is the same as for traditional projects.

1-47

1 DO-178BSoftwareLifeCycle

Certification Lia ison Process

The following table contains a summary of the certification liaison process objectives from DO-178B, including the objective, applicable DO-178B reference sections, and software levels applicable to the objective. The table also describes the potential impact to the process when using Model-Based Design.

Table A-10 Certification Liaison P rocess

Objective

Communication and understanding between the applicant and the certification authority is established.

The means of compliance is proposed and agreement with the Plan for Software Aspects of Certification is obtained.

Compliance substantiation is provided.

The following sections describe in more detail the potential impact for each certification liaison process objective w h en using Model-Based Design, if applicable, as compared to traditional development.

Communication and Understanding Between the Applicant and the Certification Authority Is Established

Establishing communication and understanding between the applicant and the certification authority is the same as for traditional projects.

Sections

9.0

9.1

9.2

Software Levels

A, B, C, D

Model-Based Design Process Impact

No impact

1-48

Certification Liaison Process

The Means of Compliance Is Proposed and Agreement with the Plan for S oftware Aspects of Certification is Obtained

Proposing the means of compliance and obtaining agreement with the Plan for Software Aspects of Certification(PSAC)isthesameasfortraditional projects.

Compliance Substantiation Is Provided

Providing compliance substan tiation i s the sa m e as for traditional projects.

1-49

1 DO-178BSoftwareLifeCycle

1-50

Abbreviations

A Abbreviations

Abbreviations

API Application Programming Interface

CRI Certification Review Item

EASA European Avia

FAA Federal Avia

IP Issue Paper

PIL

PSAC Plan for Software Aspects of Certification

RMI

RTOS

Processor-In-the-Loop

Requirements Management Interface

real-time operating system

tion Safety Agency

tion Administration

A-2

References

B References

Normative References

The Motor Industry Software Reliability Association. MISRA-C:2004 Guidelines for the use of the C language in critical systems. MIRA Limited,

2004.

SAE International. Certification Considerations for Highly-Integrated Or Complex Aircraft Systems, 1996.

B-2

Index

IndexA

API 1-17 A-2 application programming interface 1-17 A-2 ARP4754 1-11 B-2

code conformance 1-3 code generation report 1-3 1-30 to 1-31 code traceability 1-3 code verification 1-3 coding 1-3 coding standards 1-8 compiling 1-3 CRI 1-8 A-2

DO Qualification Kit 1-3 1-5 1-8 1-13 to 1-31

1-33 to 1-37 1-40 to 1-41

DO-178B 1-2 to 1-3 1-20 to 1-25 1-36

model-based design workflow 1-3 section 6.1.b 1-20 to 1-25 section 6.4 1-36 software life cycle 1-2

DO-178B checks 1-3 1-15 to 1-18 1-21 to 1-24

1-26 to 1-28 1-31

EASA 1-5 1-8 A-2 Embedded IDE Link™ 1-3 1-10 1-12 1-33 to 1-38

IP 1-8 A-2

Limit Check element 1-3 1-14 to 1-16 1-18 1-20

to 1-21 1-23 1-25 1-27 1-34 to 1-37

low-level verification 1-3

MISRA C®1-81-121-31B-2 ModelAdvisor 1-31-15to1-181-21to1-281-31 Model Advisor reports 1-44 model coverage 1-3 1-16 1-23 1-27 1-40 to 1-42

1-44

model coverage report 1-3 1-16 1-23 1-27 1-41

1-44 model traceability 1-3 model verification 1-3 modeling 1-3 modeling conformance 1-3 modeling standard 1-5 1-8 1-11 to 1-12

PIL 1-40 A-2 Polyspace

processor-in-the-loop 1-40 A-2 PSAC 1-91-48to1-49A-2

products for C/C++ 1-3 1-8 1-29 to

1-31 1-33 to 1-37

FAA 1-5 1-8 A-2

high-level verification 1-3

Real-Time Workshop®Embedded Coder™ 1-3

1-81-101-121-151-221-271-29to1-31 Real-Time Workshop report

codegeneration 1-31-30to1-31

Model Advisor 1-44

model coverage 1-3 1-16 1-23 1-27 1-41 1-44

1-3 1-8 1-10

Index-1

Index

System Design Description 1-3 1-14 to 1-18

1-20 to 1-28 1-44 requirements validation 1-3 RMI 1-3 1-17 1-24 1-43 to 1-44 A-2 RTOS 1-11 1-26 to 1-28 A-2

Simulink®Design Verifier™ 1-3 1-8 1-13 to 1-14

1-16 1-19 to 1-20 1-23 1-33 1-36 to 1-37 1-40

Simulink

1-28

Simulink

1-13 to 1-29 1-31 1-39 to 1-41

Report Generator™ 1-3 1-8 1-13 to

Verification and Validation™ 1-3 1-8

Simulink

1-31-61-81-10to1-131-15to1-16

1-18 1-21 1-23 1-25 to 1-26 1-30 to 1-31 1-40

Stateflow Stateflow

Coder™ 1-81-101-12

1-3 1-8 1-10 to 1-12

System Design Description report 1-3 1-14 to

1-18 1-20 to 1-28 1-44

SystemTest™ 1-3 1-8 1-13 to 1-16 1-18 to 1-21

1-23 1-25 1-27 1-33 to 1-37 1-39 1-44

traditional projects 1-44 to 1-49 traditional verification methods 1-26 to 1-28

1-32 1-38 1-42

Index-2

Mathworks DO QUALIFICATION KIT 1 Model-Based Design

Specifications and Main Features

Frequently Asked Questions

User Manual

DO-178B Software Life Cycle

DO-178B Software Life Cycle Overview

Model-BasedDesignWorkflowinDO-178B

Planning Process

Table A-1: Planning Process

Software Life-Cycle Environment Is Defined

Additional Considerations are Addressed

Software Development Standards are Defined

Software Plans Comply with DO-178B

Software Plans are Coordinated

Software Development Process

Table A-2 Software Development Process

Derived Low-Level Requirements are Developed

Source Code Is Developed

Verification of Requirements Process

Table A-3 Verification of Requirements Process

Software High-Level Requirements Comply with System Requirements

High-Level Requirements Are Accurate and Consistent

High-Level Requirements Are Compatible with the Target Computer

High-Level Requirements Are Verifiable

High-Level Requirements Conform to Standards

High-Level Requirements Are Traceable to System Requirements

Algorithms Are Accurate

Verification of Design Process

Table A-4 Verification of Design Process

Low-Level Requirements Are Accurate and Consistent

Low-Level Requirements Are Compatible with the Target Computer

Low-Level Requirem ents Are Verifiable

Low-Level Requirements Conform to Standards

Low-Level Requirements Are Traceable to High-Level Requirements

Algorithms Are Accurate

Software Architecture Is Compatible with High-Level Requirements

Software Architecture Is Consistent

Software Architecture Is Compatible with the Target Computer

Software Architecture Is Verifiable

Software Architecture Conforms to Standards

Software Partitioning Integrity Is Confirmed

Verific ation of Coding and Integration Process

Table A-5 Verification of Coding and Integration Process

Source Code Complies with Low-Level Requirements

Source Code Complies with Software Architecture

Source Code Is Verifiable

Source Code Conforms to Standards

Source Code Is Traceable to Low-Level Requirements

Source Code Is Accurate and Consistent

Output of Software Integration Process Is Complete and Correct

Testing of Outputs of Integration Process

Table A-6 Testin g of Ou tp uts of Integration Process

Executable Object Code Is Robust with High-Level Requirements

Executable Object Code Complies with Low-Level Requirements

Executable Object Code Is Robust with Low-Level Requirements

Executable Object Code Is Compatible with Target Computer

Verification of Verification Process Results

Table A-7 Verification of Verification Process Results

Test Procedures Are Correct

Test Results Are Correct and Discrepancies Explained

Test Coverage of High-Level Requirements Is Achieved

Test Coverage of Low-Level Requirements Is Achieved

Software Configuration Management Process

Table A-8 Softw are Configuration Man age m ent Process

Configuration Items Are Identified

Baselines and Traceability Are Established

Software Quality Assurance Process

Table A-9 Software Quality Assurance Process

Software Conformity Review Is Completed

Certification Lia ison Process

Table A-10 Certification Liaison P rocess

Compliance Substantiation Is Provided

Abbreviations

Abbreviations

References

Normative References

Index