科普文：浅谈汽车发动机控制系统软件（二）

写在前面：

限于篇幅，分多篇分享。

小编

第一篇链接：

科普文：浅谈汽车发动机控制系统软件（一）

四、汽车软件结构

汽车软件由很多程序组成。汽车软件原则上也分为应用软件和与硬件相关的平台软 件。通过软件架构可观察软件各个不同的方面，因此这些不同的方面又被称为关于架构的视图。静态视图则在不同层面上描述功能组 信 和资源的分配（图9-4-1)。

相比之下，功能视图是借助不同的功能描述信 的变化；动态视图（即基于时间的视图）则关注不同程序部分的时间特性。为了保证单个部件持续研发以及部件间的相互作用，事先制定一些相关标准是必要的。

4.1 软件的模块化结构

汽车软件可被分为不同的组。较大的组，如汽车动力控制、变速箱控制和发动机控 制又可被细分为空气系统、转速控制、燃油系统和诊断等。还可继续细分，直到某个传感器的信 求值或喷油量计算。

通常不会开发一个全新的大功能，而是尽可能多地重复应用已开发好的和经过测试验证的一部分软件组件。

与具体的汽车关系不大的软件（例如传感器信 的求值）可以在各种汽车中加以使用。专用的汽车软件则需针对一个汽车制造商、一个车型系列或者一个特定的车型开发。

4.2 AUTOSAR

为了共享不同的软件，已经制定了一些标准。作为一个实例这里将介绍AUTOSAR标准。

UTOSAR是汽车开发系统架构的简称。AUTOSAR是由汽车制造商、控制器生产商、开发工具制造商、控制器基础软件和微处理器生产商组成的开发团体。AUTOSAR的目标是使不同控制器软件之间的移植变得更加方便。为此，需要制定一个具有统一描述和 配置模板的软件架构。A盯OSAR标准定义 了描述汽车软件的方法。使用这个方法可以确保软件组件的重用、移植、扩展和集成。

AUTOSAR标准主要描述控制器专用的基础软件(BSW)，与控制器无关的应用软件 (ASW)，以及它们通过虚拟总线(VFB，见图9-4-2)进行互联的逻辑分配。通过虚拟功能总线还可以把不同控制器里执行的软件组 件连接在一起。因此，不需对相关软件组件 做任何更改就可以实现不同控制躲软件组件 的移植。这将有利千计算能力、存储需求和通信负载三者的优化。

功能性软件组件(SWC)相互之间以及与基础软件之间都是严格分开的。典型的功能 软件组件包含某些特定的实时运行的调节算法和可运行实体。它们通过AUTOSAR接口与其他功能或控制器接口进行通信。这些接 口(API)通过一个SWC-XML描述文档来定义。XML是所谓可扩展标记语言。它的内容通过一些标签来标记。这些标签给出了有关内容类型的信息。标签与标签之间的关系在一个文档类观定义(DTD)文件中说明。运行环境(RTE)提供功能性软件组件之间以及它们与相应的控制器上的基础软件之间的通信服务。RTE需要针对具体的控制器和应用进行裁剪，并可以根据接口需求自动生成。

基础软件(BSW)包含有针对特定控制器的程序，如通信接口、诊断和存储管理。基础软件中还包含有服务层，而在服务层中综合了用于公共服务功能(SRV)的软件组件，如通信(COM)以及部分与控制器相关的操作系统(Operating System, OS)软件组件。该操作系统基千 OSEK-VDX – OS标准[ 13]。操作系统用于分配和管理控制器资源，以便实现优化的 络支持、存储管理和诊断。

对所采用的硬件的封装由两个彼此相叠的层来实现。可直接访问控制器外围部件的微处理器抽象层(Micro Controller Abstraction, MCAL)将自己延伸到另外的 个层面。复杂设备驱动(Complex Device Drive, CDD)使得在功能性和时序上有特殊要求的某些应用可直接访问微处理器资源成为可能。CDD同样是基础软件的一部分。也就是说，如果需要CDD服务，可以在不考虑硬件的情况下开发相应的应用软件。

除了控制器架构外，AUTOSAR联盟还将进行开发方法部分的标准化工作。开发方法主要涉及的是不同工作成果的结构以及依赖 关系（例如数据）。这可被用来为每一个控制器生 成由不同软件组件描述的可执行程序。

