从2019年5月接管安全控制器项目，从同年10月开始TI的TMS570更换为INF的AURIX到22年6月底，这个平台花了三年时间终于获得了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厂商逐步发力，已有功能安全芯片问世，估计在不久的将来，就可以使用国内芯片开发功能安全产品了。