Your development team is focused on producing a great product. But you also need to comply with functional safety standards. This means you will need to use a best practice coding standard.
Coding rules need to be enforced. Violations need to be fixed (and documented). And quality needs to be assured.
You'll learn:
-What functional safety standards require from your code.
-How to apply coding standard rules for compliance.
-Why Helix QAC is the best way to do it.
We’ll share an example of using Helix QAC with MISRA rules for ISO 26262 compliance. Plus, we’ll discuss other functional safety standards and the basics of coding standards compliance.
20. Follow us for news and insights!
Visit info@perforce.com
Hinweis der Redaktion
In today’s webinar we’ll be looking at …
What functional safety standards require…
How to applying coding standards…
And looking at why Helix QAC is the best way to do it!
Let’s start with defining what functional safety really is…
Functional safety is the part of the overall safety of a system, or piece of equipment, that depends on automatic protection operating correctly in response to its inputs or failure in a predictable manner
The automatic protection system should be designed to properly handle likely human errors, hardware failures and operational or environmental stress
When looking at the key functional safety standards, the mother of functional safety is IEC 61508.
If an industry does not have a functional safety standard, then IEC 61508 can apply. This was introduced to force the implementation of Functional Safety.
If an Industry does have their own standard, like Automotive, Railway and Nuclear, then their standard applies.
The exception to this is civil big aircrafts, where DO178 applies and this is even older then IEC 61508!
Functional Safety standards cover all areas of product development, including documentation, systems, software and hardware.
It’s important to note that static analysis can only cover sections related to software and systems.
With this in mind, Helix QAC can help you achieve functional safety in the following standards, enforcing these sections of the standards.
I think it’s important to stress that, when using the Perforce Safety Manuals, knowledge is required of:
The Programming Languages
The coding standard guidelines, such as MISRA C
The build environment you are working in
And the capabilities and limitations of static analysis
If we take a quick look at the differences between certified and uncertified tools we know it can take up to 10 years of work to certify.
This means you are then responsible for maintaining all tests and certifying everything again, should you change a single part. And you have no guarantees on how the tool vendors deal with development of the tool or how it is supported.
Whilst going with a certified tool means the work has been done for you! That work is then independently certified by SGS-TUV Saar and the tool will be maintained and supported.
We then offer you guides on how the tool should be used in the safety-related environment.
If we move now to look at coding standards and compliance…
the concept of compliance is more complex than it might first appear, this is because there are times when it may not be appropriate or desirable to seek 100% compliance with coding rules.
Safety critical standards provide guidance on how to avoid risks, such as systematic failures and random hardware failures, by providing appropriate requirements and processes.
With these differences in mind, by achieving compliance to a coding standard doesn’t mean you are compliant to functional safety, however it does go along way and makes it much easier.
Currently, only ISO 26262 is the only standard that gives an example of a specific coding standard, this is of course is MISRA.
To meet the requirements of a functional safety standard, you will need to comply to a coding standard.
However, within these coding standards, there are a number of rules which are essentially “promoted” and when we say promoted, we mean you should not deviate away from the rules.
Instead, treat the highly recommended methods as mandatory.
For example, if we look at MISRA C:2012 rule 10.5, which is a MISRA advisory rule, this can be mapped again ISO 26262, table 8, method 1G – no implicit type conversions. This is highly recommend for achieving compliance to ASIL levels B – D.
As we’ve been looking at C, lets just touch on C++ and in particularly MISRA C++:2008 written for ISO C++ 2003 – which is now very old!
Since then the language has evolved and compilers & tools have improved.
The AUTOSAR Guidelines were written for C++14 language in critical and safety-related systems
AUTOSAR…
Benefits from changes to core language
Gives guidance on safe usage of new core features
Has some rules that are ‘Less’ restrictive
And some rules that are ‘More’ restrictive
When working towards achieving compliance to functional safety, there are a number of methods which require metric tracking.
These range from enforcing low complexity, to restricting the size of the software components, to limiting the use of global variables.
So for example, if we look at ISO 26262, Table 1, Method 1a – with the enforcement of low complexity - Helix QAC can track the cyclomatic complexity.
And again for EN 50128, which limits the use of global variables, Helix QAC can track the usage of variables with external linkage.
All of which can be track through reporting, or via the Dashboard for full project life cycle tracking.
If we look at how we can manage compliance with Helix QAC, there are a number of different ways to track project compliance to the various standards…
First, we have the File compliance index which is an average compliance across the project
And then we have the Project compliance index which is a percentage of fully compliant files
Of course for those of you that prefer raw data, you can look at the number of violated groups vs number of compliant groups or even create your own compound metrics, all within the Helix QAC Dashboard!
But then, what about software quality? How can we manage that?
Well there are a number of different ways to measure software quality, for example…
The percentage of source code containing violations
We can also track quality by looking at …
Rule violations removed vs new rules violated
Or We can track quality by looking at …
Rule violations removed against the amount of code change
But everyone measures quality differently, with different levels of acceptability.
So I again, I think it’s important to note that you can add in your own custom metrics to suit your own needs
Helix QAC is a static code analyzer that automatically scans code for violations (based on C and C++ coding rules). It enables development teams to detect defects earlier in development — when they’re easier and less costly to fix.
Additionally Helix QAC automatically enforces coding standards, such as MISRA C:2012 & AUTOSAR C++, which ensures your code is compliant.
So just a quick recap before I hand back to Rachel, we’ve looked…
What functional safety standards require,
How to apply coding standards,
And why Helix QAC is the best way to do this, for you!
So thank you for time today, I will now be handing back to Rachel.
To find out more about Perforce’s static code analysis solutions, please visit perforce.com, or email us at info@perforce.com with any questions, or to organise a free demo or evaluation of any of our software products.
Facebook: https://www.facebook.com/Perforce/
LinkedIn: https://www.linkedin.com/company/perforce-software?trk=top_nav_home
Twitter: https://twitter.com/perforce
Blog: https://www.perforce.com/blog
So, I hope you’ve enjoyed this webinar. All that remains is for me to say thank you very much for attending