Automotive-grade microcontroller for low-cost development

[bobsaccamano]

Hi,

I'm working on an automotive hobby project where I am looking to swap out an Arduino (Mega 2560 Rev3) with an automotive-grade MCU.

The main requirements are:
● Ease-of-use of MCU tool chain (good documentation, workflows etc.)
● Open-source/low-cost licenses for tool chain usage
● Qualified for safety-critical automotive applications (ASIL-D)
● Ready availability in low volumes (1-10 units)

A preliminary list of candidate platforms are below:

● STMicro SPC5: https://www.st.com/en/automotive-microcontrollers/spc5-p-performance-mcus.html
● STMicro Stellar: https://www.st.com/content/st_com/en/landing-page/stellar-32-bit-automotive-mcus.html
● NXP MPC57xx: https://www.nxp.com/products/processors-and-microcontrollers/power-architecture/mpc55xx-5xxx-mcus/ultra-reliable-mpc57xx-mcus:MPC57XX
● Renesas RH850: https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rh850.html
● TI Hercules MCU: https://www.ti.com/microcontrollers/hercules-safety-mcus/overview.html
● Infineon AURIX: https://www.infineon.com/cms/en/product/microcontroller/32-bit-tricore-microcontroller/?r
edirId=41544

To the experts out there: Which platform would you recommend and why?

[joeqsmith]

I am no expert.  I have never heard of ASIL-D.   Now that I read a little bit about it, could you explain how it relates to your project?   Hardware, software, system levels?  I'm sure you could write a book on that one subject but I am more asking just the basic ideas of how it effects you in simple terms. 

[free_electron]

Freescale has many

[bobsaccamano]

Sure, the most common implications of ASIL-D on the hardware and system is:

- Two or more MCU cores running in lock-step mode for integrity checking, fault detection and correction (requires at least 3 cores)
- Power management and monitoring: to detect power spikes, interruptions etc.
- Software and hardware watchdog timers
- ...

For more info, this whitepaper is pretty good:  https://www.nxp.com/docs/en/white-paper/FUNCSAFTASILDWP.pdf

[bobsaccamano]

Which Freescale (NXP) boards specifically? How is their toolchain, IDE etc.? Do they offer free licenses for hobbyists or small companies?

This is what I found for NXP...

[Scrts]

We use Renesas F1L series for ADAS, but definitely not ASIL-D... Are you serious about this? You will certify it? Are you going to run AUTOSAR on it?

[JPortici]

Most of the new PIC18/dsPIC from microchip are qualified for automotive, probably not ASIL-D yet
however in the past two years they've put A LOT of effort in making the hardware and the compiler ready for functional safety

but i have to ask, if it's a hobby project why do you care? It's not like you are going to actually certify the thing..

[filssavi]

Forget dsPIC, STM’s, AVRs etc.

If you even want to hope to get close to something ASIL-C (let alone D) you need to use a chip that is specifically designed and certified to do that (technically that is not needed, however the amount of documentation and supplemental work you need to do to do to come up with a non standard solution is mind boggling). Don’t forget that ASIL is as much (if not more) certifying your development process (why and how every decision was made) than the hardware itself. While you might find it pointless, you would be surprised how many engineering disasters occur because of miscommunication/misunderstanding between different groups of people.

Few MCUs that are targeted at safety critical (asil) applications are the Freescale MPC56xx and MPC57xx, the Ti Hercules (TMS570), Infineon Aurix (Tricore). Many designs also use a CPLD/FPGA to implement separate IO checking and validation functions.

Also you don’t really certify as ASIL the MCU only but the entire design, so what you need to do is really dependent on your system overall

In a a company when developing a design that is going to be ASIL Certified the first thing you do is hire as consultants (paying them a lot of money) the guys that do the certification (TÜV un Europe for example I guess it would be the UL labs in the USA) and you let them tell you exactly what hardware you need to implement to pass without issues, then you do exactly as told and not deviate at all

[bson]

