汽车电子电器架构设计与开发合集
电子电气架构发展与设计开发自1886年1月29日，卡尔.本茨的三轮汽车奔驰1号成功注册专利到现在，汽车发展已经有了百年的历史。当平顺的变速箱加调校和已经无可挑剔的电机传动出现，平顺相应和线性加速已经不值得去追 ...
以下为文章全文：(本站微信公共账号:cartech8)
汽车零部件采购、销售通信录 填写你的培训需求，我们帮你找 招募汽车专业培训老师
| 电子电气架构发展与设计开发 自1886年1月29日，卡尔.本茨的三轮汽车奔驰1号成功注册专利到现在，汽车发展已经有了百年的历史。 当平顺的变速箱加调校和已经无可挑剔的电机传动出现，平顺相应和线性加速已经不值得去追求了；当更加平顺的悬架和调校技术日显成熟，底盘的高级性能已经不是独门绝技的时候。这个时候无可否认软件和电子电器成为汽车的核心，软件和电子电器正在驱动着汽车行业四大突破ACES-自动驾驶，车联网、电气化，智能出行。这些日渐成为汽车的差异因子。所以汽车行业接下来的主战场正是电子电器和软件，而这些背后的核心是基础的电子电气架构。 ● EEA(电子电气架构)定义 EEA(Electrical/Electronic Architecture),电子电气架构是首先由德尔福公司提出的，集合汽车的电子电气系统原理设计、中央电器盒的设计、连接器的设计、电子电气分配系统等设计为一体的整车电子电气解决方案的概念。 通过EEA的设计，可将动力总成、驱动信息、娱乐信息等车身信息转化为实际的电源分配的物理布局、信号网络、数据网络、诊断、容错、能量管理等电子电气解决方案。 ● EEA（电子电气架构）发展 博世：未来汽车电子电气架构趋势  在博世的EE架构演进规划中最核心的思想就是ECU从分布到集中。如下对整个过程进行了更详细的说明。 01-分布式：当前的汽车电子电气架构绝大部分都是分布式  第一代分布式为每个ECU都独立控制不交互数据； 第二代为ECU交互通过域，基本上有车身模块、底盘模块、动力传动模块和娱乐系统模块等三个或四个独立的网，其中独立的网络及少数的数据交互通过域。 第三代为ECU交互数据通过网关，网关通过整合让不同网络数据能进行交互，例如CAN、LIN、MOST、FlexRay。汽车网关承担不同总线类型之间的协议转换工作，并参与各网段的网络管理，从而实现不同模块和功能之间的通讯。 02-域的中央式：  域中央式的，其实他的域中需要一个强大的中央处理器，他将其他ECU电子控制单元所有信息进行汇总同时能够再处理和运算，再发回不同的处理器进行执行。 03-整车中央电脑式：  当汽车电子电气架构发展到整车中央电脑式时候，是整个产业的完全变革，那个时候没有多个ECU电子控制单元概念，完全是电脑模式，整个汽车架构里面就是分为中央电脑、传感器、以及执行机构。通过以太主干网概念融合。 ● EEA的挑战 汽车内部的快速电子化让传统汽车电子架构不堪重负、对于未来汽车电子架构来说，应是做减法了，垂直融合将取代分布协同成为趋势。同时，软件定义的需求正呼之欲出，汽车亟待一个从机械化到电子化的华丽转身，这些都要求汽车电子架构做出变革。提升效率，降低复杂度（不论是硬件制造的复杂度还是软件开发的复杂度）。 以太网新型总线技术和5G无线技术的引入，已使这一融合变为部分现实。如果网络带宽足够宽，延迟足够低，这一趋势将会更加明显：算力向中央集中，向云端集中，汽车电子架构（EEA）的演进也正朝这个方向前行。 ● 特斯拉model3电子电气架构  如果将汽车整个电子系统视为一个主机，那么Model 3的架构与X86的电脑主板如出一辙：中央计算模块（CCM）、左车身控制模块（BCM_LH）和右车身控制模块（BCM_RH）。特斯拉似乎是有意为之，一个再清晰不过的思路展现在众人面前：域控制尽可能集中，仅留下负责外设的ECU分散布置，通过CAN或以太网总线桥接起主要域控制单元；同时在中央计算单元上选用X86架构为后续软硬件扩展打下基础。 连续在电子电气架构和计算架构上做出变革，对标PC的发展路线，特斯拉的野心暴露无遗：更抽象而标准的电子电气设计、更丰富而统一的软件能力。从正在发生的事实来看，这场汽车软硬件架构的变革正在朝特斯拉设定的方向演进，如果Model 3成为爆款，那么特斯拉将成为行业颠覆者。 ● EEA开发流程 现阶段，汽车电子电气架构的设计与优化都要遵循国际通用标准，即“V”模式的开发流程。  1、需求及目标定义阶段： 应对全新车型市场定位与客户所提出的特殊需求进行有机结合，对于不同车型数据进行比较。在分析与评估后则需要确定出全新车型的需求。在此基础上对子系统需求进行定义。同时制定验证整车需求是否被实现的测试规范与方法。 2、系统/架构设计阶段： 应充分考虑电子电气系统的实际需求，对系统级别的电子电气架构解决方案予以合理地制定，同时对物理与逻辑架构需求进行准确的定义。同时制定验证系统/架构设计目标是否被实现的测试规范与方法。 3、电子电器件设计阶段： 将物理与逻辑架构的实际需求作为重要基础，对电子电器件解决方案进行合理地制定，对相关硬件与软件需求予以定义。同时制定验证电子电器件设计目标是否被实现的测试规范与方法。 4、电子电器件开发阶段： 充分考虑电子电器件的硬件与软件实际具体需求，对相关器件进行开发。另外，零部件开发商需采用自身所具备的测试规范以及方法开展验证工作。 5、电子电器件设计验证阶段： 将测试规范和方法作为参考标准，对电子电器件设计目标的实现状况进行验证。 6、系统/架构设计验证阶段： 将测试规范和方法作为依据，对其设计效果进行验证。 7、整车需求目标验证阶段： 同样需要遵循相关规范和方法，对整车需求的目标实现状况进行验证。 电子电气架构简介 来源：新能源汽车控制软件开发 什么是电子电气架构？电子电气架构包含了车上所有的硬件、软件、传感器、执行机构、电子电气分配系统，电子电气架构是通过系统集成化的工具把这所有的内容整合到一起，它包含了最软件设施、硬件设施和高效的动力和信号分配系统三个基础的要素，在软件设施和硬件设施具备基础上还要一套高效的动力和信号分配系统把这些软件和硬件有机地结合到一起。电子电气架构（EEA）涉及电子与电气两部分，它是在成本、重量、可靠性等一定约束条件下，能最优实现整车电子与电气需求的技术方案。电子电气架构是整车电子电气开发的主体框架，为具体的整车项目中的模块开发提供整车实现方案与规范指导，需具备前瞻性，平台化，可拓展性等特点。 总结来说，电气架构是整车电气系统的基本结构，它包括功能，系统，组成系统的零件，零件与零件之间的相互关系，零件与环境之间的关系，以及指导系统设计和演化的原理。 下图电子电气架构视图。  EEA的主要支撑技术 1. 车载以太网：在车载以太网概念出现之前，我们知道汽车内已经有不同的总线标准在应用，包括CAN、LIN、FlexRay、MOST等；那为什么还需要车载以太网呢？主要还是因为车载以太网在面向未来应用的低成本、高带宽、低延迟等特性。 2. 仿真技术：依赖于V流程，有整车级、系统级、软硬件等多种层级的仿真，针对于具体应用包括新能源、智能驾驶等领域的仿真，主要优点是可以缩短产品开发流程、降低开发成本。 3. 信息安全：在EEA中，当车与外界互联时，涉及到信息安全。在第一、二代EEA中，广播收音系统、胎压监测系统、汽车安全门禁系统等都涉及到信息安全；未来EEA中，面向5G的LTE V2X，基于以太网的DOIP等与外界频繁交互的功能及相关产品需要考虑信息安全。 4. 功能安全：现在讲功能安全的车厂和零部件公司很多，但始终不要忘记，功能安全是正向开发的，一个优秀的EEA，会将功能安全需求合理的分配给相应的零部件。 5. 网络设计：根据EEA要求，设计网络节点、点与点的通信方式、传输速率等。 6. 诊断设计：根据EEA要求，参考相关诊断标准，完成ECU级别的诊断设计。 7. 电气设计：主要指线束设计，作为汽车内部的神经血管，未来EEA中对于线束设计的要求方向是：轻量化、缩短整车线束长度；电气设计还包括整车的电源分配、EMC设计等。8. 硬件设计：EEA，需要通过硬件来实现落地。未来架构中，域控制器/中央计算平台会随着MCU/MPU的性能提升而不断提升，而每个域下的传感器和执行器会逐步走向标准化。9. 基础软件设计：每个ECU的基础软件会走向标准化，即满足Classic AUTOSAR和Adaptive AUTOSAR。 10. 应用软件设计：基于模型的应用层软件开发将会是未来的发展趋势，而未来的EEA将是基于服务的，类似于手机APP,可实现软硬分离，车厂可以根据用户的需求快速开发应用软件。 为什么要做电子电气架构（EEA）？
EEA的发展趋势  目前市场上一些厂家已经实现域控制器的量产，一些厂家还是用的分布式架构。现在的电子电气架构不仅要满足车辆本身的功能和车辆本身的服务，还要延伸到云端，实现车跟车之间的互联、车跟交通设施之间的互联、车跟人之间的互联，这些都将通过电子电气架构来实现，所以将来的电子电气架构是互联的电子电气架构。  随着智能化汽车的发展和新能源汽车的发展对电子电气架构的要求会越来越高，随着用户体验系统、娱乐系统、互动系统和主动安全功能的不断完善，导致目前的电子电气架构已经无法满足这些需求，现在的电子电气架构已经没有足够的空间和相应的成本增加，并且在物理安装上也有很大的困难。如果在想继续满足自动驾驶和新能源汽车的相应功能，现在的架构已经超过负载，目前的架构需要更新。随着智能车辆的普及，汽车会 采用集中计算架构，实现集中计算，区域连接。后续继续发展可能会将部分内容放至云端。 汽车电信通信速率朝着高速化方向发展，而且越来越注重安全。电气化、网联化的推进也使功能安全、信息安全的问题越来越凸显。安全的问题也在汽车开发过程中越来越受到重视。 未来的电子电气架构应该具备四个特点：第一，要易扩展，第二要高性能，第三要一体化，第四要强安全。 易扩展就是电子电气系统要很方便的增加、减少，按照功能的需求进行增减。第二高性能，不管我们在计算力还是通讯方面都需要有高性能的基础。第三一体化，车和云是一体化的考虑，以后车不再是单独独立的个体，是云端互联和旁边的车一起形成有机的整体。第四是强安全，这是车从诞生以来就着重强调的，但是在智能网联的时代安全性就更加重要。 第二方面是软件，我们未来的架构需要开放标准化的基础软件平台，我们要从以前单个系统的纵向软件开发转向到横向分层的结构开发。面向服务架构的设计，要成为我们未来电子电气架构设计主流的思想，统一协调车内的资源，让车内的资源能够快速、有效的进行重新组合，形成新的功能。 第三方面是软硬分离对架构开发模式带来的变化。我们以前传统交钥匙的，整车厂、供应商、用户的关系很难维系，整车厂、供应商、用户要形成新的开发模式。我们合作模式来讲，以前整车厂提需求，供应商软件做好交到整车厂，整车厂组装测试，要变为整车厂更多的涉及到底层软件，包括硬件软件的开发。第二个改变思维要从以前和消费者之间一锤子的买卖，售出车辆之后不再进行优化的模式，变成全生命周期的迭代，就是从我们设计开始那一天到用户抛弃这辆车，这辆车报废的那一天，整个的生命周期要形成新的开发模式。第三是车云的协同开发，以后车的功能开发部再仅仅局限于车端，和云端一体化，以及云端快速的迭代、监测，一些控制，将会成为车功能开发新的特点。第四个要和用户一起，把用户介入进来，以后我们整车上的功能不仅仅是整车厂的想法，用户的想法要加入进来，要迭代到整个的开发流程当中去，让用户也成为开发的一个部分，让每个用户都有属于自己的一辆车，成为新的一个特性。 EEA应该怎么做？ 1. 架构设计：明确开发目标 对于城市规划师来说，他们的设计对象并不是某一个街区或某个建筑，而是整个城市，他们要对整个城市的设计质量负责。如果我们如果把汽车上每个控制器甚至电子部件都想象成城市中的一个特定功能区域，那么电子电气系统的架构师做的就是规划整个的E/E系统，并对E/E系统的设计质量负责。 架构师首先要确定E/E系统（整个城市）的主要功能和性能，然后根据确定的功能与性能的目标来规划整车的拓扑（城市的街区）：确定有多少个主要的控制器、每个控制器的基本功能和相互的连接方式、车辆的主要通信网络的形式（CAN或者以太网或其它）等，并要设计整车的电源方案等。 因为E/E系统在车上并不是一个孤立的系统，它要与车辆本身的物理架构充分的融合，并与车辆的外部世界也有着密切的联系，所以，在进行E/E系统的规划时，他们还要考虑车辆本体的很多具体限制与能力，就如同城市规划师需要考虑城市的地形、气候以及与其它城市之间的关联性一样。每个控制器在车上的大致布置位置、质量要求、性能要求等也是需要在架构设计阶段需要考虑并确定的。 上述的各种架构设计阶段所确定的各种详细信息最终会以各种原则、规范、标准或者需求等形式输出给相关方，他们会根据得到的需求来进行详细的设计，然后再交给最终承担具体实现任务的各个供应商进行部件的开发。 2 .系统开发：细化具体策略 对于一个城市来说，每个街区的功能都是不同的，比如说可以分为商业区、居住区、工业区等等。因为每个街区的功能不同，所以它们的设计要求也不同。例如：居住区要能够容纳100万人，并有各种便利的生活设施，而工业区要能够支持多个大型的工业项目的生产、物流等要求。当某一个街区的设计要求由城市规划师确定之后，一般会有专门的人员进行详细的设计。例如：负责居住区的设计师把城市规划师的要求可以细化为：1000栋高20层的楼、有3所小学、两座医院等等，并详细的在图纸上列出它们的位置和边界，并对区内的交通网络、通信、电力网络等进行详细的设计，并给出具体的要求。这个过程可以类比为E/E系统中的系统设计。 车上的E/E系统也会被分为多个域或者子系统，每个域或者子系统的功能与技术要求都是不同的，比如：底盘控制、仪表显示、电池管理等。所以一般都会由来自专业领域的系统工程师来负责进行详细的设计。他们会像街区的设计师一样，根据架构设计的要求对自己所负责的领域进行详细的设计。灯光控制的系统工程师会根据车辆的配置和功能需求来设计灯光系统的详细逻辑以及具体的信号交互、硬件驱动的参数要求，并且给出对每个相关部件的详细要求，从而让各个部件的工程师能够完成对部件的详细设计。 3. 零部件设计：详细设计不同的域、零部件 当街区的设计完成之后，接下来要做的就是每栋建筑的详细设计，建筑的设计者发布的图纸中规定了房屋的主要结构、所在位置与周边环境的相互关系，以及屋中各种组件的位置与相互之间结合的关系，比如砖混结构、房屋的具体位置和朝向、卧室与客厅的相对位置与尺寸、马桶在卫生间中的位置等，还会对各种建筑材料的选取原则给出具体的标准，比如水泥的标号，钢筋的型号，各种电线的等级要求等等。 零部件工程师完成的也是类似的工作，他们会和供应商进行深入合作，在满足系统工程师给出的具体要求的前提下，进一步详细的设计每一个具体的零部件，完成诸如硬件、软件逻辑的详细设计、整个零部件的外观尺寸、可靠性和EMC标准等，并要确保供应商的产线能够保质保量的稳定生产，随时解答供应商的各种问题，并将其中的部分问题反馈给系统工程师乃至架构师，让他们决定是否要更改原来的设计。 4 供应商开发：系统的搭建及实现 在各种设计需求最终到达供应商的时候，供应商就要开始具体的实施工作了。 在建筑行业，施工单位拿到具体的图纸之后，将组织施工队伍进行具体的建造工作，并最终在验收完成后结束一切具体的工作。而汽车行业的供应商则有所不同，他们将在设计验收之后开始大规模的量产活动（SOP，Start Of Production），并且一直持续到产品退市（EOP，End of Production）。而且，对于很多复杂的产品，整车厂与零部件供应商的设计职责之间的界限并没有那么清晰，很多时候，整车厂只要给出概要性的设计，所有的详细设计工作都由供应商来完成。 从整个E/E系统的开发实现过程中可以看出：无论是架构设计、系统设计还是零部件的设计，其实都是设计的过程，而设计本身是一种不断产生需求、传递需求的活动，上下游之间的信息传递过程是以需求作为载体的，设计过程产生的各种规范、原则、标准等本质是一种需求——一种需要下游来遵守或满足的需求。需求的传递并非完全是瀑布式的单向传递，而是双向的，只有被下游接受了的需求才是有效的需求，而且，下游是可以反向对上游提出需求的。具体需求的最终实现则是通过供应商的开发、验证和生产活动完成的。 EEA的评估  一个架构成功与否必须有它的评价条件。上图的评价维度仅供参考，也不全面。后续会根据理解继续细化。 电子电器架构设计与开发流程 随着汽车配置复杂度的增加，电子电器系统越来越复杂。同时，电子电器的成本压力也越来越大，对电器系统优化的要求也日益增加。鉴于以上原因，电子电器架构EEA （Electronic & Electrical Architecture，以下简称EEA）的概念就应运而生。  一、EEA的定义 EEA 相当于汽车电子电器系统的总布置。具体来说，EEA就是在功能需求 、 法规和设计要求等特定约束下，通过对功能、性能、成本和装配等各方面进行分析，所得到的最优的电子电器系统模型。  二、EEA开发的必要性 汽车发展至今，已不仅仅是代步工具，更是具备安全、 舒适 、 娱乐等性能的集合体 。 而实现这些配置的正是不同的电子器件；电子电器对整车空间、功能、性能、成本、装配 、 开发周期等各方面都有更高更复杂的要求，传统的原理及线束设计已经远远不能满 足 。 而且随着汽车行业平台化和模块化的发展，整车电子电器的开发也必须遵循一定的次序和规则，顺应汽车行业和企业自身发展方向。 因此 ，在平台规划和项目规划前期，就要开始EEA 的规划，从而对电子电器系统开发进行有效管理和控制。电子电器平台及开发如下图所示 。  三、EEA开发流程 针对汽车电子电器架构的设计与优化，遵循目前国际上通用的标准的V模式开发流程。  1、需求及目标定义 结合新车型的市场定位、对比车型的各种数据以及客户的特殊需求，经过分析与评估，制定新车型的整车需求，定义各个子系统的需求（包含电子电器系统），同时制定验证整车需求是否被实现的测试规范与方法。 2、系统／架构设计 根据电子电器系统的需求，制定系统级电子电器架构的解决方案，定义电子电器架构中物理架构和逻辑架构的需求，同时制定验证系统／架构设计目标是否被实现的测试规范与方法。  电子电器架构图 3、电子电器件设计 根据物理架构和逻辑架构的需求，制定各个电子电器件的解决方案，定义电子电器件硬件、软件、机械的需求，同时制定验证电子电器件设计目标是否被实现的测试规范与方法。 4、电子电器件开发 根据电子电器件硬件、软件、机械的需求，开发各个电子电器件，此项工作由零部件供应商完成；同时零部件供应商根据自己的测试规范与方法，验证是否满足主机厂的电子电器件硬件、软件、机械的需求。  5、电子电器件设计验证 根据相应的测试规范与方法，验证电子电器件设计目标是否被实现。 6、系统／架构设计验证 根据相应的测试规范与方法，验证系统／架构设计目标是否被实现。 7、整车需求目标验证 根据相应的测试规范与方法，验证整车需求目标是否被实现。 电子电气系统架构开发设计交付内容如下：  四、V模式设计与开发解析  EEA的开发是一个庞大的系统工作，下面主要从设计及开发整体的角度进行解析。 设计目标定义 1、需求及目标定义 需求及目标的定义是整车EEA 开发的输入和目标，关系到整车及 EEA开发的成败 ，其意义非常重大，主要包含 3个方面: 1）客户需求分析 通过市场调研，获取不同客户群对不同级别车型的配置和功能要求、操作习惯等信息。此项工作目前由专门的咨询公司，如 JD Power等，或者整车厂的市场部通过各种渠道来完成。  2）标杆车型分析 对标杆车型的选择及其分析，目前由整车厂选择标杆车型自行分析 ，或者委托设计公司分析；通过分析，可以得到不同级别、不同配置车型在不同方面 （配置 、 装配、空间、成本等）设计的优劣。作为搭建 EEA平台的输入，标杆车型的分析是一个行之有效的方法。  3）发展趋势分析 当今社会，科技高速发展，汽车电器件更新换代异常频繁，客户对汽车的娱乐性、舒适性等要求也日新月异。作为EEA开发，在需求分析和定义的时候必须考虑到这一点，才不至于落后于时代，满足未来市场的需求。另外，汽车行业的法规也是发展趋势分析的重点，车型的定义需要有前瞻性。 以上三部分内容，相互关联，相互影响，故在EEA 开发在最初阶段，要作为需求分析和定义的纽带，将客户需求、发展趋势和标杆车型做全方位的融合，做出符合市场和客户需求，同时又满足发展趋势的需求及目标定义，EEA 与需求分析的关系如下图所示 。  2、需求规范与管理 1）需求规范 需求规范是指对要开发的系统或产品确定一个完整的、无歧义的、结构化的规范进行描述，这种规范化描述机制，不仅对描述的内容与结构进行了限制，而且对描述语言的规则和描述方法也作了要求。 需求规范的内容包括 : A、确定需求类型 B、确定需求相关文档的内容； 如任务书、相关的标准、法规、合同或其他正式规定性文档 、开发流程要求 、各系统或部件的详细功能描述、接口描述 、各种需求分析报告等； C、定义出合适的需求描述模板； D、定义出评价需求规格说明书的质量准则等； E、定义专用词汇表； 由于电子电气架构开发的专业性较强，还必须定义专用词汇表让有不同知识背景的人、不同部门的人了解同一个概念，其内容可包含 : 技术概念、缩写、动作描述等； F、最后根据规范的文档和描述格式对需求获取的内容进行文档化，形成规范的需求规格说明书，作为系统开发的输入。 完善的需求规格应满足以下基本特性:  2）需求管理  A、需求活动管理 在整车电子电气架构开发的需求工程活动中 ；制定需求工程各个阶段的工作计划；安排各阶段 的活动内容 ( 如讨论、技术交流 、会议、评审等 )。 B、需求跟踪管理 跟踪需求的每一个状态；并根据不同的需求跟踪信息类型 ；采取相应的跟踪能力联系链；实现需求的可追溯性；建立与维护需求跟踪矩阵。 C、需求变更管理 对要变更的内容进行标识；并从不同角度对需求变更将给系统开发带来的影响进行分析给出评估结果，明确哪些需求可以变更，哪些需求不能变更，并设置实现的优先级，确定目标版本，最后把需求变更的内容更新到需求规格说明书中去。 D、版本管理 在保持单个需求同需求文档的联系的同时，管理这些需求文档和开发过程中产生的文档之间的相互关系，每个版本的需求规格说明都应该注明版本号，避免新 旧版本的混淆，记录变更需求文档版本的日期以及所做的变更原因记录每项需求的状态，当某项需求变更时需要根据需求规格说明对相关部分可能进行修改。 设计开发方案的制定 有了完整的EEA设计输入后，便可正式开始 EEA方案的制定。EEA方案的制定分二步：第 1步对 EEA 方案进行前期规划、第2步对不同方案进行具体分析。 1、EEA方案的规划 功能的实现有不同的途径，如下图所示（车窗升降为例）；在EEA分析之初，必须对各种途径进行梳理，并组合为不同的方案进行分析。  2、 EEA方案分析 规划好方案之后，要对每个方案进行具体分析。EEA的分析内容广泛，可分电源分配 、 网络分析、原理设计、线束设计等4部分。这四个部分的内容互有交叉，相互支撑。其关系如下图所示：  1）电源分配  A、电源分配图可获得以下信息：根据负载来选择适合的熔断丝型号； B、负载表主要包括： a. 根据电路类型来提供所有系统的电流值或电量要求； b. 通过电源分配系统中每个子系统的设计要求来决定熔断丝的最大规格； c. 最大熔断丝型号常常用来决定基于电路保护原则的最小的导线型号和最小的连接系统的型号。 C、电路保护策略： a. 第1级保护包括熔断丝、易熔丝、电路断电器，通常用来保护蓄电池电路或将蓄电池电路切断； b. 通常主电路会提供更大的电流（＞30A）给多子系统； c. 典型电路保护装置包括：Maxi熔断丝和Pacific熔断丝，常被用在大电流值的电路中（≥30A）。 2）网络分析 网络在汽车上的应用越来越普遍，其拥有信息共享、减少布线、降低成本、提高总体可靠性和网 络管理等很多优点。 如CAN、LIN、MOST、Flex Ray等，目前应用最广泛的是 CAN。 对于EEA 开发来讲，网络分析的主要任务如下: A、确认哪些模块和网络相连，分别传输了哪些信号； B、确认不同的网络对于整车功能和成本的影响； C、确认网络对线束的要求。包括了网络线束的最大总长度、节点间距、ECU 距离压接点的最远距离、是否双绞、线的颜色、线径、绞距、以及诊断接口线束的要求；对节点总数、节点连接网络的部分导线以及双绞线与连接器端子的具体要求。 3）原理设计  A、建立整车电器连接 a. 根据子系统电器信息，连接所有的电器零件，进行电器连接时，按照各个系统分块连接； b. 按照各个子系统电源输入的要求，连接电源线； c. 进行搭铁的分配，给各个电器零件连接搭铁线，搭铁线以就近搭铁为原则，并要把高电流和低电流的搭铁分开,特殊情况如EMS（Engine Management System，发动机管理系统）、ABS（Antilock Brake System ，防抱死制动系统）等单独搭铁。 B、选择导线 包括线径、绝缘层、种类、颜色等的选择。 a. 导线线径的选择，除了考虑熔断丝的大小外，还要考虑电气件电压降的要求，以及压接后的机械强度；搭铁回路的线径很大程度上取决于电器件本身的失效模式； b. 导线绝缘层的选择要根据其所属环境温度来选择； c. 导线种类可根据电气及环境要求选择，根据各子系统要求，也可选用绞股线，屏蔽线；常用导线标准有DIN （Deutsche Industrie Norm，德 国 工 业 标 准 ）、JIS（Japanese Industrial Standards ，日本工业标准 ）、SAE （Society of Automotive Engineers ，美国汽车工程师协会）； d. 导线颜色的选择 ，对于每个回路 ，需要定义不同的导线颜色 ，以示区分。 C、选择线束对接插接件 在选择对接插接件时，要考虑流过此插接件的电流值 、所经回路的导线线径 、孔径大小（如需要穿过孔）和固定方式等。 a. 定义孔位号时，插接件的视图方向要与线束图纸所示的视图方向一致； b. 定义回路号按照企业标准或系统等要求，为不同的回路进行命名； c. 定义功能选项在相关的回路进行标记，以区别不同的配置。  4）线束设计 线束是原理功能在整车上的具体实现 ，是EEA分析的输出；遵循的原则是原理和整车环境要求，如功能实现 、装配、温度、 成本等各种因素。按照以上分析，得出多种EEA方案的线束设计 后，可以对每个方案进行仿真、检查正确性，并不断地进行修正和完善。  方案测试与验证  1、功能测试 这部分测试从试制车前的台架测试开始，到试制造车，再到小批量生产一直持续到车辆上市阶段。  1）整车级集成功能测试 规范规定了整车层面跨系统功能测试当然范围和方法。由于各控制器开发周期的不尽相同，造成前期零件开发状态的不同步，因此该阶段关注的是系统性功能的“有没有”，保证整车电器零件的正常运行。对没有实现的系统功能进行记录跟踪。避免检查工作的重复进行，并出具装车推荐报告，对各系统的状态进行评估，为其它环节的验证提供依据。 2）系统级集成功能测试 待零件开发状态相对稳定之后，以零件所在系统为关注点，以设计规范为依据详细测试各系统功能实现的精准性，同时评估系统功能的合理性，不仅仅关注该功能“有没有”，同时关注该功能“优不优”，严格把关系统设计准确性和合理性，从工程师和用户多角度验证系统功能，提高产品的质量和用户满意度。 3）接口测试 包括硬件接口和软件接口，硬件接口主要关注输入输出的匹配，软件接口主要关注信号的交互。为了完成一个跨系统的功能，多个不同的信号通过不同的接口传至同一个控制器，应该测试各接口间的电路匹配、软硬件信号的同步性以及定义的一致。另外，当某信号通过接口时，应该测试此信号是否由于受到某些因素的干扰而失真甚至丢失，从而保证系统信号传输的准确性和稳定性。 4）用户感知测试 从测试人员、车间工人、维护人员、消费者、售后服务人员等多角度出发，规范了车辆在使用过程中的实际感受和考核标准，它主要包含以下5个方面： A、用户感知的基本功能测试； B、用户感知的声音功能测试； C、内部灯光的缠身是否同意、是否舒适； D、开关零件使用手感是否良好，灵敏度、设计逻辑等是否满足用户的需求； E、整车功能操作区域划分是否符合一般用户期望，操作是否方便。 5）误用滥用测试 包含误用和滥用两个方面。误用是指驾乘人员在使用车辆过程中异常的或不正确的操作。滥用即频繁、过度地使用某一项功能或某一系统。以不同的使用工况为依托规范了系统集成测试中需要考虑到在非正常操作中产生的预期操作，确保非正常操作时既能给用户必要的警示又不能影响确保驾驶员安全的基本功能，同时在操作恢复后能正常的使用相应的功能。 6）故障处理测试 规范如何选取失效模式场景，对系统发生失效时进行反复测试，寻找可能导致失效的各种情况，从设计进行警示，减少失效模式给用户带来的不便和困扰，从用户角度出发，体现产品设计中以人为本的宗旨。 7）过压测试 规范了在系统高负荷运行环境等情况下的测试内容，用于测试系统在这些场景和环境中是否能够正常工作，体现产品的过压承受力和鲁棒性。  2、性能测试 整车电气系统性能测试（VEST）主要在台架上进行前期的部分测试，试制造车阶段EP1和试制造车阶段EP2制造的工程车上进行实车测试。在汽车使用生命周期内，由于整车电气负载、接地点、线束、保险丝等电气系统设计不合理，导致不必要的能量消耗、电气系统性能下降、电气功能失效等问题。加之电气系统的老化，以及恶劣的工作环境，在车辆实际使用过程中，整车电气系统会产生不可预知的电气故障。 VEST测试，是为了验证整车电气系统的性能，以及在极端电气环境下，电气系统失效带来的影响，并通过测试结果改进电气系统的设计方案，从而保证整车电气系统在使用寿命内的可靠性、稳定性和安全性。主要包含以下测试内容： 1）整车静态电流测试； 2）整车待命状态电流测试； 3）电气回路电流及电压降测试； 4）整车接地性能测试及接地点移除造成电气功能紊乱确认测试； 5）保险丝熔断性能测试以及保险丝缺失造成电气功能失效确认测试； 6）整车电压相关的功能测试。 每项测试内容都有相应的技术规范对其操作方法及评价结果进行详细描述与规定。  3、诊断测试 诊断测试规范制定了关于系统参数配置、软件刷新、DTC测试、I/O控制测试、传输层测试和服务层测试。诊断分为以下三个阶段：  1）装车测试 为试制和试验应用进行的功能测试，包括诊断故障代码、控制器输入/输出数据、配置参数和零件物流数据。 2）应用测试 为制造和售后应用进行的功能测试，需要测试工程师模拟制造和售后应用环境，对诊断需求和诊断数据进行测试。 3）验收测试 对所有需求进行验收测试，包括企业标准、诊断故障代码设计和诊断规范中定义的所有诊断数据进行验收测试。 4、网络测试 试阶段与功能测试可同步进行，该部分测试根据整车网络测试规范，对整车网络进行认证。包含整车的CAN总线测试以及LIN线测试，测试过程涉及到了网络管理、网络负载、一致性测试以及总线故障处理等。  5、EMC测试 EMC测试也称为电磁兼容测试。电磁兼容测试主要在试制造车阶段EP1和试制造车阶段EP2制造的工程车上进行实车测试，目前很多OEM已经在前期零件设计中增加硬件评审和电磁兼容仿真等工作。电磁兼容测试分为EMI测试和EMS测试。EMI测试包括辐射发射骚扰、传导耦合、EMC测试、瞬态发射骚扰。   五、结语 电子电器系统集成测试纵向发展、横向交叉，系统集成测试贯穿于整车电子电器开发的始末，已经成为一种必然。随着整车电子电器技术的发展，零件可以在不同车型上进行移植和复用，而不同车型之间的交叉测试，对于问题的发现和测试经验的分享推广具有重要的意义。 来源于汽车大漫谈、线束世界                              - END - 说明：本文来源机电微学堂 新一代汽车电子电气架构开发的职责边界前言 01 近两年牵头参与了多个，基于SOA的全新架构项目。在和客户一起开展项目的过程中，也遇到了很多共性的问题。所以想借这个机会，和大家分享一下，希望对大家有所启发。有错误，不恰当的地方，欢迎大家指正。 开发过程中的痛点 02 近年来，由于汽车电子电气架构的快速迭代，很多主机厂都处于新老架构交替的重要时期，搭建一个全新的架构，对于任何团队都将是一个不小的挑战。任何新生事物的出现，都是对传统的革命，我们需要抱着积极的心态，至少在一定程度上打破原有的思维和框架，从而建立新的秩序。 在SOA架构设计项目中，无论是和主机厂，或是我们团队内部，都对项目开展了多次复盘总结，大概得出了下图中的这些共性问题。包括：“职责边界”，“传统和变革共存”，“服务是什么”......  这些问题需要从宏观上，或者从思维意识上，给予特别的重视。今天我们就——“职责边界”，来重点聊一聊。 我们知道，汽车电子电气是个异常复杂的系统，不可能由一个人，一个组织来完成。所以站在主机厂角度，梳理出正确的事情，然后把他们交给正确的组织来做，就显得异常重要。 当然这也涉及到公司的业务策略，对未来的定位，比如公司是否致力于主导打造完整的生态链，还是掌握核心的软件，还是仅仅专注于市场需求的理解及实现，等等。 无论如何，宏观的职责分工在一开始就需要规划清楚，否则所有的工作是没法有效开展的，就算开展了，也会逐步偏离初衷，变得难以控制。 职责定义 03 在我们讨论职责边界之前，应该先清晰一个问题，“职责由何而来？”，只有清楚了职责的由来，才能梳理出职责的准确定义，并进一步明确职责的边界。 为了得到答案，先让我们回到最初的起点，看看我们对车辆的定义是怎样的。车辆是仅仅作为交通工具，还是发展成为所谓的第三生活空间？无论是哪种发展方向，有一点是肯定的：车辆都是为人来服务的。 从下图中，我们可以看到车辆使用时的三个要素：环境，车辆和用户。车辆需要感知环境，来满足用户的需求。从这点来看，也能说明为什么把整个车辆作为系统的边界来定义用户需求。（环境和用户在这里都是广义的，我们就不展开了。）  接下来我们拨开车辆的外壳，进到车辆的内部，来看下车辆是如何感知环境来满足用户需求的。这个层级已经属于解决方案了，核心元素是传感器，ECU和执行器。  从上图中，我们可以看到，环境中的一切物理表象，通过传感器转化为对应的电信号，然后这些模拟电信号，传输到在ECU内部，转化为数字信号。然后在软件世界进行沟通，计算和分析，之后将控制指令转化为模拟信号。模拟信号传递到执行器，执行器遵照这些指令，结合自身的物理特性，执行器完成功能在物理世界的最终实现。这个层级看得见摸得着，传统的零部件供应商基本也是按照这个职责来划分。 对于传感器和执行器，目前的现状和趋势是各家的技术和方案逐渐趋同，以后应该是向标准化的方向发展了。当然这些不是我们今天讨论的范围，ECU才是我们今天讨论的重点。我们可以看到ECU在感知环境和满足用户的过程中起到了关键的分析与控制的角色，所以ECU才是满足车辆定义的核心元素。由此，也回答了我们之前的问题，当我们讨论架构开发中的职责，其实本质是溯源到ECU所承担的职责。 接下来我们再拨开ECU的外壳，到ECU内部来看看。这里我们提到的ECU是个泛化概念，对于用户，不太在乎是1个ECU还是100个ECU实现了他们所期望的功能。但是从架构的角度，我们需要评估需要有哪些ECU，这些ECU分别承担什么职责是最优化的。 我们详细来看看ECU可能承担的职责，这里将忽略ECU的中间件，应用层，操作系统......这些是用以 “实现” ECU职责的部件，但我们今天单讲 “职责”，不讲 “实现”。 在下图中，我们根据不同的职责，将ECU分成多个软件层级。  最底层的是Device (S&A) abstraction，这里是指传感器，执行器这些物理部件的抽象。  当我们和其他人进行沟通，或者协作时，首先要保证有同样的语言。如果都不能理解对方说了什么，好的沟通结果根本无从保证。  这里的Device (S&A) Abstraction其实就是这个作用，他们是在软件世界里对实际物理设备的抽象，或者说翻译。 除了Device (S&A) abstraction以外，其他的每一层都发挥着独有的作用，为了更好的理解ECU每一层所承担的职责，我们可以将他与人体机能进行类比，如下图所示： 
这个最底层的作用就相当于人的双手，双脚，是最终接触这个世界的对象。
这层就是对Device的控制，比如对天窗电机的控制，开还是关等等，类似于人手部的肌肉，控制手的活动。
这层主要是通讯的枢纽，类似于人的关节，连接身体的各个部位。
这层是功能域控制，是对控制之间的协调。比如为了保证车身的稳定，需要考虑如何协调制动控制和转向控制。类似于神经系统，如何协调手脚，来保持身体平衡。
这层就是整车范围内的规划。比如所谓的场景定义汽车，基于场景来进行整车范围内的规划。这类似于人的大脑，处理一个项目，考虑要做哪些事情，前后次序是什么等等。 这个层级架构，从下往上，层级越高，处理的事务就越复杂，就越需要规划和计算，层级越低，越简单，只需要条件反射。这和人，也是一样的。 在了解了ECU可能承担的职责以后，接下来我们来看看，架构在演变过程中ECU的职责是怎么变化的。 分布式架构 首先是最传统的分布式架构，ECU承担了设备抽象和设备控制的职责，每个ECU基本上是各司其职，尽可能不打扰对方。这个架构里，人承担了总体规划，思考分析，及车辆行为的协调的职责。  域（Domain）控架构 接下来是功能域架构，在原来的基础上增加了功能域控制器，来承担域内的协调及域间的沟通。  区域控制+中央计算架构 最后，就升级为区域控制+中央计算的架构，在这个架构中，人大脑的职责也要被取代了。到这一步，车辆将真正发展成为数据世界中的一环。  因为每个公司或多或少都有遗留的资产或者负担，包括基于原有架构的打造的，车型，组织架构，流程和工具，原有的零部件和供应链体系等等。另外，支持新架构的产品体系还没有完全打通，尤其是在性能，功能安全等方面，所以这个架构还处于，传统控制器和新架构控制器同时存在的中间状态，各自的职责还在不断的发生演进，这背后会有不同的力量在推动。 接下来，我们聊下为什么要分层？ 这和我们对架构的理解，以及供应商合作方式都有很大的关系。  我们暂且以ECU这个颗粒度来举例。在上图中，如果把一个ECU和另一个ECU的交互定义为一个复杂度，那么左边这平级架构中的每个ECU因为自身功能，需要沟通的话，都将有3个可能的复杂度。最终，这4个ECU组成的架构，一共将存在3*4，12个复杂度。 而如果把其中一个ECU提高一个层级，通过这个ECU来协调底层的ECU。这个ECU将依然保持3个复杂度，但是底层的每个ECU，复杂度都将变成1。那这4个ECU组成的架构，就变为6个复杂度。 大家可以看下这个差异。同样是4个ECU的总数，但最终的复杂度数量却减少了一半。ECU数量越大，两种架构的复杂度差异也将越大。 另外，因为不同层级复杂度的明确，对于如何宏观分配资源，规划平台，我们就心中有数了。 需要注意的是，这个例子，只是以ECU为单位，对功能实现来讲，颗粒度必须下沉到软件单元才有意义。这种情况下，因为架构分层引起的数量差就更加可怕了。 从这点上，也能理解，为什么在传统的架构和供应商体系中，有任何小的改动都如此缓慢和昂贵了。我们如果不从根本上解决复杂度，其他的措施都是扬汤止沸，治标不治本。 职责边界 04 从车辆定义再到ECU层级的拆解，我们对开发过程中ECU所承担的职责已经较为清晰了。最后，根据ECU所承担的职责，我也对实际开发过程中的职责边界给出自己的看法。  在上图中，我们先将整个开发分为两个大的阶段，需求开发和产品开发，然后根据之前提到的ECU层级，将产品开发划分为3级，每一级又拆分为软件产品和硬件产品。然后基于这个分类，应当由主机厂，还是合作商来承担某一分类的职责，在图中给出了推荐程度。 因为传统OEM的开发设计人员，不太懂软件，而传统的软件商只关注单个ECU，没有整车视野，所以在这个变革的历史阶段，市场上需要有能结合两种能力和视野的方案供应商，来弥补缺失的地方。（在实际的情况中，方案商也可能是软件供应商。） 最后，重点说明两点：
作者介绍 05  新能源汽车的电子电气架构作者：邪道长，来源：云飨汽车 前言：本文主要介绍新能源汽车的电子电气架构以及当下各车企其车型EEA架构的发展与未来规划。一、概论按照老规矩，了解问题时，先问个为什么。什么是电子电气架构？电子电气架构是做什么的？它是如何产生的？在汽车发展的早期，整车上的控制节点较少较单一，但随着汽车的发展，其功能越来越多，同时所需的控制单元也开始不断增加，而在不同的控制单元的交互之下，整车的通信、能量分配、功能交互、电磁干扰等问题被发现并放大，为了解决该问题，德尔福公司首先提出了电子电气架构（EEA Electrical/Electronic Architecture），这是集合汽车的电子电气系统原理、中央电器盒、连接器、分配系统等设计为一体的整车电子电气解决方案。通过EEA的设计，可将车身信息转化为实际的物理布局、信号网络、数据网络、诊断、容错、能量管理等。而后博世又将电子电气架构划分为三个大阶段：分布式电子电气架构—【跨】域集中电子电气架构—车辆集中电子电气架构，这也是现今汽车电子电气架构发展的方向。而在架构发展的过程中，由于控制单元的不断增加，车企开始将部分工作分配给到其合作伙伴，渐渐的车企开始扮演技术整合与车辆组装的角色，不过在整体架构趋于集中化的趋势之下，开发工作及核心技术将再次回归到车企。二、EEA发展趋势如图1即为博世定义的电子电气架构的三个大阶段，现今国内各大车企主要处于第二阶段及往第三阶段发展的交互过程。  图1 博世定义的EEA发展图随着时代的发展，车辆作为出行工具的单一定义将被推翻，随之而来的是网联化与智能化，这一变革将使得EEA不再是独立的，而应该是互联的、可扩展的。基于这一需求，高阶段的EEA必须具备易扩展性、高度集成性、高安全性以及高性能性的特点。而为了实现如上功能，整车在开发前期规划时，硬件的预埋将变得至关重要。比如域融合成为单一的中央计算单元，高算力、高性能、高集成度的硬件不仅具备了车辆后期更新迭代的所有功能，同时集成后的单一控制器的成本将低于多控制器的组合成本，在减少线束的同时电干扰等问题将进一步减少。而基于强性能硬件的基础上，软件扩展更新将变得更加容易。同一款硬件平台在成本不变的情况下，通过用户喜好可解锁不同的功能，千人千面亦可以是“千人千车”，比如中控氛围灯样式、人机交互界面自定义、游戏、车辆高性能等等，真正实现软件定义汽车。单这么说可能许多小伙伴不太理解，我们来类比一下，以前我们玩游戏是从单机游戏开始的，都是各玩各的，这时的手机就类似于汽车电子电气架构的第一阶段。而后通过蓝牙等技术我们可以建立局域网，几个小伙伴可以一起联机玩，这时的手机类似于汽车电子电气架构的第二阶段。而如今我们已经可以随时随地跟不同的人玩，这除了手机硬件性能的提升外，云端技术、通信技术等的提高也是不可获缺，就类似于汽车电子电气架构的第三阶段。5G技术、车内以太网技术都使得整车电子电气架构正在朝着既定方向发展，而那些需要解锁的付费功能，就类似于王者的英雄皮肤、原神抽卡五星人物。言归正传，在不久的将来，基于中央集成平台的硬件，更多的软件扩展功能将被不断推出，整车的软件系统将被不定时更新，就类似于手机系统的更新。而对于用户而言，整车是时用时新的，直到整车完整生命周期的完成。电子电气架构的提升，改变了以前车子一旦售出，功能将停止维护的老旧方式。三、EEA相关支撑技术
|
文章网友提供，仅供学习参考，版权为原作者所有，如侵犯到
你的权益请联系542334618@126.com，我们会及时处理。
会员评价：
共0条 发表评论