安全控制器研发心得

从2019年5月份接手安全控制器项目，同年10月份从TI的TMS570更换为INF的AURIX平台，到22年6月末，历时3年终于获得TUV莱茵认可，正式颁证，且为莱茵大中华区相关领域发出的首张证书。作为主要项目成员，负责硬件设计、前期底层驱动攻关、以及所有审核文档的管理提交。整个认证过程比较顺利但也有曲折之处，同时我司除莱茵之外，也有项目在国内SGS和北德认证，对于认证机构、标准、开发过程从一头雾水到逐步清晰，感触颇多。写点心得，希望对国内这块相关技术发展有所帮助。

一.认证机构篇

1.机构

目前国内认证机构主要有TUV莱茵、TUV北德、TUV南德和SGS这几家。每家的认证风格，认证费用，资质范围等有所差别。莱茵审核比较严格，终审在德国进行，认证周期长，认可度比较高。机构这方面曾遇到过两个问题，一个是一家出的证另一家不认；一个是国内发的证国外不认，最后加钱补做国外的证。因此认证之前需要仔细评估，认证的目的最终还是销售产品，如果最后证书不被认可，会造成比较严重的后果。

2.审核员

审核员在认证过程中的作用在于知识培训，咨询辅导，文件审核，流程控制等。角色及其重要，其技术背景和业务能力，直接关系到项目进度和质量。如果之前从事过相关行业硬件软件开发，有一定技术积累，这样和公司技术人员对接起来比较顺畅。如果缺少技术和行业背景，只是熟悉标准，纸面带兵，认证之行就会比较难受，很有可能技术路线被带偏。

好的审核员就像老师一样，会抓住重点、理清思路，很多人刚接触功能安全，很容易纠结细节不见整体，不知如何入手设计，这时就需要审核员带路。从技术人员个人成长角度来说，审核员的答疑非常重要，我认为比具体文件的作用还大。这里给TUV莱茵的审核员点个赞，业务能力过硬，带领我们成功拿证。另外SGS的培训课程也不错，比较有体系。

二.安全标准篇

1.IEC 61508

基础标准，需要仔细反复研究。不同认证机构审核员对标准理解也不尽相同，如果有疑问，可以向不同认证机构咨询，看看他们对同一个问题是如何解释的。

2.ISO 13849

   工程机械行业很重要的标准，有些认证机构，只做这个标准的认证，这样费用和周期都比较少。

3.ISO 26262

   面向乘用车辆，工程机械行业暂时没有做。

三.开发费用篇

1.认证费用

各家认证机构费用各不相同，一句话，质量和价格是对等的。有的机构可能给钱就可拿证，文件少，中间辅导过程接近无，比较符合国内短平快的企业需求。

2.平台费用

   安全控制器的硬件平台主要有TI，NXP，Infineon三家。 TI，NXP平台费用较少，INF家固件库，诊断库，开发环境，仿真器都是比较昂贵的。单就仿真器而言，小公司一般很难承受劳德巴赫Tricore仿真器的价格。

   现在还有在非安全MCU运行诊断库，以达到安全完整性等级的做法，比如STM32，整体开发费用较低，不过某些行业某些场合使用有限制。

   软件平台主要是安全型CODESYS，CANOpen safety，以及配置工具，编译工具等，这也是很大一块的费用支出。

3.硬件费用

   这个项目第一次尝试14层盲孔工艺，打样焊接非常昂贵。后来优化了下，改成12层通孔就好多了。PAD点数1.5W左右，比一般产品多不少。器件费用，都是硬性支出不说了。中间由于诊断思路变化，外观变化，做了一次比较大的变更。多次打样，公司真是下了血本。

4.实验费用

  首先是安全类产品选择的第三方实验室，必须有相关标准实验资质。其次安全类产品实验项目较多，周期很长。主要分为两大块，环境实验和EMC实验。从开始实验到拿到实验报告总的耗时在2个月左右，本产品实验过程没有进行整改，基本是一次通过，比较顺利。

四.技术研发篇

1.平台选择

