下载文档原格式
符合ISO 26262的汽车电子软件开发流程董淑成**************************MathWorks中国ISO 26262(2011)高完整性软件开发标准和基于模型的设计01219901995200020052010基于模型设计的应用标准生效的年份DO-178B (1992)NASA-GB-8719.13(2004)IEC 61508(1998)DO-178C（2011）IEC 61508(2010)EN 50128(2001)EN 50128(2011)IEC 61511(2003)软件开发标准里出现基于模型的设计为什么？大纲▪ISO 26262软件开发项目的启动▪符合ISO 26262的软件开发过程软件开发ISO 26262定义的软件开发过程系统集成和测试系统设计软件需求验证软件集成和测试软件单元测试软件单元设计及实现软件需求定义软件架构设计系统测试软件测试软件测试软件测试设计验证设计验证设计验证软件开发ISO 26262的软件项目启动系统集成和测试系统设计软件需求验证软件集成和测试软件单元测试软件单元设计及实现软件需求定义软件架构设计系统测试软件测试软件测试软件测试设计验证设计验证设计验证1.软件开发计划2.软件验证计划3.编程、建模语言的选择4.编码、建模标准5.工具的选择6.工具应用指南建模/编程语言的选择及相关标准▪建模或者编程语言的选择标准–明确的定义–支持嵌入式实时软件和运行时错误处理–支持模块化、抽象及结构化▪语言本身不能涵盖的上述标准应通过相应的指导或开发环境涵盖TopicsASILA B C D 1a Enforcement of low complexity++++++++ 1b Use of Language subsets++++++++ 1c Enforcement of strong typing++++++++ 1d Use of defensive implementation technique O+++++ 1e Use of established design principles+++++ 1f Use of unambiguous graphical representation+++++++ 1g Use of style guides+++++++ 1h Use of naming conventions++++++++▪通常，汽车电子软件选择C语言–基础软件手工编写C代码–控制策略软件通过Simulink建模并自动生成代码C代码•建模/编码标准要涵盖的内容Simulink/Stateflow建模标准▪汽车行业建模标准（MAAB）–专门为汽车行业Simulink用户制定▪高完整性系统建模标准–专门为民航、火车、汽车等高完整性系统建模制定设计工具/验证工具的选择 工具的分类及资质审核TI 2TI 1TD 3TD 1TD 2TCL 3TCL 2TCL 1工具错误的检测工具置信水平高中无/ 低增加审核需求工具的影响ASIL 为TCL2级的资质审核无需额外的资质审核为TCL3级的资质审核工具分类工具资质审核UC 1..n 软件工具有引入错误或者不能检出错误的可能工具的功能/用例TÜV SÜD认证的工具▪Embedded Coder™功能：生产针对嵌入式优化的C和C++代码▪Simulink® Verification and Validation™功能：验证模型和模型生成的代码▪Simulink® Design Verifier™功能：定位设计错误，生成测试用例，并根据需求对设计进行验证▪Polyspace® Client™ for C/C++功能：证明源代码没有运行期错误▪Polyspace® Server™ for C/C++功能：在计算机集群执行代码验证并发布度量开发工具的应用指南▪除了选择开发工具之外，还要提供开发工具的应用指南▪Embedded Coder等工具具有非常详实的用户手册需求分析•模型架构•可实现性•可测性•可追溯•可配置模型建立•建模语言•建模标准•模型复杂度•平台化开发模型验证•建模标准•模型评审•形式化方法验证•功能测试代码实现•数据管理•等效性测试•代码验证•代码集成需求分析•模型架构•可实现性•可测性•可追溯•可配置模型建立•建模语言•建模标准•模型复杂度•平台化开发模型验证•建模标准•模型评审•形式化方法验证•功能测试代码实现•数据管理•等效性测试•代码验证•代码集成汽车电子软件的现状和复杂软件开发的困境▪GM汽车上的代码量▪软件工程师的工作效率▪解决复杂软件开发效率低下的途径–模块化开发模块化的原则和目标▪模块划分的一般原则–从功能上–高内聚–低耦合▪模块划分的目标–简化设计–便于分工–便于测试–便于后期维护▪In order to avoid failures resulting from high complexity, the software architecture design shall exhibit the following properties,–Modularity;–Encapsulation; and–Simplicity.ISO 26262软件架构设计原则▪软件架构设计原则MethodsASILA B C D1a Hierarchical structure of software components++++++++ 1b Restricted size of software components++++++++ 1c Restricted size of interfaces++++ 1d High cohesion within each software component+++++++ 1e Restricted coupling between software components+++++++ 1f Appropriate scheduling properties++++++++ 1g Restricted use of interrupts+++++软件的层次化结构设计▪模块如何划分–从功能上划分组件▪以发动机为例，分为：点火、进气、油量计算、怠速、巡航等▪模型实现上model reference发动机控制点火控制进气计算燃油控制怠速控制巡航控制其他–对复杂组件进一步划分为单元模块▪以发动机的怠速控制为例，分为暖机怠速、闭环速度控制、扭矩请求等单元▪模型实现上model reference系统级组件级单元级单元模块的设计不建议使用Model Reference.基于模型的嵌入式软件开发需求分析•模型架构•可实现性•可测性•可追溯•可配置模型建立•建模语言•建模标准•模型复杂度•平台化开发模型验证•建模标准•模型评审•形式化方法验证•功能测试代码实现•数据管理•等效性测试•代码验证•代码集成Simulink建模语言▪使用建模语言的子集▪Simulink和Stateflow之间的选择–如果算法是复杂的逻辑运算，使用Stateflow；–如果算法主要是数据运算，使用Simulink；▪Stateflow的flow chart和state chart之间的选择–如果算法本质上是计算工作状态或者离散状态，使用state chart；–如果算法本质上是if-then-else结构，使用flow chart或者真值表；ISO 26262软件单元的设计原则▪Example: Parallel states should not appear at the top level of a state-chart.--Misra Modeling GuidelineMethodsASILABCD1a One entry and one exit point in subprograms and functions++++++++1b No dynamic objects or variables, or else online test during their creation +++++++1c Initialization of variables++++++++1d No multiple use of variable names+++++++1e Avoid global variables or else justify their usage ++++++………1h No hidden data flow or control flow +++++++1jNo recursions++++++▪软件单元的设计和实现原则模型复杂度监测对单元模块进行复杂度监测–Model advisor–圈复杂度Simulink模型的平台化开发▪Model Variants–通过配置不同的参数选择不同的被引用模型–比如，K_Param== CLASS_A，选择Model_A.mdl；K_Param== CLASS_B，选择Model_B.mdl–支持生成条件编译的代码▪System Variants基于模型的嵌入式软件开发需求分析•模型架构•可实现性•可测性•可追溯•可配置模型建立•建模语言•建模标准•模型复杂度•平台化开发模型验证•建模标准•模型评审•形式化方法验证•功能测试代码实现•数据管理•等效性测试•代码验证•代码集成软件开发ISO 26262定义的软件开发过程系统集成和测试系统设计软件需求验证软件集成和测试软件单元测试软件单元设计及实现软件需求定义软件架构设计系统测试软件测试软件测试软件测试设计验证设计验证设计验证MAAB及相关规范的检查▪Model Advisor实现建模规范检查▪定制检查集▪定制检查项模型评审▪模型和需求的双向追溯–模型→需求–需求→模型▪Simulink Report Generator生成报告–为非Simulink用户生成报告▪Simulink Report Generator实现不同版本模型比较使用Simulink Design Verifier检查逻辑错误▪设定生成测试用例目标为MC/DC100%覆盖▪生成测试用例▪逻辑错误导致无法生成100%覆盖的测试用例，并提示错误逻辑使用Simulink Design Verifier检查数据错误▪通过算术运算分析定位错误–数据溢出–被零除▪证明没有错误的运算演示Simulink Design Verifier检查错误单元模块的功能测试▪仿真测试▪覆盖率分析模型测试的覆盖率要求▪对单元软件测试的结构覆盖率要求–覆盖率达到分支覆盖率100%–MC/DC 要求▪对软件架构测试的覆盖率要求MethodsASILABCD1a Statement coverage ++++++1b Branch coverage+++++++1cMC/DC (Modified Conditional/Decision Coverage)+++++MethodsASILABCD1a Function coverage ++++++1bCall coverage++++++模型的集成测试▪模型的组件级集成测试▪模型的系统级测试–模型在环测试–快速原型▪不同组件之间的接口测试▪不同组件功能上是否冲突基于模型的嵌入式软件开发需求分析•模型架构•可实现性•可测性•可追溯•可配置模型建立•建模语言•建模标准•模型复杂度•平台化开发模型验证•建模标准•模型评审•形式化方法验证•功能测试代码实现•数据管理•等效性测试•代码验证•代码集成代码生成的前提条件 模型经过充分验证模型符合建模标准功能测试覆盖率足够高模型不含有无效逻辑模型不含有数据错误GenerateCode数据对象和数据字典▪使用数据对象定义数据属性Properties （属性）Classes （类）Package （包）SimulinkSignal DataTypeData Storage ClassMin/Max ParameterData TypeData Storage ClassmodelName = 'f14';dictionaryName = 'myNewDictionary.sldd ‘;dictionaryObj =Simulink.data.dictionary.create(dictionaryName);set_param(modelName,'DataDictionary',dictionaryName);▪使用数据字典管理数据对象数据字典管理数据按照组件划分进行数据管理代码生成工具配置1. 通过系统目标文件设定回调函数2. 在代码生成设置的回调函数里固化设置软件工具除确定id 和版本号之外，还需要确定配置等效性测试▪SIL测试/PIL测试都是等效性测试–验证生成的代码和用于代码生成的模型具有相同的行为属性–PIL除等效性验证之外，还可以用来测量运行时间▪等效性测试的测试用例–功能测试的测试用例–Simulink Design Verifier自动生成▪模型覆盖率和代码覆盖率的比较代码的集成和集成测试▪代码集成的两种方式–单元模型的代码生成，代码级别做集成–模型级别集成，然后生成代码▪软硬件的系统级集成–硬件在环测试–台架测试–实车测试Plant model uController models1s2s3+Plant Model in PC uControllers1s2s3+基于模型的嵌入式软件开发需求分析•模型架构•可实现性•可测性•可追溯•可配置模型建立•建模语言•建模标准•模型复杂度•平台化开发模型验证•建模标准•模型评审•形式化方法验证•功能测试代码实现•数据管理•等效性测试•代码验证•代码集成MathWorksChange the world byAccelerating the paceof discovery, innovation, development, and learningin engineering and science。
Stateflow系统建模在车身控制软件开发的应用作者：何璟来源：《中国新通信》2013年第02期【摘要】采用Stateflow系统建模可使车身控制软件开发的效率大大提高，同时达到软件便于仿真和升级维护的要求。
本文主要以汽车车内照明灯的控制为例，较为详细的介绍了在Stateflow下系统模型的建立和验证，并简要说明系统模型的软件代码生成。
可视化的建模、验证和调试方式表明，Stateflow系统建模可以有效的应用于车身控制系统的软件开发。
【关键词】Stateflow车身控制状态转移MATLAB软件产品是用来解决工程与科学实际问题的应用软件，广泛应用于航空航天、汽车、兵器与国防工业、通信、大学教育以及金融财经等多个行业。
Stateflow作为其中一个产品模块，是集成于Simulink中的图形化设计与开发工具，主要针对控制系统中的复杂控制逻辑进行建模和仿真，适应于对事件响应的动态变换系统设计。
Stateflow涉及的功能包括：控制对象建模、状态逻辑切换、复杂逻辑的可视化编程、嵌入式系统集成等。
本文主要介绍利用Stateflow针对车身控制软件开发中涉及的功能逻辑进行系统建模以及进行时序仿真，并最终生成可直接用于嵌入式系统开发的软件代码。
一、车身控制模块的介绍车身控制系统包括汽车安全、舒适性控制和信息通信系统，主要用于增强汽车的安全性、驾驶的方便性和乘坐的舒适性。
车身控制技术发展至今，已形成模块化和系统化，即众多的电器控制功能已整合到一个（或几个）功能强大的控制模块中，即我们常说的车身控制模块（BCM）。
车身控制模块主要涉及中央防盗门锁、室内灯、电动车窗、玻璃除霜、雨刮器、遥控、转向灯、前后组合灯、雾灯、喇叭、天窗、座椅、后视镜等控制。
二、系统模型的建立车身控制模块包括了许多不同的功能模块，各个功能都可以用建模来实现，最后集成到一起，形成一个完整的车身控制系统。
下面将以汽车车内照明灯的控制为例详细介绍控制软件的模型建立。
基于Simulink—TargetLink的AMT电控系统软件开发【摘要】利用Simulink-TargetLink开发AMT电控系统软件，具有模块功能定义明确、算法实现与验证方便快捷、模型数据统一管理、自动定标、代码自动生成等优点，极大地提高系统软件开发效率和开发质量。
【关键词】TargetLink；AMT；软件开发前言现代汽车电控系统功能越来越复杂，要求电控单元开发周期越来越短，采用传统的开发方式已难以满足车辆电控系统软件开发的要求。
因此应采用规范的软件开发平台，以提高软件开发效率和质量。
Simulink基于模型的设计以及Targetlink代码生成工具，目前在汽车电控单元开发中广泛使用。
本文主要介绍应用Simulink和TargetLink进行的AMT电控系统（以下简称TCU）软件开发的方法和流程。
1.AMT电控系统底层驱动软件AMT电控系统硬件采用Freescale公司的MC9S12DP256微处理器，电控系统底层驱动软件主要是对MCU寄存器操作，得到最底层输入信号并控制最末级输出信号，在电控系统开发周期内它们变化不大，且用Simulink不容易实现，故采用传统方法用手工编写，它们包括：I/O，A/D，转速，定时器，中断，CAN 通信等。
2.信号处理与控制策略信号输入、控制策略以及控制量输出在Simulink环境下进行编写。
2.1 模拟输入信号处理为了保证电控系统稳定可靠运行，必须对信号（数字I/O，模拟输入等）进行处理，如开关输入信号消抖以减小外界干扰、模拟输入信号高低限检查以判断是否故障，在出现故障时用什么值来替代输入信号等，它也是系统故障诊断的依据。
对于任何数字输入信号，由I/O信号处理状态机得到处理后的I/O值。
采用stateflow可以方便地实现模拟输入和数字输入的信号处理算法建模。
2.2 基于Simulink的控制策略车辆行驶时，TCU根据当前车辆运行状态确定变速箱的目标档位，并控制执行机构完成下面动作：离合器分离→摘空挡→选档→换档→离合器结合，实现自动换档，同时控制发动机的扭矩和转速以提高AMT的换档品质。
·44·兵工自动化Ordnance Industry Automation2018-1137(11)doi: 10.7690/bgzdh.2018.11.009基于量子框架和Stateflow模型的嵌入式系统软件设计刘芮滦，邓 杨，史伟娜，刘 志(中国工程物理研究院电子工程研究所，四川绵阳 621000)摘要：基于模型的设计是目前嵌入式系统软件设计的发展趋势，对嵌入式系统建模和根据模型自动生成代码是其关键技术。
量子框架作为一种事件驱动型的基础框架，可以作为嵌入式软件运行的支撑平台。
Stateflow模型适用于描述嵌入式系统的逻辑控制功能，利用RTW工具可以直接从该模型自动生成C代码。
以某飞行控制系统为应用实例设计其活动对象和事件，针对时序控制功能建立Stateflow模型并进行仿真，最后自动生成C代码与量子框架集成，从而实现飞行控制系统的软件设计。
研究表明：量子框架较好地支持了Stateflow模型自动生成的代码，两者结合可以实现基于模型的设计在嵌入式系统软件设计中的应用。
关键词：嵌入式系统；基于模型的设计；量子框架；Stateflow；自动代码生成中图分类号：TP391.9 文献标志码：AEmbedded System Software Design Based on Quantum Frame and Stateflow ModelLiu Ruiluan, Deng Yang, Shi Weina, Liu Zhi(Institute of Electronic Engineering, China Academy of Engineering Physics, Mianyang 621000, China) Abstract: Model-based design is nowadays the development trend of the embedded system software design, and modeling the embedded system and auto code generation by models are the key technologies. Quantum framework, as an event driven framework, can be used as a supporting platform for embedded software. Stateflow model is suitable for describing the logic control function of embedded system, and the C code can be automatically generated from the model directly by using the RTW tool. In this paper, a flight control system is used as an example to design the active objects and events, and the Stateflow model of the sequential control function is established and simulated, finally the C code is automatically generated and integrated with the quantum framework. In this way, the software of flight control system is designed. The research shows that the quantum framework can support the codes generated by Stateflow model automatically, and the combination of them can realize the application of model-based design in embedded system software design.Keywords: embedded system; model-based design; quantum frame; Stateflow; auto code generation0 引言嵌入式系统大量应用于航空航天、国防军工等安全关键领域，随着嵌入式系统软件规模和复杂度的急速增长，嵌入式系统软件设计、开发及验证面临新的挑战。
基于Simulink的嵌入式软件可靠性虚拟仿真测试方法作者：尚京威陈平来源：《科技与创新》2017年第02期摘要：嵌入式软件的可靠性测试是一短极为耗费时间和人力的测试过程。
针对软件可靠性存在的问题，提出了一种嵌入式软件可靠性测试的虚拟仿真测试方法，能增强对软件场景的描述，实时监控软件中的数据，并通过已知故障模式高效、快速地获得失效时间，以期为嵌入式软件可靠性相关研究提供验证支持和数据支持。
关键词：虚拟仿真；失效数据；Simulink；MTTF中图分类号：TP311 文献标识码：A DOI：10.15913/ki.kjycx.2017.02.106嵌入式软件的可靠性测试是一个极为耗费时间和人力的测试过程。
传统的软件可靠性测试的方法是构造剖面，按照剖面生成测试用例，按照测试用例的顺序进行测试，过程为：可靠性分析→修改→再测试→再分析→再修改。
只有在测试样本（测试数据）非常丰富的情况下，随机抽样产生的测试数据才能更加准确地体现出软件的使用分布，但是测试数据的增加势必造成剖面的增大，从而使研究所需的数据收集变得非常困难，进而造成现有的软件中可靠性数据只是数学推导，无法广泛试验。
1 现有软件可靠性测试的局限性目前，广泛采用的软件可靠性测试方法主要是对软件的使用情况进行建模，构建出可靠性测试剖面，比如操作剖面、马尔科夫剖面、使用剖面等，并基于测试剖面开展测试工作。
由于可靠性测试剖面中除了包含软件怎样被使用外，还包含着软件使用的分布情况，因此，通过基于测试剖面的随机抽样生成的测试数据不仅可以体现出用户怎么使用软件，还能体现使用随时间分布的特性，可用于软件的可靠性定量评估，获得的软件的MTTF或故障率等软件可靠性评估结果。
2 可靠性测试虚拟仿真测试研究2.1 Simulink建模的场景剖面利用Simulink建模的场景剖面可分为系统场景及软件场景2个部分：①系统场景主要以软件所在的自主控制系统及其中所包含的各个交联系统为描述对象，对全系统的运行状态、影响系统运行状态转变的环境因素及外界激励进行描述；②软件场景主要以软件自身为描述对象，对软件自身的运行状态及其可能的输入输出进行描述。
申请上海交通大学硕士学位论文上海交通大学学位论文基于Simulink/Stateflow的车身控制模块开发DEVELOPMENT OF VEHICLE-BODY CONTROL MODULES BASED ON SIMULINK/STATEFLOW硕士姓名：胡益汀专业：电子与通信工程学号：1070342060研究方向：软件建模及仿真指导导师：王军锋教授上海交通大学电子信息学院2011年9月基于Simulink/Stateflow的车身控制模块开发摘要随着越来越多的厂商加入汽车电子的阵营，如何高质量、高效率的开发汽车电子产品，迅速占领市场，成了众厂商共同面临的问题。
在这种情况下，使用Simulink/Stateflow对汽车电子控制模块建模，并用Real-Time Workshop Embedded Coder生成特定硬件目标的嵌入式代码，这种开发方式在业内逐渐推广，并流行起来。
在深入学习和研究Stateflow建模和Real-Time Workshop自动生成代码机制的基础上，本文详述了MATLAB中几个重要组件的功能及特点，以及自动生成代码的流程。
对于Real-Time Workshop的两种不同应用：快速仿真和嵌入式代码生成，文中也作了详细的介绍。
车身控制模块是汽车的一个通用部件，本文以它为例介绍了系统建模及生成代码的整个过程。
在开发过程中还涉及到了几个重要方面，包括模型的调试、模型测试用例的编写、代码覆盖率检查、定制代码格式等，文中对于这些内容都作了详细描述。
除了车身控制模块，汽车上其他系统控制模块的开发流程也与之类似，因此一个完善的软件开发流程对于汽车电子零配件厂商来说至关重要。
本文详细介绍了基于Simulink/Stateflow的软件开发流程，对于众厂商具有一定的实用价值。
关键词：Stateflow建模，自动代码生成，车身控制模块DEVELOPMENT OF VEHICLE-BODY CONTROL MODULES BASED ON SIMULINK/STATEFLOWABSTRACTAs more and more companies start to design the electronic control units for the automobile,they are all thinking about designing the products with high quality and efficiency,and grabbing the market as soon as possible.Under this circumstances,modeling the electronic control units with Simulink/Stateflow,and generating the code with Real-Time Workshop Embedded Coder for specific hardware,becomes a popular design pattern for these companies.Based on the deeply study and research of Stateflow and Real-Time Workshop,this thesis introduces several important tools and the process of code generation in MATLAB.It also describes the two different applications of Real-Time Workshop:Rapid Simulation and Generate Embedded Code.Body Control Module is an important part of the automobile,this thesis introduces the process of modeling and code generation for BCM. Besides this,it also describes the process of model debugging,writing the test case,checking the code coverage,and defining the specific code format.There are a lot of control modules in the vehicle,they have different functions but can be designed in the same process.Based on this thesis, automobile OEM companies can improve their software development process and design more reliable products.KEY WORDSWORDS：：Stateflow,Code Generation,Body Control Module目录第一章概述 (1)1.1研究背景及意义 (1)1.2国内外的研究状况 (1)1.3论文的主要工作 (2)第二章Real-Time Workshop及Stateflow开发环境 (3)2.1产品概述 (3)2.2Real-Time Workshop的主要功能和特点 (4)2.2.1Real-Time Workshop的主要功能 (4)2.2.2Real-Time Workshop的主要特点 (4)2.3Stateflow的主要功能和特点 (6)2.3.1Stateflow的主要功能 (6)2.3.2Stateflow的主要特点 (6)2.4Real-Time Workshop Embedded Coder的主要功能和特点 (7)2.4.1RTW Embedded Coder的主要功能 (7)2.4.2RTW Embedded Coder的主要特点 (8)2.5Real-Time Workshop的应用 (9)第三章Real-Time Workshop自动代码生成过程简介 (10)3.1Real-Time Workshop代码格式介绍 (10)3.2GRT与ERT目标代码的比较 (11)3.3Real-Time Workshop创建程序的过程 (13)3.4生成代码过程中产生的文件 (15)第四章构建车身控制模块的系统模型 (17)4.1BCM(Body Control Module)简介 (17)4.2基于Stateflow的车窗模型 (18)4.2.1车窗的功能需求 (18)4.2.2建立车窗模型 (20)4.2.3Stateflow建模的要点 (22)4.3Stateflow模型的验证 (26)4.3.1建立用于仿真的Simulink车窗模型 (26)4.3.2测试用例的编写 (28)4.3.3对模型进行调试 (30)4.3.3.1Stateflow调试器 (30)4.3.3.2设置断点 (32)4.3.3.3调试过程 (34)4.4代码覆盖率检查 (34)4.4.1常用的代码覆盖测试准则 (34)4.4.2车窗模型的覆盖率检查 (35)第五章生成定制的嵌入式代码 (39)5.1TLC目标语言 (39)5.1.1TLC文件分类 (39)5.1.2TLC语法简介 (39)5.2修改TLC文件 (41)5.2.1修改全局函数的函数名 (42)5.2.2修改代码中引用的头文件 (43)5.3配置Simulink模型 (44)5.4生成代码 (47)第六章结束语 (51)参考文献 (52)致谢 (53)攻读学位期间发表的学术论文目录 (54)第一章概述1.1研究背景及意义随着现今社会的进步和发展，汽车产业在工业领域所占的比重越来越大，然后汽车电子面临着市场需求的多样性和和设计开发高效性之间的矛盾。
