前一篇文章中我们谈了实施功能安全的人员内部人力资源和团队组建问题，有朋友私信我说，似乎还没有提到企业内部一些评审专家的人力资源需求，这个意见很有道理，在功能安全项目实施的过程中，很多文件的评审不仅仅是让功能安全团队和开发团队内部人评审自己的产出物。
而更应该让其他部门功能安全专家集思广益，在某些功能安全要求高的项目，必须有组外专家和外部咨询公司专家来参加评审。实际的过程中，不像GM之类国际大厂，有多个很完整的功能安全团队可以交叉评审，都是刚刚开始做功能安全项目，很多公司在项目里面投入功能安全的人力都不足，评审也不可能邀请外界同行来看，所以只能依靠咨询公司的专家了。记得要签署NDA哦。
说完了人力资源，下面我们谈谈要投入的财力资源。
从产品本身的开发成本而言，投入硬件和软件方面成本的增加，前面的文章中，我们已经给了一个同行口头提供的数据。当然这个和你自身产品的现状与功能安全的要求之间的差距息息相关。不好明确估算。这里纠正一个很多boss的误解，在他们眼中花钱买的芯片啊元器件啊等看得到的，他们觉得有成本，对于软件方面，觉得横竖总是那么几个人，时间进度总是那么几天，投入的研发人力成本似乎是固定的，在功能安全上的投入的软件研发成本可以忽略不计一样。这个也是我们国家某些人对产品研发传统的意识作祟，总认为软件反正可以不断卖拷贝，几乎零成本，甚至可以盗版，算到成本中，也可以低到尘埃里。其实哪有那么容易，增加的功能安全在软件方面的工作量不说，光是按ISO26262标准中的建议，功能安全等级稍微高一点的产品都有大量的测试工作需要完成。
此外，还有一个非常大的开销要花在软件工具购买上，就是为功能安全搭建的配套软件工具链。很多公司原有的软件开发工具，要和供应商了解是否有功能安全的支持包和支持文件，这又要花一笔银子。因为那些软件开发工具的提供商在通过功能安全认证的时候，自己就花了一大票银子，所以，他也要考虑把以前的功能安全方面的成本收回来并且盈利，怎么收，当然从客户身上收，带功能安全和不带功能安全支持包的软件价格可是不一样的哦，其实，很多家软件工具的所谓功能安全支持包并不意味着他买给你的软件功能不一样，而仅仅是给你一个各种功能安全所需要的支持文件，证明他的软件的开发是符合功能安全开发过程，他的产品的评估认证文件等等。如果你是首次购买补齐工具链，一定要问清楚价格，综合考虑是不是一次性买好带功能安全支持包，要根据你项目的性质和咨询服务提供商确定比较好，省得花冤枉钱。
更进一步的，你也可以学这些供应商一样，面对你的客户，同样提供所谓“不含功能安全”版和“含功能安全”版，采用不同的价格策略，把你的成本进一步向下游摊销。
此外，选用的工具链一定要经过咨询公司的认可，因为毕竟认证是他们来做，你买的他们不认可，钱财就浪费了。
这里补充一个小问题，根据ISO26262的要求，采用的软件开发工具和测试工具都一般会要求满足功能安全要求，要经过专业机构的评估。但是，自己在项目开发过程中开发的一些好用的小工具呢？相信很多喜欢自己动手的程序猿是很喜欢做点提高效率的小玩意儿。我们找的咨询公司的大牛是这样和我们说的，毕竟在功能安全领域，开发工具就那么几家，所以，一般你买的，基本都还在他们了解的范围内，想找些不知名的能完成任务的都不容易。而自行开发开发的小工具，也很罕见能够超越这些行业大牛的，基本就是小打小闹，一般而言，都是比较简单的功能的，不需要什么认证，自己好用即可。但是，作为要输出咨询公司需要的各种评估必须的输出件，你用自己开发的小工具来执行和完成可就不行了。
等等，刚刚说到了工具链采购，要花一大笔，随便就是个几百万，对于连蚊子肉都要省下来的各位老板，肯定是心痛加肉痛。那我们采购工具来补齐功能安全工具链，需要注意什么问题呢？
在谈到工具链补齐之前，先补充一下前述的内容中一些疏漏和需要更新的部分。
首先，在上面写的“毕竟ISO26262的制定，就是背后有国际大厂制订游戏规则，提高行业进入门槛的身影，把后来进入者尤其是新兴国家新兴企业阻挡在门外。中国还没有机会参与制定，国际车企自己参与编写的标准，自然底气十足，对自身的体系小修小改就能满足要求有足够自信。希望，将来新的功能安全标准不断发展，能够有我们中国企业的身影和话语权。”有读者私下联系我说，我们国家也开始参与标准的更新工作了。的确，在GB征求意见稿中的文件编制说明中就有描述，其中提到“2015年1月，秘书处组建了中国代表团包括中国汽车技术研究中心、泛亚汽车技术中心、东软集团股份有限公司、舍弗勒贸易（上海）有限公司、CATL赴德国参加了ISO/TC22/SC32/WG8工作组会议，来自奥地利、比利时、中国、丹麦、法国、德国、意大利、日本、韩国、瑞典、英国、美国等12个国家70名代表出席会议，启动ISO26262第二版本的修订工作，包括软件工作小组、硬件工作小组、商用车工作小组、摩托车工作小组、Safety of the Intended Functionality Topic Group议题组、Fail Operational Topic Group议题组、Topic Group on Safety and Security议题组。”而且从这个描述看，预计2018年发布的新的功能安全标准，功能安全标准的覆盖面开始将扩展到乘用车向商用车和摩托车。
好，我们接着谈工具链的问题。
买工具链，最大的浪费不在于花了多少钱，而在于花了很多钱，但是没有充分将购买的工具充分使用起来。其实在功能安全项目的实施过程中，按我个人的理解，需要的工具是分两类，一种是属于必不可少型的，就是项目实施过程中，你完全无法避开的，比如统计系统各个硬件失效率计算单点故障，你如果手动做个计算表对照SN29500或者IEC62380中的数值来统计，非得让你疯掉。而有专门的软件工具可以很轻松帮你进行统计和分析。再比如，基于模型的开发，你不用大家常用的工具，也会事倍功半。另外一种是属于经商添花型的，比如输入输出文档的格式转换，很多工具的导入导出都支持多种通用格式，而你是否需要专门购买一个文件格式转换工具就需要自己考虑了。当然，我们的建议是，如果有足够多的经费，还是把工具链补齐，补充得越完善，越能节省开发时间，提高效率。
此外，购买工具链，要看一下你的客户一般常用的软件是什么，比如很多OEM供应商使用的需求管理工具是Doors，你就不得不也匹配上一个，否则发给你的需求每次还得他导成word给你，你完成后倒给他，虽然很多时候，用简单的word格式加上细致的需求跟踪矩阵也能完成同样的功能，但双方交互不便，很容易造成客户对你的抱怨。
最后，供应商给你推荐的工具链包含的工具，你要问清楚，哪些是有可替换选项的，价格如何。经常可以看到财大气粗的金主买了一大堆工具回去，结果只用到了一小部分功能，甚至有一些软件连开展使用都很困难就束之高阁了，对于要降低项目成本的公司而言要避免这种情况出现。要解决这个问题，我提个概念，就是工具链必须实现端到端打通，就是你必须让提供工具链给你的供应商演示和讲解清楚，甚至要供应商做一个demo样例，从客户需求到最终通过系统测试交付的产品，是如何通过工具链中工具一环扣一环，上一级输出作为下一级输入，逐步推进实现的。在这个过程中，各个工具发挥的作用是什么，哪些涵盖了功能安全标准的要求，哪些要求没有涵盖需要其他手段来补充。只有这样才能充分发挥工具链的作用，保证项目研发过程的顺畅，也避免了采购不实用的工具的浪费。无独有偶，在实际项目过程中，我们听说了有几家很聪明的公司对工具链供应商提出了端到端打通的要求，颇有英雄所见略同之感，别以为他们是那种抠抠搜搜的小公司，也有五百强呢。
不仅仅是软件工具链，在实施功能安全标准的项目中，MIL-SIL-HIL，整个开发和测试的过程，还要配置模型仿真，硬件仿真平台，模拟整车环境测试平台，做上车前的集成测试验证。这些也都要哗哗投银子。
此外，开发符合功能安全的软件，如果按ISO26262的要求，什么都自己开发的话，嗯，时间就不是一年半载那么简单，很多软件模块，比如通讯，标定，故障处理，都要花费大量的时间来不断测试和修改。所以很多厂家选择购买符合功能安全的基础软件来减少软件开发工作量，毕竟很多开发符合autosar架构的基础软件供应商的产品都已经非常稳定且满足功能安全要求，可以直接拿过来用了。
算算吧，光软件工具链搭建需要投资的几百万，加上硬件仿真，加上咨询公司的咨询百万咨询培训费用，如果你想花钱买时间，加快研发速度，还可以考虑花几百万购买基础软件，花几百万购买解决方案，粗略算下来要接近千万的费用哦。
好了，我们初步讨论了所需的财力资源，下一篇，主要谈谈自身研发能力现状分析对实施功能安全项目的影响以及对行业竞争对手状况分析，从而影响实施功能安全项目的决策。