Both IEC 61508 and ISO 26262 highly recommend a modular approach to software development. One question that comes up regularly asks if there are quantitative targets for determining whether sufficient progress has been achieved by software engineers.

IEC 61508-3 Table B.9 Modular approach

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

ISO 26262-6 Table 1 Topics to be covered by modelling and coding guidelines

Topics

ASIL-A

ASIL-B

ASIL-C

ASIL-D

1a

Enforcement of low complexity

++

++

++

++

1b

Use of language subsets

++

++

++

++

1c

Enforcement of strong typing

++

++

++

++

1d

Use of defensive implementation techniques

o

+

++

++

1e

Use of established design principles

+

+

+

++

1f

Use of unambiguous graphical representation

+

++

++

++

1g

Use of style guides

+

++

++

++

1h

Use of naming conventions

++

++

++

++

When writing a coding guideline for an organization of software engineers sometimes it’s useful to give specific guidance. Especially new developers like to have targets to gauge how well their safety related code matches up with more mature code that has the benefit of longer maintenance.

Manufacture Initiative (Herstellerinitiative Software)

Hersteller, German for Manufacturer or possibly OEM, is the name of a project group consisting of German automobile manufacturers that got together to establish among other things guidelines for software code metrics. The sort of information that is useful for a coding guideline.

The group consisted of Audi, BMW, Daimler, Porsche and Volkswagen. With over 15 million vehicles sold by German manufacturers in 20171 and suppliers that provide similar parts to many of the rest of world-wide vehicle production, it’s hard ignore their recommendations or argue that the targets are anything other than feasible, appropriate, valid, or cost effective.

HIS Source Code Metrics version 1.3.1 01.04.2008

Although the original website2 no longer exists and now redirects to an Autosar3 site if you google this section heading or the file “HIS-sc-metriken.1.3.1_e.pdf” you’ll find your own copy to download. There is no copyright asserted and I understand the intention of the work was to benefit software development and standardization of target setting across at least the German Automotive OEMs.

It’s worth noting that your existing static analysis tools may already measure and report these metrics. One example is QAC from PRQA4.

Section 3.1 Metrics with limits

Metric 

Description 

Comment 

Range

Comment Density

Relationship of the number of comments (outside of and within functions) to the number of statements 

Comprehensibility, clarity in the code. With violation documentation to decide on the acceptance or rejection. According to its definition the value cannot be > 1

> 0.2

Number of paths

Number of non-cyclic remark paths (i.e. minimum number of necessary cases of test).

Measurement for the reduction of paths. Allocation into several functions, Display in sub-functions.

1 - 80

Number of Go to Statements

Number of Go to Statements 

This drastically increases the number of paths and thus reduces testability.

0

Cyclomatic Complexity

In accordance with the Cyclomatic Number

Measurement for the decrease in cyclomatic complexity. Allocation across several functions with paging into and out of sub-functions.

1 - 10

Number of Calling Functions

By how many sub functions is this function called? 

The range 1 to 5 only makes sense when the entire system is analyzed. With subsystems and libraries 0 to 5 is permissible. For the complete system there is the exception of main(), since this will only be called by the Start-up-Code. 

0 - 5

Number of called functions

How many different functions does this function call? Calling the same sub function counts only once. 

Examine width of nesting.

0 - 7

Number of Function Parameters 

How complex is the function interface? 

Complexity of the function, need for stack

Structures and Arrays hide the complexity in the same way. 

0 - 5

Number of Instructions per function

How complex is the function? 

Empty functions fall through.

1 - 50

Number of call Levels

Depth of nesting of a function. 

Maximum nesting levels within a function + 1.

0 - 4

Number of return points

Number of return points within a function 

Complexity of a function, Maintainability of a function, when does a function return.

0 = a function without a specific return statement.

0 - 1

The stability index

The stability index supplies a measure of the number of the changes (changes, deletions, additions) between two versions of a piece of software.

To be collected at a function level or at the total software level.

The value is per definition <= 1. The lower this value of this metric the more changes the new software version contains. If no changes had been made overall then the value of this metric would be 1. 

As might be expected the stability index for two early successive versions of a piece of software will be rather low and should always then continue to rise for the later versions.

0 - 1

Language scope

The language scope is an indicator of the cost of maintaining/changing functions.

Higher value = similar or duplicated code portions; Calls in/out of sub-functions need to be considered.

1 - 4

Violations of rules

Total number of the violations of the Rules of the [HIS Subset MISRA C 1.0.2].

Compliance of HIS rules within the Software production process.

0

Violations per rule

Number of violations of each rule of the [HIS Subset MISRA C 1.0.2], Classified according to the rules.

Compliance of HIS rules within the software production process.

Should also contain a rule to identify “Dead Code”.

0

Number of recursions

Call graph recursions 

Recursions over one or more functions.

0

Further reading

If you want to study this topic some more and the references like MISRA then visit these links:

“MISRA, The Motor Industry Software Reliability Association, is a collaboration between vehicle manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety-related electronic systems in road vehicles.”

https://www.misra.org.uk/

High Integrity C++ Coding Standard Version 4.0

http://www.codingstandard.com/request-high-integrity-c-manual/

HIC++ V4.0 An overview by the authors

http://info.prqa.com/high-integrity-c-coding-standard-v4-whitepaper-awareness-lp

If you have enjoyed (or otherwise) this short blog then please let me know. I’ll be grateful of any comments and incorporate any recommendations.


https://focus2move.com/world-car-group-ranking

2 www.automotive-HIS.de

3 www.autosar.org

4 www.prqa.com/press-releases/2014/prqa-releases-qac-v3-2-boosting-c11-coverage-simplifying-the-adoption-of-secure-coding-best-practices-and-more


Tagged as:     Jonathan Moore     ISO 26262     IEC 61508  

Other Blog Posts By Jonathan Moore