“ETAS汤易：基础软件怎么应对软件定义汽车的挑战”

由爱因斯坦汽车、汽车、上海车展共同主办的2021第二届软件定义汽车峰会论坛暨汽车峰会中国日4月19-21日在上海成功举办，此次论坛也是第十九届上海国际汽车工业展览会的同期活动。 这次会议邀请了etas软件工程系统总监汤易先生，在这次论坛上“在软件定义汽车时代，汽车企业有多么出色的软件开发能力，

因为我是技术出身，所以要偏向于技术，这里我想用比较短的语言介绍一下在soa的框架下如何应对软件定义汽车的课题和软件定义汽车的开发过程中遇到的问题，以及如何用soa应对。

etas和博世有点羁绊，所以我们在欧洲和国内和博世合作了很多项目。 在合作过程中一起处理技术问题，包括进行一点创新，我们与主机厂合作处理并行计算、分布式计算、自动驾驶等方面的探索，etas也是了解全球自动驾驶，包括汽车软件领域面临的动态和挑战。

对博世来说，行业内形成了一个共识，现在的电子电气结构一定有点不妥当，原因是什么？ 对于自动驾驶的高计算能力要求、高速解决的要求，包括分布式计算的要求。 现在做自动驾驶车，现在出的新车又大又有30多个传感器。 一旦输入了这么多数据，首先需要强大的计算功能，其次需要数据的融合。 如果进来了这么多数据，怎么传输？ 如何将数据从传感器传输到中央解决单元，最后由中央解决单元决定并传播到执行器。 这意味着该数据传输量在每秒gb的范围内，从以前流传下来的信号架构不能满足这种设计。

从此进入了新的话题，电子电气架构迅速发展。 本图往上是中央计算方法，现在中央计算以hbc框架为中心，下面带一点域控制或驱动器。 在中央计算中，考虑扩展性来决定能力的情况越来越多。 在照片的下面是cross-domain。 在国内，很多em都在做这件事，很多域控制都集中在原来的控制器上。 关于cross-domain将来是否会进化为中央控制器，现在还不能说。 如果将来要上云的话，hpc肯定是最好的方法，但是制作中间的方法，在技术上没什么问题。 关于l4、l5是将来的事。

soa带来的好处是提供更多的灵活性、可扩展性和更开放的体系结构，以支持软件流程中的更多事件。

让我们来看看例子。 我经常遇到这件事。 顾客说有新的功能。 这个功能可能会带来软件的变化，甚至硬件的变化。 如果是硬件变更的话，那就有点麻烦了。

首先，我们知道现在中高端的车中增加了80-100台控制器。 找个地方控制它有点麻烦。

第二，如何供电？ 包括通信接口、限速在内，有必要重新研究设计。 这与特别的工作量有关，价格也有一点挑战。

第三，软件方面。 自己改变也没关系。 如果和其他控制器一起改变，会带来这方面的挑战。 我们前段时间和国内的oem做了一个项目。 我们发现一个功能必须改变，一个更新beats必须改变。 结果，当发现这个会改变时，另一个与转向相关的控制器也必须改变。 这个诉求变更的出现花了两个月，但光是换个小软件就花了两个月。

这个多余的价格如果oem不挖出来的话，第1层就会挖出来。 这会带来麻烦的地方。 soa有什么好处呢？ 第一个方面从硬件上不说，整个车未来的硬件数量将大幅减少。 具体有几个行业正在讨论中？ 首先从减少到一半的可能性来看，可以说至少在变更方面，硬件的变更对整车、车的制造影响很小。 第二个方面对于软件来说，有hpc意味着有扩展性，意味着将来可以即插即用地放置硬件。

说到可扩展性，实际的可扩展性来源于分布式计算的要求。 我们经常看it。 常见的例子。 还是我读书的时候，大家都热衷于破解密码。 基本上黑了服务器把密码拿来了。 基本上200人以上，500人以上。 基本上早的话一周，晚的话一个月，就能得到东西。