4.3 诊断标准

用千汽车开发、生产 以及维修服务的车 辆诊断系统维护起来复杂而昂贵，并且不灵活。它是连接生产商和供应商的桥梁，但又 对跨公司间合作所需的那种简单数据交换构成了障碍，因此便产生了一些诊断标准。

汽车电子协会(ASAM-AE)[4]制定了3 个基于数据的（或者说基于软件的）汽车诊断专业标准。这些标准发布在国际标准ISO22900中。其中，ODX标准（开放式诊断数据交换）是被用于制定基千 XML的车间参数预标定的标准(MCD -2D, ISO 22901)的基础。

五、开发流程

为了满足汽车软件开发过程中的上述要求，除了技术和工具外，定义开发流程也是很重要的。原则上，软件开发的所有步骤都必须与整车和控制器硬件开发步骤保持一致（例如样品时间表和试制）。

开发过程描述开发的整个进程以及进程之间的关联。下面给出了这个过程：首先在逻辑系统架构中对汽车的功能进行描述，然后将其映射到一个包含所有程序和数据的具体软件系统。此处需要考虑整个由微处理器 控制车辆控制系统。这样做的价值在千可清楚地将软件功能的技术规格（系统用于做什么）、设计构思（怎样构建组件）和技术实现 （软件怎样转换）3步工作加以分离。软件功 能的技术规格用物理层面上的电压、电流和转速等来表现，而程序和数据的设计以及技术实现则需针对某一特定的微处理器来开发。

5.1 过程描述模型

大扯不同复杂程度的模型已被用于描述软件开发的进程。这些模型用来使开发 过程更加清晰化，用来进行对比并发现开发过程中的蒲弱环节，并用来验证是否满 足相应的标准。设计这些模型的最初目的并不是为了借助模型本身改善软件质撮、 提高效率、消除软件开发进程中的系统级错误，然而过程描述模型在一定的条件下 确实可以起到上述的这些作用。作为实 例，这里对应用广泛的V模型进行介绍。在实际使用时V模型可以采用不同的细化程度，也有多种不同的变体。

5.2 V模型原理

V模型将直接屈千开发过程的那些步骤沿着一个V字形进行划分，其中3轴代表时间，y轴表示深度，即指出相应步骤的细化程度（图9-5-l)[IS］。一个开发步骤可通过如 输人参数、方式、方法、所起作用、采用的工具、质批判据和输出参数这些必要的参数来描述。定义在左侧分支上的步骤由右边分支上的步骤加以验证，且验证步骤可以多次进行或者进行细分。

在扩展V模型中还可考虑一些伴随的管理过程，如需求管理、更改管理、项目管理和质量管理等。

六、软件开发的质量保证

与其他技术产品一样，软件也需要采用大揖的工具来保证其开发质量。与机械和电子产品不同，因为软件的复制生产相对容易， 因此其生产过程的质量保证并不是很重要。软件系统的整体功能性、质量的度量、复杂性控制以及应用（标定）才是其重点。因为汽车软件还被用于与安全相关的系统，如汽车动力学系统和驾驶辅助系统，因此对其质量的 验证也很重要。另外，在追求软件质量的同时，还要考虑所付出的经济上的代价。这一 点对于复杂的系统来讲，尤其重要。

EC 61508和ISO 26262基千!EC 61508（与安全相关的电气、电子和可编程电子系统功能安全标准）标准，汽车工业界制定了针对与安全相关的汽车电子／电气系统设计的标准ISO 26262（道路车辆功能安全）。这个标准包含了对产品以及产品开发过程的要求，包括与安全直接相关 的系统和涉及安全的系统（安全风险较低的 系统），从方案构思到规划 、 开发、实现、投产、 维修、修改、 废以及拆卸全部要求。这个标准将上述各个阶段的整体称为“ 整个安全生命周期”。产品可以根据安全要求等级(Safety Inte伊ity Level)划分为SILl -S且4（根据lEC 61508)或ASTL A -ASIL D （根据ISO 26262)几个不同的等级。其中，S ．[Ll和ASIL A为最低安全要求等级，S且4 和ASIL D为最高安全要求等级。

七、汽车软件的开发

在开发汽车开环和闭环控制功能时，除了要考虑功能性外还必须全面考虑可靠性要求安全性要求以及实现过程的各个方面。现在很多领域中都采用了基于模型的开发方法（图9-7-1)。这种开发方法分为两大方 面：用逻辑系统架构中的虚拟模型（图中灰色部分）实现早期的功能测试和验证，而在技术 系统架构（图中白色部分）中才涉及真实的控 制韶和车辆。

在功能 络和控制器 络开发时也采用 上述的方法。开发中也常常采用将虚拟功能 和已在控制器中代码实现的功能加以组合的 方式，以及将虚拟部件和实际的物理部件加以组合的方式。

图9-7-2给出了开发过程的一个实例。

在步骤A中，这些新功能将在PC机上进行虚拟的模拟，并借助千 个环境模型对该功能 进行测试。接下来在步骤B中将在试验车辆 上进行功能的有效性验证。这些功能将由一 个快速原型模块执行。试验车辆既可以是一 辆简单的测试车辆，也可以是其他类型的车 辆。在功能得到充分的测试后，再在步骤C 中将其集成到控制器软件中，生成控制器代码并在控制器中运行。接下来在步骤D中将针对一个环境模型进行控制器或者控制器 络在环测试。环境模型在一个实时PC上运 行。对于控制器 络可在 络仿真中模拟每个 络节点。广泛应用的总线包括CAN, FlexRay，LIN[6]和MOST。在步骤E中进行 小批矗试验车辆的测试。车用测试模块通过接口模块与汽车总线相连，记录各种信 和 物理拯值。步骤F，即所谓软件的参数化过 程，也即软件与车辆的准确匹配。它可以从一开始就伴随其他步骤同时进行。开始时这个过程被称为预参数化，而后期时才被称为 应用或者标定（即参数化过程）。

随后将对基于模型开发的每一个步骤结合闭环和开环控制功能的实现做进一步的解释。还可以将基于模型的开发应用到其他软 件开发中，如监控和诊断功能开发。

7.1 开环和闭环控制

在开环控制中，控制器的输出最是根据输入量、预先设定的数据、特性曲线以及控制 算法（计算过程）在控制器中计算得到的。由 于不对作用效果进行检验，因此被称为开环 控制，如对电热塞工作过程的控制。

7.2 软件功能的建模和仿真

开环和闭环系统的建模主要采用方块图 或者自动状态机。方块图模型借助框图和框 图间带箭头的信 流描述各部件的传递特性 （图 9-7-3) 。通常情况下，系统涉及众多变量，可采用向量形式表示这些变量。这些变量有检测量或反馈量 y ，控制器或调节器输出量u*，设定量或期望值（量） w，驾驶员设定 量矿，被调节量或被控制量y*，调节量u和干扰量z。

还有如下的框图单元：控制骈或调节器、执行辖模型、被控对象模型、期望值发生器模 型、传感器模型、驾驶员模型和环境模型。

驾驶员通过给定一个期望值来影响开环或闭环调节功能。所有能够产生驾驶员期望 值的器件（例如开关或者踏板）都被称为期望 值发生器。传感器测扯实际输出的物理量并将其转换成相应信 值。驾驶员获得车辆状态信息，并做出相应的反应。利用所有这些参址就可以建立模型。模型在仿真系统（例如PC机）中执行，并进行精确的仿真研究。

基千模型的开发方法还有其他的优点：如果建立的是规范的模型（清晰，不需多加任何解释），它就可以在计算机上进行仿真，还可以通过快速控制原型技术在车辆上进行快速、逼真的试验。此外，还可以较容易地发现模型的不稳定性。一个模型化的功能可以作为可执行的技术条件由汽车制造商下达给软件供应商。与口头的技术条件相比，模型化的技术条件一般更加清晰和一致。

7.3 软件功能的快速控制原型技术

利用快速控制原型技术可以提前在实车 上实现控制和调节功能的技术指标。模型化的控制或调节功能必须首先在试验中实现。一个试验系统可以用作实现控制和调节功能软件的执行平台（图9-7-4)。

试验系统与期望值发生器、传感器、执行器以及其余的隶属千该总系统的车辆控制器 相连。由于这个连接接口是连接到实际车辆 上的，因此在试验系统执行软件功能时必须和在实际的控制器中一样，要考虑实时性 要求。

