I was wondering about use of the Functional Safety version of the XC32 compiler...
 
I am working on an ISO26262 project, and I understand that I need this version of the compiler.   Does this include the PRO version of the compiler, or do I need to get that too?
 
How is this different from the non-functional safety version of the compiler - do we need to get a seat of the functional safety compiler for each developer, or can we do interim builds with the regular compiler, and just use this for the final build?   And when new versions of XC32 are released, will there be a functional safety version for every new release - or will we have to stay with the previous version until the next functional safety version is released?
 
Will we have an annual HPA for the functional safety compiler?
 
 

Hi EmDevEng,
 
I'm sure a lot of people have these questions. Thanks for asking. Let's take the easy ones first:

EmDevEngFunctional Safety version of the XC32 compiler ... Does this include the PRO version of the compiler, or do I need to get that too?

 
The Functional Safety version of the compiler comes with all of the PRO optimizations. It is only the PRO compiler. The Functional Safety compiler has no free mode.
 

EmDevEng Will we have an annual HPA for the functional safety compiler?

 
There is no HPA for the Functional Safety compiler.
 

EmDevEng
And when new versions of XC32 are released, will there be a functional safety version for every new release - or will we have to stay with the previous version until the next functional safety version is released?

 
It's best to think of XC32 and the Functional Safety compilers as different tool chains, with independent release schedules. We release two-ish versions of the XC compilers per year. The release schedule on the Functional Safety compiler is approximately once every 18 months. As you can (or will! wink: ) appreciate, getting certification is a time-consuming process. Microchip is a good partner here: If you choose to upgrade a Functional Safety compiler, there is a reduced price for the upgrade.
 
Now for the juicy one:

EmDevEngHow is this different from the non-functional safety version of the compiler - do we need to get a seat of the functional safety compiler for each developer, or can we do interim builds with the regular compiler, and just use this for the final build?

 
The final answer is: That's between you and your auditor. Consider (as I said above) that the XC compiler and the Functional Safety compiler are two different tool chains. Why would an auditor accept that two different compilers being used on a project are consistent? Why would an auditor accept that a test suite will accurately identify any inconsistencies precipitated by the differences between the compilers? Reductio ad absurdum helps clarify this situation: What if every developer used different compilers? How is an auditor convinced that is consistent with a Functional Safety development? Those are questions that every aspirant has to answer for themselves, with their auditor.
 
As we mature in our understanding of Functional Safety development we realize that the code that's generated is a tiny part of the exercise. There must be proof from requirements, through architecture and design, and eventually coding and testing, that what is done is what was required, and that it has been done within given safety specifications. Every development organization must prove that to their auditor. Using different compilers complicates that already complicated process. It's easier to prove with one tool chain. Even after the (descending, left-hand side of the V) development part of a Functional Safety development, every organization must demonstrate that they verify and validate - traceable all the way through to requirements, everything that was required. It's a lot of work. Why complicate it?
 
I apologize that's the easiest possible answer. Functional Safety development is not for the faint of heart or the weak of resolve. This is the tip of the iceberg. I wish you strength and good luck on your journey.
 
All the best,
jfd

Hi (again) EmDevEng,
 
There's another thing to consider. In a Functional Safety development you must qualify every tool that you use in your development. The Functional Safety compilers come with an extensive package of information (including classification and classification review documents, Functional Safety Manual, FMEA, Validation Strategies and Results, etc.!) that's being referred to in the community as a "self-qualification tool kit." It isn't everything that you need, but it's everything that we can provide.
 
If you use a different compiler, how will you qualify it? The XC validation team runs nearly a MILLION tests on the Functional Safety compiler. Will you?
 
Cheers,
jfd
 

Would it be possible (and permissible) for a developer to use non-certified tool chains for developing portions of a project, but then recompile the entire project using the functional safety compiler for final testing and release?

I can’t see why they would.
As long as all submissions and testing are done with the certified compiler .

If possible, it would make sense to get a dongle version.

Tools can also be "proven in use" which is a slightly easier route for the supplier, but means you will forever be using an old version, as a new version cannot, by definition, be proven in use.
 

PStechPaul
Would it be possible (and permissible) for a developer to use non-certified tool chains for developing portions of a project, but then recompile the entire project using the functional safety compiler for final testing and release?

Yes, but you run the risk of incompatibilities between the versions, E.g., you develop something with assembly modules and the supplier then ditches that assembler toolchain. You will need robust version control so I would, at the very least, run check-in tests with the certified toolchain if you cannot roll it out to all developers.

