适合才是最好的：中小企业如何做功能安全

        

开发功能安全产品需要投入很大的资源成本，对于中小企业管理者，面对竞争压力，自己的产品要不要做功能安全，怎么做。面对功能安全标准各种复杂的流程和技术要求，有些抓不住重点，即使通过努力取得了产品的认证证书，但感觉收获并不大，项目执行中还受到了很多羁绊。本篇以问答的方式，以具体实践讲讲中小企业如何做功能安全。

一，为什么要做功能安全

管理者首先要自问，我做功能安全的目的是什么？一般有以下2种情况：

1，客户有这个要求，要求提供的产品有功能安全认证证书；

2，行业已形成约定俗成的要求，对标业内同类竞品，达到行业同等水平.

对于情况1，如果这个要求是来自于用户要求，又不是很明确的情况。以前没有因为产品的安全性而受到很大压力，说明你的产品在实际应用中承担的安全风险不大，因此产品的安全等级不会高。除了功能安全，更要在产品的可靠性，性能方面多投入资源。

对于情况2，对标产品是业内普遍认为安全级别高，产品失效存在很大的安全风险。那你要考虑不仅是拿到一张认证证书的问题，还要考虑如何把功能安全要求与企业的实际情况结合，贯彻到公司的日常运作中，这样睡觉会比较踏实。

本篇讲的实践方法主要针对第二种情况。

二，什么人来主导做

在一个规模不大的企业，各方面管理体制不健全，主导者起主要作用。产品要做功能安全，最好是这个产品的技术总工或产品经理作为负责人比较合适。功能安全解决的不是什么都有，看上去很美的问题，如果是产品设计层面存在安全缺陷，流程再完善也无法弥补，技术负责人主导功能安全，有助于抓住重点。

负责人本身应积极学习标准，学习功能安全标准中关于产品技术要求、开发过程要求，理解为什么要这样做的背后原因。建立安全意识后，加上他在团队中的领导作用，各个角色的人就可以有序地组织起来。可以再搭配一个项目经理或质量经理作为副手，协助跟进项目内各专业的工作。

避免把功能安全等同于体系认证，交给负责流程体系的主管，按照体系做的功能安全，各个角色经常搞不清楚自己做事的目的，只作为完成体系工作交给的任务，浮于表面、效率低下。

三，组织内部如何分工

一个完整的项目组存在以下工作角色：项目经理，技术主管，需求工程师，研发工程师（硬件、软件），验证工程师，确认工程师，安全工程师，质量工程师，配置管理工程师。对于小的项目，避免人员冗余，沟通不畅，建议能合并的进行合并，比如项目经理和技术主管可以是同一个人，需求工程师和研发工程师可以合并，质量和配置管理合并。

在项目组织有两点展开讲讲：

1.安全工作如何开展

是否需要配一个专门负责功能安全的工程师，笔者认为如果组织中有功能安全项目经验的人，可以设定安全工程师，统管全局，但应注意适当授权。

如果组织中没有合适的人，没有必要拉一个人来做安全工程师，这样容易形成功能安全都是这个人的事，其它专业各干各的，无法形成一体。安全工作在项目前期主要是风险分析，需要熟悉产品应用场景、技术要求的人来做，最好是研发、验证参加一起来做，可以由研发或验证工程师把风险分析的过程和安全需求进行整理，形成危害记录册。

在项目中期随着研发的不断深入，硬件和软件各自的安全分析会形成更加细化的安全需求，补充到危害记录册中。在项目后期是对安全需求是否被产品所实现进行验证，由验证工程师进行跟踪比较合适。当然安全工作涉及的文档工作比较多，当研发、验证主要精力投入到系统设计和测试中，可以由项目组中其他人进行记录整理，研发和测试配合提供相应记录证据。

2.组织架构的独立性

功能安全强调组织架构的独立性，目的在于让组织中有独立于产品开发的一方对产品的最终功能、性能、缺陷进行判断，给出客观的评价。确认者在项目组织中，应有一定的权威性，简单来说，就是说话要有分量。他可能是测试主管，或质量主管，或产品经理，对产品需求和产品实现是否匹配有比较深入的认识。比较好的组织独立性设置是将验证与确认人员放在一起，与开发团队独立，这样确认者不是在产品确认阶段才得到所有证据，而是与验证人员一起或对验证的工作进行阶段性的检查，有助于在确认时获取全面的信息给出确认结论。

