传统上把汽车应用程序划分为几个不同的、拥有各自特点和要求的功能领域，这在掌握其复杂性上是有用的，但是这也导致了几个独立的子系统——特定的结构、网络和软件技术的发展。

由于越来越需要跨领域的数据交换，因而一些困难也因这种划分而出现。这要求实现网关的CPU负载和在数据刷新的影响方面的性能必须被仔细评估（参见文献[61]的案例）。例如，从功能的角度来看，一个属于特定领域的ECU可以因接线的原因连接到另一领域的网络上。例如，在一些车上，柴油机微粒过滤器（the Diesel Particulate Filter，DPF）和车身网络（尽管从功能的角度看，该网络属于动力总成部分）连接。这可能会引起性能问题，因为DPF需要对来自位于动力总成网络上的发动机控制器的数据流有强的时间约束。跨领域数据交换的例子可以举出许多，例如发动机控制器（动力总成）从温度控制器（车身）获得输入，或从仪表板（车身）上显示的动力总成获得信息。也有一些功能可以考虑作为交叉领域，如防盗器，它同时属于车身和动力总成领域。而即将到来的线控功能，也需要底盘、动力总成和车身的ECU之间的紧密合作。

目前的一个做法是在不同的领域间通过属于车身域、通常被称为“中央体电子”的网关来传输数据。它被确认为汽车的关键子系统：它构成了一个单故障点，其设计过于复杂，并且由于日益增加的工作量，系统开始出现性能问题。(www.daowen.com)

一个最初的可预测的改进领域是为了进一步发展位于不同子网的应用程序之间的互操作性所需的技术。AUTOSAR项目已在过去几年中在中间件方面实现了重大进展，并且我们正越来越接近4.3.1节中列出的理想特性。

今后的工作将致力于优化网络架构。这意味着需要重新考虑目前包含每个领域基础上的网络实施的做法。使用能够完成可扩展性能的多种通信需求（例如，高速、事件触发和TT通信）的技术无疑是一个促进设计的可能方向。当然，如NETCAR-Analyzer（见http：//www.realtimeatwork.com）这样的软件工具将有助于掌握复杂性，有助于成本及可靠性优化的解决方案。在软件的开发周期中，由于在被AUTOSAR接受的进程中的ASAM FIBEX标准^[62]的问世，将促进软件的使用，而该软件能充分描述嵌入在汽车中的网络（CAN，LIN，FlexRay，MOST和TTCAN协议）、在ECU之间交换的数据帧以及网关策略。