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.

Safety Manual 文件的问题

您好,

我目前正在阅读TMS570的safety manual(SPNU550)

http://www.ti.com/lit/ug/spnu550/spnu550.pdf

其中的3.1节,有张图如下

可否请问此图的内容主要是用来说明什麽呢?

  • Hi Shunfan,

       首先,在安全系统中,系统的失效分为随机失效和系统性失效。随机失效时不能消除的,只能是提高检测随即失效的概率,这也就是我们芯片内部的那些安全模块所做的事情。而系统失效是可以通过提高管理机制效率和通过丰富的生产经验来达到降低甚至消除。

    我们这张图显示的就是我们建议的一个安全系统开发过程中的每一个具体过程,我们给出它的意思,就是给用户一个参考,帮助用户在系统设计之初,对安全系统有一个宏观的概念。同时在系统开发的过程中,严格按照这个流程来降低系统性失效的概率。

    谢谢

    ken

  • Hello Ken,

    谢谢您之前的回覆,我想再询问一些safety manual的问题

    关於以下这张图,我看了说明之后还不是很清楚,可否劳您跟我说明一下

    三个颜色(红色、蓝色、黑色)之间的一个差别?

    Best Regards,

    ShunFan

  • Hi Shunfan,

       这是个很好的问题,你真问到点子上了,这个是我们安全MCU里最重要一张特性介绍图。

    首先,红色部分,它的英文名叫safety island,我们可以叫它安全岛。它是芯片内部关于安全功能最重要的核心模块。它包括我们的memory,BUS,和所有的安全诊断硬件机制。我们只有保证这这些模块工作正常,才能用他们去检测其他的模块是否正常。举个例子来说,首先我们得确定LBIST工作正常,然后才能用它去检测我们各个外设的RAM空间(包括register)是否正常;或者说我们得先确认DCC模块工作正常,才能用它来检测我们外设的时钟或是系统外接的时钟工作正常。

    其次,蓝色部分,是我们芯片的板载资源。它主要是各个功能模块,对应的是其相应的各个硬件功能以及其具有的相关安全机制。比如说外设传输数据时的自动奇偶校验功能,I/O的loop back回环检测功能,ADC模块自检测功能,以及ADC共享通道的冗余检测功能等。 

    黑色部分,是我们芯片内部的非安全功能模块,一般是相关开发和调试模块。

    希望这样的描述,能帮助你理解我们的安全芯片。

    如果还有什么不清楚的地方,可以随时提出。

    谢谢

    ken

  • Hello Ken,

    请问在safety manual最后的附件中,有TI建议的safety function的表格如下

    它最后一栏,Possible Latent Diagnostics,所代表的是什麽意思呢?

  • Hi Shunfan,

       Possible Latent Diagnostics,,指的是潜在的可能还需要诊断的项目。

    它这个主要还是和安全规范有关,在ISO26262或是IEC61508关于processor的安全检测章节里面规定了,针对于Processor哪些内部的功能模块需要做什么样的安全检测。举个例子说,针对于电源模块,针对于不同的安全等级要求,在需要你的系统有外围的输入电源电压检测电路之外,还有可能会要求你的芯片内部有供电的电压检测包括过压或是欠压,同时有相应的机制来保证Processor检测到电源有问题时,做出什么样的反应。是重启,还是一直保持reset状态。

      因为我们提供的是芯片内部的安全检测机制,所以针对电源模块,我们首选规定强制的检测手段是芯片内部的电源检测模块,同时外部的电源监控手段对于我们芯片来说就是潜在的诊断项目了。

       换句话说就是针对一个检测项目,你有首选做的测试条款,也有按具体的安全规范的要求,需要另外做的项目。

    不知道这样解释,你能不能接受。

    谢谢

    ken

  • Dear all,

    在Safety Manual中,

    有很多项目都有 Periodic Read Back of Configuration Registers 跟 Software Read Back of Written Configuration

    有人能跟我简述一它们之间的不同吗?

    Periodic Read Back of Configuration Registers

    Periodic read back of configuration registers can provide a diagnostic for inadvertent writes or disturb of
    these registers. Error response, diagnostic testability, and any necessary software requirements are
    defined by the software implemented by the system integrator. The use of read back of configuration
    registers mechanism is recommended.

    Software Read Back of Written Configuration

    In order to ensure proper configuration of memory-mapped clock control registers in the system module, it
    is highly recommended to software implement a test to confirm proper operation of all control register
    writes. To support this software test, it is highly recommended to configure the system module memory
    space as a strongly ordered, non-bufferable memory region using the Cortex-R4F memory protection unit.
    This ensures that the register write has completed before the read back is initiated.

  • Shunfan,

      关于这两个安全机制的应用场合,我也不是太清楚。我们的safety manual里面更多的是在针对不同的外设模块提供了类似于period software readback 或者是software readback 的安全机制。其实read back这种机制在很多的安全文档俩面都会提到,我个人觉得的是,应用哪种安全机制,很大程度上取决于安全标准关于它的定义。它要求我们的软件具备哪种读回的安全机制。

    谢谢

  • Dear Ken,

    我後来有个想法是这两种都是用来读回寄存器的状态,并比较是否和我们的需要相符,

    只是一个是周期性的检测,譬如利用中断每多久检测一次,一个是在写值後检测。

    跟您分享我的个人看法

    谢谢

  • Dear Ken,

    针对Safety Manual的文件中,有个项目如下,不晓得你那边是否理解下面的这个功能,可以解释一下。

    5.10.8 SRAM Bit Multiplexing

    The SRAM modules implemented in the Hercules architecture have a bit multiplexing scheme
    implemented such that the bits accessed to generate a logical (CPU) word are not physically adjacent.
    This scheme helps to reduce the probability of physical multi-bit faults resulting in logical multi-bit faults;
    rather they manifest as multiple single bit faults. As the SECDED SRAM ECC can correct a single bit fault
    in a logical word, this scheme improves the usefulness of the SRAM ECC diagnostic. Bit multiplexing is a
    mandatory feature of the architecture and cannot be modified by the software.

    Best Regards,

    Fan

  • Shunfan,

       我个人的理解是,首先这是芯片内部架构关于on-chip RAM的一个检验机制。它在芯片内部做了一个寻址位复用的机制,因为我们内部的RAM是支持1个bit自动校正,2个bit报错(SECDED)的机制,现在这个位复用的机制可以减少芯片内部寻址位两位出错的而导致RAM里面存储的数据或指令出现两位错位的概率。

     你可以简单的理解这个是对RAM校验机制的一个功能,和SEDDED功能一起运作,降低RAM出错的的一个有效机制。但是这个对用户来说是透明的。

    不知道这样解释,你有没有什么其他的疑问,我们可以再讨论一下。

    谢谢

  • HI, KEN,

         我看到诊断库说是按照safety manual来实现的,经过一段时间的研究发现诊断库只是对一些插入错误进行检验,根本就不是实现safety manual。这些诊断对我们没有太多的帮助。

  • Ron,

      诊断库确实是按safety manual里面提到的各种检测随机失效的功能模块来设计的,因为是随机失效,在现实的应用场合中,这些失效出现的的概率非常小,我们不肯能直接去等待错误的出现吗,然后再去测试。

       所以我们设计了错误插入的方式,来设计各种随机错误的出现,从而测试我们的安全机制是否能够检测到并快速的反应。同时这也是测试你软件功能的诊断覆盖率的一种检验方法。

       你在做安全系统认证的时候,你的软件需要过诊断覆盖率的认证,如果你不用这种错误插入的方式来测试,你的代码覆盖率达不到90%或是99%,这样的话,就比较麻烦了。

    当然,诊断库的另外一个作用是展示出我们的安全机制,因为对于很多入门者或是对功能性安全不了解的人来说,芯片能做什么样的功能,有什么样的表现,这个对用户的操作来说比较透明。所以有了诊断库的错误插入机制,会更直观一些。

    以上是我的看法和理解,如有疑问,我们可以继续讨论。

    谢谢

  • 谢谢你的回答。safety  manual中有一个表格,列出对各种模块的诊断项目。如对FLASH

       我想选择FLA1,FLA2,FLA3,FLA4,FLA6,FLA7,FLA8,FLA9.这几项诊断。其中只是诊断要求具有ECC功能,而在诊断库主要是如插入1 bit或2bit错误来诊断FLASH,诊断的主要看如果发现错误ECC校验逻辑是否正确。  ECC校验逻辑本身是用来诊断的,其实这就是对诊断的诊断,我们通过IEC61508 SIL3认证不需要对诊断再过诊断。这是我自己的理解。