国内的主机厂和Tier 1正在加速开展功能安全工作，其中一些中等规模以下的供应商还没有开始，这里我们针对中小型供应商，介绍一下施行ISO26262的可行策略。
正式发行后的一年
ISO26262在2011年11月正式发布，一直处于观望状态的主机厂逐渐被要求全面实施。如一场运动一样，大的tier 1公司开始加速行动。
时隔一年之后，回想起来，对于汽车行业来讲，正确的理解ISO26262的需求、掌握这个工具、并产生明确的结果已经成为大势所趋。也可以借助ISO26262实施的机会，尝试解决开发上一直以来存在的问题。
虽然迄今为止，发行了很多国际标准，都没有得到有效的实施，对于国内的汽车产业来讲，对于一直不出成果的痛苦可能也是习以为常了。
因为ISO26262是面向安全的标准，如果不能满足的话，会面临更高的经营风险，比如海外市场开展业务，发生问题时赔偿金额很大。因此，应该尽早的量体裁衣、根据开发情况作出调整，以满足标准要求。目前，在商务上好像已经要求满足功能安全标准才能给出预测或订单。那么，是优先解决开发问题好，还是优先调整体制好，这个判断有时候也比较难。
无论选择哪个，一定不要匆匆忙忙花了很多钱推进ISO26262的实施，后面只留下像山一样的各种标准文档和模板。
本连载的目的
汽车是国家支柱产业，从主机厂，分包商再到供应商这个产业链非常广，企业的规模也多种多样。
而ISO26262是一个以设计制造为中心，涉及到管理、系统开发、硬件开发、软件开发一直到制造的大型的标准，这就意味着，ISO26262是汽车开发领域大大小小的企业都必须参照的一个标准。
但是，在ISO26262的推进上，中等规模以下的tier 1和Tier 2供应商需要和实力雄厚的大企业进行一样的工作吗？至少之前提到的“先建立体制，现场的实际调整后面再做”这种应对方式可能有点困难。必须要在较少的预算和有限的人力资源情况下，高效且富有成果的满足标准要求。
汽车工业是国家基础工业，如果中小企业推行了错误的ISO26262，结果就会陷入成本上升、技术能力下降、国际竞争力下降的漩涡中。虽然不是简单的事情，但是也要有个措施避免这个情况发生。
ISO26262推行方法
图1是ISO26262推行的一般方法，这个流程不会一次就结束。建立的流程运转起来后，要把执行中的一些经验教训不断反映到流程中，在这样一种“持续改进”循环当中不断滚动。
図1 ISO26262推行的一般流程
根据企业实际情况不同，有流程实施和试点项目同步展开的，也有流程实施和部署不断往复的。但是基本上是按照这里显示的要素，按照阶段一步一步推进。
这个连载的目的，主要是基于我们做过的一些ISO26262实施相关的经验，给现在开始推行ISO26262的中小企业，介绍一下图1中提到的推进方法中各个阶段的课题以及应对方案等。
标准实施前的准备
ISO26262实施活动开展前，首先要理解”风险”这个概念，风险以及风险管理似乎一直是我们文化的一个弱点，但是在企业层面似乎没有意识到。
对于欧美的人来说，考虑问题的前提是“人类会犯错误”，“机器会有故障”，零风险或者绝对安全的系统是不存在的。他们认为，对于存在的风险(不存在零风险)明确的辨别出来，根据风险等级考虑最合适的解决方案是产品开发者的责任。当然，包括判别记录在内的这些活动必须是以第三方也能看得到的形式。
ISO 26262也是以这个为前提，考虑如果功能失效的情况下，评估其发生危险的可能性和破坏程度，并根据评估结果采取措施。关于应对措施，根据危险的结果，在ISO 26262规范中按照ASIL(Automotive Safety Integrity Level)A-D几个安全等级分类。
表1 ASIL不同等级的应对策略举例(软件架构设计的记法)
很多人都只关注列出的ASIL等级要求的条目本身，从短期的视角考虑如何应对。但是这里的应对措施表达的比较抽象，不太好理解。应该尽可能把目前的技术水平下想得到的最好的措施列出来考虑。当然，随着技术的进化，这些应对措施也应该是变化的。
ISO26262的理解上最重要的不是ASIL各个等级列出的应对措施和方法，而是之前说到的风险思维。精心的识别风险、并对采取的应对措施和开发活动是否能充分降低风险等级作出合理判断、带着“组织”意识去不断推进开发，这才是ISO26262规范的基本思考方法、思想和精神。
如果意识不到风险，就会导致根据要求的ASIL等级，只从如何满足ASIL等级出发来采取应对措施。往往由于交付节点、成本限制等因素导致忽视了安全活动。如果在下游工作中连新的危害也没有发现，那么ISO26262建设健康的“安全文化”的目的就没有达到。
如之前所述，ISO26262是管理、系统开发、硬件开发、软件开发直到制造，整个产品的设计开发中通用的规范。不过本连载目的不是为了解读标准，所以关于标准文件的解读，后续我们在NEWCAR单独列出。
图2是汽车开发流程中，主机厂，tier 1，tier 2这些供应商及其硬件和软件外包服务商负涉及到的范围，在Part2-9的标准文档中有列出来的。当然，这仅仅是标准的要求，实际情况是要根据一直以具体合作协议来定义责任和范围。
図2 汽车开发过程中ISO26262的职责范围及各部分的标准文件
标准适用对象
纵观ISO26262的全局，这是一个非常庞大的标准，不仅要理解自己负责的部分(比如软件)，还要考虑超出这个范围会不会更好。但是这个标准，充分阅读标准文件是一个方面，在此基础上，对思考方法和思想的理解是比较难的。虽然没有必要对各个部分的具体要求都去理解、探讨，但是至少要在自己负责的工作开展之前，事先理解需要推进哪些安全活动。
比如，对于Tier
2来讲，“Part 3：概念阶段”是主机厂和Tier
1负责的，不需要自己实际开展。要在理解上游的工作如何按照要求开展，他们会给自己分配哪些部分的基础上，开展业务。如果不这样做，安全活动就会出现很多差错。而且，一旦发现安全上有疏漏，就能够推导出正确的解决方案或者作出适当的选择，这也是需要有全局思想和理解水平的。
现在如果上游工作相关的功能安全领域还不是很容易理解，那么最低限度是要理解ISO26262追求的宗旨。
这样的考虑方法在航天领域已经被采用。为了减少下游软件设计过程中的错误，上游的人将卫星的运行和使用相关的要求以软件工程师也能参考的方式，尝试输入给软件设计团队。因为实际上软件设计工程师欠缺卫星使用的知识，不能理解全部的要求，但是即使理解一部分的话，也是能够防范一些设计错误的。
要实施ISO26262，也必须要定义好自己公司必须要负责的范围，还要确定谁来牵头，通过什么样的内部工作来推进。简单的说，推动工作是由技术部做还是管理部做。
另外，ISO26262大部分是对流程的要求，必须要定义好设计开发工作的流程，并严格的遵守。这个时候，是采用全新的流程，还是在原来流程(比如质量管理体系)上去修改，也是ISO26262推进工作在决策上非常重要的一点。
根据笔者的经验，质量管理部门主导的部分以及设计开发部门主导、质量管理部门支持的部分多一些。表2比较了质量管理部门和设计开发部门擅长和不擅长的工作内容。实际上跟企业固有的特征有关系，不一定非要遵循这个。
表2 质量管理部与设计开发部的擅长/不擅长
业务
质量管理部
设计开发部
过程定义和准备 | ○ | × |
操作手册和要领制作 | × | ○ |
经营理念 | ○ | × |
流程固化 | ○ | × |
流程的运用和推进 | × | ○ |
○：擅长，×：不擅长
ISO26262的施行需要把环境的营造、实际开发工作中标准相关内部流程的使用、固化等工作持续的开展下去。因此，需要从施行之后企业中长期的角度去考虑各部门的任务和职能分配。
关于风险的补充
这次我们提到了“风险”的思考方法和它的重要性，我们经常说“避免风险”或者” 风险太高”，这些都是都是些负面的词语。
但是，风险这个词来源于意大利语里面“带着勇气去尝试”的意思。ISO26262实施上也是要“面对问题，带着勇气去挑战”的姿态。可能这也是这个标准包含的一些思想和精神。
这次，我们只介绍图1中提到的最开始进入“准备”阶段之前应该注意的一些事项。下一次，我们介绍一下ISO26262开展的“准备”工作。
