You are on page 1of 20

IEC Certification Kit

Polyspace® Bug FinderTM


Conformance Demonstration Template

R2015a
How to Contact MathWorks
Latest news: www.mathworks.com
Sales and services: www.mathworks.com/sales_and_services
User community: www.mathworks.com/matlabcentral
Technical support: www.mathworks.com/support/contact_us

Phone: 508-647-7000

The MathWorks, Inc.


3 Apple Hill Drive
Natick, MA 01760-2098
IEC Certification Kit: Polyspace® Bug FinderTM Conformance Demonstration Template
© COPYRIGHT 2013–2015 by The MathWorks, Inc.
The software described in this document is furnished under a license agreement. The software may be used or copied only under
the terms of the license agreement. No part of this manual may be photocopied or reproduced in any form without prior written
consent from The MathWorks, Inc.
FEDERAL ACQUISITION: This provision applies to all acquisitions of the Program and Documentation by, for, or through the
federal government of the United States. By accepting delivery of the Program or Documentation, the government hereby agrees
that this software or documentation qualifies as commercial computer software or commercial computer software documentation
as such terms are used or defined in FAR 12.212, DFARS Part 227.72, and DFARS 252.227-7014. Accordingly, the terms and
conditions of this Agreement and only those rights specified in this Agreement, shall pertain to and govern the use, modification,
reproduction, release, performance, display, and disclosure of the Program and Documentation by the federal government (or
other entity acquiring for or through the federal government)and shall supersede any conflicting contractual terms or conditions.
If this License fails to meet the government’s needs or is inconsistent in any respect with federal procurement law, the
government agrees to return the Program and Documentation, unused, to The MathWorks, Inc.
Trademarks
MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See www.mathworks.com/trademarks for a
list of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective
holders.
Patents
MathWorks products are protected by one or more U.S. patents. Please see www.mathworks.com/patents for more
information.
Revision History
September 2013 New for Version 3.2 (Applies to Release 2013b)
March 2014 Revised for Version 3.3 (Applies to Release 2014a)
October 2014 Revised for Version 3.4 (Applies to Release 2014b)
March 2015 Revised for Version 3.5 (Applies to Release 2015a)
Contents
1 Introduction ...................................................................................................................................... 1-1
1.1 System/Element Identification ................................................................................................ 1-2
2 Static Analysis of C/C++ Code to Assess Compliance with Coding Standards ............................... 2-1
3 Static Analysis of C/C++ Code to Determine Code Size and Complexity Metrics ......................... 3-1
4 Determination of Software Quality Metrics ..................................................................................... 4-1
5 Static Analysis of C/C++ Code to Assess Interface Between Components ..................................... 5-1
6 Static Analysis of C/C++ Code to Detect Systematic and Potential Software Defects .................... 6-1
7 Additional Considerations ................................................................................................................ 7-1

v
vi
1 Introduction

This Conformance Demonstration Template can be used to demonstrate conformance with the
parts of ISO 26262-6/8, EN 50128, or IEC 61508-3 covered in the document

Polyspace® Bug FinderTM Reference Workflow

To access the reference workflow document, on the MATLAB ® command line, type
certkitiec to open the Artifacts Explorer. The reference workflow document is in
Polyspace Bug Finder > r2015a.
For each technique or measure:
 In the third column, state to what degree you applied the technique or measure for the
application under consideration by using one of the phrases: Used, Used to a limited
degree, or Not used.

 In the fourth column, state how you used the technique or measure in the application under
consideration. If the reference workflow includes alternative means for compliance,
indicate what variant you used. In addition, enter a reference to the document (for example,
test report or review documentation) that satisfies the requirement.
1.1 System/Element Identification
Applicant: <Company name>
<Item or element to be analyzed or verified using Polyspace Bug
Item/element under development:
Finder>

1-2
2 Static Analysis of C/C++ Code to
Assess Compliance with Coding
Standards

Checklist 1: Static analysis of C/C++ code to assess compliance with coding


standards
Technique / Measure Associated Used / Used to Interpretation
Requirements a limited degree in this
/ Not used application,
Evidence
1 Coding standard compliance  Suitable Polyspace
analysis configuration and project
information
 List of coding standard
rules to be checked
 Analysis of applicable
code modules
 Raw code analysis results
2 Results review  Reviewed and
commented code analysis
results
 Evidence for following
the specified corrective
action in case of failure
of source code analysis
Technique / Measure Associated Used / Used to Interpretation
Requirements a limited degree in this
/ Not used application,
Evidence
3 Error prevention / detection  [M1] Preceding or
subsequent dynamic
verification (testing) of
the software
 [M2] Specified procedure
for corrective action on
failure of source code
analysis
 [M_MISC1]
Revision control and
configuration
management to identify
the artifacts to be
analyzed; Use of
checksums
 [M_MISC2]
Competency of the
project team
 [M_MISC3]
Adherence to Installation
Instructions; Integrity of
Tool Installation
 [M_MISC4] Analysis of
available bug report
information
 [M_MISC3]
Adherence to Installation
Instructions; Integrity of
Tool Installation
 [M_MISC4] Analysis of
available bug report
information

2-2
3 Static Analysis of C/C++ Code to
Determine Code Size and
Complexity Metrics

Checklist 2: Static analysis of C/C++ code to determine code size and


complexity metrics
Technique / Measure Associated Used / Used to Interpretation
Requirements a limited degree in this
/ Not used application,
Evidence
1 Code size and complexity  Suitable Polyspace
metrics determination configuration and project
information
 Analysis of applicable
code modules
 Code metrics results
2 Results review  Reviewed metrics results
 Evidence for following