TT和INF都实际使用了，不过后来从TI平台更换为INF平台，这也是项目进展曲折的原因之一。TI平台资源相对较少，工业上应用较多，开发平台还是CCS，对于用惯2X系列DSP的技术人员比较友好。TI在电机控制这块沉淀较多，有些新能源的车辆选其用于功能安全的电机驱动器。不过近来市场供货存在很大问题。

INF的AURIX平台比较合适车辆相关应用，端口多，资源非常丰富，可靠性没得说，车辆应用首选。其XMC ARM内核的MCU也支持安全相关应用，市面部分电机控制器有在使用。INF不太理想的地方就是价格贵，技术支持有限，现在的市场状况下，供货依然存在问题。

NXP现在公司合作的BMS项目开始选用S32 ARM系列MCU，以前Power Architecture架构的比较老，现在不大用了。整体资源还是偏少，没有深入使用过。

ST的STM32平台，MCU本身不是功能安全的，加上ST提供的诊断库后，可以到达SIL3/PLe等级。此诊断库，我在F4和L4上分别评估过，移植挺顺利，但基本属于纯软件诊断(硬件CRC可以选择参与诊断)，耗时比较长，影响事件响应的实时性，所以使用中需要严格限制安全相关资源的使用。在安全相关的传感器和部分低要求安全控制器上，还是有应用市场的。某些场合对主MCU的安全等级有要求，所以STM32平台用于安全相关产品有一定限制。

2.硬件架构

   目前市面上安全控制器(主要是国外品牌)架构主要有CAT2和CAT3两种(按ISO 13849分类)，CAT3架构由于冗余程度较高，成本翻倍，所以一般IO点数比较少，典型如Epec SC52。CAT2架构点数相对比较丰富，如IFM的CRS721S和TTControl的TTC580。此次我们的产品采用CAT2架构，安全相关输入部分全部采用冗余架构，安全相关应用运行于MCU带锁步的安全核，非安全相关应用运行于MCU普通核。辅助以配套的安全监控芯片，以达到较高的诊断覆盖率。

3.软件架构

   软件组件包含：MCU固件库，诊断库，安全型组态软件CODESYS，CANOpen Safety协议栈等。工作量巨大，这里就不细说了，总之不是一两个人的活，需要团队协作开发。这里面有很多坑，网上资料很少，一般只能靠自己摸索，原厂支持有限。

4.文档编制

国内技术工程师比较明显的弱点就是写文档不行，东西能做出来，写文档描述就束手无策。而公司德国部门的同事，文档写的非常好，图文并茂，有理有据，清晰简练(可能和他们项目周期长，年假多有关系)。此次功能安全控制器的认证，所需的是系列文档，文档数量多、内容多、各成体系，对于开发人员挑战较大。这时候需要认证机构审核员提供模板、指导文档编写。

安全概念是功能安全产品的核心文档，详细描述安全架构和诊断机制，需要前期和认证机构反复沟通修改。

5.测试实验

   包含两个方面，一是公司内部进行的模块测试，集成测试、故障注入测试、性能测试等，测试工作量是普通控制器的数倍，依靠人工测试是不现实的，为此专门开发了针对功能安全控制器的自动化测试系统；另外一个是第三方实验室的环境和EMC实验，这个需要实验室有相关资质，实验项目也要符合功能安全的相关标准，和普通控制器有不少区别，不过普通控制器的实验项目，安全控制器都会做，只不过引用不同标准。

6.项目管理

   认证不仅仅涉及研发，还有工厂、工艺流程等方面审核，是跨部门的项目。因此需要有一个及其“烦人”的、靠谱的项目经理，否则资源无法保证，进度无限拉长。当然最重要的是要有倾力支持的领导，而不是光问进度的领导。

五.总结

   功能安全控制器的研发成本很高，周期很长，目前在国内浮躁的开发环境下，很少有企业愿意试水。不少厂商“艺高人胆大”，沉迷于自声明，对于行业发展很不利。虽然功能安全认证，可以看作是国外给国内产品走向世界设置的一个门槛，但应该看到认证过程对于提升产品安全性、可靠性的确存在重大意义。

可喜的是，国内MCU厂商逐步发力，已有功能安全芯片问世，估计在不久的将来，就可以使用国内芯片开发功能安全产品了。