当前位置:首页 > 文章资讯 > 汽修专业 > 【系列篇】-汽车软件架构师是如何养成的-第一章-现代汽车电子和软件发展过程中软件的历史
【系列篇】-汽车软件架构师是如何养成的-第一章-现代汽车电子和软件发展过程中软件的历史
【系列篇】-汽车软件架构师是怎么样的一种体验 -第一章-概述
现代汽车已从机械设备演变为依靠软件正常运行的分布式网络物理系统。 从1970年代开始,所使用的电子和软件数量已从仅一台计算机(电子控制单元,ECU)逐渐增加到2015年的多达150个ECU。但是,汽车电子电气架构的趋势是减少中央计算节点的数量,并将它们与数量增加的I / O节点连接(即域控制器底下挂多个执行类控制器)。 在本章中,我们将介绍本系列内容的概览以及用到的专业术语,并介绍我们将在全文中使用的示例。 我们还描述在现代汽车电子和软件发展过程中软件失效的历史。 在本章的最后,我们还描述了可以加深汽车软件知识的方向。
1.1软件与现代化汽车
向汽车里引入软件给汽车性能的优化和令人欢快的信息娱乐功能带来了非常多的机会。现代化汽车有很多电子产品,消费者在寻找软件驱动的汽车平台。特斯拉就是这种汽车的一个很好的例子,它以软件驱动创新而闻名,该制造商不断向客户推送新版本软件,以给客户提供新功能,是他们获得新的体验感。
现代化汽车里的软件系统带来了很多新机会,但是这些软件系统需要更仔细的设计、实现、验证和确认才可以推送给消费者。而且,尽管软件工程的实践已经包含了能够满足汽车软件安全性和可靠性需求的方法和工具了,但这些方法和工具必须是适应于汽车领域的,以满足汽车的安全性和可靠性。
我们可以看到,汽车工业的发展逐渐从完全机械化转变为逐渐增长的电子和软件化,我们已经看到软件从1970年代的简单发动机控制算法到2000年代的先进安全系统以及2010年代的先进连接性的演变。我们可以观察到该趋势,即电子化和软件化。
随着软件在现代化汽车里数量和重要性的增加,我们可以看到专业软件工程的需求不断增长,同时软件工程的开发过程要求要非常严格,以保证软件的高质量,确保软件不会造成致命性缺陷。
软件工程的一种实践是软件系统的高级设计,也成为软件架构。软件架构可以让设计人员规定软件功能如何分配给软件组件以及如何与组件交互。软件架构通常是在软件开发的早期阶段完成,并作为将软件模块分配给组件以及将功能分配到软件组件的基础。
1.2汽车工业软件历史
尽管现在我们的汽车有很多软件,但与汽车行业刚开始的时候不一样,第一辆汽车是不包含任何电子产品。只有在1970年代的时候,为了燃油效率的高要求,引入了电子燃油喷射系统,汽车系统里才有了软件。
在1970年代,汽车中的软件通常与单个应用强强的嵌入到一起,例如,动力总成中的电子燃油喷射,电气系统的点火系统。由于在那个年代很少使用电子设备,所以功能安全的概念与软件无关,对于嵌入式系统来说,功能安全机制相对容易。软件架构通常是整体式的,不与其他软件部分有关联。
到了1980年代,中央计算单元有了一些创新,可以显示车辆的基本信息,如当前油耗、平均油耗和行驶距离。在嵌入式软件方面,软件算法控制着新功能,如防抱死制动系统(ABS)甚至是电子变速箱。
1990年代引入了更多消费者可见的电子产品。最显著的创新是信息领域里的导航系统,或者俗称GPS。在线显示信息需要集成重要的电子组件,如动力总成控制计算机,专用GPS接收器和信息娱乐显示器。同一个十年,在诸如ACC(自适应巡航控制)之类的安全关键领域也引入了更多的电子设备和软件,ACC系统根据前方车辆的速度来控制车辆的速度,这种功能的引入提出了由软件故障引起的事故责任的重要问题。1990年代使用的汽车软件架构更加分散,软件已经被认为是汽车行业创新的重要因素。下图是汽车上计算机系统示例(90年代的某车型发动机控制器)。
这种发展一直持续到2000年代,此时软件开始主导汽车行业的创新。也是在2000年代,提出了高级驾驶员辅助系统的概念。“高级”是指将多台计算机集成在汽车中并为驾驶员做出更多“难”决定的功能。最典型的系统之一是沃尔沃在其XC60车型上引入的城市安全系统,当障碍物出现在前方并且驾驶员没有时间做出反应时,该系统可以使汽车停止下来。正是这些系统需要更复杂的控制交互和实时响应,因此需要更高级的软件架构,AUTOSAR标准的引入可以实现这些需求,在不同的硬件平台上使用相似的软件方案,让制造商共享软件组件,为车载计算单元引入操作系统。
最后在2010年代,推出了一种全新的汽车电子设计方法。与十年前单个汽车内的分布式计算不同,这个年代引入了无线网络汽车、车车通信、车与基础设施通信以及无人驾驶的概念。市场上出现了很多新玩家,以后市场上的汽车不是最终的产品,而是在汽车平台上可以引入新功能。这类汽车最典型的就是特斯拉汽车和谷歌的自动驾驶汽车。同时,在这个时代,需要更多的供应商提供软件,以支持很多高级复杂的功能,且在不改变硬件的情况下可以升级软件进而获取新功能。下图就是该应用的一个例子-信息娱乐系统:
据说当前的汽车里所有软件的代码数已经超过了1000万行了。
1.3汽车软件开发发展趋势
Pretschner et al在2007年列出汽车系统软件开发几大趋势,主要有5个趋势:
软件的异构性:现代化汽车的软件在不同领域实现不同的功能。这里所说的域包含高功能安全的系统(如主动安全系统),也包含用户体验中心系统(如信息娱乐系统)。这就意味着对不同域的软件设计和验证会有很大的区别。
合作开发:软件系统的开发在汽车OEM(如沃尔沃、宝马、奥迪等汽车制造厂)和零部件供应商之间分工开发。甚至如果供应商只要满足OEM的需求,遵守OEM的要求并与OEM达成一致,还可以按照自己的工作方式去开发和工作。
软件分布:汽车软件系统有很多ECU组成,每个计算单元都有其自己的软件,需要与其他ECU配合才能满足它的功能。这给软件带来更多的复杂性。
变型和配置:全球化和高度竞争化的汽车市场要求汽车制造厂根据不同国家和用户的需求进行定制化,这就要求现代化汽车的软件在无需重新认证的情况下可以在不同的国家和地区可以工作。因此,软件需要以多种方式来支持这些变型,动态的或者静态的,动态的支持变型是指在软件可以自适应变化,运行不同的软件逻辑;静态的是指通过改变软件源代码来适应变化。
基于单元的成本模型:竞争市场意味着每辆车的价格不能太高,倒逼OEM不断优化硬件和软件,使单个成本保持较低水平,而开发成本可能会更高。
2007年以来,汽车市场发生大的变化,主要的趋势有如下:
连接与合作:通过移动网络使用互联网功能,汽车可以与其他汽车和道路上的基础设施连接,以获取很多的信息,基于这些信息做出相关决策。智能交通系统领域的研究项目探索了诸如规划公交车速度的想法,尽量减少在接近红绿灯时踩刹车。现代化汽车还可以通过蓝牙与手机连接,还能够使用互联网功能,如浏览器或音乐服务。
自动驾驶功能:完全取代驾驶员自动完成制动、转向、自动驾驶,还存在很多复杂性。但是这是一个大的趋势,所以接下来汽车软件的验证和确认方法将变得更加严格和先进。
无人驾驶场景具有挑战性,因为需要具有汽车物理环境的准确模型。 这种对准确性的要求需要更复杂的测量设备,因此需要处理更多的数据,更多的决策点,进而需要更复杂的算法。 一种用于自动驾驶的测量设备是激光雷达,如下图所示:
上图显示了安装在自动驾驶汽车车顶上的激光雷达。 该设备可360度全方位查看周围环境,并允许汽车软件查找其附近的物体。 激光雷达通常是雷达的补充,雷达通常放置在车辆的前部。 下图沃尔沃FH16卡车的雷达ECU的图片。
通常情况下,批产车辆会使用前置摄像头来感知物体。
1.4 汽车软件系统结构
多年来,每个汽车制造商(通常称为OEM,原始设备制造商)都有自己的组织软件系统的方式,组织方式的多样性可以跟汽车品牌相媲美。但是,许多汽车制造商都以类似的方式设计软件-他们使用V开发模型,并且将电气(和软件)系统组织成类似的域和子系统。具体可以参考下图。
在此视图中,我们可以看到电气系统被组织成多个领域,例如信息娱乐和动力总成域。 这些域中的每个域都有一组特定的属性-有些对安全性要求很高,而有些则要求不高,有些是面向用户的,有些是实时的和嵌入式的。但是,每个域都被组织为子系统,这个子系统集中了一些特殊的功能(某些OEM称这些子系统简称为“系统”),例如主动安全系统和高级辅助驾驶功能。这些系统将许多逻辑元素组合在一起并实现功能,这些逻辑元素会被组合成功能,这里的功能通常被称为端到端功能,因为它们实现了用户功能,例如自适应巡航控制,车道偏离警告和从A到B的导航。
这些功能由电气系统的子系统实现,并且与子系统,组件和模块的组织相关。 因此,我们经常看到“功能架构(视图)”就是描述功能之间的依赖关系。
每个子系统包含许多组件,这些组件包括实现功能部分的软件元素的较小部分(例如,该部分可以是信息娱乐系统的消息代理)。 这些组件被组织成软件模块,这些软件模块通常是一些源代码文件。这些编程语言功能或软件类别的组合称为逻辑软件组件。
软件架构这个词可以用在这个层次结构里的每个层次(除了最低层次以外),我们可以使用EE架构(电子电气架构)描述整车软件和硬件组织方式。我们可以使用ECU架构描述ECU里软件子系统、组件和模块的逻辑组织方式。根据ECU的大小和在车内的角色,我们可以在ECU里定义模块、组件或子系统。
1.5 架构是一门学科
软件架构在软件开发过程中是一种工作产品,但是架构设计是一门成熟学科,有其自己的活动和任务。通常情况下,软件架构设计需要更丰富的经验,同时架构设计师比软件设计人员有更大的决策权。让我们简要的讨论一下软件架构与设计人员及项目经理的关系。
1.5.1 Architecting vs. Project Management
成为一名架构师意味着技术方面的领导者,架构师是为整个系统的开发打下基础的人,架构师的职责是制定架构风格和指导系统开发的原则,同时确保在软件系统的整个生命周期内都遵循这些原则。
从某种意义上说,为系统设计设置框架与为系统开发的项目成本和范围设置框架是相对应的。但是,项目经理有责任设置和监视该项目的范围,进度和成本。下图列出了架构设计与项目经理的区别和联系:
由于架构设计是技术专家的实践,其是技术原理的应用,即如何创建对象,发送消息,将组件部署到ECU。这意味着技术及其特性是重点。比如说,架构设计需要平衡不同质量要求特性-性能&功能安全、可维护性&可移植性以及其他。架构师还关注质量和功能-解决诸如“如何在不增加新线束的情况下通过Flexray网络启用视频传送”的挑战。最后,架构师将重点放在功能上,并确保在给定约束的情况下,汽车的电气系统可以实现该功能(例如线束的重量,ECU的数量)。 所有这些方面使软件架构看起来像是技术产品管理。
与技术管理相比,我们拥有项目管理,项目负责人运用组织理论来确定是执行敏捷还是瀑布式工作,如何协商合同或如何衡量项目进度。 在运用管理理论和组织理论时,项目领导者专注于项目的范围-解决在项目预算有限的情况下是否可以开发给定功能的问题。 项目负责人的重点是资源,平衡成本和资源与项目进度。 所有这些方面都可以看作是项目管理,而不是产品管理。
在开发同一个产品时,技术和项目管理都需要彼此合作! 汉弗莱在他的《管理技术人员:创新,团队合作和技术过程》一书中,提供了许多有关如何将这两者结合在一起的有用指导。
1.5.2 Architecting vs. Design
与将架构设计学科与项目管理学科进行对比类似,我们还可以将架构与设计进行对比。 从先前的对比中我们可以观察到,技术产品管理与设定工作原理有关。 设计的纪律就是遵循这些原则以达到最终的软件产品。 我们在下图提出了一些差异。
作为系统的技术管理的软件架构师,根据有关系统设计的原则,规则和决策,为设计设定了界限。 这种决定的一个例子是选择ECU之间的通信协议和系统中ECU的数量。 它还涉及遵循哪些标准以及原因。 就像我们将在本书中看到的那样,架构设计是一门高抽象级别的学科-考虑组件(例如,软件类组)和执行节点。 这需要对系统进行全面了解,包括软件和用于执行软件或为软件提供数据的底层硬件。 这种“系统思考”使架构师成为任何软件团队的核心部分,因为他们了解“为什么”事情发生的背景,而不是仅仅做事情。
架构学科也是非常面向文档的,因为需要传达决策,规则和原则,还需要对它们进行解释和记录,以确保规则的一致性和强制性。 这通常是在系统分析和建模过程中发生的。
相反,设计学科侧重于以软件代码或可执行模型来实现体系结构的原理,决策和规则。现在,该体系结构中讨论的高级结构是使用较低级的结构开发的,即使用类和块的组件,使用执行过程的ECU。这需要在所讨论的特定领域(例如信息娱乐或动力总成)具有专门知识和能力。设计的重点是软件实体及其与底层硬件的交互,其中经常给出硬件(或者至少在软件设计过程中给出了硬件规范)。这意味着设计专注于代码和可执行/详细模型,而不是抽象分析和建模。因此,设计是讨论测试和执行的第一个活动,而在体系结构中,我们讨论的是评价和评估(assessments and evaluations)。
与架构师和项目经理之间的合作类似,架构师需要与设计师紧密合作,以开发和交付满足所有要求和质量约束的软件系统。
以上就是100唯尔(100vr.com)小编为您介绍的关于汽车软件的知识技巧了,学习以上的【系列篇】-汽车软件架构师是如何养成的-第一章-现代汽车电子和软件发展过程中软件的历史知识,对于汽车软件的帮助都是非常大的,这也是新手学习汽修专业所需要注意的地方。如果使用100唯尔还有什么问题可以点击右侧人工服务,我们会有专业的人士来为您解答。
本站在转载文章时均注明来源出处,转载目的在于传递更多信息,未用于商业用途。如因本站的文章、图片等在内容、版权或其它方面存在问题或异议,请与本站联系(电话:0592-5551325,邮箱:help@onesoft.com.cn),本站将作妥善处理。