“博世张人杰：Autosar在面向服务架构中的支持与应用”

由格斯坦汽车、汽车公司、上海车展三方共同主办的sdvf2021第二届软件定义汽车峰会论坛暨autosar2021中国将于4月19-21日在上海举行，此次活动也将是2021上海车展的同步活动 此次会议邀请了博世工程技术服务有限企业电子电气架构工程师张人杰先生[/S2// ]，并在本次论坛上发表了

你好。 感谢Gaishi汽车和中国的autosar为我们准备了这样的交流平台。 并且，感谢autosar组织给我这个机会。 这里介绍了autosar在面向服务的体系结构中的支持和应用。 我今天共享了的几个副本。 分别是未来的移动愿景、博世电子电气架构的开发流程、autosar是如何为实现和支持服务架构进行比较的？

众所周知，在新的全球科技革命和产业变革下，互联化、定制化、自动化、电动化成为汽车产业的趋势。 在这四个现代化中，受政策和环境的影响，电动化已经成为最先进的布局方面，但随着远程信息技术自动驾驶的融合，汽车的功能也更加多样化，定制的汽车功能也成为衡量汽车质量的标准之一。 总之，电动化已成为未来出行的基本要求，互联化、自动驾驶、定制化带来的智能出行成为我们对未来出行的美好期待。

随着对四化的理解和落地，我们发现汽车产业需要更先进的架构、更强大的硬件和更丰富的软件。 目前，汽车产业随着软件功能数量的增加，软件周期迭代缓慢，价格不断上涨。 另外，由于我们的电子电气架构还以分布式ecu为中心，软件数量在上升，硬件数量也在逐渐上升。 对oem来说，包括对供应商的限制在内，硬件购买价格正在上涨。 此外，网络安全也成为最终话题。 就是汽车产业的开发价格上升。

随着新“四化”带来的美好构想，汽车需要更强大的架构、硬件、软件的加持。 但是，让我们回顾一下过去流传下来的汽车工业设计开发过程。 汽车功能数量增加，功能增加，复杂导致功能开发周期过长，硬件数量激增导致电子设备架构增加，复杂度急剧上升，汽车互联带来的新闻安全和功能安全考虑增加，重量、通信负荷、能源 另外，客户需要更好的客户体验，面临跨域功能的多种协作挑战。 所有这些都造成了核心问题——汽车设计开发生产价格的上涨。 毕竟，汽车作为一种商品，如何能同时实现四个现代化，并提供高性价比的汽车成为了oem的考虑事项。 软件定义汽车、面向服务的体系结构的提出是为了能够应对以上问题。 在面向服务的体系结构中，soa解决了软件开发迭代周期过长的问题，推动了体系结构从分布式ecu向基于高性能计算平台的域集中型转型。 软件定义汽车强调了软件的重要性，也强调了autosar的必要性。

让我们来看看博世对软件定义汽车结构的理解。 首先分成两端，一个是车端，另一个是云。 车端包括云实现的汽车服务和平台服务、博世iot服务。 从车的边缘可以看出，分为硬件和软件两个部件。 再加上上面所有级别都是按软件分类的，所以软件的重要性得到了强调。 再往上一层是硬件虚拟化和硬件抽象层，这个层对下层硬件进行抽象和虚拟化是为了向操作系统提供硬件调用，也是不同的操作系统共享相同的硬件 在支持的操作系统中，也有大家熟知的osek。 当然还有性能更高的linux、安卓和qnx。 上面有与autosar相关的协议、中间件和基础软件。 这一层正焕发出autosar的异彩，而供应商和oem则降低了软件开发的复杂性，提高了软件的通用性。 再往上就是APP应用层和接口层，可以看到博世在软件定义层面将汽车分为几个层面。 从另一个维度来看，从分布式控制器到域集中控制器，从电子电器的角度来看，有什么能力呢？

博世的汽车电子和软件包括汽车电子、动力、自动驾驶、驾驶辅助、车载多媒体和软件体系结构。 车身电子包括网关、中央控制器、域控制器、车身控制单元、直流/直流转换器。 电力电子包括vcu-plus，自动驾驶和驾驶辅助包括各种传感器、dasy、vmc等。 车载多媒体包括显示器、娱乐等汽车电子产品。 另一方面，软件方面有基于早期cp开发的cubas基础软件，应用于esc、ebooster、radar等多种控制器，目前是基于ap开发的，与cp兼容的vrte ( vehite， 这些都构成了博世汽车的跨域汽车电子软件。 并且，依托这些宝贵的产品和经验，eea的设计更加丰富全面，跨域功能设计更加合理。

博世有这样的经验和技术，那么在平时的e/e中，如何实现更好的布局和域间接口的设计呢？ / S2///S2 /博世的体系结构设计过程是基于/ S2// S2// MBSE /S2/]模型的系统工程的设计方法，但是 根据场景对客户的诉求进行用例分解，从而获得客户功能的模型包括客户功能之间的交互界面。 当前的客户功能是黑匣子模式，例如客户打开 TCS-off [/S2// ]功能，将内部逻辑分解为白匣子后进行系统 如果细分为TCS-off，则变为键的功能诉求、转矩控制的功能诉求等。 如果将这些功能配置在适当的域中，则会被分类为物理钥匙、软开关等各种域(车身和娱乐)，通过分配与分配了的部件相对应的诉求，向oem和供应商提供部件

这是因为我们博世对于整车电子电气结构的开发方法，无论是面向功能结构还是服务结构，这种开发方法都能够应对这些场景。

其实未来的e/e架构主要分为两个方面，这个快速发展趋势图很明显，第一是硬件的减少和功能的提高，随着硬件的减少和功能的提高，但实际上软件并没有减少，反而会更多。

目前，汽车领域的e/e架构仍然是分布式ecu、ecu分布式的，cp为ecu控制器服务。 它所能解决的问题是实现了软硬件的解耦，提供了统一的标准，提高了软件的通用性。 随着基于高性能预算平台的域集中式或中央计算平台体系结构的出现，不仅在ecu上，而且在以前的计算平台上，都有不同的操作系统和大量的APP软件 操作系统和APP软件之间是如何断开连接的？ 一个中间件的实现是必要的，如果不能解耦，不同的操作系统可能会开发几十个应该应用的东西，要实现解耦就需要中间件的实现。 中间件的出现一方面抽象和利用下层的硬件资源，另一方面为提供上层ecu服务(包括诊断服务、控制器和高性能计算平台)的接口提供软件开发。

这也是soa处理的中心问题，即如何实现APP开发和e/e架构的解耦，减少软件工作量，减少互联网接口配置的工作量。 实现这些硬件层、中间层、APP层的去耦，在它们因组件不同而迭代周期不同的情况下，APP应用层软件的迭代周期会变得迅速，可以丰富对定制的要求。 我发现这也随着问题的到来，各阶层之间分得很清楚。 我们可以和cp类比，区分硬件层和软件层。 它的cp规定硬件层和软件层有统一的标准、统一的接口。 这三个级别也是分层的，那么中间件作为从上到下的部件，是否需要标准来实现接口的标准化呢？ 与之相伴，自适应autosar为帮助中间件的开发提供了非常详细的标准、完整的规格。

博世关于汽车计算机的体系结构也分为三层:硬件层、APP应用层和中间层。 那么，如何基于autosar进行中间层的开发呢？ 我把这个分成三个步骤。 第一步是隔离中间件功能，分为硬件抽象层、操作系统接口层、服务中间件层、ecu平台服务层、整车平台服务层。 再下面，基于已经成功分层的中间层结构，包括功能集群的分布，基于autosar功能模块，将不同的功能集中到不同的层次上进行研究是合理的。 这样的好处是因为我们知道autosar的版本经常发生变化。 例如，以前的s2s版本作为单独的服务，但在最近的版本中集成到了通信管理中。 分层和模块化开发可以更快地比较autosar的更改。 重新集合模块并将其打包。 我们基于这种软件的模块进行了具体的设计和开发，得到了我们宣传的产品vrte。 提供支持autosar的中间件，也支持经典的autosar。 它支持多个操作系统，还支持加密第三方软件的集成和多功能域的集成。 另外，博世中间件不仅是软件的模块，还集成了开发工具包，支持上层APP的开发。

可以看到博世软件的层次是这样的8层，中间的5层主要是中间层。 第一层硬件抽象层，它和cp做同样的工作，是统一硬件设备接口解决的。 的实现方法大家都不同，但接口标准相同。 第2层是操作系统的接口层，包含各种通信的协议栈。 第3层是面向服务的通信中间件，如通信管理。 第四层是ecu平台服务，是原子级服务。 提取下层ecu提供的服务，作为ecu平台服务提供给上层整车层进行开发。 整车层按原子服务集聚集，根据服务集进行上层更高级的APP研发。 它还提供了保护域的功能。 例如，在基础设施保护方面，我们通过划分安全域和管理流程来保护操作系统和软件的安全。 此外，在共享通信的情况下，例如通过流量检测等功能来保护安全。

虽然在APP应用层的保护方面会对功能安全进行说明，但实际上功能安全的第一解体还是要看各个功能安全目标，如果这个应用功能安全水平非常确定之后，我们就会把它运行在域控制器上。 这就是软件中间层包含的功能和拷贝。

说到中间层，可以基于adaptiveautosar进行开发，但中间件是实现soa面向服务开发所需的组件，其目的是减少软件的耦合度，更新软件的开发周期。 那么，APP应用层进行开发时，如何实现相互独立开发，开发过程包括什么，如何利用中间件接口进行配置和开发呢？

首先，基于对象硬件OS的选择qnx、linux、androidy，我们也选择了对应的开发工具momentics、eclipse、adaptivestudio等之后，在项目包中第一分为三个部分 端口的定义，关于底层中间件平台的服务调用静态代码其实是逻辑代码，configuration是编辑通信实例。 我们通过生成技术生成APP，APP包含两种文件。 一个是c +。 因为autosar需要c +作为唯一的代码语言。 APP的设计也生成proxy和skeleton码，留下这些api和互联网，路由通过APP进行配置。

具体编译时，无论即将运行的OS的种类如何，结构整体都是一致的，但在编译时，可以根据系统执行的对象OS，比较采用该编译器。 如果是在qnx上运行的话，可能会使用qcc，如果是linux的话，可能会使用gcc编译器。 这样你就会得到整个APP的APP。 整个app APP应用程序包含可执行文件和中间层配置文件。

其实这一套实现了APP应用层软件和中间件开发的分离。 因为有autosar统一接口和标准，所以我们之前的配置、内容的拷贝都是一样的。 无论什么样的操作系统，只要对编译进行选项调整，就可以得到一个APP。

随着面向服务的体系结构和中间件的出现，以往的商业模式(合作方法)也发生了变化，第一是博世提供了一整套。 渐渐地，我们开始提供硬件和中间件。 可以通过中间件集成端口接口、第三方oem和第三方供应商进行APP开发。 当然，也只有博世可以提供中间件。 硬件和APP由第三方开发。 当然，也可以基于博世的中间件进行二次开发。 基于二次开发的中间件，无论是采用第三方硬件还是博世硬件，都可以进行APP开发。 中间件可以说是处理soa面向服务的体系结构的关键。

总而言之，四化已成为汽车的趋势，但都很沉重，路途遥远，还有很多路要走。 面向soa服务的体系结构帮助我们的软件定义了汽车的实现。 autosar还帮助soa提供了非常确定的中间件开发诉求和标准。 在软件定义汽车的时代，各oem和供应商之间在软件开发方面的投入越来越大，希望将来能得到更深层次的合作。

这次向大家介绍博世在大会上的精彩瞬间。