Great answers so far. There aren't that many experienced practitioners, Paul, and you got some good advice.
 
In the final analysis, it's between you and your auditor. If parts were developed with one compiler and parts with another, and then recompiled with a third, where is the supporting documentation and proof that versions, and testing and validation and everything else are according to standard? Can you prove that changes between compilers didn't introduce some inconsistency or intermittent bug?
 
crosland raises an excellent point in that "proven in use" is easier - if all of the prerequisites are in place: exactly the same tool version was used in exactly the same application (if it was used in a window lift and now you want to use it in a door handle, that makes "proven in use" invalid) and the previous combination was "safe" (I'm not even sure, not having pursued this method, how that's done). I believe this method was provided to ease "grandfathered" applications and updates, not for new development.
 
Functional safety developments have many requirements. Taking every easy advantage (like using a functional safety certified compiler) is worth it in reduced labor. Proving the things you have to prove (requirements traceability comes to mind) is tough enough. Why complicate your life?
 
Cheers,
jfd

jfd
crosland raises an excellent point in that "proven in use" is easier - if all of the prerequisites are in place: exactly the same tool version was used in exactly the same application (if it was used in a window lift and now you want to use it in a door handle, that makes "proven in use" invalid) and the previous combination was "safe" (I'm not even sure, not having pursued this method, how that's done). I believe this method was provided to ease "grandfathered" applications and updates, not for new development.

Proven in use tools are definitey used for new developments. It's how some complex toolchains are qualified that are simply too complex to be proven correct or qualified by any formal means. I can't say too much as I'm not sure what me ex-employer actually tells customers about qualification methods, but think of hardware compilation. Don't get me wrong, there's still man years of qualification and auditing that has to be done.
 
Proven in use status is not invalidated by changing the application, e.g., a C compiler would be proven in use whatever the function of the end code. That function and the application still has to be qualified.

Hi All,
 
Thanks crosland for jogging my memory. There are only so many words in the English language so some phrases, like "Proven in Use," are easily confused with phrases like "Increased Confidence from Use." I confused the two terms above, so please allow me to clarify. ISO 26262 provides only four methods for qualifying tools: Increased Confidence from Use (11.4.7), Evaluation of the Tool Process (11.4.8), Validation of the Software Tool (11.4.9), and Development in Accordance with a Safety Standard.
 
Before we talk about qualifying tools for use in a Functional Safety development, let me clarify that "Proven in Use" is for components, not tools. The concepts are similar. The application is not.
 
ISO 26262 provides three guidelines for when a tool can be qualified under the rubric of "Increased Confidence in Use":

1. The tool has been used for the same purpose, with comparable use-cases (this is what I was getting at with the window lift vs. door handle example)
2. The specification of the tool is unchanged (this is what I was getting at with the "exactly same tool version" statement), and finally
3. There has not been a violation of safety requirements allocated to the "item" identified in the first bullet

I don't have any experience identifying that last point. I'd be happy to hear from anyone who does, and can describe how to prove that to an auditor. In fact, I have never attempted to qualify a tool using "Increased Confidence from Use." Again, this is between an organization and their auditor. If the auditor accepts that a tool has met these three criteria, the tool is qualified, by definition. It is still the sole responsibility of the development organization. The tool vendor can't do much, if anything, to help.
 
The other issue here is that tools must be qualified appropriately for the ASIL (Automotive Safety Integrity Level) desired for the "item." Qualifying a tool according to "Increased Confidence from Use" is only appropriate (by the standard) for ASIL A, B, and C. It is not appropriate for ASIL D.
 
ISO 26262 is a much more modern standard than, for instance, IEC 61508. Tools are qualified or not in IEC 61508, with no gradations.
 
All of this is rather academic in relation to EmDevEng's original questions. If a certified tool is used, and that tool has a "self-qualification" kit that provides most of the collateral needed to qualify the tools for a functional safety development, that provides the minimal effort solution to qualifying those tools. Without such certification and without the provision of a self-qualification kit, the burden of qualifying tools for your functional safety development falls squarely on your shoulders.
 
Best,
jfd

jfd
Before we talk about qualifying tools for use in a Functional Safety development, let me clarify that "Proven in Use" is for components, not tools. The concepts are similar. The application is not.
 

Tell that to the multinational multi-billion $ company I worked for. "Proven in use" is very much used for tools, but everything i then audited by TuV.