6.12.1软件架构
软件体系结构的设计必须考虑从软件开发到目标微处理器的需求的许多方面，包括连接的模块，这些模块必须灵活，以适应不断的变化和变化。必须定义几个软件层。最少是两层，一层是平台软件，一层是应用软件，如图6.12.1 Schauffele和Zurawka(2005)所示。平台软件面向ECU，包括操作系统、通信和网络管理，符合OSEK/VDX(2005)标准和诊断协议。OSEK代表“汽车电子的开放系统和接口”，是由主要汽车制造商和零部件供应商组成的委员会于1993年成立的，旨在支持实时约束下应用软件的可移植性和可重用性。它还包含标准化的闪存编程过程。在软件开发过程中，平台软件的标准化对软件的变化和参数化也有一定的好处。通过CAN协议进行测量和校准的接口也支持开发阶段，Borgeest (2008)， Zimmerschied等(2005)。硬件抽象层(HAL)允许访问ECU的外围组件，并为使用的微处理器指定硬件抽象层。
应用软件可由发动机或整车制造商自行设计，包含发动机专用功能。从查表及其插值到动态控制算法，控制函数都要标准化。标准化工作例如在msr - megma工作组和ASAM(2012)中进行了处理。
标准化软件组件的配置通过使用配置工具允许特定的应用程序。自动化配置包括信号、消息、总线、节点和功能的处理。它可以包含具有数据交换格式和文档接口的导出和导入接口。更多的细节，如引擎变量的数据模型，易失性存储器(RAM)或非易失性存储器(ROM, PROM, EPROM或Flash memory)中的存储，以及数据结构的描述文件，可以在Schauffele和Zurawka(2005)中找到。
供应商和制造商之间的汽车软件体系结构开放行业标准的活动从2003年开始在AUTOSAR联盟(汽车开放系统体系结构)中进行，AUTOSAR (2012)， Heinecke et al (2004)， ATZ extra(2013)。目标之一是建立一个开放和标准化的汽车软件体系结构。该标准包括描述软件体系结构组件和定义其接口的规范。
AUTOSAR体系结构将基础软件与应用软件分离，并通过标准化接口进行连接，如图6.12.2所示。为了掌握复杂性，定义了几个层，Wernicke和Rein(2007)。与微型计算机的连接由最底层的单片机抽象层提供。在这里，接口被定义为内存、I/ o驱动程序、它们的通信以及不属于微控制器的其他特性。第二层是ECU抽象层，包括ECU的硬件设计，包括外部组件的驱动程序。第三层的服务层提供基本的软件模块，如操作系统、内存管理和总线通信。这一层相对独立于ECU硬件。第四层是运行时环境(runtime environment, RTE)，它将基础软件和应用软件分开，并在两个方向上进行数据交换。因此，应用软件组件具有到RTE的标准化接口。RTE还集成了应用软件组件(SWCs)，如图6.12.3所示。这种与标准化接口的分离和集成使硬件独立于软件开发成为可能。因此，可以将应用程序软件组件传输到其他ecu并进行重用。
虚拟功能总线(VFB)在设计期间连接各种软件组件，并允许独立于特定硬件的配置。因此，SWCs是可运行的实体，可以链接在一起进行开发和测试。通过标准化的软件输入和输出端口，信息交换成为可能。因此，在软件实现之前，对SWCs和接口的交互进行验证是可能的。
6.12.2代码生成
在MATLAB TM(2011)、Simulink TM(2011)、Stateflow TM (2011) (The MathWorks(2011)等高级软件平台上，如果控制函数已经准备好，并且可以作为函数块使用，则可以开始开发控制软件。MATLAB TM是一种广泛应用于数值计算的集成函数开发环境，拥有大量的数学设计和分析程序库以及专用的工具箱。Simulink TM是一个具有图形界面的交互式开发环境，用于建模、分析和仿真，并集成到MATLAB TM中。它允许使用框图处理模型和函数。Stateflow TM是Simulink TM的扩展，用于操作离散事件状态图和流图。
在此面向控制分析和仿真开发环境的块控制功能的基础上，利用专用工具开发了ECU系列产品代码。控制函数以图形形式指定，并在目标处理器上运行的产品c代码中进行转换。因此，与人类程序员的能力相比，它的目标是达到最小的执行时间、RAM和ROM资源和堆栈大小。
代码生成的过程如下所示，Kiffmeier等人(1999)使用软件开发工具(SDT)，如来自dSpace的Targetlink TM或来自ETAS的ASCET TM或来自MathWorks的实时Workshop TM。
(1) Simulink的控制功能块必须被对应的SDT块所替代，该SDT块取自块库。这些块管理用于生产代码的数据，作为伸缩参数和数据类型。
(2)定点算法需要缩放参数。因此，必须知道变量的最大值和最小值。它们可以从循环模型模拟中获得，以确定变量的范围，以防止溢出。通过仿真可以手动或自动进行缩放。对于浮点运算，不需要缩放。
(3)必须指定生产代码生成的附加信息。这属于模型或算法的划分，例如查找表处理，如插值例程。
(4)利用Simulink对上位机进行离线仿真，利用定点算法检测问题。仿真采用浮点算法进行。
(5)将生产C代码翻译为目标微处理器并加载到评价板上。评估板和主机PC机之间的通信链路允许使用Simulink模拟的过程模型测试单片机代码。代码是可读的，开发是与文档并行的，文档是自动生成的。还提供了关于代码大小、执行时间和使用的RAM和ROM资源的信息。其结果是一个通用的可移植的ANSI c代码，运行在许多微型计算机上。然而，一些特定的微电脑适应总是要考虑到。如果必须另外应用手工编码，则必须遵循MSRA-C给出的规则。特殊的工具集允许在编码之前分析实时操作系统应用程序OSEK的计时行为，提供运行时性能和可能的修改。
由于必须为校准任务准备ECU代码，因此变量通过数据字典以标准化的ASAM文件格式呈现。需要考虑的其他标准是OSEK/VDX和AutoSAR。autosar结构元素例如可运行文件、端口和通信接口。用于仿真和控制原型的专用计算机以及用于控制软件开发的软件工具汇编在目录dspace（2011）和etas（2011）中。
现代汽车控制系统通过CAN、Flexray、LIN等车载数据总线进行互联，发动机ECU与其他车辆ECU在传输控制、牵引控制(TCS)、电子稳定控制(ESC)、自适应巡航控制(ACC)等方面的实时协作也需要设计和监控。
6.12.3软件测试
软件测试是开发的v模型验证的一部分，如图6.1.1所示。验证是指所开发的功能满足客户在项目开始时以标准或法律法规规定的规格。更普遍的是验证，最终产品是根据总体需求进行检查的，Balzert (1998)， Tran(2007)，参见第6.1.1节中的V-model。验证确保最终产品满足用户的需求，并包括规范的正确性，如IEEE-STD 610。
软件测试可以理解为分析质量保证的一部分，并包含软件测试。这种质量保证可以分为分析方法(静态)和测试方法(动态)，Liggesmeyer (2002)， Thaller(2002)。静态的分析方法可以在早期应用，因为不需要运行软件。方法是人工检查，可视化和数据流分析，通常由不同的人。动态测试方法对运行的软件进行操作，并检查其功能是否符合规范。将检查输入/输出行为并将软件程序视为黑箱的功能测试与将程序视为白箱的结构测试区分开来。这些结构测试可以分为符号测试、多样化测试和突变测试，Schafer(2012)。
在开发的早期阶段进行软件测试的应用程序可以避免太多的迭代周期。为了实现硬件部件的集成，采用了半实物仿真的方法。然后对目标ECU上的实时软件进行发动机或车辆的仿真实时模型以及实验室中执行器或喷射系统等真实部件的测试，避免对真实发动机或车辆进行测试，见6.11.2节。
表6.12.1概述了用于控制开发的各种开发测试台和工具。开始时需要对发动机进行建模，并使用发动机试验台进行在线和离线建模。控制功能的开发主要在试验台和MiL、HiL、RCP计算机上进行。软件开发通常与PC机和ECU评估委员会离线完成。对实际车辆进行了驾驶性能的微调和排放认证。
7.汽油发动机控制
接下来是汽油机的控制结构，考虑了直接喷射(DI)汽油机(或火花点火(SI)汽油机)的主要部件、主要控制任务以及由此产生的面向控制的框图，如引言章节1.3.1所述。根据图1.3.5的框图、图5.1.5的软件结构和图5.1.6中ECU的层次控制结构，汽油发动机的控制可细分为:
bull;转矩控制
-燃油喷射控制
-空气/燃料比控制
-点火角度控制
-燃烧控制
-爆震控制
bull;排放控制
-排气再循环控制
-催化剂控制
bull;怠速控制
bull;冷却剂温度控制
汽油发动机的一个中心作用是形成空气燃料混合物(A/F)。
汽油的燃烧需要一个非常具体的空气/燃料比，这是化学计量燃烧
m air,st = L st m f
L st = A/F = 14.7...14.9 asymp; 14.8 kg air/ kg fuel.
空气-燃料混合物的测量方法是过量空气系数，其定义为
lambda; =mair/mair,st
A/F混合料对燃烧效率有很大影响，因此对比油耗和废气处理效率有很大影响。
可以区分出过量空气系数的以下范围:
bull; lambda; = 1:
提供的气体与理论(化学计量)要求的气团相对应。
bull; lambda; gt; 1:
通常过多的空气,称为稀混合气,需要实现一个完整的燃烧。对进气歧管喷射燃料消耗最低为lambda;= 1.2到1.5。
bull; lambda; lt; 1:
更少的空气意味着丰富的a / F混合物。最大功率是在lambda;= 0.85到0.95。
催化废气处理经常三方使用的催化剂,这需要lambda;= 1为正常运行。这使得催化剂能够尽可能地减少CO、HC和NO x这三种污染物成分。
lambda;的不同最优值意味着必须找到适当的折衷方案。对于进气歧管喷射发动机和均质燃烧直接喷射发动机，lambda;=0.9至1.1的范围通常足够。然而，分层燃烧直喷汽油机在稀薄燃烧条件下运行，且lambda;le;4。然后需要其他类型的催化转化器，例如NO X蓄电池类型。它们需要再生一个丰富的a/f比（lambda;lt;0.8）。为了获得具有不同参考变量的精确的a/f混合气，在排气中设置了lambda;-传感器，从而实现了一个lambda;-反馈控制器。
摘要目前电控汽油机汽油空气/燃料混合气的形成可分为进气歧管喷射的外部混合气形成和直接喷射的内部混合气形成。表7.0.1给出了特性、属性和组件的概览。
过去，化油器和位于节流阀上游的连续、单点机械喷射系统只采用外部A/F混合气形成。然而，由于不可能满足精确的A/ f比率的高要求，它们不能再应用。它们被进气阀上游的进气歧管注入所取代，这些进气歧管间歇地工作，每个气缸单独工作。喷射器的喷雾直接进入进气口和进气阀，允许湍流中的快速蒸发，只有小的燃料壁膜。注射必须在720执行◦CS和电动燃油泵在坦克提供关于p = 6bar通常是足够的。
在缸内直接喷射形成内部a/f混合气的情况下，可以区分均匀燃烧和分层燃烧。对于均质燃烧，燃油在感应冲程中喷射，即在180 cs内。混合物按化学计量，lambda;=1，分布在燃烧室内。分层燃烧在节气门打开且空气流量充足的情况下运行，平均稀薄混合气lambda;gt;1。引导混合气使其可以在火花塞周围点燃。根据侧喷或顶喷以及活塞凹槽的设计，存在三种类型的喷射：壁喷、空气喷射和喷射喷射。直接喷射需要一个高压燃油泵和一个非常快的电磁阀或压电式喷油器，它们允许喷射时间小于5毫秒。为了放大翻滚或涡流，在进气阀前面安装了可变的湍流襟翼。
下一节将讨论汽油发动机的控制结构。由a/f混合气形成燃烧决定，必须考虑lambda;的不同值
论本章内容
本章首先考虑了目前经典的面向扭矩的控制结构，给出了一种更为详细的汽油机基本控制结构和各种信号流方案。然后，推导了用于动力传动系控制的简化转矩模型。汽油发动机的基本控制方案是空气/燃料和催化转化器控制，也称为lambda;控制。点火角或点火正时通常是前馈控制的，根据不同的变量，通过前馈查找表和基于燃烧压力的燃烧中心计算反馈的自适应查找表相结合，可以提高点火角控制的精度。因此，点火角与各个气缸的特性相适应。进一步研究表明，通过改变点火角和采用分段燃烧中心控制，可以实现平均有效压力的极值控制。然后分别对爆震控制、怠速控制和可变配气机构进行了研究。
作为均质燃烧的替代方案，考虑了分层燃烧和均质充量压缩点火。最后，讨论了冷却系统和润滑系统的信号流方案和控制系统。
7.1汽油机控制结构
过去发动机的电子控制主要是通过各种输入和操纵变量之间的二维映射来实现的，如节气门开度、喷油量、喷油正时和点火正时等。然而，由于许多相互作用和交叉耦合的控制系统结构没有中央扭矩协调是不透明的。自1997年以来，结构已改为扭矩导向方案，从而实现更清晰的基于物理的结构，Gerhardt et al（1997年），Gerhardt et al（1998年）。图7.1.1描述了基本的静态扭矩模型。该模型由气缸充气量（空气质量）m air和发动机转速n=n eng（化学计量燃烧lambda;=1）以及最佳点火角组成。内扭矩由燃烧产生，并且
其中m eng是离合器处的平均扭矩，平均阻力扭矩为
阻力
6.12.1 Software architecture
The design of the software architecture has to consider many aspects from software Development to the requirements of the target microprocessor and includes connected modules which have to be flexible with regard to continuous changes and variants.Several software layers have to be defined. The minimum is two layers, a platform software and an application software, as shown in Fig. 6.12.1, Schauml;uffele and Zurawka (2005). The platform software is oriented to the ECU and comprises the operating system, communications and network management according to OSEK/VDX(2005) standards and diagnostic protocols. OSEK stands for “Open Systems and Interfaces for Automotive Electronics” and is the result of a committee of major automotive manufacturers and component suppliers to support portability and reuse-ability of application software under real time constraints, started in 1993. It also contains standardized flash memory programming procedures. The standardization of the platform software is additionally advantageous during the software development with regard to software changes and parametrization. Interfaces for measurement and calibration via CAN protocols support the development phase as well,Borgeest (2008), Zimmerschied et al (2005). A hardware abstraction layer (HAL) gives access to the peripheral components of the ECU and is specified for the used microprocessors.
The application software can be designed by the engine or vehicle manufacturer and contains engine specific functions. Standardization takes place for control functions, ranging from look-up tables and their interpolation to dynamic control algorithms. The standardization is, e.g. treated in the MSR-MEGMA working group and ASAM (2012).
The configuration of standardized software components allows a specific application by using configuration tools. An automated configuration comprises, e.g. the handling of signals, messages, buses, nodes and functions. It may contain export and import interfaces with data exchange formats and a documentation interface. More details like data models for engine variants, storage in volatile (RAM) or nonvolatile memories (ROM, PROM, EPROM or Flash memory) and description files for data structure can be found, e.g. in Schauml;uffele and Zurawka (2005).
Activities for an open industry standard for the automotive software architecture between suppliers and manufacturers are going on in the AUTOSAR consortium (AUTomotive Open System ARchitecture) since 2003, AUTOSAR (2012), Heinecke et al (2004), ATZ extra (2013). One of the aims is an open and standardized automotive software architecture. The standard includes specifications describing software architecture components and defining their interfaces.
The AUTOSAR architecture separates the basis software from the application software and connects them by standardized interfaces, see Fig. 6.12.2. To master the complexity, several layers are defined, Wernicke and Rein (2007). The connection to the microcomputer is provided by the lowest level, the microcontroller abstraction layer. Here, the interfaces are defined to the memories, the I/O-drivers, their communication and to additional features which are not part of the microcontroller. The second layer is the ECU abstraction layer, comprising the hardware design of the ECU including driver to external components. The service layer at the third level provides basic software modules like the operating system, memory administration and bus communication. This layer is relatively independent on the ECU hardware.The fourth level is the runtime environment (RTE), which separates the basis software and application software and carries out the data exchange in both directions.Therefore, the application software components have standardized interfaces to the RTE. The RTE also integrates the application software components (SWCs), see Fig. 6.12.3. This separation and integration with standardized interfaces enables a hardware independent software development. The application software components can therefore be transferred to other ECUs and reused.
A virtual function bus (VFB) connects the various software components during the design and allows a configuration independent of a specific hardware. Thus the SWCs are runnable entities and can be linked together for development and testing.An exchange of information becomes possible through standardized software input and output ports. Thus a validation of the interaction of the SWCs and interfaces is possible before software implementation.
6.12.2 Code generation
The control software development can start if the control functions are ready and available as function blocks in a high level software platform like MATLAB TM (2011), Simulink TM (2011) and Stateflow TM (2011) (The MathWorks (2011)). MATLAB TM is broadly used as an integrated function development environment for numerical calculations with a large library of mathematical design and analysis programs and special tool boxes. Simulink TM is an interactive development environment for modeling, analysis and simulation with a graphical interface and is integrated into MATLAB TM . It allows the handling of models and functions with block diagrams. Stateflow TM is an expansion of Simulink TM to operate with discrete event state charts and flow diagrams.
Based on the block-oriented control functions of this control-analysis-andsimulation-oriented development environment, the series production code for the ECU is developed by using special tools. The control functions are specified in graphical form and they are converted in production C-code which runs on the target processor. Thereby it is intended to reach a minimum of execution time, RAM and ROM resources and stack size, compared to human programmerrsquo;s abilities.
The process of code generation is performed in following steps, Kiffmeier et al (1999), using a S
资料编号：[4723]
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