试验系统通常是一个实时计算系统。它的计算能力比以后的证产控制器明显要高。最常用的是将PC机作为执行该任务的计算内核。使用快速控制原型工具并遴循统一标准，就可以将特定的软件功能模型自动转换成可执行模型，以尽可能准确地模拟特定的各种特性。

模块化结构的实验系统可以针对具体的应用对输入／输出接口进行配置。整个系统专门为汽车应用而开发，并由一个PC机进行管理与控制。PC机还可安装不同的软件版本和开发工具。这样就可以在开发的前期直接在汽车上测试软件功能的技术指标，如有需要还可以做相应的修改。

针对不同的应用有两种实验系统模式可供选择，即旁路应用模式和全替代应用模式。

7.4 旁路应用

如果只开发少量软件功能，或者已经 有了一个带有经过测试的基本软件功能的控制器（例如出自以前的工程项目）可以被利用时，可优先选择采用旁路应用模式。

此外，旁路应用还适用于以下情况，即控制器中的各种传感器电路和执行器电路很多，实验系统要支持这些装置需要花费很大代价时（例如发动机控制器）。

如果不是上面描述的这类控制器，或者系统中还有其他的设定值发生器、传感器和执行器也需要试验以及没有足够的硬件接口时，优先选择全替代应用。全替代应用属于“ 特殊的旁路应用” ，对于这种应用模式整个软件不是在控制器中而是在实验系统中运行。单个功能软件采用旁路模式，而总的控制器软件采用全替代模式。这种混合模式灵活性比较强，因此得到了 广泛应用。

(1) 旁路自由切换

新软件功能或者是更改过的软件功能可以使用快速控制原型工具转换成可执行模型，并通过一个旁路接口在实验系统上运行（图 9-7-5)。如果控制器中还有可用资源， 也可以将新功能作为一个软件在控制器上 运行。

这种方式还可被用千控制器现有功能的 扩展。在这种情况下控制器原有功能还将被保留，但是必须做一定的修改。使输入批可以通过旁路接口发送至新扩展功能，并使新开发的旁路功能的输出值可被输出利用（图9-7-6)。控制器方面需要做的软件修改被称为 ＂旁路自由切换＂ 。当控制器和实验系统的功能计算需要同步时，通常采用这样的方法：控制器通过一个流量控制接口影响在实验系统中进行的旁路功能计算， 而旁路功能的输出值则被用千监控控制器的可信度。

旁路自由切换既可以借助汽车总线（例如CAN)来完成，也可以通过一个仿真器探头(ErnuJator-Tastkopf, ETK)来直接访间控制 器CPU。在此，所开发控制器的CPU被ETK 代替。ETK也被用 来建立与实验系统的接口。

(2)全替代应用

如果要在车上测试一个全新的功能或者带有旁路接口的控制器不可用时，可以采用全替代开发模式。这种模式下，实验系统必须支持所有实现功能所 需的期望值发生器、传感器和执行器的接口，还必须确定功能的实时性，并由实验系统加以保证（图9-7-7)。通常情况下全替代应用的计算机采用实时操作系统。

7.5 软件功能设计和实现

通过自动代码生成方法可以将先前特定

的功能模型映射到控制器软件组件中去。这

需要在功能模型中扩展软件设计信息。在需要的情况下，根据所要求的电子系统产品特性还要包含必要的优化措施。此外，自动代码生成还可以保证代码的质批稳定。

从数据、功能特性以及软件功能的实时

性技术条件出发，进行软件设计时需要考虑

控制器 络的所有技术细节，以及采用的微控制器和软件架构。这样，软件功能才能够通过软件组件来具体实现（图9-7-8)。

除了针对微控制器在时间与数值上都工作在离散化方式下的特点，要对数据和软件功能特性的设计做出决定外，还需制定微控制器和电子控制器的任务分配和 络连接， 考虑电子系统的可靠和安全性要求。

此外，还需考虑来自电子系统和汽车产品生产和服务的全部要求（例如监控和诊断系统方案、现场控制器软件更新或者软件功能的参数化）。

许多伴随产生的数据可以根据既定的标准自动生成，如资料数据、变扯管理或者预标定参数。

【未完，待续……】