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.
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,