Hi,欢迎来到东北汽车配件网

ETAS汤易:基础软件如何应对软件定义汽车的挑战

   日期:2021-04-28     浏览:29    评论:0    
核心提示:由盖世汽车、AUTOSAR组织、上海车展联合主办的2021第二届软件定义汽车高峰论坛暨AUTOSAR中国日4月19-21在上海成功举办,本次论坛

由盖世汽车、AUTOSAR组织、上海车展联合主办的2021第二届软件定义汽车高峰论坛暨AUTOSAR中国日4月19-21在上海成功举办,本次论坛也是第十九届上海国际汽车工业展览会的同期活动。本次会议邀请到了ETAS软件工程系统总监汤易先生在本次论坛进行了题为《软件定义汽车时代,车企如何打造卓越软件开发能力》的主题演讲,以下是他在本次演讲的主要内容:

ETAS汤易:基础软件如何应对软件定义汽车的挑战

我是技术出身,所以讲的偏技术一点,在此希望用比较简短的语言给大家介绍一下我们在SOA框架下如何应对软件定义汽车方面的挑战或者软件定义汽车开发过程中碰到的问题,怎么通过SOA解决这些问题。

因为ETAS跟博世有一些纽带关系,所以我们在欧洲和国内跟博世有很多项目合作。合作过程中一起解决技术问题,包括做一些创新,我们还跟主机厂合作解决并行计算、分布式计算、自动驾驶等等方面的探索,ETAS也是了解全球自动驾驶,包括汽车软件行业面临的动态和挑战。

对于博世来说,业内形成了一个共识,现在的电子电气架构肯定是有些不合时宜的,原因是什么?对于自动驾驶所带来的高算力要求、高速处理要求,包括分布式计算要求。现在做一个自动驾驶汽车,现在出来的新车大概有30多个传感器,这么多的数据进来首先就需要很强的计算功能,其次需要数据融合。这么多数据进来怎么传输?怎么把数据从传感器传输到中央处理单元,最后中央处理单元决策后传递到执行机构。这个数据传输量是在GB每秒的范畴,意味着传统信号架构没有办法满足这个设计。

ETAS汤易:基础软件如何应对软件定义汽车的挑战

从此进入了新的话题,电子电气架构发展模式。这个图往上走是中央计算方式,现在中央计算是围绕HBC架构,下面带一些域控或者执行机构。对于中央计算来说,更多的是考虑扩展性,决策能力。图下面是Cross-domain,国内有很多EM在做这个事,把很多域控从原来的控制器集中,至于Cross-domain将来会不会演化成中央控制器的方案,现在还不好说。如果将来上云,那HPC肯定是最好的方式,但做一个中间方式,从技术上来说没有太大的问题,至于L4、L5是将来的事。

SOA带来的好处是能够提供更多的灵活性、可扩展性及更开放的架构,帮助大家在软件过程中做更多的事情。

我们看一个案例,我经常碰到这个事,客户说有一个新功能,这个功能有可能会带来软件的改变,甚至硬件的改变。如果是硬件的改变,那会稍微的麻烦一点。

ETAS汤易:基础软件如何应对软件定义汽车的挑战

首先,大家知道现在一台中高端的车里面80-100个控制器甚至更多,你要找一个地方来放控制其有点麻烦。

第二,怎么供电?通信接口,包括限速设计要重新改一下,这会涉及到格外的工作量,还有成本带来一些挑战。

第三,软件方面。你自己改也还好,涉及到其他的控制器一块改,就会带来这方面的挑战。我们前段时间有一个项目,也是跟国内一个OEM做。我们发现有一个功能要改,要改一个update beats,结果发现这个要改的时候,另外一个跟转向相关的控制器也要改。这个需求变更改动出来用了两个月的时间,仅仅是改一个小小的小软件,用了两个月的时间。

这个额外的成本如果OEM不掏那就Tier 1来掏,这就会带来一个很麻烦的地方。那SOA会有什么好处呢?第一方面从硬件上面不说了,整个车将来的硬件数量会大大减少,具体有多少个业内还在探讨。先看能减到一半的可能性,至少说从改动方面来讲硬件的改动对整车、造车的影响会比较少。第二方面,对于软件方面来说,有HPC就意味着有扩展性,意味着将来放一个硬件过来能做到即插即用。

ETAS汤易:基础软件如何应对软件定义汽车的挑战

讲到扩展性,其实扩展性来自于分布式计算的要求。我们在IT看得比较多,一个比较常见的案例,还是我读书的时候,大家比较热衷于去破解密码,基本上黑了一个服务器把密码拿过来,基本上都是200多位、500多位。基本上的话快的话一周,慢的话一个月,还是能弄点东西出来的。

这个是IT的应用,对于汽车来讲我们扩展性其实也可以用起来,比如说对于一些图象处理,对于一些比较高精度的图像来说,如果处理器算力不够了,加一个处理器进去,我们把服务破解进去,处理的时候会快很多,整个对于扩展性来讲,加硬件方便,在硬件上面部署服务很方便,这个是很关键的,如果说加一个硬件还要写代码,重新把整个基础软件到应用层再搭一遍,这个效率不高。如果是基于面向服务,我只要有一个下面的技术软件框架,我有硬件上去的话直接把服务部署上去,因为SOA有自动发现的机制,他自动能录用到指定的硬件上面去跑。

ETAS汤易:基础软件如何应对软件定义汽车的挑战

下面讲信息安全,现在基本上每家OEM都在做这个事,我们之前跟很多客户做一些分析,信息安全的话如果我们去做一个车辆体的开发,我们至少要考虑三四层,但SOA谈三层。

第一,ECU层级;

第二,内部通信;

第三,外部通信;

之所以分成这几层,道理很简单,我防止在某一个点的时候被攻破了,导致全盘的崩溃,做多层的防御,像打仗一样,至少说外层破了,还有内层。

我们从里面往外看,ECU比较重要是保护应用程序的安全。除此之外的话如果想做得更好一点可以做主机入侵检测方案(IDS),这个主要是防一些恶意的读写文件。我们做这个就需要操作系统做很多改善,我们需要做文件系统的监控管理,还有其他的比如说通信的监控都是主机IDS要做的事。

说完主机我们说网络层,因为是防止内部通信,所以基本上就是按照基于流量的保护,主要防止信息篡改,非法注入。这块来说对于IT来讲是做得比较好,不管是基于流量还是状态的,其实这一块做得都不错,对于汽车这一块道理很好讲,实施起来也不是特别难。

再往上走有一个系统级,系统级的保护我们要做什么事呢?首先就是分段,对于整车系统来讲的话,我可以考虑我把这些ECU或者把这些预控、节点分成不同的子网,有的子网我是直接连的外部,我们放在公共区域,我们做什么保护呢?我们要做一些防止黑客攻击的防护,比如说防火墙。除了公共区之外,中间还有有一些中间区,中间区域就是正常一些整车的网络的结点,它其实维护一台车正常工作必要的保证,对它的安全保护采取一些通常的措施就行了。有的情况下做一些关键的软件保护都可以,对于私有区来讲的话,更多的时候在于说我对于私有区入侵检测的防御,根据这三个不同的区域,制定三种不同的安全策略,这是我们在软件定义汽车里面我们要去考虑的一些事情。

ETAS汤易:基础软件如何应对软件定义汽车的挑战

那为什么SOA比较容易实施?SOA有一个特性,它会在所有的服务中间形成服务总线,这个服务总线是虚拟的总线,类似传统的autosar里的VFD。但它有一个区别,在上面可以制定一些属性,比如安全策略。对于安全策略来讲,可以在上面定义安全框架,这个安全框架包括对于进入服务,包括服务使用者做一些管控。我们也可以参考IT方面的技术和知识,你可以把管控做的很严格。

简单例子,如果你要做管控,你放一个第三方验证服务器,所有注册进来的新服务需要验证服务是否合法,这个服务需要向验证服务器申请证书,有了证书将来在汽车网络内跟使用者通信,我把这个证书带上去,那么对使用者来说也可以验证提供服务的人是否合法。对于使用者来说也是,我要防止突然进来的使用服务APP,它有可能是非法的,它也需要向第三方服务器验证。这是很简单的实施方式,除此之外还有一些日志管理,这个模式对于服务总线来说是很必要的东西。在这个之上它可以配置一些其它的安全策略,它还可以做一些入侵或者异常模式监控,在上面做会容易一点,因为服务总线知道车上有哪些服务,一旦出现异常第一时间就会知道。如果你规划了这个模式,它在第一时间就会上报给相关的IDS节点。

ETAS汤易:基础软件如何应对软件定义汽车的挑战

我刚才讲到基于公共区防火墙部署,除此之外我们也考虑部署分布式的IDS,它是怎么作用的呢?从架构上来讲,它在云端有一个后台,后台主要是做一些模式类型的供给检测,包括制定新的服务策略及软件更新。中间云状部分是异常攻击的汇报中心,这个中心会从不同节点过来的入侵数据进行汇总,判断大致的攻击模式,有哪些信息可以过滤掉。最终是下面每个部署IDS的ECU,正常处理逻辑是下方每个ECU上获得相关的入侵异常,然后上报云端,最后云端会发到后台。后台会收集所有这两车上布局分布式IDS的数据,它会做一个判断,更新策略,然后下发到所有的控制器中。这样有一个好处,它可以保证车上所有部署了入侵检测系统使用的是同一个安全策略。

ETAS汤易:基础软件如何应对软件定义汽车的挑战

