非常高兴今天还有机会跟大家有一个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。如果你对我们的开发工具一点都不熟悉的话，可以考虑，先从培训做起，工具的问题解决了，我们再来看开发过程。首先是需求分析，然后是模型建立，模型有了之后我们要做模型验证，验证完之后做代码生成，在不同阶段我们考虑不同的内容，在模型需求阶段，我们考虑模型的架构、可实现性、可测性、可追溯、可配置这样一些概念。在建模的时候考虑建模语言、建模标准、模型复杂度、平台化开发等等。模型验证有评审啊、静态检查、有功能测试。代码生成里面要做什么事情？有数据管理、等效性测试、代码验证、代码集成等等。咱们先看第一部分需求分析，首先看一下汽车电子行业的现状，和复杂软件的开发困境，那么我们来看一个图，关于代码量的图，这个图不是我造出来的，是我截图的，来自NASA这份报告，就是美国国家宇航局给出的一份报告，在一辆通用汽车品牌车上，从1970年的十万行代码，到2010年1000万行代码，这是他给出一个数据。再看一个图，这个图来自嵌入式系统设计的艺术，软件工程师的工作效率随着程序的规模增长而不断减小。大家知道一个软甲工程师一天可以写多少行代码，十几行是吧，一个小时只用写两行代码，所以软件工程师是一个无比舒适的职位，是吧。一天写八到十六行代码，其实他考察的是软件的整个开发过程。如果软件足够复杂，那么我们应对复杂系统的能力是不断降低的，所以我们的开发效率是降低的，那么怎么办啊，解决复杂软件开发的有效途径是什么？模块化开发是吧。好，我们看模块化的原则和目标是什么？模块划分的一般原则是什么？从功能上划分，高内聚、低耦合。我们看到一些客户的模型非常非常大，客户一般会告诉我们没法测，那这就是一个困境是吧，我们模块划分的目标是什么？是简化设计、便于分工、便于测试、便于后期维护。我们的模型经常发布之后经历各种各样的变更，所以我们要做到便于后期维护，这是我们模块化的原则。咱们再看26262，他说为了避免搞复杂性引起的各种错误，在模型架构上应该做到模块化、封装、做到简化。这是我们应该做的，对软件使用上也是，我们应该使用matlab最简单，最基础的功能，去实现我们最稳定可靠的系统。知道在座的各位有不少是matlab玩家，很多人在论坛上追求matlab各种各样的功能，其实没必要，我们就要matlab最简单的功能，开发安全可靠稳定的产品，这是我们的目标。Simulink最简单的可以使用我们的subsystem是吧，还可以在内部继续用subsystem。如果模型复杂一点，我们还可以用模型引用，从架构上可以满足乘此化设计的需求。我们面临一个比较复杂的系统，模块如何划分呢，从功能上进行划分，不要把各个功能拆开，我们至少要保证我们的产品是功能上符合要求的，我们可以把复杂软件从功能上划分成很多组件，像发动机可以划分成点火等等功能，在simulink中可以用模型引用去实现。分别把点火、进气、喷油、做到不同模块里去，再通过模型引用去集成，这是一个简单例子。其实对于复杂组件，可以把他进一步划分成不同单元模块。同样你可以用模型引用把他做到一个模型里去咱们看这样一个例子，上面是发动机的整个系统，系统级模型可能有这么多模块，通过模型引用过来，我们拿其中一个模块分析，分为几个组件，拿怠速模块为例子，又可以分为几个单元。 单元里面可能有subsyetem，有statechart等等，通过这样的设计整个软件架构看起来比较清楚，便于我们后期的维护和测试，对于单元级的模块不建议用model reference,因为这不仅仅考虑架构为题，还要考虑未来问们生成代码的问题。对于模型引用模块都会单独的生成model.c与model.h文件。我们再来看第二部分，关于模型的建模，建模的话首先来看建模语言，咱们看了一条规则，使用建模语言的子集，我们刚才已经说过，我们要选择最安全、最稳定、最可靠的工具来进行开发。我举一个很简单的例子，我们多数人可能都有c代码的经验，我们知道c代码可以使用go to 语句去实现某一个跳转，但是我们的公司里面基本不容许使用go to语句，同样simulink有一些功能，simulink是可以实现出来的，但是我们最好不要去使用它。那么simulink与ststeflow之间该怎么去选择？Flow chart 与statechart又该怎么去选择呢？这个其实就是怎么方便怎么来？这个不是必须的，你习惯用什么，擅长什么？怎么方便怎么来。其实他们都可以互相替代，怎么让你的模型更简单，更加方便维护，你就怎么去做他。咱们再看单元模块的设计原则，很多原则可能是针对c代码开发的，我们看这样一条没有隐藏的数据流和控制流，我想给出一条建模规则，他是说在stateflow里面不应该出现并行状态，为什么不这样做，是因为并行状态会把数据流与控制流隐藏起来了，如果不使用并行状态我们可以用不同的chart去表示，再用信号线把这些状态链接起来。这样的话他的信号流与控制流可以清晰的看到。我们再来看一下模型复杂度监控，我们在开发过程中，我们需要去监控复杂度，我们看复杂度是不是很高，如果高的话我们可能考虑，从新划分模块，这里有两种监控方式，一种是model advisor,另外一种是圈复杂度，通过运行模型产生报告的方式给出这样一个复杂度，这个数据和我们以前听到的圈复杂度是一样的概念，他是通过你的模型有多少个分支，多少个结点计算出来的。Simulink模型的平台化开发的话，是我们汽车行业经常要用到的，我们可以通过model variants，通过配置不同参数，条件编译的方式生成不同代码。还有一个system variants跟他类似。咱们在快速的看一下模型验证，咱们再回到这个图，这个图里有各种各样的验证，一个是设计验证，是我们再开发过程中要做的验证，这种验证在以前的开发模式里有评审、静态分析等方法，而基于模型的设计你在设计阶段就可以用动态仿真的方式去验证模型，另外一个就是测试验证，等我的代码出来之后，我们要做代码测试，代码测试不是以前传统的测试，比如我们可以做sil测试和pil测试等等工作，静态检查有这样一些检查方式，比如我们可以用MAAB做检查，可以在这些里面定制一些检查集，加一些检查项。另外一个是模型评审，我们提供模型和需求的双向追溯功能，另外我们可以通过report generate生成报告，在我们需求变更的时候，我们会去做这个模型比较。我们还有一个比较高端的工具，叫simulink design verify，是用来检查逻辑错误，可以用来做测试用例，但是这个测试用例并不能用来做功能测试，他在生成测试用例时候可能因为你的逻辑错误报错，那其实这种方式可以协助你检查算法的一些逻辑错误另外我们还有一个比较头疼的，尤其我们在做一些定点化的问题时，经常会出现一个数据溢出错误，其实检查数据溢出也很麻烦，尤其检查一些中间结果的数据溢出，这个工具同样能帮我们哪些地方有数据溢出。还有就是单元模块的功能测试，说白了就是利用simulink的仿真功能，我们去设计一些测试用例，去驱动程序运行，然后去观测模型输出结果是什么样的，在做功能测试的时候，我们要关注一个指标，覆盖率分析。在输出结果保证正确的前提下，我们要看覆盖率是否足够高。如果覆盖率不够高的情况，你需要追加测试用例，保证足够高的覆盖率。26262对覆盖率是有要求的，覆盖率达到分支覆盖率100%，对软件架构测试的覆盖率，在单元测试做完之后需要做集成测试，集成测试一个是组件级别集成，另外是系统级集成，系统集成可能伴随着模型在环啊，快速原型去实现，我们关注从接口上是否匹配，另外一个关注在功能上是否冲突，因为不同模块可能来自不同开发工程师，是有冲突的代码生成前提条件是什么？代码生成的前提条件是模型经过充分验证，什么叫充分验证代码生成要做的工作是什么啊？主要工作是数据管理工作是吧，数据管理是怎么做的，咱们通过数据对象和数据字典去管理我们的数据，对象是什么意思，跟我们说的面向对象是一个意思。Simulink有一个包，里面有两个类，signal类与parameter类，这些类有这么多属性，那么我们可以通过这两个类去创建一些对象出来，然后去定义每个对象特有的属性，使用数据字典去管理这些数据对象数据管理工作做完之后，其实就可以做代码生成，对于一个复杂系统怎么去做数据管理工作，我建议可以这么做，比如每一个组件我们有一个数据字典，还有一些数据可能每一个组件都会用到的，其实可以共用一个数据字典。还有一个问题，在我们代码生成时，我们对代码生成工具版本，matlab版本有要求，我们通常在一个项目里面我们不去变更这个版本，尽管我们的产品每年做两次升级，但是我们在开发过程中，一个项目都是用一个版本来进行开发。我们同事希望固化一些配置，我们可以通过系统目标文件设定回调函数，然后在回调函数里面进行配置，我们可以把一些配置设定下来以后，让他变成灰色，就是改不了，同一个模型这样不同的工程师生成的代码是一样的。代码有了之后我们要做等效性测试，怎么去做等效性测试呢，等效性测试是因为代码生成工具可能有bug,那么我们为了避免代码生成工具的bug导致我们最终生成的产品出现问题，我们希望有一个环节可以检查出错误，就是等效性测试，一种是sil,一种是pil,sil。等效性测试的测试用例有两种方式得到，一种是复用功能测试的测试用例，一种是用design verify自动生成，这个时候我们只是做一个输入输出对比，而不关心他是否具有功能意义。在26262里面告诉我们要做一个模型覆盖率和代码覆盖率的比较，同样的测试用例测模型和测代码是否一致，是因为在代码生成过程中不能出现一些无意识引入的错误，同样的测试用例下覆盖率是否一致可以判断是否有一些不应该有的功能引入进来。最后是代码的集成测试，代码集成有两种方式，一种是单元模型的代码生成，在代码级别做集成，另一种是模型级别做集成，然后生成代码，如果你的调度很复杂我建议用第一种方式，如果你的调度很简单，你可以用第二种方式，还有一个软硬件系统级别的集成，我们会伴随着硬件在环测试啊，把控制模型放到控制器里面去运行，把被控对象放到工控机里面去运行。除此之外还可以做台架测试，实车测试。那我们最后回顾下基于模型的设计，我们今天介绍的太快，但我希望有些地方大家可以去看一下，比如说模型架构，比如说模型复杂度，比如说功能测试，比如说数据管理，因为我以前看到客户在不同阶段出现过各种各样的问题，我要介绍的就是这些，我希望我们的matlab能加速我们的开发过程。
|