I'd add MSP430 to the list of stuff to evaluate.  TI provides both their own compiler for free, as well as a gcc port, various libraries (not always great, but can be dissected to identify undocumented behavior when something won't work), documentation, examples, etc.  They have lots of evaluation boards, and a ton of processor variants.  For example, the MSP430F2252-Q1.  (Can't help with ASIL-D or other certifications.)

[rounin]

I spent about 2 years give or take on the MPC5777M, I like it a lot. We didn't do full ASIL-D but were planning on being able to upgrade at some point. It is a very large microcontroller, def overkill if coming from an atmega, but it is nice to have more than enough of everything sometimes.

Maybe the MPC564xL series, its a bit more atmega sized (ie, just a lockstep pair, LQFP option instead of a 512 pin bga...)

SPC5 is old, i think. MPC5777M is old too. Stuff like non-iso CAN FD can be annoying.

s32K1 doesn't have an ASIL D yet, I think, but is worth watching or using if you can get by with ASIL B. There is a new family coming out soon, I think this line will be replacing the MPC56XX over the next 10 years.

[Siwastaja]

This really is an all-or-nothing thing. If you aim to pass those certifications, it will be a $1M project with a very experienced team you need to build.

If this isn't your target, there is absolutely zero point in using such parts in a low-cost / not experienced / startup / hobby / university / whatever project, they only add confusion, make it harder to find a "low-cost" team familiar with them, or you to learn how to use them, the end result won't pass any certification process, not even close, and even informally, the result is likely much less safe than if you used any standard MCU you are most familiar with (and hence can spend your time trying to be as bug-free as possible).

The most likely culprit will be your code. Secondarily, your electronics.

[rounin]

FWIW the MPC5777M was pretty easy to use, we actually picked it more for the high peripheral & pin count than for ASIL. Some of the internal self-test stuff is automatic and on by default, so you get it for "free", like MBIST, LBIST, bus parity, ram/flash parity.

OP said low cost - what is the cost target? ASIL-D parts are a bit spendy. MPC5777M and SPC5 are 20$-30$ chips. it was low cost compared to a network of 3 small MCUs for us.

[bobsaccamano]

Thank you all for your replies...great community here 

Addressing some questions:

but i have to ask, if it's a hobby project why do you care? It's not like you are going to actually certify the thing..

Yes that's true, but I'm looking to bridge the gap between hobby project and automotive-grade certified system. My idea is to just use automotive-grade hardware and ignore the certification aspects as an intermediate step.

We use Renesas F1L series for ADAS, but definitely not ASIL-D... Are you serious about this? You will certify it? Are you going to run AUTOSAR on it?

Nice, what kind of ADAS applications?  Yes I am serious but will not certify in this phase. See my previous comment.
I don't plan to run AUTOSAR at first, just use the available toolchain and platform libraries.

Maybe the MPC564xL series, its a bit more atmega sized (ie, just a lockstep pair, LQFP option instead of a 512 pin bga...)

That's a nice option!

SPC5 is old, i think. MPC5777M is old too. Stuff like non-iso CAN FD can be annoying.

s32K1 doesn't have an ASIL D yet, I think, but is worth watching or using if you can get by with ASIL B. There is a new family coming out soon, I think this line will be replacing the MPC56XX over the next 10 years.

s32K1 looks interesting - have you worked with it before? How is their SDK and MCAL support?

This really is an all-or-nothing thing. If you aim to pass those certifications, it will be a $1M project with a very experienced team you need to build.

If this isn't your target, there is absolutely zero point in using such parts in a low-cost / not experienced / startup / hobby / university / whatever project, they only add confusion, make it harder to find a "low-cost" team familiar with them, or you to learn how to use them, the end result won't pass any certification process, not even close, and even informally, the result is likely much less safe than if you used any standard MCU you are most familiar with (and hence can spend your time trying to be as bug-free as possible).

The most likely culprit will be your code. Secondarily, your electronics.

Great insights. The goal is not certification in the first step - rather to understand the intricacies of automotive-grade hardware and port the application to run on it. The following step will involve the full standards-based development lifecycle and certification.

I agree with your view to use the most familiar MCU to reduce risk and costs. In this case, this is (was) the Arduino I want to get into Automotive embedded software development, hence the next step would be to pick an easy-to-use, friendly automotive-grade-ish platform that can be used to port the same application to. Selection of this platform is where I need help/advice.

In the past, I've worked on TI DSPs (TMS320 C6000, over 10 years ago) so I have some base to start with.

FWIW the MPC5777M was pretty easy to use, we actually picked it more for the high peripheral & pin count than for ASIL. Some of the internal self-test stuff is automatic and on by default, so you get it for "free", like MBIST, LBIST, bus parity, ram/flash parity.

OP said low cost - what is the cost target? ASIL-D parts are a bit spendy. MPC5777M and SPC5 are 20$-30$ chips. it was low cost compared to a network of 3 small MCUs for us.

How about their toolchain? Do they offer compilers, code generation tools, MCAL etc. for free? How is the documentation and support?

Hardware cost is not a major concern (and does not vary much anyway). The main concern is development time, which relates to ease-of-use, toolchain support, documentation, community and of course, engineering skill

[rounin]

s32K1 looks interesting - have you worked with it before? How is their SDK and MCAL support?

We started a design (HV BMS), but haven't gone past schematic. SDK seemed complete enough to get started, but I hadn't written any code yet.

FWIW the MPC5777M was pretty easy to use, we actually picked it more for the high peripheral & pin count than for ASIL. Some of the internal self-test stuff is automatic and on by default, so you get it for "free", like MBIST, LBIST, bus parity, ram/flash parity.

OP said low cost - what is the cost target? ASIL-D parts are a bit spendy. MPC5777M and SPC5 are 20$-30$ chips. it was low cost compared to a network of 3 small MCUs for us.

How about their toolchain? Do they offer compilers, code generation tools, MCAL etc. for free? How is the documentation and support?

Hardware cost is not a major concern (and does not vary much anyway). The main concern is development time, which relates to ease-of-use, toolchain support, documentation, community and of course, engineering skill

Toolchain is ok. Compiler is available, GCC 4 series. We paid for openrtos but there is a port available for free for a similar part that could have been adapted. Code generation & drivers is not available - Vector wouldn't sell AUTOSAR at any price to a non-automotive company (we were aerospace). I ended up writing my own driver stack, which we probably would have done any way for tighter/better freertos integration. The S32k and S32S families look like they will be better supported by NXP with open non-rated SDKs in addition to the rated code provided by Vector.

[Rudolph Riedel]

Forget about ASIL, at least for the beginning, that is a whole extra level.

And have a look at ATSAMC21 as an inexpensive upgrade for an M2560 Arduino that is as a bonus available in automotive grade.

[ealex]

Forget about ASIL stuff and even dedicated mcu's if you're not doing some safety critical stuff.
Most OEM's will go for the cheapest hardware, so no specialized mcu's if they can. (let the software guys handle it ...)

The MPC / SPC series is nice if you don't have to write the Autosar MCAL drivers for it ...
A good debugger will be the difference between throwing the board out the window and understanding why the chip is doing something that makes no sense.
(like PLL's having the locked flag set, but behaving like wide band jamming devices, or having to set / clear a lot of undocumented bits / registers to make something work)
We used Lauterbach debuggers because they could be easily automated / integrated in the test env.
Also, the MCU definition files where text based, and you could easily patch them - extremely important for "cut 0" chips.

From my experience, you might have a lot more to learn / and show at an interview if:
    - learn CAN / LIN / FLEXRAY, at leas CAN is easy / common and you can play with your vehicle, if you can get your hands on the CAN message database (or reverse engineer it)
    - learn robust hardware design - how to protect inputs from noise / junk, how to detect that external hardware is missing or defective (a button or an indicator, for example)
    - learn to design robust code - parameter checking, how to handle errors, how to perform runtime tests ( test RAM or some important sections at run-time, for example / run a chip-check in the bootloader section, perform safe firmware update - no bricking allowed )
    - learn how to design the code to be easily testable (TDD - test driven development )
    - learn how to build an automated testing system for software and hardware
    - learn how to document everything - as in design requirements, breaking them down to different software and hardware blocks, down to component and line of code
    - think about the FMEA ( failure mode analysis ) - what happens if the PLL does not lock, what happens if this CAN message has a bit field out of range, what happens if this pin goes open circuit, what happens if this variable is corrupted by the array that's next to it
    - get comfortable with assembler, very low level debugging, memory maps, linker files, optimizing every possible byte or instruction

Once you are comfortable with those things on a platform, you can switch to something else quite easy.

You'll learn a lot if you run through all these steps with a normal MCU that has cheaply available tools.

=> get your project through all those steps with a cheap arm that has all of your peripherals, dirt-cheap dev. boards and it's supported by open source tools + has a good community around.

The step from avr to an arm will be a hard one, so it might be a good idea to start from 0 - set up build env., set up debugger, learn to connect them - some basic openocd stuff (recover a chip when you accidentally reconfigure the jtag pins for example), then learn how to work with that chip from 0 - write your own low level drivers, etc - that way you'll get used to the hardware, learn how to understand the documentation, and learn how to debug.


(not very articulated at this hour, but hopefully I got the idea across)

[Mr. Scram]

Judging by your story it may not be what you're looking for but Atmel has automotive AVR variants, including the ubiquitous 328P. I've been wanting to tinker with a lockstep CPU but they tend to be complicated beasts with little documentation other than what the manufacturer supplied. Forget getting help or examples.

[MosherIV]

Hi
like a couple of others, I work on hv bms systems. One system I worked on used the TI Hercules tms570. It has the arm core r lock step. TI provide the development tools free. Hope that helps.
It is up to the software to then detect a failure in lock step and do something.

To achieve ASIL D, a failure mode effects analysis needs to be performed at system behavoural level to determine the system critical failures and recovery. The hardware being ASIL D is just part of the solution. The software is just part of the solution.

[Mr. Scram]

Hi
like a couple of others, I work on hv bms systems. One system I worked on used the TI Hercules tms570. It has the arm core r lock step. TI provide the development tools free. Hope that helps.
It is up to the software to then detect a failure in lock step and do something.

To achieve ASIL D, a failure mode effects analysis needs to be performed at system behavoural level to determine the system critical failures and recovery. The hardware being ASIL D is just part of the solution. The software is just part of the solution.

How complicated are the requirements and the peripherals to get going compared to more well know and basic MCUs? The Hercules chips always looked intimidating to me.

[mipl]

The TI Hercules from experience has lowest entry point from the development perspective. It is possible to Code Composer Studio, and there is additional tool (for free!) for the periphery, hw config. It is HAL or McAl layer, however I don't remember if Autosar certified version does not required fee. On top of that there is port of freerots lwip included. I saw few research projects uni plus auto makers using this with success. Not to forget that it was speed up in development.
As others mentioned ASIL is a engineering process,  so hw is only small part of it. In addition the ST, Infineon, Renesas automotive CPUs and tools you can get on a free market, but for some of the features you may need NDA. Then the problems starts because those fat cats would ask for the predicted volume and treat you accordingly...
Moreover if your demo app runs on arduino, then it should fit TI Hercules. The other charm it has there are variants not only dedicated to the automotive, but other safety critical industries as well. They tend to be more relax and easy going with handling low volumes as well.

[bobsaccamano]

Forget about ASIL, at least for the beginning, that is a whole extra level.

And have a look at ATSAMC21 as an inexpensive upgrade for an M2560 Arduino that is as a bonus available in automotive grade.

Thanks, I looked at the  ATSAMC21-XPRO Eval Board , but unfortunately it has just one CAN connector (I need two).  Do you have the name of the Automotive-grade board with that MCU?

Toolchain is ok. Compiler is available, GCC 4 series. We paid for openrtos but there is a port available for free for a similar part that could have been adapted. Code generation & drivers is not available - Vector wouldn't sell AUTOSAR at any price to a non-automotive company (we were aerospace). I ended up writing my own driver stack, which we probably would have done any way for tighter/better freertos integration. The S32k and S32S families look like they will be better supported by NXP with open non-rated SDKs in addition to the rated code provided by Vector.

That sounds like a lot of work. How necessary is AUTOSAR for Functional Safety? Are there decent open-source implementations? Is there an accessible practical tutorial to AUTOSAR for experienced engineers? Sorry for the barrage of questions

Judging by your story it may not be what you're looking for but Atmel has automotive AVR variants, including the ubiquitous 328P. I've been wanting to tinker with a lockstep CPU but they tend to be complicated beasts with little documentation other than what the manufacturer supplied. Forget getting help or examples.

Is there an Eval Board that supports two CAN connectors? The only one I found was this (and it doesn't have CAN)

Hi
like a couple of others, I work on hv bms systems. One system I worked on used the TI Hercules tms570. It has the arm core r lock step. TI provide the development tools free. Hope that helps.
It is up to the software to then detect a failure in lock step and do something.

To achieve ASIL D, a failure mode effects analysis needs to be performed at system behavoural level to determine the system critical failures and recovery. The hardware being ASIL D is just part of the solution. The software is just part of the solution.

Great insight, thank you! I've heard multiple people recommend Hercules now. TI generally has a good reputation when it comes to documentation, was it easy to work with the board?

The TI Hercules from experience has lowest entry point from the development perspective. It is possible to Code Composer Studio, and there is additional tool (for free!) for the periphery, hw config. It is HAL or McAl layer, however I don't remember if Autosar certified version does not required fee. On top of that there is port of freerots lwip included. I saw few research projects uni plus auto makers using this with success. Not to forget that it was speed up in development.
As others mentioned ASIL is a engineering process,  so hw is only small part of it. In addition the ST, Infineon, Renesas automotive CPUs and tools you can get on a free market, but for some of the features you may need NDA. Then the problems starts because those fat cats would ask for the predicted volume and treat you accordingly...
Moreover if your demo app runs on arduino, then it should fit TI Hercules. The other charm it has there are variants not only dedicated to the automotive, but other safety critical industries as well. They tend to be more relax and easy going with handling low volumes as well.

Excellent insight, thank you! Do you mind sharing the links to the research projects? That would be really helpful. At the moment, AUTOSAR and certification are not the main concerns, only development time, firmware support and some safety features. So, Hercules definitely looks promising.

[bobsaccamano]

Forget about ASIL stuff and even dedicated mcu's if you're not doing some safety critical stuff.
Most OEM's will go for the cheapest hardware, so no specialized mcu's if they can. (let the software guys handle it ...)

I am doing safety critical stuff, hence I do need dedicated MCUs. Not concerned about volume/pricing.

The MPC / SPC series is nice if you don't have to write the Autosar MCAL drivers for it ...

Is there a way to run MPC/SPC boards without Autosar? I don't want to write device drivers/HAL at this stage.

A good debugger will be the difference between throwing the board out the window and understanding why the chip is doing something that makes no sense.
(like PLL's having the locked flag set, but behaving like wide band jamming devices, or having to set / clear a lot of undocumented bits / registers to make something work)
We used Lauterbach debuggers because they could be easily automated / integrated in the test env.

I've used Lauterbach debuggers for DSPs - I remember they were very pricey. My application code is not very complex (at least in Arduino ), hence if I could get away with JTAG/SWV that would be preferable.

Also, the MCU definition files where text based, and you could easily patch them - extremely important for "cut 0" chips.

I don't understand this, could you please elaborate?

From my experience, you might have a lot more to learn / and show at an interview if:
    - learn CAN / LIN / FLEXRAY, at leas CAN is easy / common and you can play with your vehicle, if you can get your hands on the CAN message database (or reverse engineer it)
    - learn robust hardware design - how to protect inputs from noise / junk, how to detect that external hardware is missing or defective (a button or an indicator, for example)
    - learn to design robust code - parameter checking, how to handle errors, how to perform runtime tests ( test RAM or some important sections at run-time, for example / run a chip-check in the bootloader section, perform safe firmware update - no bricking allowed )
    - learn how to design the code to be easily testable (TDD - test driven development )
    - learn how to build an automated testing system for software and hardware
    - learn how to document everything - as in design requirements, breaking them down to different software and hardware blocks, down to component and line of code
    - think about the FMEA ( failure mode analysis ) - what happens if the PLL does not lock, what happens if this CAN message has a bit field out of range, what happens if this pin goes open circuit, what happens if this variable is corrupted by the array that's next to it
    - get comfortable with assembler, very low level debugging, memory maps, linker files, optimizing every possible byte or instruction

Once you are comfortable with those things on a platform, you can switch to something else quite easy.

Great list, thank you!

You'll learn a lot if you run through all these steps with a normal MCU that has cheaply available tools.


=> get your project through all those steps with a cheap arm that has all of your peripherals, dirt-cheap dev. boards and it's supported by open source tools + has a good community around.

I was thinking of going with an STM32F4 Discovery board as it is well documented and easy-to-use.

The step from avr to an arm will be a hard one, so it might be a good idea to start from 0 - set up build env., set up debugger, learn to connect them - some basic openocd stuff (recover a chip when you accidentally reconfigure the jtag pins for example), then learn how to work with that chip from 0 - write your own low level drivers, etc - that way you'll get used to the hardware, learn how to understand the documentation, and learn how to debug.

Cool, thanks again. Any further advice/insights, please do add on

[MosherIV]

Hi
TI provide a utility which generates the driver code and start up code for the peripherals. Just include this code in your project. Their equivalent of STMCube.

I believe the has 2 CAN ports. One has more COB masks than the other. This can be overcome by decoding CAN in software stack.

AUTOSAR is not necessarily a safety requirement. It is actually an interface specification to allow vehicle manufacturers to use a standardised interface for components instead of manufacturers propriatery interfaces.

Forgot to mention, Ive also used Infineon xmc4400 and xmc1400 on auto motive. I would not recommend them, no lock step. Pre built COTS controller board used them as a main and supervisor arrangement. The tools from Infineon are worse than TIs CCS

[ealex]

hello

I am doing safety critical stuff, hence I do need dedicated MCUs. Not concerned about volume/pricing.

Safety is about the process, and not about a specific hardware and software choice.
You can create a safety system with off-the-shelf parts, but you'll need to be able to prove that you've covered all possible failure modes, how to mitigate them, and how to get the system in a "safe state" - reduced or no functionality, but a state where it can do no harm.
That part will also cover you when the system fails in some unexpected way - see the "Sudden acceleration" feature that toyota had in some of their cars.
If a safety system developed by you fails doing it's job, you / or your company are on the line.
Even at Freescale, we where personally responsible for the safety stuff.

Is there a way to run MPC/SPC boards without Autosar? I don't want to write device drivers/HAL at this stage.

There is no need for the Autosar layer, it's just a set of interface standards agreed in the automotive world.
There are open source implementations, and you can freely get the standards and all of the documentation.
Practically, the OEM does not want to write everything from scratch for each chip (and spend a ton of time debugging it) => think of it as STM32CubeMX for automotive / or the Arduino env. you already know.
For example, just the clock tree, clock distribution, and power management parts of a MPC55xx will take you several weeks to understand and get going. 256x32 bit registers just to specify which peripheral gets connected to what clock source in whatever power mode you are right now (and the CPU's are on that list as well)
Then the power mode switching state machine, that interacts with all clock sources and can get stalled if something does not look OK.
Take a look over the reference manuals, and then think on how much time and budget you can spend on getting the chip able to run your code.

I don't understand this, could you please elaborate?

It's pretty much having to deal with engineering samples - the management's goals where to have a fully tested code release the day the chips where available to the OEM => we had to work with untested chips => a lot of fun and frustration for the devs.

[Jeroen3]

Isn't the only difference between industry and automotive parts a tighter spec, longer availability and ECC/lockstep options?

[Siwastaja]

"automotive part" is completely meaningless, any manufacturer can mean anything arbitrary with it. Sometimes just temperature ranges, sometimes simply nothing.

What's discussed here are some actual certifications, meaning some of the design-for-certification engineering burden have been taken care of. This also means there's a truckload of paperwork available from the manufacturer. For relevant discussions, the actual certification names must be used.

[NivagSwerdna]

ASIL-D doesn't sound like a hobby project...

"ASIL D represents likely potential for severely life-threatening or fatal injury in the event of a malfunction"

ATSAME51 maybe but it really depends on your requirements and which eco system you will be happy in...

... tell us more and don't kill yourself or anyone else!

[voltsandjolts]

Choosing to do a pretend safety rated project as a hobby project??

Maybe something more enjoyable would be to rub a few hundred 0402's into your eyes.

Safety related stuff sucks ALL the fun out of electronics and programming and leaves you dreaming of a different career.
Or maybe its just me.

[Scrts]

"automotive part" is completely meaningless, any manufacturer can mean anything arbitrary with it. Sometimes just temperature ranges, sometimes simply nothing.

This isn't true. If the datasheet states that there's automotive qualified part available, it means that the part has passed AEC-Q100 testing. There's also AEC-Q200, but it's for passive components. Many OEMs do not allow using non AEC components, not even passives, so there was a tremendous issue when the world got into ceramic capacitor shortage.

[Siwastaja]

Safety related stuff sucks ALL the fun out of electronics and programming and leaves you dreaming of a different career.
Or maybe its just me.

Actually thinking about the actual safety, calculating design margins, simulating edge cases, measuring actual performance, and so on, is very rewarding, but I can totally see how seeing the metric shit-ton of paperwork on pretend-safety tailored to pass certification processes, while having to ignore (as per the bosses orders) all real safety issues you can't avoid seeing sucks the life out of you.

The hobbyist at least has the option of putting effort towards actual safety, and not having to listen anyone forcing them to ignore issues that arise.

[Siwastaja]

"automotive part" is completely meaningless, any manufacturer can mean anything arbitrary with it. Sometimes just temperature ranges, sometimes simply nothing.

This isn't true. If the datasheet states that there's automotive qualified part available, it means that the part has passed AEC-Q100 testing. There's also AEC-Q200,...

... and also AEC-Q101. In any case, datasheets of parts passing AEC-Q100 obviously state "AEC-Q100" in the datasheet. I mean, if I pay for all the testing required to pass a standard X, and pay for the (possible) royalties, I sure as hell want to state that on the datasheet.

If I only see "automotive" claimed, I would not make an assumption it's AEC-Q100 (or any other specific standard) qualified, IMHO such assumption would be ridiculously dangerous, but your mileage clearly varies.

[voltsandjolts]

... while having to ignore (as per the bosses orders) all real safety issues you can't avoid seeing sucks the life out of you.

Erm, no. I would quite simply walk out of the door if that happened.

I just find that the majority of the work on safety rated projects is done in spreadsheets, text documents, emails and phone conferencing. Yuk.
Less than 20% of my time is in 'real' engineering and Altium (which is the bit I enjoy).

The hobbyist at least has the option of putting effort towards actual safety, and not having to listen anyone forcing them to ignore issues that arise.

Yeh, skipping all the paperwork and third party assessments makes it more appealing but then its no longer a safety rated project.
It's just playing around with a dual core lock-step micro.

[bobsaccamano]

Yeh, skipping all the paperwork and third party assessments makes it more appealing but then its no longer a safety rated project.
It's just playing around with a dual core lock-step micro.

Yes, the goal is not to get assessed/certified but rather do an efficient "dry run" of the FuSa lifecycle (from safety concept to V&V) in order to gain experience and understand the pitfalls. Some of the building blocks are in place, ex. requirements management but not to a certifiable level (Using an approved requirements management tool with the correct TCL).

I realize that this approach might be heretical (even insane) in the Safety/Automotive community and that is why views and advice from experienced folk are very welcome.

[Rudolph Riedel]

Forget about ASIL, at least for the beginning, that is a whole extra level.

And have a look at ATSAMC21 as an inexpensive upgrade for an M2560 Arduino that is as a bonus available in automotive grade.

Thanks, I looked at the  ATSAMC21-XPRO Eval Board , but unfortunately it has just one CAN connector (I need two).  Do you have the name of the Automotive-grade board with that MCU?

There is none directly from Microchip but it does not really matter.
First of the normal version is pin and code compatible, so for evaluation there is no need to use the automotive version.
And you can easily connect a second transceiver to the extension headers.
PB14 is CAN1_TX and connected to EXT1 Pin 9.
PB15 is CAN1_RX and connected to EXT1 Pin 10.

You need your own board anyways - if things go beyond evaluation.

[mipl]

Do you mind sharing the links to the research projects? That would be really helpful. At the moment, AUTOSAR and certification are not the main concerns, only development time, firmware support and some safety features.

Some links in case TI Hercules is still under consideration.The TI GUI tool for the CPU configuration https://www.ti.com/tool/HALCOGEN, some would have to get used to generated code. However, the generated code tend to be direction in case of safety related functionality. The verification of the correctness is on the different level...
Example of a project focused on a standard, not application related, functionality http://loszi.hu/works/ti_launchpad_freertos_demo/.
Research paper describing one of many aspect in the safety development consideration. http://home.mit.bme.hu/~kollar/papers/Scherer-Graz.pdf
Even the CPU is capable of safety related computation (lockstep / ECC / etc.) it might be, that it still has to be supervised by external watchdog... depends on the system safety goals and decomposition of them.

P.S. Regarding other project it was someway interesting to experience disappointment when prototype develop on a fancy
ARM Cortex R4F had to be ported back to the humble PowerPC for the serial production...