这是it的应用，对汽车来说，我们的扩展性也可以实际应用。 例如，对于一点点的图像解决，对于一点点高精度的图像，如果解决器的计算能力不够了，就添加解决器，我们解密服务，解决的时候会变得相当快。 从整体上来说，添加硬件很方便，在硬件上部署服务也很方便，这一点很重要。 如果添加硬件写代码，这很重要。 如果基于面向服务的，我将直接部署服务(如果有以下技术软件框架) : 因为soa有自动发现的结构，所以他可以自动采用在指定的硬件上跑。

对新闻安全性进行说明。 现在，基本上每个oem都在做这件事。 我们以前和很多顾客有点解体。 新闻安全的话，我们要开发车身的话，我们至少要考虑三四层，但是soa谈三层。

第一，ecu等级

第二，内部通信

第三，外部通信；

之所以分成这些层，是因为道理很简单，防止在某一点上被突破而全面崩溃，做好多层防御，就像战争一样，至少外层破裂，有内层。

我们从里面往外看，欧盟保护APP安全很重要。 除此之外，如果想要更好的主机入侵检测方案( ids )，这首要的是防止恶意文件的读写。 这样做需要对操作系统进行很多改进，还需要对文件系统进行监控管理。 另外，例如通信的监视是由主机ids进行的。

说起来主机，互联网层为了防止内部通信，基本上根据基于流量的保护，防止新闻的篡改、非法注入是最重要的。 这对it来说做得比较好。 无论是基于流量还是基于状态，其实都做得很好。 对汽车来说是理所当然的，实施起来并不特别困难。

再往上走就有系统水平了。 系统级保护要做什么？ 首先是分段。 对于整车系统来说，我可以考虑把这些ecu或者这些预先控制，节点分成不同的子网。 有些子网是我直接连接的外部。 我们放在公共区域，我们保护什么？ 必须做好防止防火墙之类黑客攻击的防护。 除了公共区域外，中间还有一点中间区域。 中间区域是正常整车互联网的节点，它实际上是维持一辆车正常工作所需的保证，对其安全保护采取一点一般措施即可。 在某些情况下，可以进行一些重要的软件保护。 在私人区域的情况下，越来越多的情况下，我是说对私人区域的入侵检测进行防御。 基于这三个不同的区域制定三个不同的安全策略。 这是我们在软件定义汽车中必须思考的一点事件。

那么为什么soa容易实施呢？ soa有其特点，所有服务之间形成服务总线。 这个服务总线是虚拟的总线，就像以前流传的autosar的vfd一样。 但是，它们之间有差异，可以设置安全策略等属性。 安全策略允许您定义上述安全框架。 该安全框架包括访问服务、管理包括服务招聘者。 我们也可以借鉴it的技术和知识，严格管制。

举个简单的例子，如果要进行管制，就要设置第三方认证服务器。 要注册所有新服务，必须向认证服务器申请证书。 如果有证书的话，将来会在汽车网内和招聘者进行通信。 如果持有该证书，对招聘者来说也可以验证提供服务的人是否合法。 对于招聘者来说，也防止突然进入的招聘服务app。 有可能不正当，也需要向第三方服务进行验证。 虽然这是一个简单的实现方法，但它还有另外的日志管理。 这个模型是服务总线所需要的。 除此之外，还可以设置其他安全策略。 另外，还可以监视入侵和异常模式。 服务巴士知道车上有那些服务，所以一旦发生异常马上就会知道。 计划此模型时，将在第一时间向相关的ids节点报告。

我刚才提到了基于公共区域的防火墙的部署，除此之外，我们还在考虑部署分布式ids。 它是如何工作的？ 从体系结构上看，云有后台。 在后台，进行一点模式的供给检查是首要的，如制定新的服务战略和软件更新等。 中间的云状部分是异常攻击的报告中心，该中心汇总来自不同节点的入侵数据，评估大致的攻击模式，这些消息可以过滤。 最终，在以下各ecu中导入ids的ecu。 通常，要解决逻辑，请在以下各ecu获取相关的入侵异常，并向云报告。 最后，云被发送到后台。 后台将收集分散在这两个车布局中的所有ids数据，进行评估，更新策略，然后分发到所有控制器。 这样做的好处是，可以保证车上部署了所有的入侵检测系统，并采用了相同的安全战略。

