受篇幅限制，这个大的话题将会分为以下三个大的部分来和各位朋友讨论：
第1部分：在德国流行的对EEA的定义
第2部分：EEA在研发流程中的意义以及对产品本身的意义
第3部分：EEA在CarIT时代下的发展趋势
在前两篇的第1部分里，我们聊过了：
第1.1段：在德国流行的对EEA的定义
（EEA则是个上层概念，站在全局的角度调配、评估资源。）
第1.2段：CustomerFeature/RequirementsEngineering需求层
第1.3段：FunctionalArchitecture功能架构
第1.4段：SoftwareArchitecture软件架构
第1.5段：HardwareArchitecture硬件拓扑
第1.6段：CommunicationLayer/NetworkDesign通信层
第1.7段：WirningHarness/Bordnetz电器布置
前两篇文章链接请点这里：
绝对值得收藏的干货-德国汽车企业电子电器系统正向开发流程解析(第一篇)
绝对值得收藏的干货-德国汽车企业电子电器系统正向开发流程解析(第二篇)
今天，咱们继续聊一聊：
E/E-Architecture各层的协同工作
在前两篇中，小编介绍了EEA框架下各层的基本情况，并且说到了EEA作为一个大框架起着协调资源，调配资源，评估Concept的作用。那么它到底是怎么工作，怎么产生价值的呢？在这篇中我们先从架构各层的输入输出及他们之间Roundtrip-Engineering说起，不过这些都已经是德国这边的夕阳技术了，结尾处我们看看他们对于下一代架构有些什么样的计划。
首先，我们来了解一下EEA眼中的汽车和平时我们聊天时提到的汽车有什么不同。
图1.不同视角下的汽车
上图展示了从EEA工程师视角和用户视角中看到的不同景象。对于EEA工程师来说，首先要考虑的是有哪些CustomerFeature要实现，这是Global的考量，即和具体车型/车型项目无关的考量，是公司层面所能向客户提供的所有“汽车电子功能”资源。如上一篇所提到的，紧接着EEA工程师会着手准备这些Feature的功能架构，FunctionRealization。EEA工程师并不是FunctionDevelopment的专家们，那么他们在这里的工作重点是什么呢？除了初步的功能框架，更重要的是初步的功能集成，即避免产生过多的功能模块以及过多的InformationFlow，这些不仅会造成系统冗余，关键是这些都是钱。。重要的事情说三遍，这些都是钱（所谓有情怀的厂商，大抵是marketing的广告用语..）！所以哪些功能模块是现有的资源，哪些InformationFlow是可以共用的，为了实现这些资源的共用需要做哪些技术上的调整等等等等，是这个环节中的关键问题。
在上篇写完之后，有朋友表示对架构中每一层的输出物比较感兴趣，那我们接下来就从这每一层的输出物着手，做个简单的介绍，因为这确实是一个结合了流程和工程的，比较重要和核心的问题。不过因为小编也学疏才浅，所以只能点到为止啦。另外一方面，和流程有关的东西都比较敏感，出于对知识产权的尊重，如有更深层的讨论需求及业务需求，可以像大家推荐两位专业领域的前辈，一位是IAV中国的EE经理，一位Vector中国的负责人（车叔，请让我再做一会儿广告！）IAV和Vector在德国就是以合作伙伴的形式为客户进行EEA的开发，IAV负责汽车工程部分，工具的plug-in开发，Vector负责整个Database的技术保障和工具的新concept的实现等，两家强强联手，在model-based-EEA-Development这个领域做的非常领先，IAV是整个大众集团（包括奥迪，保时捷）新一代架构开发的核心合作伙伴，包括集团内部的流程整合与后台工具整合，有兴趣的朋友可以看一下软文SAE--26-，简单展示了下小编和当时IAV的同事们做的一些事情。
图2，来自SAE论文-26-,
广告之后，回归正文。首先，CustomerFeature，这里发生的基本是比较RequirementEngineering的事情。这里基本都是大家所熟悉的数据节点，比如DOORS阿，比如所有人最爱的Excel阿，或者特定的需求管理工具，只要他的数据可以转化为xml文件。在架构模型的帮助下，这些信息会被赋予到架构模型中相应的Artefacts上，同时该信息也可以按着所需求的数据形式再次输出。RequirementEngineering嘛，最重要的任务是Dokumentation以及保障可追溯性。这两点恰巧也是模型化架构开发的有点和特点。
图3：CF层输入输出
接着，FunctionRealization与SW-Archi，包括SW-Compostion,SW-Case的设计。这里开始就百花齐放了，各家有各家的做法，有些厂商可能也不用LogicalFunction这一层。不过初始模型你肯定还是要建立一边，正所谓“想要致富得先修路”。在这里，其实每个部门的专业部门可能用着不同的工具，该专业部门在不同的公司可能还流程和工具也不同。这种时候对于供应商来说，或者对于多品牌多公司的大集团来说，或者对于在LegacyArchitecture上不断做集成的技术路线来说，实现各个stakeholder,各个工具之间的Round-TripEngineering或者说迭代式的EngineeringIteration就非常重要。
在AUTOSAR的大背景下，大家一般会通过AUTOSAR文件arxml来进行工程模型的交互或更新。这一文件比如可以从软件架构这里导出，然后做SW开发的同事在他们的环境（比如DaVince,比如Simulink）进行SW的功能定义，Bedatung，或者编码。完工之后同样通过AUTOSAR的文件将其导回到架构模型，模型会自行（自行的意思当然也是指你首先得自己把后台的程序给写了哈）进行更新，会显示异同，会检查Inconsistence等等等等。这个时候如果软件工程师或者功能工程师的局部设计与架构整体有冲突，或者与周边系统有冲突，架构模型Round-TripEngineering的优势和意义就显现无遗，它相当于前瞻性的检查了一下这些节点。不然这些问题可能要等到硬件prototype也做出来之后，进行HiL测试时才能发现，这意味着什么？重要的事情说过三遍了，意味着钱，开发成本。
图4：功能与软件层输入输出
最后，关于硬件，网络拓扑以及线束拓扑，这里小编之前涉及到的就比较小了，尤其是线束拓扑（灵光一现想到的翻译，不知道对不对，就是WiringHarness），小编其实并没有实际涉及过。网络拓扑的话，小编所了解的主要是以dbc形式承载的CAN数据在架构模型中的交互，这点亚洲厂商也经常问到，关于如何实网络拓扑在架构中的优化以及数据形式的交互。这里大家就被德国人给骗了好吗，他们早不用dbc了，从工程的角度，dbc无法识别CAN-ID，对于大型数据或者反复迭代的数据处理来说是个灾难，从人文与成本的角度，dbc本身基于一个独立且小众的工具,买工具的Licence需要钱，培训大叔们需要钱，而且大叔们有用得熟练的Excel干吗要用其它奇奇怪怪的工具！？所以，不过德国人在海外市场怎么忽悠，他们自己用的基本是直接Excel为基础的CAN-Matrix设计与架构模型之间进行数据交互与迭代。至于交互完的数据，与软件层一样，可以各取所需的被应用。通信数据本身对于架构模型来说也像是血液，可以用于之后进行比如多种架构变量下的buslast计算阿，控制器负载计算阿，等等等等。
图5：通信及硬件层输入输出
至此，我们把几个重要的层的数据交互，输入物输出物简单描述了一下。大家可以发现，一个完整的EE架构模型，有能力在整体模型中取出任何一部分和别人交互信息，也能够接受任何一个局部层的输入信息，然后对自身进行更新迭代。这，就是Round-TripEngineering的力量。在Digitalization，BigData盛行的时代背景下，不仅电子功能本身越来越复杂，研发周期越来越快，它也要求着这背后支持整个研发的工具与流程更加数字化，智能化，以及快速反应化。Round-TripEngineering的另外一个特点或者原则是：各stakeholder自己原本用的工具和系统保持不变（不知道谁说的那个“neverchangetherunningsystem”），在后台建立一个信息交互和储存的平台。
其他部分车叔往期文章回顾：
从大众供应商断货事件聊聊德国汽车业
绝对值得收藏的干货-德国汽车企业电子电器系统正向开发流程解析(第二篇)
绝对值得收藏的干货-德国汽车企业电子电器系统正向开发流程解析(第一篇)
丰田第四代混动系统-16年4月刚发布的改进设计及数据和图片，攻城狮们必看！
别再看48V弱混的广告了。不看点干货敢说自己知道MHEV48V混合动力？
发动机热管理如何助力混动-用技术知识加FEV的StripDown实验少走弯路
干货分享：燃料中水分（湿度）对柴油发动机燃烧性能的影响
博世，戴姆勒，大陆--正在专为中国市场挑选人才
大众宣布汽油机排放控制GPF技术路线
柴油排放门有救了-欧洲Amminex出现最新科技AdAmmine已获大奖并批量
从主机厂角度深度解析-大众奥迪缘何为法规不再加深小排量化
终极分析:马自达创驰蓝天VS小排量化-读完再也不用争论了!（高能，慎入）
感谢您的阅读！本文由陆巍编写，转载请注明作者陆巍及白癜风怎样能治好北京治疗白癜风哪儿最好