• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 663 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28388D: Functional Safety: ISO-26262 ASIL-D software requirements allocation to TMS320 controllers.

Yasser Fathy
Prodigy 40 points
Part Number: TMS320F28388D

Tool/software:

Hello and thank you for your support.

We're working on a power management ECU for the automotive industry, it has to be certified according to the Functional Safety - Road Vehicles standard ISO-26262. following the safety analysis, we have software requirements that will be allocated ASIL-D integrity level (SIL3).

We are considering the use of the TMS320 family of controllers, reviewing its functional safety capability and certification we can see the following statement mentioned. 

– Systematic capability up to ASIL D and SIL 3
– Hardware capability up to ASIL B and SIL 2

So to be able to assign ASIL-D software requirements to the controller, we are considering the use of two controllers, one acts as a main controller, and another smaller one acting as a checker controller, both will be integrated according to the safety manual to achieve ASIL-B hardware quantitative rating, and independence among the two will be ensured, effectively performing a decomposition on the probabilistic quantitative side of the analysis, while the systematic side is certified by TI.

I would like to get your opinion on that approach, I have not previously used controllers that make that distinction between the systematic and probabilistic ASIL rating, also if different approaches are recommended I would be happy to hear it.

Thank you.

  • 0
    TI__Mastermind 27641 points

    For ASIL decomposition you will be asked to demonstrate "sufficient independence" between the decomposed elements. Using different MCUs (even if from the same manufacturer) is a good step in demonstrating this independence, but you must also consider the IP (peripherals) used in the primary MCU and the backup MCU. If it's the same IP (ADC, C28x CPU, same software, etc.), you may still be challenged by your safety assessor. 

    Diversity of systematic processes is not necessary, per my understanding. So even if you use MCUs from the same manufacturer you should be ok from that perspective. 

  • 0 in reply to Gus Martinez
    Prodigy 40 points

    Thanks Gus for your response, appreciate it.

    My thinking is if the controller was rated as ASIL-B from both its systematic and probabilistic aspects, then a decomposition would require diversity on the architecture and IP side to avoid systematic faults (an undiscovered HW design bug), and the duplication of elements and reciprocal comparison would address the hardware probabilistic fault possibility.

    But since here TI states that the systematic aspects of the controller are ASIL-D rated, then my thinking is that I don't have to use HW diversity, and duplicating the units would address the probabilistic ASIL-B side, but I haven't seen that that distinction made before so I wanted to get other opinions.

    In any case appreciate your response.

  • +1 in reply to Yasser Fathy
    TI__Mastermind 27641 points

    Hello Yasser,

    Apologies for slow response. The ASIL D systematic capability of our MCUs does allow you to implement decomposed systems. Whether that removes the requirement for HW diversity or not is a matter for you to consider. Certainly having HW (and by extension SW) diversity makes the case for independence straight forward. However, even duplication of HW in a decomposed system may still be possible if you can demonstrate "sufficient" diversity in the implementation of the safety goal. This could entail different methods for sensing, different CPU algorithms, etc. I don't have specific guidance to give, but as you probably already realize, ISO26262 does leave plenty of items up for interpretation.