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.” |
|
|
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.
1 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