搞一下新架构下的软件技术 (A1)：新架构下的软件技术概述

前言

新电子电气架构的变革确确实实正在发生，而且势不可挡。

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

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

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

本文将从汽车软件技术创新开始，给大家分享这些变化。本期视频及材料，请后台回复'SW点映'

1

汽车系统软件工程的创新

技术发展离不开创新，在汽车软件领域的创新，主要是IT技术的创新。

如图1所示，从汽车系统软件工程的角度，主要分为现代嵌入式系统，云计算技术，分布式计算，实时系统，混合安全(Safety & Security)系统。

在新架构下，这些方面有着技术方面的创新。仔细琢磨的话，会发现这些创新点多少投射出互联网领域IT技术的影子。

图1 汽车系统软件工程

以上谈到了详细的技术革新，那从宏观层面，汽车行业又在经历哪些变化呢？

①

数字化转型趋势

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

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

②

新EE架构以及软件

再接着谈谈新电子电气架构，新EE架构最大的变化是设计思路上的转变。

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

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

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

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

③

敏捷转型与运维

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

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

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

2

什么是软件架构

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

①

软件架构式样

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

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

下面我们接着讲软件架构的几个方面：高层架构，架构视图，还有架构风格。

（一）高层的架构包含这几种结构。如图2。

• 功能角度描述的逻辑架构结构，包含软件功能，属性和需求。
• 软件组件结构，软件组件是基于逻辑架构延展开来的。
• 硬件组件ECU结构，ECU上执行了软件代码，ECU之间有总线的连接，以及执行器与传感器

图2 高层架构

(二) 以下是不同的架构视图，它们的目的和使用它们的原则。如图3。

• 功能视图，功能视图通常也称为功能架构，这类视图的重点是描述车辆的功能及其相互依赖关系
• 物理系统视图，通常将其描绘为整个电气系统的顶层视图，并附有底层网络拓扑示意图。
• 系统逻辑视图更专注于对软件层面的描述。在逻辑视图中，通常会展示软件中使用了哪些类，模块和组件，以及它们之间的相互关系。 用于此模型的符号通常是UML

图3 架构视图

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

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

• 基于组件的架构。相对于分层架构，这种架构灵活度更高。在当代汽车软件设计中，我们可以在娱乐影音领域中看到这种架构风格，其中系统分为平台和应用程序层，这里也具有分层架构的设计。而对于应用程序层，所有可以下载到系统上的应用程序都是根据基于组件的原则设计的。

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

图4 架构式样

上述我们分享了软件架构式样，接下来我们看一下软件架构的趋势。

②

软件架构的趋势

关于软件架构的发展趋势，主要有以下方面：

（一）自动驾驶软件架构

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

(二）自恢复和自适应系统设计

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

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

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

(三）大数据软件架构

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

那么新架构下的软件技术有哪些？

3

新架构下的软件技术

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

①

SOA

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

服务架构应具备的基本要素，从服务的动态特性方面，有3点。

• 可见性，服务需要有提供方和消费方，它们互动的前提是需要知道对方的存在。
• 相互作用，服务的相互作用通常是消息的发送和接受，另外还包含状态的迁移和改变。
• 真实世界效应，服务动作产生的效应，这种效应包括信息的改变，数据的添加和删除。

从服务的本身的描述上，又分为以下3种。

• 服务描述，目的是描述服务包含哪些能力，怎么样去接入和使用这些服务，服务的约束和策略是什么。其中一个重要的描述信息就是服务接口描述。
• 契约和策略，策略代表某种使用服务的约束或者条件，服务契约是具体化的策略断言，管理双方或者多方的需求和期望。契约致力于解决服务提供者和消费者之间的交互问题
• 执行上下文，主要是指服务的执行依赖关系。

说了很多参考模型抽象的概念，落实到具体实现层面指的是什么？请参见图5。

图5 SOA

有了SOA的理论和具体技术实现层面的支持后，服务如何定义呢？

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

图6 服务定义

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

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

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

②

以太网为主干网的总线技术

以太网总线技术在新架构下的潜力是它能取代其他总线成为主干网的地位。

如果要成为汽车网络的主干网，还需验证以太网的很多方面的性能。例如带宽利用率，网络延迟，数据流的设计等等。

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

图7 以太网总线技术

③

中间件

广义范围的中间件分为很多种，这里主要是指主机基础设施中间件，以及分布中间件。

经典AUTOSAR也包含了中间件的设计思想，RTE为SWC提供了虚拟的通信总线，就类似于一种通信中间件，只不过它主要用于ECU软件内部。

在POSIX操作系统上，比较著名的是ROS和Adaptive AUTOSAR。如图8。

图8 中间件

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

图9 中间件比较

④

汽车软件的专门需求

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

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

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

图10 汽车软件专门需求

⑤

基于模型的开发

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

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

再和AUTOSAR的方法论结合后，能实现需求和实现完美追溯，代码自动化生成，以及标准验证和仿真工具。如图11。

图11 基于模型的开发

以上便是本期为大家分享的《新架构下的软件技术》概述，下期我们将分享《整车以太网技术》概述，主要内容如下：

• 车内总线现状

• Why Eth 带宽？安全？EEA？

• IEEE 802 标准总览

• 汽车以太网标准

• 以太网协议栈

• AVB/TSN

• 面临的问题及解决

如果大家有想分享的内容，欢迎大家一起来分享！