|
本篇属于汽车功能安全专题系列第10篇内容，我们开始聊汽车功能安全软件开发相关内容。 08 - 汽车功能安全(ISO 26262)系列: 硬件开发 - 硬件随机失效概率化评估 09 - 汽车功能安全(ISO 26262)系列: 硬件开发 - 随机硬件失效量化FMEDA 在功能安全系统开发阶段，我们已经得到了技术层面可实施的技术安全需求TSR，并将其分配至系统架构中的硬件(HW)和软件(SW)组件，接下来以此为基础进行相应硬件和软件功能安全开发。
鉴于内容较多，我们这篇来聊前两部分内容。 01 软件开发模型
 1 规范及流程的存在是为统一标准，为让大部分普通工程师在其约束下也能够开发出一流产品，保证产品质量一致性。 2 条条大路通罗马，只要企业内部开发流程完善，并不一定完全按照ISO 26262，ASPICE等规范进行开发，规范的存在也只是提供指导，帮助企业建立及完善自己的开发流程。研发流程的存在虽然短期会增加研发工作量，但长远来看绝对利大于弊。 3 企业研发流程的制定需要结合企业规模，内部组织结构，企业文化多种因素考量，选择适合自身发展的开发流程。 4 规范及流程必须合理有效且能够付诸于实践。尽可能利用相应的开发，管理工具链，加速流程的应用和管理。例如，ASPICE和ISO 26262要求开发需求，软/硬件，测试用例之间的可追溯性，如果没有强大的开发工具链支持，其工作量巨大，且可用性也差。 5 考虑到成本及可行性，对企业开发能力的评估也只能采取样本认证，即对其开发流程和具体样本项目进行评估，无法覆盖企业所有项目，这是所有认证的共性问题。而企业是否能够坚持标准，应用于所有开发项目，取决于企业自身的坚持，我相信我们还有很长的路要走！ 02 什么是软件安全需求？ 功能安全软件开发始于需求开发，即软件安全需求(Software Safety Requirement, SWSR)，而SWSR源于分配至软件组件的TSR，是软件相关的TSR在软件层面的进一步细化。 SWSR定义相对比较简单，但需要注意的是，很多朋友认为只要定义软件相关安全机制就足够了，其实除此之外，SWSR还包含和安全机制无关的SWSR，它是保证功能安全的基础或支持内容，SWSR一般来讲:
1 使标称功能可以安全执行的功能等。 例如: 软件安全运行相关基础软件，包括操作系统，时钟，运行模式等。 2 在生产、运行、服务和报废过程中与车载测试和非车载测试相关的功能。 3 允许在生产和服务过程中对软件进行修改的功能。 4 软硬件接口规范要求。 5 对软件功能和特性的要求，包括对错误输入的鲁棒性、不同功能之间的独立性或免于干扰、或软件的容错能力。
1 与应用软件本身、基础软件或操作系统失效探测、指示和减轻有关的自检或监控功能。 2 与安全相关硬件要素故障探测、指示和减轻相关的功能。 3 使系统达到或维持安全状态或降级状态的功能。 例如: 错误管理，安全状态等。 1 在实际操作中，除安全机制相关的SWSR外，还需要根据适用性，充分考虑上述提到的非安全机制相关SWSR，尤其是软硬件接口规范和FFI免于干扰的安全需求，它们是保证软件功能安全重要内容。 2 FFI免于干扰的安全需求多和基础软件相关，部分属于安全机制。在实际操作中，一般会将SWSR分为应用层软件安全相关和基础软件相关的安全需求，便于后续独立开发。 软件需求作为后续软件开发的重要输入，其质量很大程度上决定了软件开发质量，所以写好需求是门技术，需要对系统及Stakeholder需求有充分的理解，这也是为什么近几年需求的定义和管理越来越收到企业重视的原因。 鉴于此，接下来我们聊一下软件需求书写实践原则，具体包括以下内容：
网络上有很多需求文档书写模板，包括RUP版本，Volere版本，ISO版本，SERU版本等，大家直接关键词搜索即可，在此不再赘述。
|
|
|