the specified corrective
action in case of
unexpected metrics
results
Technique / Measure Associated Used / Used to Interpretation
Requirements a limited degree in this
/ Not used application,
Evidence
3 Error prevention / detection  [M1] Preceding or
subsequent dynamic
verification (testing) of
the software
 [M_MISC1]
Revision control and
configuration
management to identify
the artifacts to be
analyzed; Use of
checksums
 [M_MISC2]
Competency of the
project team
 [M_MISC3]
Adherence to Installation
Instructions; Integrity of
Tool Installation
 [M_MISC4] Analysis of
available bug report
information

3-2
4 Determination of Software Quality
Metrics

Checklist 3: Determination of software quality metrics

Technique / Measure Associated Used / Used to Interpretation


Requirements a limited degree in this
/ Not used application,
Evidence
1 Quality metrics determination  Suitable Polyspace
configuration and project
information
 Availability of
underlying analysis /
verification results
 Defined software quality
level for the application
 Defined software quality
objectives for applicable
code modules
 Software quality metrics
results
2 Results review  Reviewed software
quality metrics results
 Evidence for following
the specified corrective
action in case of
detection of unexpected
metrics results
Technique / Measure Associated Used / Used to Interpretation
Requirements a limited degree in this
/ Not used application,
Evidence
3 Error prevention / detection  [M3] Check of the
underlying analysis
results for critical issues
 [M2] Specified procedure
for corrective action on
failure of source code
analysis
 [M_MISC1]
Revision control and
configuration
management to identify
the artifacts to be
analyzed; Use of
checksums
 [M_MISC2]
Competency of the
project team
 [M_MISC3]
Adherence to Installation
Instructions; Integrity of
Tool Installation
 [M_MISC4] Analysis of
available bug report
information

4-2
5 Static Analysis of C/C++ Code to
Assess Interface Between
Components

Checklist 4: Static analysis of C/C++ code to assess interface between


components
Technique / Measure Associated Used / Used to Interpretation
Requirements a limited degree in this
/ Not used application,
Evidence
1 Component interface assessment  Suitable Polyspace
configuration and project
information
 List of applicable coding
standard rules to be
checked (e.g. MISRA-
C:2012 rules 8.3, 8.5, and
8.7)
 Analysis of applicable
code modules
 Analysis of interface
metrics
 Raw code analysis results
2 Results review  Reviewed and
commented code analysis
results
 Evidence for following
the specified corrective
action in case of failure
of source code analysis
Technique / Measure Associated Used / Used to Interpretation
Requirements a limited degree in this
/ Not used application,
Evidence
3 Error prevention / detection  [M1] Preceding or
subsequent dynamic
verification (testing) of
the software
 [M2] Specified procedure
for corrective action on
failure of source code
analysis
 [M_MISC1]
Revision control and
configuration
management to identify
the artifacts to be
analyzed; Use of
checksums
 [M_MISC2]
Competency of the
project team
 [M_MISC3]
Adherence to Installation
Instructions; Integrity of
Tool Installation
 [M_MISC4] Analysis of
available bug report
information

5-2
6 Static Analysis of C/C++ Code to
Detect Systematic and Potential
Software Defects

Checklist 5: Static analysis of C/C++ code to detect systematic and potential


software defects
Technique / Measure Associated Requirements Used / Used to Interpretation
a limited degree in this
/ Not used application,
Evidence
1 Systematic and potential  Availability of data range
software defect specifications
assessment  Suitable Polyspace configuration
and project information
 Verification of applicable code
modules
 Raw code verification results
2 Results review  Reviewed and commented code
verification results
 Evidence for following the
specified corrective action in
case of detection of software
defects in the source code
Technique / Measure Associated Requirements Used / Used to Interpretation
a limited degree in this
/ Not used application,
Evidence
3 Error prevention /  [M1] Preceding or subsequent
detection dynamic verification (testing) of
the software
 [M1_lim] Limited preceding or
subsequent dynamic verification
(testing) of the software
 [M2] Specified procedure for
corrective action on failure of
source code verification or
analysis
 [M_MISC1]
Revision control and
configuration management to
identify the artifacts to be
analyzed; Use of checksums
 [M_MISC2]
Competency of the project team
 [M_MISC3]
Adherence to Installation
Instructions; Integrity of Tool
Installation
 [M_MISC4] Analysis of
available bug report information

6-2
7 Additional Considerations

Checklist 6: Additional considerations

Technique / Measure Associated Used / Used to Interpretation


Requirements a limited degree in this
/ Not used application,
Evidence
1 Tool environment  Evidence for using
suitable tool operational
environment
2 Tool configuration / verification  Evidence for using
options applicable analysis
options

3 Configuration management and  [M_MISC1]


revision control; use of Configuration
checksums management for artifacts
to be analyzed
 Configuration
management for other
applicable artifacts (e.g.
source code, reports)
4 Competency of the project team  [M_MISC2] Evidence for
competence of project
team members
 Evidence that coding and
verification activities are
conducted by
independent roles (if
applicable)
Technique / Measure Associated Used / Used to Interpretation
Requirements a limited degree in this
/ Not used application,
Evidence
5 Adherence to installation  [M_MISC3] Adherence
instructions; Integrity of tool to installation instructions
installation  Verification of the tool
version
 Validation of
modification and
additions to shipping
tools (if applicable)
6 Analysis of available bug report  [M_MISC4] Assessment
information of bug report information
provided by tool vendors
and compliance with
recommendations and
workarounds (during
development and after
deployment)
 Reporting of issues with
MathWorks products
7 Deviation from the reference  Documentation and
workflow justification for
deviations from the
reference workflow by
using a deviation
procedure (if applicable)
8 Integration with the software  Documented software
safety life cycle safety lifecycle, including
application-specific
verification and
validation activities

7-2

You might also like