PID理论及其C语言在工程实际中实现
AUTOSAR 软件组件介绍
在AUTOSAR中，应用软件是由一系列相互交互的软件组件构成的。在基于AUTOSAR的应用软件开发过程中，软件组件是整个应用软件的基础，其他软件开发工作如配置、映射等，都是围绕软件组件展开的。本小节重点介绍AUTOSAR中软件组件的相关概念。
软件组件（Software Component，SWC）是AUTOSAR中的一个重要概念。软件组件是封装了部分或者全部汽车电子功能的模块。软件组件包括了其具体的功能实现以及与对应的描述。各个软件组件通过虚拟功能总线进行交互，从而形成一个AUTOSAR应用软件。
虚拟功能总线（Virtual Function Bus，VFB）是AUTOSAR中的另一个重要概念。虚拟功能总线是对AUTOSAR提供的所有通信机制的一种抽象，是所有软件组件进行交互的桥梁。通过虚拟功能总线，软件组件之间的通讯细节被抽象出来，软件组件通过AUTOSAR定义的接口对通讯进行描述，即可最大程度地独立于具体的通讯机制，实现与其他软件组件和硬件的交互。通过虚拟功能总线，无论软件组件使用的是单ECU 的内部通信还是ECU间的外部通信，对于应用软件的设计者来说没有本质区别。内部通信与外部通信的区别只有等到系统配置阶段，将软件组件分配到不同的ECU之后，才能体现出来。而在这种情况下，虚拟功能总线的真实通信实现可以由运行时环境和基础软件来保证。因此，在虚拟功能总线的帮助下，应用软件的各个软件组件不需要关注通信的区别，从而可以在独立的情况下设计开发软件组件，使得应用软件的开发可以独立于具体的ECU，使得开发人员将精力集中在应用软件及其软件组件的开发上。
一个应用软件是由多个相互交互的软件组件构成的，而各个软件组件之间的交互是由虚拟功能总线提供的通信机制来保证的。软件组件通过端口（Port）来进行不同软件组件间或者软件组件与硬件间的通讯或者交互。每个软件组件都需要定义端口。端口代表了软件组件间通信内容及其方向，分为两类，一类是供型端口
（P-Port），一类是需型端口（R-Port）。供型端口用于对外提供某种数据或者某类操作，需型端口用于从其他软件组件获得所需数据或者所请求的操作。将一个软件组件的供型端口与另外一个软件组件的需型端口进行连接，即实现了两个软件组件直接的通信，如图1 所示。
图1 基于VFB的软件组件通信
每个端口虽然定义了软件组件间通信内容及其方向，但是通信内容以及用于交互的操作却仍不得而知。AUTOSAR中使用端口接口（Port-Interface）来描述端口之间的供需关系。端口接口有3种，分别为发送者/接收者接口（Sender-Receiver Interface，S-R）、客户端/服务器接口（Client-Server Interface，C-S）和标定接口（Calibration Interface），如表1所示。
端口接口类型描述
发送者/接收者发送者发送消息到一个或多个接收者
发送者/接收者服务器是操作的提供者，多个客户端可以调用这些操作
标定标定是一种静态的通信方式，它允许模块访问静态标定参数
发送者/接收者接口定义了一系列的数据元素用于在虚拟功能总线上进行接收和发送，如图1的ISignalPeriod所示，该接口定义了一个命名为duration，类型为无符号16位整数的数据元素。
客户端/服务器接口定义了一系列的操作，这些由包含该接口的供型端口所在的软件组件来实现，并提供给包含该接口的需型端口所在的软件组件调用，如图1的ILeverPos所示，该接口定义了一个命名为getAngle，有一个输出类型（即值可以被函数修改）的有符号12位整数参数的操作。参数的名字不影响接口的含义。每个端口只能定义其中一种接口类型，具有相同端口接口类型或者兼容接口类型的端口才可以进行通讯。
以上介绍了软件组件的对外表现形式，即一系列的端口以及与之对应的端口接口类型。下面介绍软件组件的内部行为。
软件组件的功能是通过运行实体（Runable Entity）来表现的。软件组件被分成若干个可执行程序单元，即运行实体。运行实体软件是组件中的一组指令序列，一个或者多个运行实体实现了其所在软件组件对外提供的功能。每个运行实体都与一个特定的RTE事件（RTEEvent）绑定。当绑定的事件发生时，对应的运行实体就会被触发。在AUTOSAR操作系统中，运行实体将会运行在操作系统的任务的上下文中。任务需要给运行实体提供必需的资源，例如栈空间等。运行实体通过访问端口的数据或者操作来完成自身的功能，并把数据处理的结果或者提供的操作通过端口对外提供。因为端口上的通信机制是由虚拟功能总线进行抽象过的，因此运行实体的实现中，涉及到访问端口数据或操作的时候，需要使用RTE提供的API来进行访问。这样，使得运行实体的实现是与平台无关的，从而软件组件也是与平台无关的，进而增强了软件组件的移植性和可重用性。运行实体可以通过建模工具进行建模设计并自动生成代码，也可以手工编写代码。
如前所述，每个软件组件必须提供其代码的具体实现以及描述文件。代码实现即运行实体的实现，以C源文件或者目标文件的方式提供。而描述文件必须描述软件组件的属性，包括所使用的端口、端口接口、运行实体、以及运行实体所对应的RTE事件等，以XML（eXtensible Markup Language）文件形式提供。
综上所述，在AUTOSAR中的软件组件可以使用如图2 所示的示例图来表示。
图2 AUTOSAR软件组件示例
根据应用目的的不同，组件可分为7种类型。如表2所示。软件组件不允许绕过RTE直接访问下层基础软件提供的服务，因此服务、ECU抽象和复杂驱动被抽象成一个同样有端口的软件组件，通过服务连接器与应用层的软件组件组合成ECU组合组件。BSW中的组件都具有标准化的AUTOSAR接口。
种类描述
应用软件组件应用软件组件是一个原子软件组件，它实现部分或者一个应用。原子软件组件可以使用所有符合AUTOSAR的通讯机制和服务。应用软件组件通过传感器/执行器软件组件与传感器或执行器交互。
传感器/执行器软件组件传感器/执行器软件组件是一个来处理具体的一个传感器和(或)执行器的原子软件组件，它直接
与ECU抽象层交互。
标定参数组件标定参数组件提供标定参数值。
组合组合包含了原子软件组件和组合，因此它可以使用所有符合AUTOSAR的通讯机制和服务。服务组件服务组件通过AUTOSAR标准化的接口提供服务，主要处于基础软件层。
ECU抽象组件ECU抽象层提供访问ECU具体的IO的能力。该层次仅使用C-S接口的供型端口，并且由传感器/执行器软件组件所使用的。ECU抽象层也可直接与其他一些基础软件交互。
复杂设备驱动组件复杂设备驱动组件推广了ECU抽象组件。它可以定义端口，通过特定方式与其他软件组件交互，也可以直接与硬件交互，是灵活性最强但可移植性最差的组件。
AUTOSAR是由全球汽车OEM和供货商共同推出的一种汽车电子嵌入式软件分层架构。该分层架构由微控制器抽象层、ECU抽象层、服务层、执行时环境(RTE)和应用层组成，前三层被统称为基础软件(BSW)。
AUTOSAR各层软件的通信通过三类接口实现，分别是标准接口、AUTOSAR接口和标准AUTOSAR接口。其中，标准接口用于BSW各个模块之间的通信，已用C语言定义，如void Adc_Init(const Adc_ConfigType* ConfigPtr)。AUTOSAR接口用于软件构件(SW-C)之间的通信或者软件构件和ECU固件(IO硬件抽象、复杂设备驱动)之间的通信，这类接口命名以“Rte_”为前缀。标准AUTOSAR接口用于软件构件存取AUTOSAR
服务。依赖这种分层架构和接口定义，AUTOSR显著提高了汽车电子嵌入式软件的可重用性——层级越高者，可重用性越强。值得注意的是：
* 微控制器抽象层层级最低，随微控制器的更换而更换；
* RTE虽然层级仅低于应用层，但由于它负责着应用层和BSW之间的桥梁作用，和硬件的耦合性最高，不具有可重用性；
* 应用层(除传感器、执行器相关的软件构件外)完全独立于硬件，具有绝对的可重用性。
都是汽车电子软件的标准。
osek基于ECU开发，标准包括三部分：操作系统、通信(交互层)、网络管理
autosar基于整体汽车电子开发，包括汽车电子功能的划分、ECU统一软件架构、ECU软件开发过程等整套的方法论
autosar中规定的操作系统就是osek os，而通信和网络管理虽然和osek有区别，但思路一样的。
所以认为，autosar是基于osek提出的(但不仅基于osek)，osek被autosar标准软件架构包含。
基于FPGA的汽车ECU设计充分符合
AUTOSAR和ISO 26262标
当今的汽车制造商正在把越来越多的高级功能添加到汽车电子控制单元（ECU）中，以改善驾驶体验，增强安全性，当然还期望超过同类竞争产品的销量。在这种情况下，汽车开放系统架构（AUTOSAR）计划和功能安全国际标准ISO26262 正在快速成为汽车ECU 设计的技术和架构基础。
为了满足新车型日益提高的功能需求，汽车电子产品的密度不断增大，FPGA 厂商也正在不断推出更大型的器件。这些器件能够集成所有的应用，而且与前代器件相比，功耗更低，价格更具竞争力。这种趋势意味着可重配置计算技术在汽车产业将会得到进一步推广和应用。
我们推出了一种具有开创性的方法，即使用可编程FPGA 器件而非基于MCU 的平台作为ECU 的基础，设计出一款能够同时满足AUTOSAR 和ISO 26262 标准的汽车ECU。我们的设计方法对可重配置硬件的关键特性，比如并行性、可定制性、灵活性、冗余性和多功能性进行了充分的探索。在概念设计完成后，
我们希望在原型中实现设计。为此，赛灵思Zynq?-7000 可扩展处理平台成为了理想选择。该款FPGA平台将ARM? 双核Cortex?-A9 MPCore 硬处理器和具备动态部分可重配置功能的28 nm 赛灵思7 系列可编程逻辑器件完美结合在一起，不但可充分满足所需要求，而且还配备有CAN 和以太网等车载网络常用的片上通信控制器。
新兴应用
目前汽车计算能力借助通过通信网络互连的ECU来分配。在未来几年内，由于机动车辆中新应用的兴起，这样的计算能力有望进一步提高。这些新应用包括安全和驾驶员辅助功能、车辆间通信功能、舒适性和控制功能、车载娱乐功能以及为数众多的混合动力电动技术。毫无疑义，车辆电子设备的数量预计还会增加。根据分析人员的预测，汽车应用半导体市场的规模将在未来五年内以8% 的年均复合增长率（CAGR）增长。其中增长最快的细分市场之一涉及到微控制器（MCU）和可编程逻辑器件，比如现场可编程门阵列（FPGA）。
在车载功能的数量和先进性与日俱增的同时，设计和管理这些系统变得日趋复杂，汽车制造商认为有必要采取有效方式来解决这一难题。其结果就是当今AUTOSAR 和ISO 26262 两大标准都在影响着实际汽车ECU 软硬件系统的架构、设计和部署方式（见侧边栏）。
2003 年由多家汽车制造商共同制定的AUTOSAR 标准旨在为分布于车辆中的ECU 定义标准的系统软件架构。而ISO 26262 标准的目的则以功能安全性为中心，实质上是以避免或检测并处理故障为目的，从而减轻故障影响并防止出现对任何既有的系统安全目标的违反行为。随着全新的安全关键功能（比如驾驶员辅助或动态控制）的推出，功能安全性已经成为汽车开发中的关键问题之一。ISO 26262 标准于2011 年批准生效，可为软硬件的安全开发提供支持。
因此，整个ECU 的设计和开发流程由需要系统性进程的标准进行管理。我们的工作就是设计一款高性价比嵌入式计算平台，采用可重配置硬件技术实现优化的系统架构。
系统架构
AUTOSAR 和ISO 26262 标准主要从软件开发的角度着眼，面向的是基于微控制器单元的计算平台。但是，硬件/软件联合设计和可重配置计算技术的应用可为这个领域带来众多优势。虽然标准的MCU 往往是汽车ECU 硬件平台的最佳选择，但随着新型FPGA成本的不断降低，加上部分FPGA 产品内部集成有硬核处理器，使得FPGA 器件也成为这个市场中值得广泛应用的理想解决方案。此外，汽车中不断集成新的嵌入式功能的趋势也提出了对并行计算架构的需求。这在当今的车载信息娱乐领域尤为明显，在这种领域中高速数字信号处理正在敞开大门迎接FPGA 技术。像赛灵思这样的可编程逻辑供应商和像MathWorks 这样的EDA 工具厂商已对这个领域表现出明显的兴趣。
为了在汽车应用中发挥可重配置硬件的全部优势，我们将以关于部署最终用户功能的汽车计算网络中最为重要的ECU 之一——“车身控制器模块”为重点，通过使用案例展现这种技术的潜力。该ECU也称为“车身域控制器”，负责综合和控制车辆中主要的电子车身功能，比如挡风玻璃雨刷/喷水系统、车灯、摇窗器、引擎点火/熄火、车外后视镜和中控锁。我们的目标是在FPGA平台上设计出一款配备有安全关键功能且符合AUTOSAR 的ECU 系统。
实际情景
如果汽车制造商要想经济高效地管理日益复杂的车辆功能，经AUTOSAR 提倡的ECU 系统架构的标准化则是必由之路。它能够实现分布在ECU 中的各项功能的高度集成和软件组件的重复使用。AUTOSAR
的主要目的是定义一个统一的ECU 架构，让硬件与软件分离。这样AUTOSAR 通过定义硬件无关的接口，可提高软件的重复使用。换句话说，如果按照AUTOSAR 标准编写的软件组件，只要正确集成到符合AUTOSAR 标准的运行环境中，就能够在任何厂商的微控制器上运行。
这项功能给汽车制造商带来了更高的灵活性。由于AUTOSAR 标准内在的即插即用特性，汽车制造商可以在整个汽车平台上以透明的方式更换不同供应商开发的相同软件模块的各个版本，且不会给汽车中其余功能的发挥造成负面效果。最终硬件和软件实现彼此高度独立。这种分离是通过标准软件的API 将抽象层互联实现的。图 1 是AUTOSAR 定义的功能层的分解图。
图1 从MCU 到应用层的AUTOSAR 分层模型
底部以黑色表示的是硬件层或物理层，由MCU 自身（即CPU 和与其相连的部分标准外设）构成。微控制器之上是基础软件（BSW），分为三层：粉色的微控制器抽象层（MCAL）、绿色的ECU 抽象层（ECUAL）和复杂驱动程序、紫色的服务层（SRV）。这三层经组织形成了多个列或协议栈（存储器、通信、输入/输出等）。
紧贴硬件组件的是微控制器抽象层。正如其名所示，该层是MCU 的抽象。该层的目的是提供一个硬件独立的API，负责处理微控制器中的硬件外设。微控制器抽象层的上一层是ECU 抽象层，负责抽象ECU 开发板上的其他智能器件，一般直接与MCU接触（例如，系统电压调节器、智能交换控制器、可配置通信收发器等）。接下来的第三层是服务层。该层基本具有硬件独立性，其作用是处理所需的不同类型的背景服务。例如网路服务，系统看门狗的NVRAM 处理或管理。通过这三层，AUTOSAR 定义了一套基础软件功能。这套软件功能在特定的硬件平台下支持着汽车ECU 各高级抽象层的所有功能。
第四层是运行环境（RTE），为应用软件提供通信服务。它由可从上面的BSW 层和应用层（APP）共同访问的一套信号（发送器/接收器端口）和服务（客户端和服务器端口）构成。该RTE 从基础软件中抽象出应用，明确地勾勒出将通用的可交换软件代码（APP））与特定的硬件相关代码（BSW）分离的软件协议栈架构。换句话说，RTE可将软件应用与硬件平台分离。因此运行在RTE 上的所有软件模块都具有平台无关性。
在RTE 之上，通过应用层，软件架构方式从分层变为以组件为基础。功能主要封装在软件组件（SWC）中。因此，完成AUTOSAR 软件组件接口的标准化是支持各项功能跨不同车辆平台的ECU实现可扩展性和
可移植性的中心环节。除复杂驱动程序外，AUTOSAR 标准明确地规定了这些组件的API 及特性。SWC 仅通过运行环境与其他模块（ECU 间或内部）通信。
随着ECU 不断集成越来越多的功能，FPGA 器件成为了单核或多核MCU 的明智替代。通过从总体上把握AUTOSAR 的不同层次，可以预见设计人员将这种架构部署在可编程逻辑中所能带来的优势。下文将更深入地介绍我们的设计如何实现基于定制静态硬件（基于闪存或SRAM 的FPGA 技术）的解决方案，然后将这种方法延伸为为一种运行时可重配置的硬件实现方案（基于SRAM 的部分可重配置FPGA）。
基于FPGA 静态硬件的ECU 设计
AUTOSAR 架构非常适合由CPU、存储器和可编程逻辑组成的嵌入式系统。ECU 平台需要一个CPU 或主机处理器来管理应用并处理分布在应用层的软件组件中的不同功能。同时，MCU 层和部分基础软件层可以在可编程逻辑结构中的硬件中综合。因此，除了能够实现与CPU 相连的标准外设，其它定制外设和协处理器也能够在硬件中并存，并在软件中完全或部分地加以管理。
另外从功能安全的角度来看，专用协处理器或内核处理器也非常适用，因为用它们实现功能可让硬件从源头避免干扰，即便要求冗余性，也能给系统设计带来高灵活性。另外，居于中间的RTE 层可以在分布于FPGA 中的RAM 模块中，或者在嵌入在器件逻辑单元中的触发器中以及外部存储器中综合。而且，RTE 信号接口经简单设计就能够同时进行读写操作（通过单端口存储器）或限制架构仅进行读操作或者写操作（通过配有两个独立读写端口的单个双端口存储器），以防范干扰，比如AUTOSAR 所定义的彼此对应的发送器和接收器软件端口。
图2 将AUTOSAR ECU 架构移植到FPGA 平台上
建议将基于MCU 的AUTOSAR ECU 架构移植到可扩展处理平台（EPP）或者FPGA 器件上，并在各层中确保清晰的系统分区，如图 2 所示。位于RTE 层以下的有操作系统（OS）、存储器协议栈、通信协议栈、I/O 协议栈等。位于RTE 层以上的是软件组件，它们用于实现应用并通过AUTOSAR 接口与RTE 进行通信。
由于AUTOSAR 架构内在的复杂性，需要功能强大的嵌入式计算平台才能进行部署。如今，典型的ECU 设计基于运行在MCU 平台上的32 位单核处理器。但是单核越来越难以提供所需的全部计算能力。而使用
多核CPU 需要通过多处理器总线和仲裁机制共享程序/数据存储器，往往会导致高度复杂的解决方案，造成性能劣化。
作为这种方案的替代，我们提出了一种基于可编程逻辑的设计。这种设计只采用一个单核处理器来发挥主机CPU 的作用，但配有更智能的外设、协处理器乃至从处理器。所有这些计算单元都可以在FPGA 架构中例化为新的软核处理器，比如赛灵思PicoBlazeTM 和MicroBlazeTM，从FPGA 的专用RAM 模块运行自己的代码（各个软核处理器均分别配有专用程序存储器），此外，也可例化为定制的硬件加速器。两种方式的拓扑架构均由一个主机CPU 和分担部分CPU 任务的智能外设构成，从而可降低系统复杂性。这样，主机CPU 负责管理软件中的整个应用层，而定制外设则负责管理BSW 层，这两者以并行的方式彼此独立地自动运行。此外，这种外设设计的方法的优点还在于能够让主机CPU 的软件执行更加线性化，即外设不会通过中断服务程序产生过多的请求CPU 关注的中断。图3 显示了这种系统的方框图及其对应为FPGA 器件中综合的功能单元的组件细分情况。
图3 在FPGA 中部署的汽车ECU 方框图
FPGA 方法能够实现与多处理器平台相媲美的系统性能，且和单核处理器一样简单易用，这主要归功于采用了可与主机处理器并行处理的功能强大的、自动化定制协处理器。
这种方法能够实现与多处理器平台相媲美的系统性能，而且就软件开发和维护而言，和单核处理器一样简单易行。通过使用专用硬件构建可与主机处理器并行处理的功能更强大的自动化定制协处理器，就可实现这种最佳平衡。
从概念上来说，可以通过将这些系统架构用RTE 接口划分为顶层和底层两个彼此独立的主要层次来要简化设计。顶层相当于AUTOSAR 的应用层，由负责管理车辆中最终用户功能的软件组件构成。而底层则由硬件和基础软件乃至RTE 链路构成。应用层从数值上来说，可代表约90% 的车载高级功能，而且所有RTE 以上的源代码都可重复利用。
同时，底层包含能够赋予顶层灵活性和多用性的全部功能。这即是说，底层可完成特定硬件平台上所有可重用功能的定制化。这样，顶层从本质上说是通过以有限状态机（FSM）形态实现的算法来实现对某些车辆负载、传感器和制动器的控制的一套软件功能。这些算法由CPU 循环执行，并在操作系统控制的软件任务中调度。
底层还负责实现CPU 连接的所有标准外设的驱动程序，例如A/D 转换器、PWM 控制器、定时器或者存储器控制器，从而让顶层的抽象具备可行性。底层负责管理那些需要得到实时响应的事件。在这方面可编程逻辑能够起到一定的作用。其构想为：让主机CPU 将应用当作一个简单的免受通常硬件造成的外部事件影响的软件功能序列来处理，但要定期读或写RTE 信号，让FSM 进行相应的调整。底层对硬件事件进行
隐藏与管理，然后在RTE 中对其进行预处理并更新特定信号，或作为结果，根据自身具体任务安排实时地执行特定的行动。
将定制硬件控制器连接至系统CPU 可以最大限度地降低对共享资源的需求，只要这些控制器能够自动运行。从操作系统的角度来看，这样做有助于降低系统的复杂性（避免仲裁、时延、重试机制等）。
采用专用硬件的另一项优势在于可以更简便地实现一般在软件中通过多线程才能实现的某些功能，因为硬件较软件内在更具并行性。另外，这种灵活的硬件能够采用并行和流水线硬件设计，将算法计算强度高的部分进行硬连接，而不是采用冯·诺伊曼（Von Neumann）计算机所采用的序列软件方法，从而减少执行时间。
用户可以将在MCU 和BSW 层中综合的外设和硬件协处理器设置成高智能化水平，以释放CPU 时间，从而简化车载ECU 的软件。
随着ECU 平台日趋复杂化，系统所需的I/O 线路数也在不断增加。在这方面FPGA 较微控制器有明显的优势，因为FPGA一般能够提供多得多的用户引脚数。这一点一般与基于MCU 的ECU 有关，因为这种ECU 需要采用执行并-串数据转换的外部芯片（比如数字移位寄存器或模拟多路复用器）来扩展ECU 的输入和输出。采用FPGA 可以绕开这些外部组件，进而缩减材料清单成本以及电子开发板的PCB尺寸。
先进的FPGA 器件已经集成有模数转换器。这个特性对汽车设计意义重大，因为许多ECU使用模拟信号（比如电池电压）来实现所需的部分功能。在可编程逻辑器件中集成模数转换器为FPGA 开辟了新的应用领域。
与MCU 类似，FPGA 也提供远程更新功能。但在这里需要提醒的是，下载到FPGA 中的位流不仅涉及到软件代码，而且与硬件电路也息息相关。这意味着就算产品已经进入量产阶段，仍然可以通过系统更新或升级来修改硬件设计。汽车产业非常欣赏这种灵活性，因为它能够在产品发布后修改缺陷（软/硬件均可）。
在任何嵌入有符合ISO 26262安全相关要求的功能的ECU 中，涉及该实现方案的软硬件必须根据其分类满足一定程度的保护要求。从软件的角度讲，它必须体现出抗干扰能力，即运行在ECU 中的非安全相关代码一定不能危及同一ECU 中安全相关类的代码的运行。这种隔离是保证安全相关功能与非安全相关功能在同一处理器上正确并行运行所必须的。一般来说，在可编程逻辑中管理这些指标比在MCU 中具有更大的灵活性。
对于面向功能安全的存储器保护策略，有必要确保只能授权的安全软件组件有权对特定安全相关信号进行写入存取。在MCU 器件环境中，存储器分区提供了一种故障约束机制，能够将软件应用彼此分离，避免其间发生数据错误。可编程逻辑很有可能实现一种更有效的自我保护机制。可编程逻辑可以通过专用的单个双端口存储器来管理与安全信号相关的RTE 缓存，这样数据从写端口写入，从读端口读取。采用这种方法，可以采用专用的硬件控制器给写入或读取这些来自软件侧的信号设置不同的约束条件。这种方法也可以采用寄存器来实现。
能够在ECU 系统中导入定制硬件解决方案是FPGA 的一大优势，特别是对安全相关的功能而言。具体而言，对I/O 引脚和GPIO 控制器，在安全功能中涉及的引脚布局可以组合成定制的I/O 端口，仅供ECU 中的安全组件访问，与器件的其余引脚分离。这是将系统的安全相关引脚与非安全相关引脚分开的理想办法，从设计上避免了干扰的发生。任何对非安全引脚的访问都不会破坏安全引脚的状态，因为安全引脚只受安全相关代码的管理。这种构思的具体描述见图4。
图4 软/硬件联合设计的安全架构，可将安全相关端口和非安全相关端口隔离开来，以保证无干扰
另外，还能够根据应用或处理该应用的软件组件的需求定制每个GPIO 端口的大小，从而避免将GPIO 端口转换为不同应用共享的物理资源，如MCU端口的情况。用这种方法，FPGA中每一个由不同软件组件（比如车窗升降器、雨刷、外后视镜等）管理的应用都能够将自己特定的端口映射到系统存储映射中特定的寄存器。这在MCU 平台上无法做到，因为MCU的端口有固定尺寸（一般为8、16 或32 位宽）且按字长寻址，而非按位寻址。因此在采用MCU 的情况下，这种控制寄存器在程序执行的时候变成了有多个SWC 访问的共享资源。
我们可以把用于GPIO 控制器的策略扩展用于其它标准外设。这样AUTOSAR 借助SWC 概念在顶层提倡的功能分区和隔离思路也可以在可编程硬件的帮助下推广运用到较低层的资源上。这种技术如果采用基于标准MCU 器件的静态硬件解决方案是无法实现的。
我们上文介绍的用于MCU 标准外设的隔离策略也可以用于安全功能的各个通道或数据路径。这一特性尤其适用于按ISO 26262 标准的ASIL 分级组织的精细分类安全目标（见侧边栏）。此项功能可用于将各个通道或者数据路径分解成较低ASIL 级别的冗余分区，这样每一个通道或路径都以冗余方式运行，后续根据各自的新级别予以实现。这种基于冗余的安全策略是选择可编程逻辑的又一理由，因为可编程逻辑能够在同一器件中多次例化多个相同、独立的处理引擎。另外，满足某个ASIL 级别的要求用架构方法（硬件）往往比用抽象软件能够更轻松明晰地证明，特别是像抗干扰这样的功能。C 编程语言中的栈溢出或是数据指针处理不当可能会给系统带来出乎意料的安全性问题。
这种基于冗余的安全策略是选择可编程逻辑的又一理由，因为可编程逻辑能够在同一器件中多次例化多个相同、独立的处理引擎。
可编程逻辑的灵活性及其对功能安全的适用性还带来另一项设计优势，就是可以采用三模冗
余（TMR）策略。这是航空航天应用中用于缓解单粒子翻转（SEU）风险的常见方法。这种缓解方案由三个相同逻辑电路构成，并行执行相同的任务，对应的输出由一个多数表决电路进行比较。采用硬件实现这种策略效率很高。
另外，在这个高度关注成本和功耗的市场上，赛灵思Zynq-7000 EPP等一些可编程逻辑器件能够支持多项降低系统总体功耗的功能，其中的部分功能是从MCU 继承而来。像处理系统的仅加电模式、休眠模式和外设独立时钟域这样的功能能够大幅降低器件待机期间的动态功耗。
某些可编程逻辑器件在结构中配备有硬核处理器，便于设计人员第一步先用软件开发整个系统功能，就像他们寻常在MCU 平台上所做的一样，随后逐步地在设计中增加硬件，将部分设计移植到可编程逻辑资源。这种方法能够让设计人员为解决方案开发出不同的版本，而且与纯软件方法相比，能够实现在定制硬件中综合部分功能的优势。
在运行时可重配置硬件上进行ECU 设计
在探讨完毕借助可编程逻辑在静态硬件和软件上实现ECU 的优势后，我们接下来探讨采用基于SRAM 并具备运行时部分可重配置功能的FPGA 设计ECU。部分可重配置技术能够为汽车设计人员提供更多优势。
事实上，其中的一大优势是如果FPGA 包含有不必在启动时（如在ECU 唤醒或加电）配置的部分可重配置区域，可以缩短系统启动时间。不支持动态部分可重配置的FPGA在加电时需要配置所有的FPGA 资源，但运行时可重配置FPGA 只需下载部分位流进行部分重配置。
由于当今先进的FPGA 器件具有巨大的容量，故在加电时下载完整的位流会引起可观的配置时间开销。运行时部分可重配置技术能够显著地缩短这种配置时延。在那种情况下，有可能在加电时只配置一个最起码的子系统（即引导载入程序和立即需要的部分系统应用），让系统其余部分保持待机状态，直到有必要初始化为止。如果系统在加电或唤醒时需要快速响应，可将这种启动工作划分为两个阶段，以加快初始化过程。为此，可将系统架构分解为一个静态域和一个或者多个部分可重配置域（PRR）。静态域涵盖负责执行启动过程的系统（一般来说是主机CPU），以及可重配置引擎和通往位流库的数据链路。由特定部分位流描述的其他域可按应用需求，随后下载。
另外，如果禁用PRR 域，则可以让器件的功耗与禁用区域部分成比例降低。在使用汽车电池供电的ECU 中，节能模式尤为重要。为此，在车辆未使用时（即处于休眠模式时），车载ECU 可使用低功耗模式，以让ECU 功耗保持最低。同样，可以在不需要的时候使用空白位流禁用FPGA 的部分区域，减少逻辑活动，从而降低动态功耗。
在采用运行时可重配置逻辑的系统中，汽车设计人员还可使用一种从航空航天应用中借鉴来的重配置技术。重配置（configuration scrubbing）可以将系统从因单粒子翻转（SEU）和电磁干扰造成的SRAM 故障中恢复过来。定期重新配置硬件外设可保证系统在出现故障时自我修复。另外，这样也可以将故障的最大时长限制在重配置时间间隔内。这种技术也通常运用在软件中，作为一种常见的抗干扰保护措施，例如MCU 外设的定期重配置。
另一项运行时部分重配置技术的灵活性带来的有前景的功能是在FPGA 资源的某个特定二维位置出现永久性或不可修复的电路故障，比如影响到特定逻辑单元或RAM 模块时，可通过功能重定位实现故障修复。一旦发现有硬件或软件故障出现，可以在运行中将所需的功能自动重定位到同一ECU 中的可编程逻辑器件的其他部分。虽然这个构思是可行的，但这项功能还没有得到当今的自动化工具的完全支持。
适用于汽车产业的运行时可重配置计算技术最强大的特性无疑是共享的硬件资源上功能的实时时分复用。可以对由ECU 中的相同计算资源处理的功能性应用进行时间共享，如果应用间相互独立（例如，当车辆向前直行驶时使用行车道偏离预警功能，倒车时，则切换到后视摄像头视图或停车辅助应用）。这种设计思路可以帮助降低此类嵌入式系统的成本和复杂性，释放空间，减轻车身重量。
这种设计思路还可用于实现特定算法在不断变化的环境条件或者外部条件中的自适应性。例如，给定的引擎控制算法可通过部分可重配置自主调整部分硬件模块，以在任何运行温度下或电池电压下实现理想的运行。同样的理念对通信系统也适用，比如可以设计某种加密控制器，能够在运行中运用特定的参数函数制定专门的安全等级。另如，可以设计某种ECC 加密器/解密器IP，用于在高噪声通信信道中检测和修改数据传输错误，能够根据感应到的信噪比动态适应其硬件架构。图5显示了一个采用赛灵思Virtex?-4 FPGA 部署的ECU 系统的示例，由一个静态域和一个部分可重配置域构成。静态域集成了一个MicroBlaze软核处理器和一个基于ICAP 的重配置控制器，部分可重配置域（PRR）则发挥着共享资源的作用，负责在不同时间换入和换出不同的功能任务或应用。
最后，如果将前述的构想发挥到极致，可以设计出一种通用汽车ECU 平台。这种平台可以在生产线上进行配置并针对汽车中特定的ECU 功能进行定制。这种构想在技术上借助可重配置硬件具有可行性，能够简化制造厂的物流要求，将存货压低到最低水平。这是因为从硬件的角度来看，在生产线上组装的模块对所有车辆都是一样的，都采用单一平台设计或产品架构（基于灵活的硬件）。只有可下载的位流会让ECU 的功能具有差异。
图5 在由部分可重配置域和静态域构成的运行时可重配置FPGA 中实现的汽车ECU 应用的空间分区和临
时分区
高集成度ECU
在当今的汽车产业中，有约90% 的创新来自汽车电子设备，而且这个势头方兴未艾。未来汽车将采用非常先进的软硬件技术，实现大量的新功能，比如自动驾驶、车辆间通信、娱乐以及和更高安全性。但是，对在这个以大批量制胜的产业而言，控制车载嵌入式系统的成本对汽车制造商极其重要。因此，当前的趋势是在减少车辆中的ECU 数量的同时让每个ECU 发挥强劲的功能。要实现这个目标需要功能更加强大的计算平台。
许多行业参与方共同采用的方法是开发用作域控制器的高集成度ECU。就是将多个单核处理器或微控制器布置在同一开发板上，共享总线连接和其他资源，旨在从整车的角度降低系统复杂性。这种趋势让我们联想到可以将可重配置硬件用于ECU 的设计，从而在有效提高计算并行性，降低PCB 的复杂性的同时，实现最高性价比解决方案。
这种设计方法虽然在我们的工作中尚处于萌芽阶段，却为将AUTOSAR 和ISO 26262 标准与运行时可重配置硬件融合用于软/硬件联合设计，实现完整的车载嵌入式ECU 系统奠定了基础。实际上，虽然目前AUTOSAR 还没有覆盖到可重配置硬件，但我们不排除将来有这种可能。基于SRAM 的运行时可重配置FPGA 已用于航空航天应用，能够满足容易导致SEU 的更为恶劣的环境条件的要求，况且汽车行业从历史上看有借鉴航空航天行业率先开创的风气的习惯。另外，在市场上已经存在某些合格的用于实现基于FPGA 的安全相关系统的设计方法和工具，而且行业中涉及FPGA 器件的标准也已经存在有相当长时间，比如用于规范航空电子业组件和系统设计的DO-254 标准。
联合设计带来模式变革
因此，我们的工作将掀起汽车产业计算模式的变革。在特定的ECU 应用场景中，纯软件的解决方案将被软/硬件联合设计和可重配置计算技术所取代。这是因为采用冯诺依曼型MCU 的纯软件方法由于性能、复杂性和安全性方面的局限，已不敷使用。可编程逻辑技术的价格的不断降低，加上汽车电子控制单元性能需求的不断走高，将在不久的将来把这场变革变为现实。
两大关键标准
汽车产业在设计车载电子设备时已将两项关键标准奉为圭皋。其中一项标准是AUTOSAR，它通过适当的软硬件架构解决嵌入式系统复杂性问题。另一项标准是即将推出的ISO 26262，用于管理功能安全性。AUTOSAR提出的以及ISO 26262 采用的相关技术课题主要为安全问题的检测和处理，比如运行时发生的硬件故障、时序失常和应用执行的逻辑顺序打乱、数据损坏等。
AUTOSAR详解
近年来，电子组件已经取代了车辆中的机械系统和液压系统。随着设计人员开始用软件实现更多的控制、监控和诊断功能，这种趋势正在持续。实际上，用电子技术能够实现仅用机械和液压解决方案无法开发者开发成本高的新功能。但这些部件必须满足严格的安全要求，以避免出错和故障。
虽然软件相关的故障目前来看比较罕见，但随着软件在汽车这种工业制品中用量的不断增加，系统变得日趋复杂，加上产品开发周期的缩短，最终可能导致产品故障。为解决这个问题，汽车产业通过结盟和实施标准，确保使用和开发安全可靠的软件。
比如汽车工业软件可靠性协会（MISRA）就是由福特和美洲豹路虎这样的汽车制造商、组件供应商和工程咨询方组成的团体。通过制定一系列软件编程规则，MISRA旨在在道路车辆的车载安全相关电子系统和其他嵌入式系统的开发工作中推广最佳实践。
汽车开放系统架构（AUTOSAR）是来自电子、半导体和软件行业的汽车制造商、供应商和其他公司组建的联合体为解决几项重大问题而制定的一种事实上的汽车电气/电子（E/E）架构开放行业标准。这几项重大问题包括：控制随功能不断增加而导致的日益提高的车载电气/电子系统复杂性；提高灵活性以便产品的修改、升级和更新；在产品线内部以及跨产品线提高解决方案的可扩展性；改善电气/电子系统的质量和可靠性；实现设计初期阶段的出错检测。
这个架构面临的挑战是必须集成广泛供应商提供的日益丰富的软件和电子技术。通过简化软硬件的交换和更新选项，AUTOSAR 架构为可靠地控制汽车车载电气/电子系统日益提高的复杂性奠定了基础，同时在保证质量的情况下改善了成本效益。
AUTOSAR 架构制定于2003 年，是更早期的OSEK/VDX 联合体的自然发展。OSEK/VDX 联合体诞生于十年之前，由部分德国和法国汽车制造商主推。由于有更远大的目标，AUTOSAR如今已经为世界各地大部分汽车制造商采用。
AUTOSAR 架构的核心成员包括宝马集团、博世、大陆、戴姆勒、福特、通用汽车、雪铁龙、丰田和大众集团。除了这些核心成员公司，另有160 余家其他成员为联合体的成功发挥着重大作用。由此，在“在标准上合作，在设计上竞争”的口号的指引下，汽车制造商和供应商联合一致，共同制定了这个旨在实现车载电气/电子设计突破的开放标准化系统架构。
功能安全性
与此类似，IEC 61508 是负责管理电气、电子和可编程电子系统和组件的功能安全性的国际电工委员会的一般性标准，自2004 年生效以来已经得到世界各地的认可，适用于各个领域的安全相关系统。
在专门为功能安全性制定的其他标准中，有一项系专门为汽车行业的功能安全性制定，这就是国际标准化组织的ISO 26262。这项新标准尚在制定过程中，预计将于2012 年颁布，旨在支持和推动汽车行业中安全产品的开发工作。它覆盖了从构想、产品开发、生产和经营的所有安全工作。
事实上，功能安全，即不允许发生因电气/电气系统的功能失常导致的危险性造成不可接受的风险，业已成为汽车设计中的一项重要要求。该拟在近期颁布的标准专门针对汽车行业的实际情况，定义了可接受的风险，重在防范恶性故障。为此，“风险”一词的定义为发生伤害或者损害的可能性及伤害或者损害的严重性。在工程开发阶段，该标准要求提前评估所有潜在的危险和风险，并要求开发人员采取适当的措施尽最大可能予以消除。ISO 26262 提供了适当的要求和流程，指导如何避免这些风险。
根据该标准的要求，汽车的功能被分成安全相关功能和非安全相关功能两大类。安全相关功能指如果功能失常就会给驾驶员带来风险的功能。对分类为安全相关功能的功能，该标准进一步设定了数个可能的风险等级。就是说从确保具体的安全目标的角度出发，某些功能的比另一些功能更加关键。
根据可能发生的事故的严重性、出现特定驾驶状况的概率、采用外部措施降低风险的程度，该标准定义了一系列汽车安全完整性等级（ASIL））。该系列等级具体分为四个等级，从 D 到A。D 代表最高安全等级，A 代表最低安全等级。每个ASIL 等级都列明汽车制造商和供应商必须满足的要求或建议，以将“不可容许的严重风险”降低为可容许残余风险。
例如，如果在车辆行驶中方向盘轴被卡住，驾驶员就可能遭遇事故，因为驾驶员无法转动方向盘。为将该风险降低到可容许的水平，方向盘轴控制功能的设计就必须根据ISO 26262 标准和为此安全目标设定的ASIL 等级满足一定的安全设计标准。
软件开发人员和硬件开发人员必须依据每一项安全目标的ASIL 等级，在实现涉及的功能的时候思考具体的安全措施。对高安全等级的ASIL（D 或C），常用的设计方法是将安全要求分解为冗余安全要求，以便采用充分独立的元件在较低的ASIL 等级上满足ASIL 容许度要求。换句话说，就是将原始的安全要求用不同的处理器（一般为MCU）冗余地实现，采用冗余通道最大程度地降低恶性故障发生的概率。
最后，制造商和供应商需要向认证机构证明自己的电气/电子系统能够根据行业专门的规定安全可靠地提供要求的功能。
Freescale推出四缸汽油发动机专用喷油和点火驱动集成芯片
2012-10-10
在汽油机喷油与点火控制系统中，通常用大功率三极管或场效应管及其辅助电路来产生较大的驱动电流，从而实现对喷油器和火花塞的驱动。然而，对于四缸汽油发动机而言，就必须分别有4个喷油器和火花塞驱动电路与之对应。这样，驱动电路体积较大，稳定性相对较差，结构也较为复杂。MC33810是Freescale公司推出的一款四缸汽油发动机专用喷油和点火驱动集成芯片，该芯片具有体积小、重量轻、集成度高、经济性好等特点[1]。
1 结构原理
MC33810 芯片内部具有电源供电模块、电源复位模块、SPI串行输入输出接口模块、并行控制输入模块、脉宽调制控制模块、标准/最大线圈电流比较模块、点火持续时间比较模块、喷油器驱动模块和点火门控预驱动模块，能够与汽油机ECU进行SPI通信，接受ECU的并行控制，实现喷油与点火功能，同时能对点火电流和点火持续时间进行反馈，防止损伤点火线圈,其内部电路具有过压、过流、过热保护功能[2]。
2 应用电路设计
2.1 ECU电源管理电路设计
MC33394是一款高性能的电源管理芯片，外部电源供电在 4 V～ 26.5 V之间，非常适合给发动机ECU供电。其内部包含 5 V/ 3.3 V/ 2.6 V电压调节器模块，可直接输出 5 V、 3.3 V和 2.6 V三种电压。其应用电路如图1所示。
电池由外部电源供电，汽车上一般为 12 V～ 14 V之间。VPRE口输出电压为 5.6 V，VDDH口输出供电 5 V@100 mA，VPRE1、VPRE2和VPRE3口输出供电 5 V@100 mA。VPP口可输出供电 5 V@150 mA或 3.3 V@150 mA，可对外部Flash ROM进行供电。VDD3_3口外接三极管，可形成 3.3 V@120 mA的供电能力。VDDL口外接2个三极管，形成 2.6 V@40 mA的供电能力[3]。因此，MC33394能完全满足MPC564的电源管理及供电要求。
2.2 ECU系统电路设计
以MPC564为核心的ECU系统电路包括：电源供电电路、复位电路和晶振振荡电路。电源供电电路主要由MC33394提供 5 V和 2.6 V电压给MPC564，MPC564的电源接口有：VDDH1～VDDH8，接 5 V电源；VDD1～VDD13、QVDDL1～QVDDL15，接 2.6 V 电源；GND1～GND105，接地。复位电路接口有：电源复位PORESET、硬件复位HRESET 和软件复位SRESET。由于它们都是低电平有效，所以采用传统的电阻电容复位电路。晶振振荡电路由晶振、电阻和电容组成。外部晶振选择4 MHz、晶振反馈调节电阻选择10 MΩ、电容选择22 pF，则PLL锁相环电路可产生40 MHz的内部时钟和20 MHz的系统时钟[4]。其系统电路如图2所示。
2.3 MC33810接口电路设计
MC33810 芯片外部具有：一个串行输入输出口(SPI)，4个驱动输入口(DIN0～DIN3)、4个输出口(OUT0～OUT3)，4个门控预驱动输入（GIN0～GIN3）、输出口（GD0～GD3），4个反馈电压检测输入口（FB0～FB3），一个点火线圈最大电流输出标志位（MAXI），一个点火线圈标准电流输出标志位（NOMI），一个电阻感应正极端口（RSP）和一个电阻感应负极端口（RSN）[2]。串行输入输出口主要用于发送和接收ECU 的控制命令，可以直接与MPC564的SPI口直接相连。驱动输入、输出口主要用于控制喷油器的开启和关闭，输入口与MPC564的普通I/O口相连，输出口与喷油器相连。门控预驱动输入、输出口主要用于控制功率管的开启和关闭，从而控制火花塞的点火，因此输入口仍然接MPC564的普通I/O口，而输出口控制功率管的基极。这样，喷油和点火控制指令既可以通过ECU发出SPI指令控制，也可以通过并行口直接控制。反馈电压检测口主要用于监控点火时功率管的集电极端电压，由两个电阻进行分压，阻值比例约为9:1（可选择36 kΩ和4.02 k Ω）。点火线圈最大电流输出标志位主要用于给ECU提供点火线圈最大电流输出信号参考标志。点火线圈标准电流输出标志位主要用于给ECU提供点火线圈标准电流信号参考标志，防止点火线圈因电流过大而损伤，因此可直接与MPC564的普通I/O口相连。电阻感应正极端口和电阻感应负极端口主要用于感应通过其两端的电阻电流的大小，这里放大倍数选择1倍，电阻选择0.04 Ω，如图3所示。
3 驱动程序设计
3.1 喷油程序设计
汽油机喷油必须确定喷油提前角和喷油量。四缸汽油机喷油提前角一般是固定的，位于排气行程上止点前64°，因此可以根据曲轴位置传感器发出的曲轴位置信号确定[5]。而喷油量通过喷油器针阀开启的持续时间来确定，即喷油脉宽。喷油脉宽通过ECU采集进气歧管绝对压力、发动机转速、歧管进气空气温度、节气门位置、蓄电池电压等信号的实际数据，再根据MAP图来确定。当喷油时刻到来时，ECU通过SPI口或并行口直接发出喷油指令，然后开启定时器，确定定时喷油的持续时间。当喷油完成后直接关闭喷油指令。
MC33810内部具有过热保护和定时保护命令，可通过ECU对喷油器进行过热和喷油时间过长保护。这里，选择以SPI口驱动第一缸喷油器为例，使用保护指令0E10H，喷油指令3001H。喷油程序流程图如图4所示。
3.2 点火程序设计
汽油机点火必须确定点火提前角和点火闭合角。点火提前角的大小主要由发动机的转速、负荷和汽油的辛烷值决定[6]。汽油的辛烷值一定时，只需通过试验，建立发动机的转速、节气门的位置与点火提前角的MAP图即可。点火闭合角的大小主要由发动机的点火频率决定，点火频率越大，发动机的转速越快。因此，可通过 ECU采集发动机转速传感器和节气门位置传感器信号确定点火提前角和点火闭合角。
MC33810内部具有选择点火闭合角(点火持续时间)、点火电流放大倍数、点火标准电流、最大电流参数设置的功能，能根据MAP图选择合适的点火参数。这里，以驱动第一缸点火为例，点火持续时间设置为 32 ms，点火模式选择命令为1000 H，允许多缸点火持续时间重叠，电流放大1倍，则点火命令为49CDH。点火结束滤波设置4 ?滋s命令为5001 H。点火标准电流为5.5 A，最大电流为14 A，允许点火持续时间重叠35%，则DAC命令为688AH。点火程序流程图如图5所示。
MC33810通过与MPC564组成喷油及点火控制电路，能实现如下功能：
(1)直接用MC33810驱动四缸汽油机的喷油器与点火线圈，省去了复杂的驱动电路；
(2)MPC564可根据实际需要选择SPI接口驱动或并口驱动，驱动方式灵活；
(3)MC33810能向MPC564发出点火驱动电流的反馈监控信号，保护点火线圈；
(4)MC33810内部具有过压、过流和过热保护，驱动电路稳定，使用寿命长。
通过试验表明，MC33810能在四缸汽油机中较好地实现喷油与点火电路的驱动，具有一定的现实意义和良好的使用前景
车辆控制系统开发软件闭环模拟方法
1 概述
随着计算机技术的发展，车辆上的控制系统变得越来越复杂，因而控制算法变得也非常复杂，所以控制系统开发的主要工作是内部的控制算法的开发。我们知道近几年国外先进的开发过程是呈V 字形，它分为下面几个阶段[1]：
(1) 系统设计建模与离线模拟
在这一阶段主要验证控制算法与概念，验证系统的可行性，使用MATLAB/Simulink 软件可以很容易实现控制算法并进行系统建模，这些模型可以同样应用于实时硬件模拟。
(2) 系统原型实施
这一阶段仍是采用PC 计算机或功能较强的计算机，如DSP。将系统的硬件信号加入到模拟系统中，从而实现真实的物理系统。可以采用MATLAB 工具箱，例如RTW 和xPC 等。很容易在PC 计算机中实现实时硬件控制。例如可以直接用PC 计算机对车辆进行控制验证。
(3) 目标代码产生
目标代码的产生是最困难的一步，可以采用专用的工具如Targetlink，它可以从Simulink 可视化算法直接转化为C 代码，MATLAB/Simulink 中的实时嵌入式代码生成器工具箱也具有这类功能。但生成可用于大量生产的实用代码还要作较多的修改，或许要嵌入较多的用户手工代码。
(4) 实时硬件模拟
这一步骤是验证控制器硬件和软件算法，它的环境与实车比较类似，其相似程度取决于模拟模型与实际车辆的差别。如果模型比较准确，则经过这一系统验证后再到实车试验，其工作量就降低到最少，但一般情况下模型与实车都存在较大差距，所以仍需要较多的工作。
(5) 系统验证与调试
这一过程是将控制系统在实车上进行验证并进行系统的标定及参数修改等工作。如果前面的工作比较完善，则这一步的工作量就可以减少，并节省时间与费用。这一过程是一个一般的过程，但也存在下面几个方面的不足。
1) 传统的开发大多采用模拟的方法，纯软件模拟可以部分地验证控制算法，但大部分的纯模拟控制算法都是运行在PC 计算机上。利用通用的编程工具如VC、VB、MATLAB/SIMULINK，它们都是采用浮点数运算，也不必顾及内存空间的大小。这种模拟当得到理想的结果后再向目标计算机上进行移植，这种目标计算机往往要进行产业化生产，要求有较高的性能价格比，所以它的内存空间较小，同时采用整形数。模拟验征很好的代码一旦移植到这种目标计算机。由于上述差距的存在就会使控制算法的性能大大降低，这往往需要用户重新进行构造控制算法，这样就导致开发效率降低，那么最好是从一开始就使目标计算机参与到系统上来。
2) 实时硬件闭环模拟是一种非常好的工具，目前在开发过程被大量的使用。它可以有效地验证控制器的软硬件系统，但这种系统在实际使用中事实上主要是验证控制算法。硬件的验证只要没有故障，则在以后的工作中就不会再有什么作用。
3) 实时硬件模拟验证只是在实验室内进行，如果拿到实车上就很不方便，特别是一些混合模拟由于设备庞大，很难拿到车辆上。在实际车辆上调试ECU 控制代码时要进行很多算法修改及参数的调整，这种修改与调整有些可能对算法的影响是很大的，有些情况可能会使控制失效。这样就需要再回到试验室中用实时硬件模拟再去验证算法，反反复复这样调试就会耗费比较多的时间。
4) 好的开发环境应该将这些过程集成到同一个环境下，如果系统要在不同的系统中切换，势必造成移植的困难。