This Software Metrics Report is part of the SafeQP Certification Kit↑, but applies to the whole QP/C Framework family↑. This document presents a comprehensive analysis of software metrics collected from the QP/C Framework.
Revision History
| QP/C version | Document revision | Date (YYYY-MM-DD) | By | Description |
|---|---|---|---|---|
| 8.1.0 | A | 2025-09-01 | MMS | Created for QP/C 8.1.0. |
Software Metrics
Description
This Software Metrics Report, with Unique Identifier: DOC_METRICS_QP, presents a comprehensive analysis of software metrics collected from the QP/C Framework by the PC-Lint-Plus static analysis tool ([PCLP-2025]), evaluated under the Hersteller Initiative Software (HIS)↑ standard and aligned with with IEC 61508 as well as ISO 26252 functional safety requirements. The metrics serve as quantitative indicators of code quality, structural complexity, and maintainability, critical factors in ensuring the reliability and certifiability of embedded software components. Software metrics play a pivotal role in:
Scope
By applying static analysis tools such as PC-Lint-Plus, the report assesses key attributes including cyclomatic complexity, function size, nesting depth, and interface coupling. These metrics not only support internal quality assurance but also provide traceable evidence for regulatory audits and SIL-level justification. The thresholds adopted reflect industry best practices and regulatory expectations, enabling proactive identification of architectural hotspots and guiding targeted refactoring efforts.
From the regulatory perspective, software metrics are not just engineering convenience; they are evidence artifacts that support compliance, traceability, and risk reduction across the software safety lifecycle. | Technique/Measure | SIL 1 | SIL 2 | SIL 3 | SIL 4 | |
|---|---|---|---|---|---|
| 1 | Software module size limit | HR | HR | HR | HR |
| 2 | Software complexity control | R | R | HR | HR |
| 3 | Information hiding/encapsulation | R | HR | HR | HR |
| 4 | Parameter number limit / fixed number of subprogram parameters | R | R | R | R |
| 5 | One entry/one exit point in subroutines and functions | HR | HR | HR | HR |
| 6 | Fully defined interface | HR | HR | HR | HR |
| Topics | ASIL-A | ASIL-B | ASIL-C | ASIL-D | |
|---|---|---|---|---|---|
| 1a | Enforcement of low complexity | ++ | ++ | ++ | ++ |
| 1e | Use of established design principles | + | + | + | ++ |
| 1g | Use of style guides | + | ++ | ++ | ++ |
HIS Metrics
The Hersteller Initiative Software (HIS) source code quality metrics ([EMENDA-HIS], [EXIDA-METRICS]) define recommended ranges for a set of key code quality metrics to help ensure efficient project and quality management. The set of "HIS Metriken" was initially defined by several German automotive manufacturers (Hersteller, German for Manufacturer or possibly OEM), to provide an agreed standard for developing higher quality and more maintainable code for automotive systems. The HIS metric set is still widely used within the automotive industry today, and many of the same metrics are now explicitly required by the ISO 26262 automotive functional safety (FuSa) standard (Section 6). However, the guidelines also provide a good general set of code quality and complexity metrics that have found favor in many other areas of embedded and enterprise software development, where the need for quality and enforcement of low complexity is of keen interest.
Applied HIS Metrics and Limits
The QP/C Framework source code voluntarily adopts the HIS limits to limit code complexity, improve testability, and demonstrate the overall code quality. The following table lists the reported HIS metrics with the highest regulatory relevance and provides the adopted limits in the QP/C Framework:
| HIS Metric | Purpose | HIS Limits | QP Limits |
|---|---|---|---|
| v(G) | McCabe cyclomatic complexity | ≤ 10 | ≤ 16 |
| PATH | Number of Paths | ≤ 80 | < 99 |
| STMT | Number of Staments | ≤ 50 | ≤ 55 |
| LEVEL | Depth of nesting of a function | ≤ 4 | ≤ 4 |
| CALLS | Called Functions | ≤ 7 | ≤ 7 |
| PARAM | Function Parameters | ≤ 5 | ≤ 7 |
| RETURN | Number of return points per function | ≤ 1 | ≤ 1 |
| GOTO | Number of goto Statements | 0 | 0 |
| COMF | Comment Density | ≥ 0.2 | ≥ 0.2 |
| NOMV | MISRA HIS Subset violations | 0 | 0 |
| NOMVPR | MISRA violations per rule | 0 | 0 |
| [IEC 61508-3:2010] | IEC 61508-3:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems- Part 3: Software requirements |
| [IEC 61508-4:2010] | IEC 61508-4:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems- Part 4: Definitions and abbreviations |
| [ISO 26262-6:2018] | ISO 26262-6:2018(en) Road vehicles - Functional safety - Part 6: Product development at the software level. International Standardization Organization. |
| [ISO 26262-8:2018] | ISO 26262-8:2018(en) Road vehicles - Functional safety - Part 8: Supporting processes. International Standardization Organization. |
| [IEC 60300-3-1:2003] | IEC 60300-3-1:2003: Dependability management - Part 3-1: Application guide - Analysis techniques for dependability - Guide on methodology. International Standardization Organization. |
| [EMENDA-HIS] | Hersteller Initiative Software (HIS), https://emenda.com/his |
| [EXIDA-METRICS] | Software Metrics, https://www.exida.com/blog/software-metrics-iso-26262-iec-61508 |
| [PCLP-2025] | Reference Manual for PC-lint Plus Version 2025, A diagnostic facility for C and C++, Vector Informatik↑ |
| [DOC_MISRA_QP] | misra-qp |