四，什么阶段第三方机构加入比较合适

把产品的开发阶段划分为阶段1（原型开发），阶段2（产品样机开发），阶段3（产品批量转产），做功能安全认证什么时候让第三方机构加入合适呢？分两种情况：

1. 当项目组中有对功能安全产品研发经验丰富的人，对系统的安全架构、技术要求有比较深入的理解，能够把握功能安全产品研发各阶段的要求。在阶段1时，第三方机构可以不必介入，集中力量先攻克产品的关键技术，做出产品技术方案，关键技术的概要设计等必要的技术文件。在阶段2开始时，第三方机构开始进行认证。

2. 当项目组中技术主管对功能安全开发要求了解不多时，最好在阶段1第三方机构就开始加入，做产品技术方案的预评估，避免出现颠覆性的问题。这个时候不必太纠结于文件的多少，技术方案细致清晰就可以。
   

五，功能安全在执行阶段抓什么重点

功能安全涉及到技术的安全措施，过程的安全管理，质量管理要求，中小企业很难做到面面俱到，应该抓住哪些重点环节呢？除了读者普遍熟悉的内容如产品需求的完整性、准确性、安全架构、风险分析、故障注入测试、型式试验等，再讲几个容易忽视的点：

1. 安全需求的细化：安全需求来源于风险分析，多数项目在完成初期的风险分析得到产品的安全功能后，后面就不再做风险分析了。这个阶段得到的安全需求只能作为安全目标，需要在架构设计、软/硬件设计中将安全需求进行分解。比如说为了避免共因失效，对二取二架构在系统风险分析会提出通道间独立性的要求，对于这条安全需求并不明确，需要在硬件设计根据不同的电压等级区分电气隔离要求，二取二之间的接口器件也有明确的隔离指标要求。在软件设计对双通道交互的数据进行安全分析，对数据的传输层和业务层的错误有明确的防护措施。这样细化的安全需求才可以指导设计，验证人员能制定对应的测试用例进行验证，以证明安全需求是否被正确实现。

2. 共因分析：系统安全分析常常主要关注系统内部的共因失效，忽视与系统接口的外部设备，操作用户，环境约束。由于开发成本的限制，采用异构架构的产品比较少，一般是相同的两通道或三通道实现安全架构，由于外部同一源头的数据错误、人员误操作、电气干扰可能会导致系统的独立性被打破，从而带来安全问题或系统可靠性降低。例如外部电源的波动或干扰，会造成系统运行中断或无法启动。在风险分析时，应结合应用场景进行完善的共因分析，不要把外部条件全部认为是完美的假设。

3. 变更管理：产品的生命周期中必然伴随着变更，变更的来源有需求变化，修补缺陷，设计优化。为了兼容可用性的要求，在变更中原有的安全需求可能会被打破，此时做的变更安全分析非常关键，变更影响的安全功能是什么，是否增加新的安全需求，原来的安全需求是否已修改，对于变更，应该设计哪些新的用例进行实验室的测试，在现场再做哪些测试以证明变更的有效性，这一系列的工作都是非常必要的。变更在产品生命周期会比较频繁，时间也很紧，重点把握需求、安全分析、验证这三个方面，对变更内容做充分的内部评审，做好沟通记录，以减少详细设计文档的工作量。

六，什么样的功能安全是成功的

项目组通过努力，拿到一个功能安全认证证书，并通过用户的肯定拿到订单，是一件值得庆祝的事情，这也意味着你的产品已经走上了正确的方向。此时项目组的每个人是否具有安全的意识，能够自觉地去理解功能安全标准，思考与自己工作的结合面，并在日常做好与功能安全关联的工作。在这条路上能持续走下去，保障产品整个生命周期的安全，这样做功能安全才是成功的吧。

注：笔者从事轨道交通功能安全工作，结合经验和标准的一家之言，不免存在偏颇之处，大家可以留言探讨。以上内容作为功能安全的通用性描述，对于其它行业的中小企业应该也是适用的。

码字不易，希望大家多支持转发。

原文始发于微信公众号（薄说安全）：适合才是最好的：中小企业如何做功能安全