古典风格中药医药企业网站模板源码,网页版本传奇,企业网站流量预估,邹城网站建设一、软件定义汽车
1.1 什么是软件定义汽车
软件定义汽车(Software Defined Vehicles, SDV)的核心思想是#xff0c;决定未来汽车的是人工智能为核心的软件技术#xff0c;而不再是汽车的马力大小#xff0c;是否真皮座椅#xff0c;机械性能的好坏。软件定义汽车的终极目…一、软件定义汽车
1.1 什么是软件定义汽车
软件定义汽车(Software Defined Vehicles, SDV)的核心思想是决定未来汽车的是人工智能为核心的软件技术而不再是汽车的马力大小是否真皮座椅机械性能的好坏。软件定义汽车的终极目标就是无人驾驶汽车。
这个回答是否就是“软件定义汽车”的正确含义呢恐怕未必见得。在通信行业一直都有“软件定义无线电”在IT行业又有“软件定义功能”等等概念。这些概念体现了一个基本的思路即从需求到产品的一个分析和实现的过程。 从上述的系统分析分解分配的思路来看真正定义产品的不是硬件也不是软件而是市场需求以及由此而分析推演得出的系统架构。
市场定义需求
汽车是满足人们需要的产品。因此汽车生产商(主机厂,OEM等)需要进行大量的市场调研定位目标客户群体分析客户需求对市场竞品进行分析完成市场对标和技术对标从而提炼出产品的特性得到产品需求。
2. 需求定义架构
有了需求汽车生产商的体验经理(或者叫Marketing经理)就可以提出具体的要求。例如汽车的机械性能座舱空间能力各项电子设备的功能等等。这些需求将送到系统工程师进入下一步分析环节。系统工程师分析现有的功能需求根据现有技术和预研技术能力进行梳理确定整车的系统架构。
3. 架构定义功能
如果现有的货架化产品可以满足要求则搭配组合形成产品功能矩阵。如果没有现成的技术或者现有货架化产品成本太高则需要确定自研技术或者合作开发或者选择备选方案。综合上述过程形成产品的功能模块。
4. 功能定义软件和硬件
架构设计的功能最终需要落实到软硬件来实现。硬件是载体它决定了架构的下限。软件是功力它决定了硬件能力发挥的程度。由于硬件的特性它是不容易改变的或者说它的更新迭代周期远远长于软件。因此需要对软件进行模块化设计定义好升级迭代的策略。
5. 软硬件共同定义产品
由软件平台和硬件平台共同组成了用户可见的汽车产品。当用户购买了一辆汽车时他/她所见到体验到的功能由硬件和软件共同决定。不同的车型即使采用了相同的硬件设备(Tier1提供的功能设备)由于不同的软件适配能力用户所能感受到的产品性能是不一样的。
在汽车发展的过程中电子电气设备的重要程度逐渐提升。随着电动汽车时代的到来智能化在用户感受程度方面逐渐成为产品的竞争门槛。在这种时代背景下软件能力给汽车的体验功能提供了更高的天花板提升了产品的竞争力。因此笔者认为这或许才是软件定义汽车的真正含义。
软件定义汽车是相对于传统的汽车功能定义所提出的一种改变。
传统的汽车整车物理结构主要由动力系统(发动机变速箱等)底盘电气设备车身等4个部分组成。底盘负责支承、安装发动机及其各部件、总成形成汽车的整体造型承受发动机动力保证正常行驶。电气设备负责起动控制、点火控制、照明与信号系统、电动辅助控制等主要包括蓄电池、发电机、起动系、灯光与信号系统、信息显示系统、辅助电气系统、电子控制系统等。车身包括车窗、车门、驾驶舱、乘客舱、发动机舱、行李舱等。当新时代的来临汽车电动化智能化网联化服务化的需求会要求新增更多的功能单元如果没有一个良好的架构越来越多的新功能将难以集成到现有的汽车架构中。
而新型的智能汽车将整车分为了信息娱乐域自动驾驶域动力总成域底盘域车身域等5个大的功能领域。软件定义汽车的开发理念将从架构体系入手从上至下实现软硬件的解耦。在整个过程中整车功能的定义与实现主要通过系统架构设计而实现。整车的功能不再由多个现成的ECU单元所组合而成而是被抽象成可以被软件和服务共享的资源池从而使汽车的功能由软件来定义。
总体上软件定义汽车是指汽车软硬件解耦由系统架构设计决定汽车的硬件资源池为整车提供模块化和通用化的硬件平台。以人工智能为核心的软件技术将为汽车的智能化网联化服务化提供核心支撑支持汽车功能的开发引领技术革新和产品的差异化。
1.2 如何达到软件定义汽车
智能汽车领域正在成为新一轮科技革命和产业革命的战略高地。电动化网联化智能化共享化等新四化正是智能汽车的标志。它是指搭载先进传感器运用人工智能等新技术具有自动驾驶功能逐步成为智能移动空间和应用终端的新一代汽车。
相较于传统的汽车行业智能汽车的核心差异点在于具有高级自动驾驶辅助系统智能座舱系统车联网系统。最显著的特征则是智能化网联化共享化。对应到智能汽车三大要素即智能驾驶智能交互智能服务。
智能汽车的智能驾驶智能交互智能服务的实现需要从硬件和软件两个层面得到支持。首先是需要具备摄像头激光雷达人工智能芯片等硬件系统支持其次是需要高级的感知算法决策算法执行系统等软件支持。因此智能汽车的核心竞争力体现为软件硬件。
根据软件定义汽车的概念需要实现汽车软硬件的解耦。如何实现解耦这就要求通过汽车电子电气架构的设计来实现硬件平台的模块化和资源化通过SOA来实现软件平台的服务化。
架构设计 架构设计的方向主要是平台化组件化集成化服务化。
平台化
汽车的开发中同一个平台的基础上可以发展出多款车型这既是成本的需要也是技术发展的必然。平台化同时体现了可复用性和可扩展性。基于相同的平台架构通过子功能模块的组合与集成就能够安全快捷地研发出新款车型同时可以体现出差异化竞争的优势。
2. 组件化。
当系统架构向平台化发展时另一个发展趋势必然是组件化。当软硬件解耦以后硬件设备将被抽取出来按功能领域进行划分形成多个域控制器。软件功能将实现重新区分和组合形成高内聚低耦合的功能模块。这些模块通过标准通信接口和SOA服务实现相互作用并且运行在不同的域控制器上。最终按组件形式成为了标准化的货架化产品更方便升级。
3. 集成化
传统的汽车内有近百个ECU每个ECU都是由独立的供应商设计和开发。ECU内部软件和硬件是强绑定的不同ECU之间协同难效率低升级慢。如果能够对ECU进行梳理将多个ECU的功能集中到少数高性能的计算单元中不仅可以节省算力还可以降低成本。同时更重要的是降低了汽车对ECU供应商的依赖有利于供应链的整合。比如再出现2021年汽车产业“缺芯”问题的概率就会大大降低。
4. 服务化
汽车正在由“功能型”向“服务型”进行转变基于车载软件的智能服务也在悄然兴起。如娱乐服务生活服务出行服务等。汽车座舱将成为人们的“第二生活空间”。在这种趋势下系统架构对服务化的适应体现在以下几个方面通过车联网提供云端服务通过SOA实现功能组件的协同通过OTA实现功能升级和产品迭代。
因此我们可以从系统架构的设计入手推动软硬件解耦整车物理结构不再与特定的功能绑定而是抽象成可以被软件和服务共享的资源池从软件的角度实现汽车功能的定义开发升级从而实现软件定义汽车。
二、汽车电子电气架构EEA
2.1 什么是EEA
上文中提到要想实现软件定义汽车首先要考虑的就是通过汽车电子电气架构的定义与重构实现汽车软硬件的解耦。那么问题来了什么是电子电气架构
根据百度百科的解释电子电气架构(EEA, Electrical/Electronic Architecture)是首先由德尔福公司提出的集合汽车的电子电气系统原理设计中央电器盒设计连接器设计电子电气分配等系统设计为一体的整车电子电气解决方案。通过EEA的设计可将动力总成、驱动信息、娱乐信息等车身信息转化为实际的电源分配的物理布局、信号网络、数据网络、诊断、容错、能量管理等的电子电气解决方案。
随着智能汽车时代的到来EEA被赋予了更新的意义。在实践中智能汽车的电子电气设备更多向智能化和网联化发展。传统ECU在汽车内部的占比越来越低EEA更加关注于新型智能设备例如摄像头大型显示屏人工智能芯片等。EEA从传统的面向信号体系加速向智能化时代的面向服务体系进行转变。
2.2 EEA的演进
说起EEA就要从传统汽车面临的困局谈起。虽然现在大家已经基本接受了新型EEA的概念但是简单回顾一下历史也非常有必要。
传统的汽车EEA中一开始是依赖于各供应商提供的ECU来实现整车电子电气的。这种架构下要新增一个功能那就请供应商(Tier1)看看能提供什么样的产品(ECU 电子控制单元)。然后分析该产品的布线布局看看在整车物理架构中如何塞进去。例如考虑如何供电考虑车内哪里有空间可以放下它如果它要跟其他ECU通信要怎么增加通信接口是否需要再增加一根通信线
当这种新的功能或者说新的ECU需要越加越多的时候问题就大了。如何才能满足要求一辆传统连接的汽车中导线总长度可以达到2000多米电气节点可以达到1500多个。线束材料成本剧增系统臃肿而庞大并且还存在布局空间困难......
2.
这个时候需要对EEA做点改变了。是不是首先想到要建立总线的概念系统工程师首先在车里布置好总线而后再把各ECU挂载到总线上这样当需要增加新的ECU时候只要ECU是按标准接口进行设计的直接挂载到总线即可非常的方便。这种以统一协议为基础的车载网络总线技术就是分布式ECU的EEA架构。
汽车总线技术的优点是在统一应用层协议和数据定义的基础上可以使之成为一个“开放式系统”具有很强的灵活性。对于任何遵循上述协议的供应商所生产的ECU都可轻易添加入该网络系统中或者从网络系统中拆除几乎不需要做任何硬件和软件的修改这完全符合现代汽车平台式设计的理念。因此汽车电子控制采用网络化设计可大大降低设计成本。
车载网络总线技术包括LINCANCANFDFlexRayMOST车载Ethernet等。
但是这种EEA的缺点也逐渐暴露出来总线技术是由ECU厂商确定并推广的。话语权在Tier1厂商手里。假如有新的技术出现但是部分ECU供应商并没有更新换代的动力仍然坚持采用旧的标准这样就会造成新旧技术的并存进而影响到汽车的演进和升级。尤其是智能汽车时代同一辆车上车载网络总线存在LINCANCANFDEthernet并存的现象。
3.
随着智能汽车的浪潮到来原有的分布式EEA架构完全不敷使用。其一车载网络总线带宽不足根本无法承载高带宽数据量传输的要求。例如智能车的感知系统需要传输高带宽的图像数据。其二算力不足。无论是智能驾驶智能交互还是智能服务都需要高算力的域控制器提供运行平台。因此EEA架构必须适应新的发展。 新的EEA架构需要考虑如下3个关注点
硬件成本减少ECU的个数可以降低成本。减少线缆的长度也可以降低成本。从硬件成本的角度出发要求新型EEA架构能够在汽车新功能不断增加的前提下降低ECU个数和线缆的长度从而降低硬件成本。软硬件解耦汽车行业的传统是Tier1厂商将“软件硬件”集成在ECU中打包卖给汽车厂商(主机厂)。软硬件的耦合深价格贵调试难。且供应链很长缺少任何零部件就会影响整车的生产。新型EEA需要将软硬件实行解耦这样主机厂可以通过软件OTA升级掌控汽车升级的节奏。可复用可扩展新型EEA架构下硬件资源将尽可能的实现抽象算力资源集中到少数的域控制器上。将原有的各种分布式ECU进行重构和组合感知和决策由域控制器来实施ECU将弱化为执行器其控制功能由运行在域控制器上的软件来实现。这样就可以实现可复用和可扩展的要求。
基于如上3点考虑汽车行业提出了EEA演进的Roadmap下面将以最经典的一幅图来说明。 上图是博世汽车对EEA架构演进思考后提出的roadmap得到了业界广泛的认同大量分析EEA的文章均引用了此图。EEA的发展演进被分为6个阶段分布式模块阶段功能集成阶段标准域集中化阶段跨域融合阶段车载中央计算机和区域控制器阶段车云一体化阶段。由于跨阶段发展存在重叠又可以把6个阶段合并成3个具有明显特征区分的架构即分布式ECU架构域控制器架构中央计算机架构。
分布式ECU架构
在2015年博世汽车提出这个演进路线图时EEA还处在分布式模块化和功能集中化的阶段所以把该阶段称为Today。在Modular阶段中一个功能是由一个ECU来实现的。并且还带有一组相关的传感器和执行器并从车辆网络接收其他数据。车辆的通信矩阵描述了ECU之间的这些必要的通信通道。 但是这种设计限制了可重用性。传感器和执行器直接连接到单个独立的功能性ECU上。 如果其他总线参与者需要使用这些值则需要更改通信矩阵。
后来ECU逐渐进行小规模的合并目的是减少硬件设备。但是整体架构还是一种面向信号的通信机制由CAN和LIN总线连接各ECU进行点对点的通信。这个就是Integration的演进。 2. 域控制器架构
博世预估这个阶段的时间为2019年到2023年。这时EEA发展的特征是以车载以太网为通信骨干以域控制器为处理核心融合各ECU的功能并努力集中到少数几个域控制器上。这里的域控制器(DCU, Domain Control Unit)是根据功能来划分的。在Centralization阶段整车分为信息娱乐域自动驾驶域动力总成域底盘域车身域等5个主要的功能域每个域由一个域控制器来实现域内ECU的功能。在这种EEA架构下需要有一个中央网关来连接各域控制器。通过以太网这些域控制器相互之间可以实现通信。
随着域控制器的进一步发展进入了跨域融合的时代。这时部分域控制器会实现合并5个域彼此重组融合最后形成了3个域智能驾驶域智能座舱域车辆控制域。
其中车辆控制域基本将原动力域、底盘域和车身域等传统车辆域进行了整合智能驾驶域和智能座舱域则专注实现汽车的智能化和网联化。涉及的零部件主要有4类车控域控制器VDCVehicle Domain Controller、智能驾驶域控制器ADCADAS\AD Domain Controller、智能座舱域控制器CDCCockpit Domain Controller以及中央网关其中
VDC作为Private DCU负责整车控制实时性安全性要求高ADC作为Public DCU负责自动驾驶相关感知、规划、决策相关功能的实现CDC作为Public DCU负责人机交互和智能座舱相关功能的实现
这时各ECU将降低成为执行器和传感器失去了独立决策的能力。作为执行器它们接收来自域控制器的命令做出反馈动作。作为传感器它们采集各种内外部信息传递到域控制器的感知系统。
注意对于ECU的功能变迁只是一种高层级的描述。在实际应用中由于汽车控制的要求与供应链的要求涉及到车辆运动系统的变动例如转向安全防护等还不能完全脱离传统ECU的功能定义。
3. 中央计算架构
对于EEA发展的第三阶段在博世的描述中被称为Vision远景展望。在这个发展阶段中首先所有的DCU会合并成一个中央计算机它承载了智能驾驶域智能座舱域车辆控制域的功能并且还集成了中央网关的功能。这就是所谓的Vehicle Computer。而后随着车联网进入5G时代还可以期望将Vehicle Computer的功能迁移到网络云端车辆完全作为一个网络节点而存在所有的计算功能将布置在云上。这个功能被称之为Vehicle Cloud Computing。 2022年已经有部分车企(主机厂)在向着Vehicle Computer的方向迈进。这其中的代表无疑是特斯拉。这种架构被称为中央计算机-区域控制器(Centralizer-Zonal)架构。在第二代EEA架构中以功能来划分DCU。在相同的Domain下的ECU即使分处车身的各物理区域仍然需要直接连接到同一个DCU下。以车灯为例前车灯后车灯都要连接到VDC上。这样势必会带来整车线束的过多影响成本和重量。
从网络拓扑结构进行分析可以将按功能划分的EEA架构改为按物理区域划分。这样可以将全车分为前后左右四个区域(Zonal)分布在各区域的ECU统一连接到本域的控制器上(Zonal-Controller)。这样就可以减少线束的使用。
在发展的过程中可能存在4个3个2个Zonal的实际案例。这背后体现了各主机厂对功能划分的认识对供应链整合的能力以及对成本控制的考量。并没有统一的好或者坏的说法。下图是 Zonal划分的2个范例 特别需要提起的是中央计算机的含义是将三域控制器集成在一个中央单元内但并不代表一定需要采用同一颗SOC芯片完成三域融合的功能。在当前的时期(2022)还看不到三域融合到一颗SOC芯片的可能。
三、SOA概念与应用
3.1 什么是SOA
SOA是Service-Oriented Architecture的缩写面向服务的架构。百度百科对SOA的定义是面向服务的体系结构是一个组件模型它将应用程序的不同功能单元称为服务进行拆分。通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
SOA的概念最早来自于IT界到目前为止还没有一个公认的定义。但是SOA的目标和其特性是十分清楚的。 目标构建一个灵活可变的平台系统。 特性
服务间 低耦合、无依赖服务内 高内聚、可复用、可重组服务通信接口 标准化不依赖于底层平台
SOA实现的重点在于
服务通信标准化即面向服务的通信SOCService-Oriented Communication以服务重用、灵活重组为目的的服务划分即面向服务的重用共享设计SORSService-Oriented Reuse-shared Design用于承载和适配SOC和SORS的软件实现即基于服务的软件架构SOSAService-Oriented Software Architecture
3.2 为什么需要SOA
在数字化重塑汽车的浪潮下一场深刻的汽车电子电气架构和软件的变革正在酝酿。汽车行业正沿着PC和手机行业走过的道路迈向智能时代。在这样的时代背景下传统的汽车EE架构以及传统的面向信号的车载软件架构都面临着颠覆性的变化。谁能拥抱这种变化主动迎向这种趋势谁才能赢得竞争。
传统的汽车软件是面向信号的架构。车内多个ECU通过CAN总线相连。但是信号的收发关系和路由信息通常是静态的、不可更改的。电子电气架构师在进行整车EE架构设计时通常会首先画好整车的网络拓扑结构图。每一个ECU都是拓扑图上的节点。如果没有改动那这些ECU可以很好的协同工作。但如果后期突然需要新增节点如何更改矩阵和路由表呢再如果车辆上市后想新增一个功能到某个ECU通过OTA可以将软件包本身下载到该ECU但其他ECU如何获取这个新功能所提供的信息是否需要将所有涉及的ECU全部执行一遍OTA升级每一个ECU的供应商是否能协同配合以上这些问题很难在传统的架构中得到解决。
根据之前所述SOA的特性正好可以引入汽车行业配合着新型的中央集中-区域控制器的EEA架构实现软硬件解耦。从而解决了之前所述面临的困局。
因此智能汽车软件架构进入了面向服务的时代。
3.3 SOA如何实现
与中央集中-区域控制器的EEA架构相匹配它引入域控制器DCU概念其芯片算力、操作系统以及软件架构可以满足业务需求与硬件资源解耦的需求。即有能力通过一套基础软件框架去实现SOA的设计思想从而将底层的硬件资源具备的能力抽象为一种服务供外部使用并能够支持一系列的服务管理功能服务定位、服务发现服务调用等。
应用服务化各个域将自己所能的提供服务公开化后才能实现不同域之间的开发与融合使智能汽车成为可能 服务部署灵活SOA的一个基础就是“服务发现”机制即给每个服务分配一个“全局名称”通过这个名称就可以直接找到对应的服务就好比我们上网时用的“网址” 。基于这个特性在整车生命周期内不同的车型配置可做不同的服务部署对代码几乎可以不用改动
软件更新灵活SOA的松耦合特性可以将功能更新与变更限制在更小的范围内。当硬件架构需要调整时减少复杂功能涉及的ECU数量多个ECU的功能融合到中央计算平台当中。当软件架构需要更新时只需要在中央计算平台内部更新/升级部分软件即可
SOC面向服务的通信(Service Oriented Communication)
SOC主要为了实现通信标准化动态建立通信关系连接信息孤岛。车载以太网协议架构中的SOME/IPService-Oriented MiddleWare over IP就是基于SOA思想定义的通信中间件。SOME/IP是针对车载环境定义的一套通信协议出自AUTOSAR。可以达到屏蔽系统异构性实现互操作的目的。除了SOME/IP之外还有一种DDS协议也可以用于SOC。
2. SORS面向服务的重用共享设计(Service-Oriented Reuse-shared Design)
SORS是基于下一代智能网联架构来实现的主要是完成服务实现并且体现服务复用性而进行的设计工作。使服务本身高内聚服务之间能够低耦合提高服务的可重用性明确边界概念。
在SORS的设计中我们可以采用Top-Down的思路来进行
Top-Down又称为自上而下的分解过程。从车辆的功能和业务流程入手将功能进行分解。例如整车防盗认证会有各级防盗认证流程期间会调用到很多的模块或者算法比如随机化算法、防盗认证算法等。可以将这些算法抽取出来形成不同的算法服务从一个个的功能业务链入手分化抽离出服务库。最后可以逆向重建即从服务库中挑选出一个个服务模块通过排列组合的调用就可以将原始的功能业务场景还原出来。
SORS的设计方法可以将服务分为如下三大类
原子服务不可拆分的服务一般执行单一功能。不同的功能节点(ECU)可以提供一个或多个针对业务的原子服务。系统服务系统可以提供的基础服务体现该系统可以提供的能力。需要依赖于原子服务提供的功能可以通过API或者服务提供机制向服务使用者提供组合而成的系统服务包。动态服务基于原子服务和系统服务提供的功能进行组合实现服务的级联。例如产品上定义一个抽烟模式需要同时打开车窗、天窗并播放车主收藏的音乐这就需要调用多个系统服务去实现。
3. SOSA面向服务的软件架构(Service Oriented Software Architecture)
Adaptive AUTOSAR这个基于服务理念的中间件就是一种SOSA。它体现了基于服务的架构思想运行环境ara分成了Foundation和Service两部分。 Adaptive AUTOSAR架构逻辑视图R20-11
《中国汽车基础软件发展白皮书3.0》所定义的ASF也是一种SOSA。
ASF 是位于基础软件平台即基础操作系统和运行环境和功能服务层之间的服务软件单元的集群主要用于支持功能服务的通用化基础功能的开发和使用。可实现车内各功能服务之间、车云之间共享通信、 诊断、计算等资源。 ASF 主要可分为原子服务、SOA 增强型服务、系统级基础服务、整车级基础服务。软件架构设计师需基于各服务类型进行服务定义、设计使 ASF 分层和功能定义更加清晰。在服务设计过程中遵循以下原则
SOA 增强型服务具有通用性即可为所有的应用服务提供通用功能应用服务基于服务自身需求可使用该类服务如数据存储、服务信号转换、服务调试等诸如此类的通用化功能。系统级基础服务具有一定范围的如某操作系统或控制器之上通用性且具有抽象性即对基础软件开发平台如 AUTOSAR Adaptive/Classic、Android 等提供的通用化功能进行抽象并提供给应用服务使用如健康管理服务、网络管理服务、时钟服务、电源管理服务等。整车级系统服务具有全局性即该类服务的设计更多关注的是整车层面对车内所有系统的通用化功能进行协同和管控该层服务是对系统基础服务在整车层面的抽象和管控即通过该层服务可以配置和控制系统基础服务如整车健康管理服务、整车网络管理服务、整车时钟服务、整车电源管理服务等。动态服务具有动态配置性即应用服务在运行过程中可对服务进行配置并基于配置输入执行动态服务的功能。原子服务具有独立性即其设计应与硬件配置和实现无关与上层功能服务层和下层的硬件驱动层解耦完全独立。原子服务具有原子性即设计的服务不可再拆分作为服务的最小单位和执行实体为功能服务提供最基础的执行或采集等功能
注以上描述来自《中国汽车基础软件发展白皮书3.0》