关于功能安全,谈到分布式,自然绕不开功能安全。分布式系统有很多瓶颈,首先是硬件资源,它不能无限扩张;其次它的通信带宽受限。对于SOA来讲我们解决不了这个问题,但它有额外的问题,对于服务的响应性。我们都知道对于一个系统来讲很难判断一个服务长时间不响应是因为服务失效,还是服务本身响应慢。记得几年前我去12306抢票的时候,基本上一到过年页面就不动。这对于汽车也一样,我们在运行过程中怎么知道服务,特别是远程服务不响应是什么样的状态,我怎么保护这种状态。

有人会讲加入定时器,这对于单机版的没有问题,但对于分布式的系统,定时器最后变成了统计数据。超时了就根据不同状态改一改,最后弄一个表出来。比较好的方式是做冗余,双模冗余跟同步机制很像,我把相同服务放在不同的ECU上,最后跑出来结果一样皆大欢喜,跑出来有一个没响应,一个响应了,那至少还有一个活着,所以可以使用那个。三模也是一样,无非是多了一个模数,相当于做了一个投票机制,三个人两个一样,那就用两个一样的。但三模有一个问题,三模可以解决偶发性的风险或者失效,但解决不了系统风险。对于三模来讲,我们在里面摆不同的服,达到不同目的不同的服在里面跑,最后做判断。

ETAS汤易:基础软件如何应对软件定义汽车的挑战

接下来是对应用程序的影响,每个应用程序都是封闭的空间,里面有自己的函数和私有的数据。如果这时候作为应用,我需要不同应用程序里面的数据,那么这时候想做App开放开发的人向他开放接口。有的时候App是另外一家供应商做的,那又是一个需求变更。SOA的好处是可以把框架打破,把所有的服务Open出来,结果是获得数据的时候会变的更加容易。

ETAS汤易:基础软件如何应对软件定义汽车的挑战

还有架构的问题,图中康威定律是组织架构的沟通方式会影响系统设计。右边是几个不同IT公司总架构怎么定的,为什么苹果是点状的?为什么Facebook是网状?因为它们的软件系统就是这么定的,软件系统反过来会影响组织架构。我们看一下目前基于老架构,每个OEM有什么动力总成部、智能网联、底盘部等等。这个部门里面有一部分人在做同样的事情,比如诊断开发、通信开等等。如果按照新的SOA模式,最好的方式就是把这些抽象出来,合并成一个组织,这样整体的沟通方式如果做成一个服务,效率会更高一些。

ETAS汤易:基础软件如何应对软件定义汽车的挑战

ETAS作为AUTOSAR的供应商,AUTOSAR里面aracom定义了SOA框架,目前它在SOA里面支持四种模式,SMAP、DDS、IPS和Signal PDU,这里大部分是用来做通信。

ETAS汤易:基础软件如何应对软件定义汽车的挑战

那这个怎么实施呢?在这里面只做的两个绑定,一个是语言绑定,一个是网络绑定。语言绑定是对于C++,要求开发者用C++。关于网络绑定是刚才提到的三种网络。对于软件架构本身来讲,它的机制能够帮助软件开发应用者无缝开发,不用担心下面用的哪种网络架构。

ETAS汤易:基础软件如何应对软件定义汽车的挑战

讲一下ETAS的实施,我们的产品叫VRTE,它可以在工具里面对服务接口做描述,描述之后可以生成相关所有的SOA框架,框架里面包括了Proxy、Skeleton这些不同服务实现模式,使用框架之间的通信也是满足CSA的标准,ETAS整个产品都是按照相关规范来做。

ETAS汤易:基础软件如何应对软件定义汽车的挑战

最后讲一下产品,这个产品有可能是将来做Adas相关开发不可少的。将来一个软件做完之后我们真正上车之前,对它做大量的虚拟化的测试,所有的场景都是可以去载入,我们通过一个平台可以虚拟化所有的场景,所有的软件,模型。安全这边的话,我们有完整的解决方案,从防火墙、VTX,HSM这些的加密手段。

我最后概括一下,软件定义汽车是很明确的发展趋势,对象SOA来讲的话是软件定义汽车非常有效的沟通方式,我们对于整个的SOA有非常的知识框架,我们希望和国内的同仁一起能够把这一块做得更好一点。

ETAS在本次大会的更多精彩瞬间:

ETAS汤易:基础软件如何应对软件定义汽车的挑战

ETAS汤易:基础软件如何应对软件定义汽车的挑战


 
打赏
 
更多>同类资讯
0相关评论

  • 深圳市德平国瀚汽车电子科技有限公司
  • 南京超旭节能科技有限公司
  • 泰安市欧美瑞进出口贸易有限公司
  • 霸州市铁奇电气技术有限公司
  • 福建兴瑞阳机电科技有限公司
  • 泰州市瑞腾幕墙配件有限公司
  • 河南省中翔物资贸易有限公司
  • 开平市龙胜镇江丰橡胶厂
  • 林州市长宏矿业设备厂
  • 亿煤机械装备制造有限公司
  • 青州宝睿机械有限公司
  • 邯郸市安旬金属制品有限公司