一、引言

　　随着市场需求和电子技术的发展，整车电气系统经历着电器化、电子化和网络化三个阶段性发展。技术影响在电子化阶段开始体现，并在网络化阶段进一步凸现。作为自主产业，直接面对电子化、网络化发展阶段重叠的局面，一方面存在缺乏积累、基础薄弱等挑战，另一方面也存在轻装上阵、少走弯路的后发优势。因此，如何更好地将嵌入式技术与整车电气系统开发相融合，已经成为自主产业技术路线的关键问题。

　　二、概述

　　是指将多个具有一定独立工作能力的汽车电子系统通过总线实现资源共享和数据通信的分布式实时嵌入系统。由此定义可见，整车网络以总线整合汽车电子系统的形式存在，但本质仍然是由软硬件构成的嵌入式系统。随着软件在系统实现中占据日益主导的地位，整车网络的开发过程也来越接近典型的V模式过程，如图1所示。

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

　　三、架构开发

　　架构设计是借助工程方法，通过工程需求的捕捉，合理分配系统功能，最终完成网络系统的结构设计。需要指出的是，工程方法是每个整车企业根据自身产品电气系统的竞争策略，基于相符合的理论方法，结合自身的开发配套体系，经过长期工程实践建立的。不同整车企业甚至同一企业不同平台的工程方法是不同的，作为结果的架构更是千差万别。因此，照搬系统架构甚至工程方法的做法是无法获得合格架构的。

　　架构开发容易与总线开发混淆。虽然同属系统层面开发，前者基于而高于后者。在架构设计中，总线仅是最主要的信息交互方式，其特点必须在设计过程中合理运用。反之，高性能、高质量的总线也有效增加了架构的灵活性、复杂性。

　　3.1工程需求捕捉(图2)

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

　　工程功能(图3)作为工程需求的基本载体，贯穿着整个开发过程。由于不同整车的需求差异，对工程功能的具体划分不尽相同。一般而言，工程功能被分为用户工程功能和非用户工程功能：前者会被用户直接感受到，例如灯光；后者不会被用户直接感受到，一般是前者的支撑，例如总线唤醒，通常也被称为系统功能。对于每个工程功能的需求，也分为功能性需求和非功能性需求：前者主要定义不同状态下输入输出等外在行为逻辑，通常是可复用在不同车型上，即实现功能性DNA，又减少了需求风险，也为相关应用软件复用提供了前提；后者包含了其他非功能性需求，如关键资源要求、成本，往往因车型而异。

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

　　3.2功能分配(图4)

　　对于嵌入式软硬件实现的工程功能，往往需要分布到多个零部件实现以满足工程需求，因此合理的功能分配设计尤为关键。从实现角度而言，需要从逻辑、物理和机械布置层面进行平衡。传统的做法中功能分配仅被关注在机械布置和物理层面，简单地进行基于物料成本的硬件分配。这种源自电器化阶段的做法简单直观，但是忽视逻辑分配会带来响应性差、可靠性低等一些列原理问题。

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

 　　3.3架构整合

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

　　作为分布式系统，网络系统的架构(图5)存在着更分布还是更集中的争议。在更分布式的系统中，诸多功能尽可能按功能分布在不同的控制系统实现，系统的可配置性好、可靠性高但物料成本较高；在更集中的系统中，诸多功能尽可能按区域分布在同一的控制系统实现，系统的物料成本较低但可配置性差、可靠性低。在实际工程应用中，由于不同整车系统、不同功能领域的需求差异，更分布和更集中架构往往是折中的。架构开发常见的输出是输出文档是电气原理图、功能分配规范，并直接作为线束、控制系统和总线开发的设计输入。

　　四、总线开发

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

　　总线可被视为满足分布式功能需要的用于数据交换的非用户工程功能，依托节点的嵌入式软硬件分布式实现的。因此，运用总线时必须考虑其资源占用、时延、可靠性、线束布局等需求；反之，这些也是总线技术升级换代的驱动力。通常，总线开发包括物理层、通信层、网络管理和网关四部分内容。

　　4.1物理层(图6)

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

　　4.2通信层(图7)

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

　　通信策略定义了通信机制的传输模型和时延模型，本质上服务于功能内部的数据交换需求，并属于后者的抽象。例如人机类功能一般属于开环控制类，事件触发的传输模式即可满足数据交换需要，总体时延要求在200毫秒以上。通信策略不仅可以直接作为通信层需求，也是通过总线进行功能分配的重要参考依据。忽视通信策略的设计和验证。容易造成总线负载高、时延超差等问题，由此引发的功能失效的代价极大。一般而言，采用含有成熟通信策略的嵌入式软件是较保险的解决方案。

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

　　4.3网络管理

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

　　作为解决方案，可以直接引入包含网络管理算法的嵌入式软件，进一步定义网络管理策略的时间参数设定、网络管理底层策略与应用层的接口和应用层对网络管理的具体需求。需要指出的是，网络管理的失效易导致意外的休眠／唤醒，轻者导致相关功能失效，重者将影响蓄电池电置。

　　4.4网关

　　网关实现不同总线的不同类型的数据交换，不仅包括常见的信号数据，还包含唤醒／休眠、启动／停止等管理指令。对于信号数据的路由组织，基于信号的方式利于时延的评估，而基于帧的方式便于配置的标准化，分别体现了不同的架构设计理念。

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

　　五、诊断开发

　　诊断系统能实时监控功能运行，并通过总线接口与外部用户设备实现数据交换，满足法规、开发、制造、售后甚至信息服务的需求。从法规角度，通常排放相关的诊断内容是强制性标准化的．如常见的在线诊断(OBD)。诊断开发的基本内容主要包括功能自诊断、诊断管理、通信协议和配置系统四部分开发内容。

　　5.1功能自诊断(图9)

　　任何嵌入式方式实现均存在软硬件失效的可能，因此实时在线的功能自诊断是必要的保障手段。功能诊断包括面向应用功能的自诊断和面向系统功能的自诊断，后者通常是指操作系统、总线等基础或者内核部分。功能自诊断通常针对对物理输入输出和逻辑输入输出，前者通过相关电路特性判断是否存在物理失效，后者对逻辑信号的数值、变化特性进行可信度判断。一经判断出失效，系统将采取缺省值甚至降级运行等处理策略。需要指出的是，功能自诊断的初衷是针对潜在失效，因此相关的失效模式分析是其设计来源。

 　　5.2诊断管理

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

　　5.3诊断通信

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

　　5.4 配置系统(图10)

　　基于市场、工程等多方面需要，存在大量的通过诊断进行的信息配置。以中级车为例，整车配置信息多达上百条、数十千比特。在项目的不同阶段，对上述配置进行正确无误的快速处理是配置系统的主要功能。

　　六、集成测试(图11)

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

　　6.1基础测试

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

　　6.2功能测试

　　根据系统架构、功能需求等设计规范，结合测试平台结构和测试环境特点生成测试规范。测试规范详细定义了测试要求和步骤，包括点火开关状态、功能实现的条件、功能结果、具体描述及注意事项等。同时对误用滥用也要进行详尽分析，生成相应的测试文档。

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

　　七、总结

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