电子科学嵌入式培养_浅谈嵌入式技术与整车网络系统的实现

小嵌

电子科学嵌入式培养_浅谈嵌入式技术与整车网络系统的实现,   

  

一、

随着市场需求和电子技术的发展，整车电气系统经历着电器化、电子化和网络化三个阶段性发展。嵌入式技术执行专用功能并被内部计算机控制的设备或者系统。嵌入式系统不能使用通用型计算机，而且运行的是固化的软件，用术语表示就是固件（firmware），终端用户很难或者不可能改变固件。尽管绝大多数嵌入式系统是用户针对特定任务而定制的，但它们一般都是由下面几个模块组成的： 一台计算机或者微控制器，字长可能是可怜的4位或者8位、16位、32位甚至是64位。 用以保存固件的ROM（非挥发性只读存储器）。 用以存程序数据的RAM（挥发性的随机访问存储器）。 连接微控制器和开关、按钮、传感器、模数转化器、控制器、LED（发光二极管）和显示器的I/O端口。 一个轻量级的嵌入式操作系统，一般是自行编写的。 专门的单片微控制器是大多数嵌入式系统的核心。通过把若干个关键的系统组成部分集成到单个芯片上，系统设计者就可以得到小而便宜、可以操作较少外围电子设备的计算机。 嵌入式系统的一般模型并不足以定义嵌入式系统本身。例如，某些嵌入式系统常常比标准PC机箱小不了多少。这类设备有： 信息查询以及销售点终端。 某些工业控制系统。游戏控制台（例如基于x86和Windows的Xbox）。

二、概述

整车网络是指将多个具有一定独立工作能力的汽车电子系统通过总线实现资源共享和数据通信的分布式实时嵌入系统。由此定义可见，整车网络以总线整合汽车电子系统的形式存在，但本质仍然是由软硬件构成的嵌入式系统。

  

整个开发过程可被分为系统开发和零部件实施两个应用层面，其中贯穿着算法设计、软件工程等基础技术。由于种种原因，自主汽车电子产业存在着重零部件轻系统、重应用轻基础的问题。需要指出的，基础技术涉及的建模、仿真、软件构架等均来源于主流的嵌入式技术体系，并不固定从属于系统开发或零部件实施的具体领域。在系统开发过程中，应用相应的基础技术，结合上游用户需求与下游零部件实施约束，才能完成嵌入式系统的集成设计与验证。

三、架构开发

在软件工程中，架构设计的作用在于三方面：1、行业应用架构，行业架构师往往是行业专家，了解行业应用需求，其架构行为主要是将需求进行合理分析布局到应用模型中去，偏向于应用功能布局；2、应用系统技术体系架构，技术架构师往往是技术高手中的高手，掌握各类技术体系结构、掌握应用设计模式，其架构行为考虑软件系统的高效性、复用性、安全性、可维护性、灵活性、跨平台性等；3、规范架构设计是通过多年磨砺或常年苦思顿悟后把某一类架构抽象成一套架构规范，当然也有专门研究规范而培养的规范架构设计者。

  

架构开发容易与总线开发混淆。虽然同属系统层面开发，前者基于而高于后者。在架构设计中，总线仅是最主要的信息交互方式，其特点必须在设计过程中合理运用。

3.1工程需求捕捉（图2）

从用户角度，工程需求不同于常见的市场需求：后者主要从市场用户出发，关注的是网络系统的外在使用价值而不是具体的构架、技术和零部件；除此之外，整车寿命周期内还有开发工程师、制造工程师、售后工程师等内部用户的需求。上述诸多用户的需求同时也包含约束，例如法规、标准、成本、质量、工程策略等等。从时间角度上。上述需求在项目周期中不同程度地动态变化。

工程功能（图3）作为工程需求的基本载体，贯穿着整个开发过程。由于不同整车的需求差异，对工程功能的具体划分不尽相同。一般而言，工程功能被分为用户工程功能和非用户工程功能：前者会被用户直接感受到，例如灯光；后者不会被用户直接感受到，一般是前者的支撑，例如总线唤醒，通常也被称为系统功能。对于每个工程功能的需求，也分为功能性需求和非功能性需求：前者主要定义不同状态下输入输出等外在行为逻辑，通常是可复用在不同车型上。

  

对需求的捕捉中，需求的验证是重要环节之一。上述需求数量浩大甚至相互矛盾，产生的需求风险将严重影响下游的开发。建立系统层面的功能性需求模型，不仅可以解决需求冲突问题，也是对下游功能分配的必要约束。

3.2功能分配（图4）

对于嵌入式软硬件实现的工程功能，往往需要分布到多个零部件实现以满足工程需求，因此合理的功能分配设计尤为关键。从实现角度而言，需要从逻辑、物理和机械布置层面进行平衡。嵌入式系统和外界交互需要一定形式的通用设备接口，如A/D、D/A、I/O等，外设通过和片外其他设备的或传感器的连接来实现微处理器的输入/输出功能。每个外设通常都只有单一的功能，它可以在芯片外也可以内置芯片中。外设的种类很多，可从一个简单的串行通信设备到非常复杂的802.11无线设备。

  

逻辑层面的分配，需要在保证关键资源、延迟、供电状态、安全等非功能性需求前提下进行。例如：某功能的子功能被分配到某控制器，除了需要传感器／执行器等硬件外，控制器能否提供足够的存储空间、运算能力、供电状态也同样重要；子功能之间可通过总线、硬线进行交连，但是连接方式必须确保功能本身的实时性、可靠性。

3.3架构整合

功能分配仅针对单个工程功能，而功能与功能、系统与零部件存在的关联和由此产生的冲突。因此，系统层面上针对功能、零部件的平衡是架构整合的基本内容。同时。合格的架构不仅必须满足成本要求，还需要与开发人力、可靠性、技术风险和可配置性进行折中。

作为分布式嵌入式系统，网络系统的架构（图5）存在着更分布还是更集中的争议。在更分布式的系统中，诸多功能尽可能按功能分布在不同的控制系统实现，系统的可配置性好、可靠性高但物料成本较高；在更集中的系统中，诸多功能尽可能按区域分布在同一的控制系统实现，系统的物料成本较低但可配置性差、可靠性低。在实际工程应用中，由于不同整车系统、不同功能领域的需求差异，更分布和更集中架构往往是折中的。

  

四、总线开发

总线是指连接控制器的数字、双向传输、多分支结构的通信系统，通常一条或多条总线和网关构成整车网络。常见的总线如CAN、LIN，以及MOST、FlexRay。

总线可被视为满足分布式功能需要的用于数据交换的非用户工程功能，依托节点的嵌入式软硬件分布式实现的。因此，运用总线时必须考虑其资源占用、时延、可靠性、线束布局等需求；反之，这些也是总线技术升级换代的驱动力。总线（Bus）是计算机各种功能部件之间传送信息的公共通信干线，它是由导线组成的传输线束， 按照计算机所传输的信息种类，计算机的总线可以划分为数据总线、地址总线和控制总线，分别用来传输数据、数据地址和控制信号。总线是一种内部结构，它是cpu、内存、输入、输出设备传递信息的公用通道，主机的各个部件通过总线相连接，外部设备通过相应的接口电路再与总线相连接，从而形成了计算机硬件系统。在计算机系统中，各个部件之间传送信息的公共通路叫总线，微型计算机是以总线结构来连接各个功能部件的。

4.1物理层（图6）

物理层指构成总线硬件的线束、接插件及板级收发电路。作为硬件部分，主要的难点在于设计偏差认可和一致性保证。前者主要是存在于沿用其他总线设计的控制系统，硬件的设计偏差认可与否很大程度上影响了方案最终确定；后者是指批量情况下全寿命周期的性能一致性保证，为避免散差、老化造成的质量问题。

  

4.2通信层（图7）

通信层介于物理层和应用软件之间，是通信协议的主体，主要包含通信策略和信号配置。

通信策略定义了通信机制的传输模型和时延模型，本质上服务于功能内部的数据交换需求，并属于后者的抽象。例如人机类功能一般属于开环控制类，事件触发的传输模式即可满足数据交换需要，总体时延要求在200毫秒以上。通信策略不仅可以直接作为通信层软件开发需求，也是通过总线进行功能分配的重要参考依据。

  

信号配置是与架构设计直接相关，也是总线设计中最直观的部分。信号配置本质上是把信号根据协议特性和架构需求进行组帧的过程。从逻辑角度，信号配置必须满足架构中的流向关系、帧装载字长和带宽等限制；从时序角度，分配后信号的传输时延应确保满足功能的总体时延分配。

4.3网络管理

网络管理主要完成启动／停止、休眠／唤醒、错误处理和版本控制等功能。网络管理通常包含节点管理和系统管理（狭义网络管理），前者限于节点本地的通讯管理，后者协调节点间的系统级行为。

作为解决方案，可以直接引入包含网络管理算法的嵌入式软件，进一步定义网络管理策略的时间参数设定、网络管理底层策略与应用层的接口和应用层对网络管理的具体需求。网络管理包括对硬件、软件和人力的使用、综合与协调，以便对网络资源进行监视、测试、配置、分析、评价和控制，这样就能以合理的价格满足网络的一些需求，如实时运行性能、服务质量等。网络管理常简称为网管。网络管理，是指网络管理员通过网络管理程序对网络上的资源进行集中化管理的操作，包括配置管理、性能和记账管理、问题管理、操作管理和变化管理等。一台设备所支持的管理程度反映了该设备的可管理性及可操作性。而交换机的管理功能是指交换机如何控制用户访问交换机，以及用户对交换机的可视程度如何。通常，交换机厂商都提供管理软件或满足第三方管理软件远程管理交换机。一般的交换机满足SNMP MIB I / MIB II统计管理功能。而复杂一些的交换机会增加通过内置RMON组（mini-RMON）来支持RMON主动监视功能。有的交换机还允许外接RMON探监视可选端口的网络状况。

  

4.4网关

网关实现不同总线的不同类型的数据交换，不仅包括常见的信号数据，还包含唤醒／休眠、启动／停止等管理指令。网关（Gateway）又称网间连接器、协议转换器。网关在传输层上以实现网络互连，是最复杂的网络互连设备，仅用于两个高层协议不同的网络互连。网关既可以用于广域网互连，也可以用于局域网互连。 网关是一种充当转换重任的计算机系统或设备。在使用不同的通信协议、数据格式或语言，甚至体系结构完全不同的两种系统之间，网关是一个翻译器。与网桥只是简单地传达信息不同，网关对收到的信息要重新打包，以适应目的系统的需求。同时，网关也可以提供过滤和安全功能。大多数网关运行在OSI 7层协议的顶层--应用层。

网关的功能性需求来源于架构设计，越复杂越分布，系统的网关复杂度越大。从实现角度，网关功能增加了系统的可配置性但降低了可靠性，需要在架构设计中进行合理平衡。

  

五、诊断开发

诊断系统能实时监控功能运行，并通过总线接口与外部用户设备实现数据交换，满足法规、开发、制造、售后甚至信息服务的需求。从法规角度，通常排放相关的诊断内容是强制性标准化的。

5.1功能自诊断（图9）

任何嵌入式方式实现均存在软硬件失效的可能，因此实时在线的功能自诊断是必要的保障手段。功能诊断包括面向应用功能的自诊断和面向系统功能的自诊断，后者通常是指操作系统、总线等基础或者内核部分。功能自诊断通常针对对物理输入输出和逻辑输入输出，前者通过相关电路特性判断是否存在物理失效，后者对逻辑信号的数值、变化特性进行可信度判断。

5.2诊断管理

诊断管理的主要内容是故障管理。系统运行期间，功能自诊断因为随机失效会产生相当数量的故障指示，不加处理容易造成虚警；对于正常的故障诊断，故障信息存储也容易受到非易失性存储资源的限制。故障管理将处理本地所有功能自诊断的故障指示，根据故障特性进行“识别-确认-退出”的过程管理；存在多个故障时进行类似堆栈的处理，保证高优先级故障信息的存储；根据诊断协议的指令输出或清空故障信息。

5.3诊断通信

区别于总线的在线通信，诊断通信被称为离线通信，盖因其非常在线特点。其服务层为诊断功能提供国际通用和自定义两种诊断服务支持。诊断服务层为上层屏蔽具体通信特征，使其只考虑功能应用方面。每条诊断服务作为控制器功能的触发条件或入口点。诊断服务层提供诊断服务（service）的软件实施效率是保证控制器能够及时响应外部诊断诊断请求的重要因素之一。其会话层控制器与诊断工具之间的通信使能，打开或断开双方的通信。当诊断工具与控制器间的应用服务无法维持时关闭这些服务。将所有服务功能分布到合适session中，满足诊断功能分级是该设计目的。其传输层设计实现块数据的传递功能，为大数据量的传递提供通信通道。此外还需定义传输层与上、下层之间的软件接口，优化匹配参数

5.4 配置系统（图10）

基于市场、工程等多方面需要，整车网络存在大量的通过诊断进行的信息配置。在项目的不同阶段，对上述配置进行正确无误的快速处理是配置系统的主要功能。

  

六、集成测试（图11）

不同于零部件实施的测试，集成测试关注的是系统层面的测试验证。

  

6.1基础测试

基础测试针对系统中总线、诊断等系统功能：控制器是否能够及时地通过总线将采集到的传感器信号传递给其他控制器，是否能够及时响应其他控制器通过总线传递的指令并驱动执行机构；网关实现的功能是否正确（满足设计要求）；所有控制器是否能按规定进入／退出睡眠模式（网络管理策略是否满足设计规范）；控制器网络的电流消耗是否在规定的范围之内；总线负载是否符合设计要求；在线诊断功能是否符合设计要求。

6.2功能测试

根据系统架构、功能需求等设计规范，结合测试平台结构和测试环境特点生成测试规范。测试规范详细定义了测试要求和步骤，包括点火开关状态、功能实现的条件、功能结果、具体描述及注意事项等。

根据上述测试规范进行详细的功能测试，以确认集成效果是否满足设计规范。测试解决方案建立在标准系统框架基础上，通过开放式接口提供完整的模型设计、测试设计、诊断和标定设计，虚拟试验环境、实时仿真模型、试验和试验参数可在不同设计阶段和项目中得以复用。

七、总结

本文对整车网络开发和系统开发工作进行了详细描述，结合嵌入式理论介绍了基于功能面向需求的架构设计方法以及总线、诊断、集成测试的工作重点。