汽车电子EEA新架构下软件技术及趋势

  人生没有最优解，我们大家可以有多种活法，拒绝自我设限。加入本知识星球可以拓展您的圈层，打破您的认知边界，链接到4W+的汽车赛道“局内人”，交换职场信息，打破职场信息差，遇见同行伙伴，共同探索技术交流和职业发展。

  车内的行驶电脑需要和IT后端的数字服务系统连接，通过V2X与基础设施及其他车辆建立起低延时的无线通信以获取外界环境的信息，中央电脑将这些路线信息和车辆传感器获取的周边数据汇总在一起，最后经处理后显示在用户高度定制化的大屏上。

  这些看似平常的功能，实际上需要一个很先进的车辆架构来支撑。而且要想将这些功能的使用者真实的体验逐步提升至极致，更需要强大的软件技术作为后盾。

  更让人意外的是，车辆新架构的革新带来的影响不仅限于技术层面，更是撬动了经久沉淀的组织架构划分，以及项目执行层面固有的标准流程。

  如图1所示，从汽车系统软件工程的角度，大致上可以分为现代嵌入式系统，云计算技术，分布式计算，实时系统，混合安全(Safety & Security)系统。在新架构下，这样一些方面有着技术方面的创新。仔细琢磨的话，会发现这些创新点多少投射出互联网领域IT技术的影子。

  现在很多车企都实施数字化转型，其原因是车联网，移动空间，无人驾驶这些都让汽车趋向于数字化消费品。而数字化消费品的特点是产品迭代速度快。

  那怎样才能跟上快速的产品迭代速度呢，数字化转型实际上就是要解决这一个问题。它将从企业产品研制，制造，运维各环节通过数字化技术打通，从而加快产品创新与生产效率。这也是未来企业具有竞争力的关键因素。

  以往设计某个功能模块，典型的方法就是是将产品功能映射到独立的软件系统和物理硬件，这种设计会导致一个问题，在产品复杂性达到一个限值后，将会变得难以维护，现有一些豪华车型动则上百的ECU，带来的影响除了软件开发太过复杂外，光是要把这些ECU布置到车内，留出足够安装这些ECU的空间就是一个很大的难题。这就急需一种新的架构，来改善这种现状。

  而另一方面促使架构进化的，就是对新功能的强烈需求。对于新增功能，往往要加更多的传感器，但毕竟车内的信息是有极限的，要突破信息的局限性，必须要和外部基础设施互连，以及利于面向服务的架构（SOA），与IT主干网，与云端互联，实现与车辆间通信。

  基于这些原因，面向服务的架构顺势推出，传统的功能拆分和部署将被面向服务的架构和交付模式所取代。

  面向服务的软件架构变革将是一个持续的过程，在面向服务的架构之下，以往以功能绑定某个硬件的情况将发生改变，随之而来的是硬件的平台化，通用化发展，即硬件上能随意部署软件模块，实现硬件和软件的彻底解耦。

  企业敏捷转型体现的是对于产品功能快速迭代的应对措施，敏捷方法除了允许软件的迭代开发，也同时允许需求的迭代开发。敏捷服务交付模型结合了DevOps，微服务，云解决方案。功能迭代方面优于传统V模型开发模式。

  虽然敏捷开发有很多优点，但同时也会面临很多挑战，因为它并不是在所有使用场景下都是最适合的，比如架构设计开发。

  在传统Vmodel中，架构设计工作是非常规范化，集中化，并且明确的。而在Agile方法中，工作指示更具描述性，并分配给多个独立的敏捷团队。使得架构工作变得更分散，难以集中化管理。这也是我们在敏捷转型中需要去适应和改进的。

  以上我们从宏观角度分析了汽车行业经历的变化，在这样的背景下，又有哪些软件技术呢。我们先来看看什么是软件架构。

  当我们谈架构，除了去看一个物体的外在特征，更多的是了解它的设计过程。通常情况下，系统越大，就越难了解其功能，子系统，组件和模块的概览。所以我们应该一套科学的架构方法去描述设计的过程。

  对于软件架构而言，可以认为它要以一个高层次的设计视角，综合多方面的视图去全方面展现一个软件系统的设计。软件架构大多数情况下是指软件系统的高层结构，由这些结构来解释软件系统，和创建此类结构的原则以及这些结构的文档。它的意义在于项目团队基于软件架构可以互相交流，对于整个软件系统功能设计做出技术上的决策。

  功能视图，功能视图通常也称为功能架构，这类视图的重点是描述车辆的功能及其相互依赖关系

  物理系统视图，通常将其描绘为整个电气系统的顶层视图，并附有底层网络拓扑示意图。

  系统逻辑视图更专注于对软件层面的描述。在逻辑视图中，通常会展示软件中使用了哪些类，模块和组件，以及它们之间的相互关系。 用于此模型的符号通常是UML

  （三）在软件设计中，有很多种样式，但是在汽车系统中，我们只可以看到其中一些，因为和Web服务器相比，汽车软件对可靠性和鲁棒性的要求更高。因此，某些架构式样不适用。这里我们举例说明一些汽车软件使用的架构式样。如图4。

  分层架构。这种架构风格假定系统的组件放置在彼此之上的层次结构中，彼此之间进行函数API调用。CP AUTOSAR就是典型的分层架构。CP AUTOSAR的分层结构展现的是十分清晰的应用层，通信层，MCU抽象层。这种分层方式是对于软件组件功能范畴大框架的分层，在每个层次内部，也存在着一定的软件组件功能分层。例如无人驾驶功能设计，有较高的层负责任务/路线规划的软件组件层，而较低的层负责操作汽车的执行器。

  面向服务的架构式样假定使用基于Internet的协议来松散组件之间的耦合。架构式样强调可作为Web服务访问的接口。这里的服务可以在系统运行时按需添加和更改。在汽车软件设计中，这种架构样式正在开始流行，也制定了相应的服务架构标准来支持这种架构式样，例如制定了AUTOSAR服务模型，SOME/IP的通信协议等等，也保持了和WEB服务的兼容，如RESTful。慢慢的变多的汽车功能会往这个方向转化，现阶段先从更适合的功能做起，比如汽车的队列行驶功能，它是在驾驶过程中“自发地”完成的，因此就需要灵活的架构，并且需要允许车辆相互链接和取消链接，而不需要重新编译或重新再启动系统。是面向服务的架构式样典型的应用。

  （一）无人驾驶软件架构无人驾驶的应用功能需要构建在较高层的抽象级别。比如这些功能需要获得最近障碍物的距离的信息，可行驶空间等，再把它们转换到统一的虚拟坐标系中，最后和地图视图中的目标作比较，以确定其该执行什么样的动作。这需要更高级神经网络学习算法，视觉处理相关的软件驱动库，以及可靠性高，性能优秀的中间件。

  (二）自恢复和自适应系统模块设计安全关键软件架构需要满足自恢复的需要，自恢复是指自动从错误状态中恢复的能力。一般的自恢复系统包含测量，分析，计划和执行，这些设计机制。简单的说就是监测执行过程并随时纠正的一套算法机制。

  在自动驾驶系统中额外要求这种自恢复的机制，而且要求自恢复的过程是无感的，这对设计的要求就提出了很大的挑战。

  除了自恢复，还有一个概念就是自适应，它也是在安全关键系统中十分重要的设计元素。自适应强调的是一套冗余备份的系统，提供在特定情况下功能降级的应对措施。

  (三）大数据软件架构大数据在车上的运用慢慢的变多，对现代汽车的意义也慢慢变得大。由大数据引入的挑战在于对庞大数据的存储，分析和处理。由于大数据的特点在于数据容量大，类别多，速率高。另外需要鉴别数据的价值和真实性。这都对大数据的软件架构提出了挑战。

  本节将介绍当下比较火热的软件技术: SOA, 中间件，以太网及TSN，基于模型的开发。

  ①SOA《AP AUTOSAR应用》那期分享中，也提到了服务架构参考模型。

  服务描述，目的是描述服务包含哪些能力，怎么样去接入和使用这一些服务，服务的约束和策略是什么。其中一个重要的描述信息就是服务接口描述。

  契约和策略，策略代表某种使用服务的约束或者条件，服务契约是具体化的策略断言，管理双方或者多方的需求和期望。契约致力于解决服务提供者和消费的人之间的交互问题

  服务的定义也是服务架构的核心。服务可以是业务服务，基础服务，应用服务，客户服务。这些例子并不是实际汽车领域的服务设计，仅做示例。如图6

  汽车领域的服务设计，应该是对执行器传感器这些能力的服务化，和汽车基础功能的服务化，最后将应用以服务化的方式设计。

  而将这些服务联系在一起的过程，称为服务的编排。即将服务组件通过中心协调组件，完成所需服务的调用，以实现上层应用功能。另一种形式则是将服务依次调用形成服务的操作链。

  服务设计的难点在于当前没有一个现成的可以遵从的守则或者方法，需要在项目实践中迭代改进服务的设计。还有一些关于评价服务设计质量的KPI，如可重用性，颗粒度大小，可靠性等等指标，可以综合衡量服务设计的合理性。

  以太网总线技术在新架构下的潜力是它能取代其他总线成为主干网的地位。如果要成为汽车网络的主干网，还需验证以太网的很多方面的性能。例如带宽利用率，网络延迟，数据流的设计等等。

  对于软件来讲，需要有相应的TSN协议栈，用于时间同步的最佳主时钟算法，switch的配置，QoS的应用设计等等。如图7。

  广义范围的中间件分为很多种，这里主要是指主机基础设施中间件，以及分布中间件。经典AUTOSAR也包含了中间件的设计思想，RTE为SWC提供了虚拟的通信总线，就类似于一种通信中间件，只不过它大多数都用在ECU软件内部。

  通信中间件设计的一些要素，例如通讯式样，服务发现，传输协议，序列化，服务的品质策略。如图9对AP AUTOSAR中ara::com 与 ROC IPC进行了对比。

  功能安全对软件的要求很多，从软件开发计划，软件安全需求定义，软件架构设计，软件单元设计与开发，软件测试。

  购买AUTOSAR ASIL等级的软件组件是一方面，但这仅能解决OS, BSW层面的功能安全，更多的是需要在设计和执行中满足功能安全的要求。

  信息安全的实现大多数是软件的机制，例如安全启动，安全访问，安全刷写，软件验签，防火墙等。还有HSM，TEE可信安全硬件，提供可信允许空间。还有在R20-11新增加的模块IDSM，都是为信息安全而设计的。如图10。

  基于模型开发应用是ISO26262推荐的，在ASIL-B以上的话是强制要求的。

  基于模型的开发的好处显而易见，通过应用建模再生成代码能够尽可能的防止人为的编码失误，使研发人员专注用功能本身，而无需把大量的时间花在书写代码上。

  再和AUTOSAR的方法论结合后，能实现需求和实现完美追溯，代码自动化生成，以及标准验证和仿线 基于模型的开发