关于功能安全，就分散而言，当然不能绕开功能安全。 分布式系统存在许多瓶颈，首先是硬件资源，不能无限扩展； 其次，通信带宽受到限制。 对soa来说，我们不能处理这个问题，但它有附加问题，对服务有响应性。 我们知道，对系统来说，不容易评估服务长期不响应是因为服务失效，还是因为服务本身响应慢。 我记得几年前去12306取票的时候，基本上一到正月页就不动了。 这对汽车也一样，我们在运行中怎么知道服务？ 特别是远程服务没有响应是什么状态？ 我怎么遵守这个状态？

有人说打开计时器，这在独立版的情况下没问题，但在分布式系统的情况下，计时器最终会成为统计数据。 超时后，根据状态进行变更，最后制作表。 好的方法是制造冗余性。 双模冗余类似于同步机制。 我把同样的服务放在不同的ecu，像最后出来的结果一样高兴。 出来的是一个人没有回应，一个人回应，因为至少还有一个人活着，所以可以采用它。 三模也一样。 只增加了一个模块，就形成了投票机制。 如果三个人有两个一样的话，就用两个一样的。 但是，三态模式有问题。 睡眠模式可以应对偶然的风险和失效，但不能应对系统风险。 对于三模来说，我们在里面摆不同的衣服，达到不同目的的衣服在里面跑，最后做评价。

接下来是对APP的影响，每个APP都是关闭的空之间包含自己的函数和私有数据。 作为这个时候的APP，我如果需要不同APP中的数据，这个时候想做APP开放开发的人就会给他开放接口。 虽然APP可能由其他供应商制作，但这又是诉求变更。 soa的利益是可以打破框架，开放所有的服务。 结果，在检索数据时变得更简单。

还有架构问题。 图中的康威定律是组织架构的信息表示方法会影响系统设计。 右侧是几个不同的it企业的总结构是如何决定的，为什么苹果是点状的？ 为什么脸书是网状的？ 因为那些软件系统是这样决定的，所以软件系统反而会影响组织结构。 现在，让我们基于旧的框架来看看每个oem都有哪些动力组件、智能网、机箱等。 这个部门里有人在做同样的事件。 例如诊断开发、通信运转等。 如果要遵循新的soa模型，最好的方法就是将它们抽象化，合并成一个组织。 这样的话，如果将整体的信息表现方法作为一种服务的话，效率会更高。

etas是autosar的提供者，在autosar中，aracom定义了soa框架。 现在，soa支持smap、dds、ips、signal pdu四种模式，这里大部分用于通信。

这个怎么实施？ 在这里，我们只进行两种绑定:语言绑定和互联网绑定。 语言绑定对c++要求开发者使用c +。 关于互联网绑定，就是我刚才提到的三种互联网。 对软件体系结构本身来说，其机制有助于软件开发APP应用程序无缝开发，无需担心接下来使用的互联网体系结构。

介绍一下etas的实现，我们宣传的产品叫做vrte，可以在工具中描述服务接口，描述后可以生成所有的soa框架 框架中包含proxy、skeleton等不同的服务实现模式，采用框架间的通信也符合csa的标准，etas的整个产品都符合csa

最后谈谈产品吧。 这个产品在将来进行adas相关开发时可能不可或缺。 将来，一个软件完成后，在我们实际上车之前，要对它进行大量的虚拟化测试。 所有场景都可以加载，我们可以在一个平台上虚拟化所有场景、所有软件和模型。 我们有防火墙、vtx、hsm等加密手段的完美解决方案。

最后总结一下，软件定义汽车确实是一个快速的发展趋势，对目标soa来说，软件定义汽车是一种非常有效的信息表达方法，我们对整个soa有了很好的知识框架，和国内的同事一起更好地了解了这一部分

etas在这次大会上度过了越来越多美好的时刻: