符合iso26262的汽车电子软件开发流程

符合iso26262的汽车电子软件开发流程

附赠自动驾驶最全的学习资料和量产经验：链接

非常高兴今天还有机会跟大家有一个26262的交流，本身26262就是一个比较大的话题，我们现在来看一下在汽车行业，有这么一种说法，不造大家有没有听到过，叫做高完整性软件开发标准和基于模型的设计，汽车行业有一些开发标准，我这里给出一个表，横坐标是时间轴，1990年到2010年。纵坐标是关于这些标准的 关于基于模型设计的一些提法，如果这些标准干脆没有提到基于模型的设计，没有提到代码生成，没有提到仿真测试，我认为他干脆没有这样的概念，我把它放到零的位置上，如果提到一些相对比较破碎的概念的话，我把它放到1附近的位置，如果他有一个非常具体的，我们提到基于模型的设计在我们的开发里面有什么好处，在我们开发过程中如何使用基于模型的设计开发软件，我把它放到2.

1992年的时候我们有DO-178B这份标准，可能我们汽车行业的人对这份标准不是很熟悉，这是民航里面的一份标准，也是为了从安全角度考虑制定一份标准，那么我们可以看到在1992年的时候，根本还没有基于模型设计方面的概念。再看1998年的时候，著名的61508发布，其实61508也没有关于代码生成，仿真验证这样的提法，从61508派生出来的，比如铁路行业的50128，以及医疗器械行业的51511，也同样没有这样的说法。2004年的时候，NASA出了一份8917.13，NASA里面提到了代码生成，提到了使用simulink做仿真这样一些概念，他说他提到的这样一种开发方法可以改善开发过程，所以我们把他放到1和2之间的位置上，2010年的时候61508发布第二版，他提到了可以用代码生成工具去生成代码，61508有一个非常高的高度，他把代码生成工具放到编译器里面，他称之为一个翻译器，这说的很到位，其实代码生成工具与编译器就是一种东西，只是把一种形式的表达换成另外一种形式的表达，在50128里关于铁路领域的开发标准里面也提到了可以使用代码生成，做铁路领域的代码开发，在2011年的时候，26262出来了，不仅提到了代码生成，也提到了各种仿真验证，他还非常系统提出来基于模型设计这样一个概念，提到在我们软件开发过程中，提到基于模型的设计，该怎么去做，有别于以前的传统开发模式，我们有什么需要去改进，可以变化的地方，同年民航领域也发布了一个DO-178C这样一个版本，我们可以看到，在汽车和航空领域，基于模型的设计的应用已经到了一个非常高的程度了，咱们看到一个趋势大概是这样的啊，基于模型的设计在软件开发行业呈现一个上升的趋势。

好的我问一个问题，我们看到基于模型的设计已经在各种标准里面出现了，那我想问一个问题，为什么会有这样一种变化，其实这些标准是用来规范我们的开发过程的。咱们下面讨论两个问题，一个是ISO26262软件开发项目的启动，另一个是符合26262的软件开发过程。

这个图大家很熟悉把，这个图就是来自于26262，下面我们讨论的内容是用框子框起来的，关于软件开发的内容。我们怎么基于模型的设计去改进优化我们的开发过程，在项目开发初期我们需要解决这些问题，其实26262在每一个部分都会给出一些，你在这个阶段，你需要有什么工作产品作为输出。我们在软件项目开始之前，在软件需求定义之前或者说在软件项目的启动阶段，得到这样一些输出，前面两条跟以前的开发过程相比没有什么特别，我们来看后边四条，

关于编程和建模语言，他提到了有明确的定义，支持嵌入式实时软件和运行时错误处理，支持模块化、抽象及结构化。同时他提到，如果语言本身不能涵盖上述标准，应该通过相应的指导或者开发环境涵盖，其实在我们汽车电子行业，我们用什么语言，我们其实几乎没得选，我们都在用c语言。对于基础软件来说，我们通常用手工方式编写c代码，对于应用软件，我们通过基于魔性的设计这样一种方法来实现算法，然后呢，去生成代码。这个表给出的是建模标准与编码标准要涵盖的内容。咱们这边有这么多内容，不一定在标准里面全部涵盖，因为我们从标题来看，都是1开头，1里面满足一条或若干条其实就够了，不一定全部满足，这里面有两条，咱们需要特备强调一下的，第一条关于复杂度的约束和限制，我们要尽量做到低复杂度，第二条是什么，使用语言的子集，其实刚才我们也提到过，四十分钟里面根本没有办法介绍整个26262的开发过程，但是我想说的是，这么多年我看到我们的客户，他们遇到的各种各样的开发困境。

关于simulink语言我哦们也提到了一些建模标准，一个是MAAB，是专门为汽车行业制定的一份标准，另外一个是什么，为高完整性系统建模标准，这个主要是因为对汽车行业功能安全要求越来越高，为汽车民航，火车这些领域制定的一份标准，

咱们在看26262有一点还不同的是，我们在这个开发过程中对工具是有要求的，我们不是随便用这个工具来开发产品就说这个过程是符合iso26262的，我们要对工具做一个资质审核，要做一个分类，如果这个工具的置信水平越高，我们不需要对他进行额外的审核工作，但是如果说我们考察下来分到TCL2的话，其实我们要针对应用的不同aisl等级对他进行资质审核，看他是否符合我们的开发过程。正是因为这样一些原因，导致了我们目前提供的工具，像我们的simulink，embeded,simulink design verify 等几大工具，我们需要去做一个审核，审核的方式有很多种，我们这里是通过认证的方式给出一些证书。

我们可以看到这些工具都获得了南德这个公司的认证。

前面提到的，我们除了对工具有要求，还有对工具使用指导有要求，对于每一个工具我们有非常详细的用户手册，可以怎么去用它，这是必须的。我们在质量体系里面，还有培训的要求，如果我们利用一些新的工具去做开发的话，我们需要去熟悉一些新的内容，这些内容怎么去做呢，可能通过一些外部培训啊，内部培训啊，或者说工作中的培训去实现，我们看到这些问题，用户在使用simulink和stateflow的时候，尤其在使用stateflow的时候，其实我一看他的模型就知道他根本就不会用stateflow,他连一些基本的规则都没有掌握，那么他已经画了很大的模型出来，那么可想而知，这里面会有多少个bug。如果你对我们的开发工具一点都不熟悉的话，可以考虑，先从培训做起，工具的问题解决了，我们再来看开发过程。