01 到底什么是软件定义汽车？软件与架构的 “恩怨情仇“

前言

2020年，国内汽车电子圈刮起一股 “软件定义汽车(Software Define Vehicle)” 热潮，各种 "软件定义汽车"背景下的文章、会议等层出不穷，但经过笔者一番调查发现SDV这个概念在国外并没有这么热！很其怪的是， “软件定义汽车” 在国内这么热，但是以下问题却很难找到答案：


到底什么是软件定义汽车？
到底是软件定义架构还是架构定义软件？


带着这些疑问，《搞一下汽车电子》最近对 “软件定义汽车” 进行了深入的研究，鉴于此，跟大家分享《搞一下软件为汽车赋能》系列，如有不对之处，望不吝赐教！ 《搞一下汽车电子小助手》公众号后台回复 “系列” 查看所有系列分享！


本系列请点击：《搞一下软件为汽车赋能》


所有系列请点击：《汽车电子系列分享》

一、软件定义汽车哪来的？

可能有的朋友会好奇，这个系列是软件为汽车赋能，又为啥要谈软件定义汽车？我们先往下看！

第1个问题：软件定义汽车哪来的？

百度百科指出：软件定义汽车是由其自动驾驶事业部总经理于2016年提出的概念。 真的是这样吗？


不是的：一开始的时候（自2000年起），出现较多的是软件定义无线电 Software-defined Radio (SDR)、软件定义功能 Software-defined Functions (SDF)等概念。


笔者查阅文献发现，早在2007年4月份的IEEE会议论文集中就明确提出了 “软件定义汽车 Software Define Vehicle (SDV)” 的概念。当然，笔者认为，软件定义汽车的概念应该是早在2007年4月之前就有了。除了SDV外，还有另外一种 “软件定义汽车” 的概念，即"Software Define Car (SDC)" ，SDC笔者最早是在2013的一个外国网友的博客中看到的。


虽然 “软件定义汽车 (SDV)” 的概念较早的被提出，但是在之后的一段时间内，并没有什么热度，反而热度较高的是 “软件定义网络 (SDN)” ，其中有很多与汽车相关：如软件定义车辆网络 (SDVN)、软件定义网络架构 (SDNA)等等。


在IT界流传着这样一种说法：IT世界中的所有事物都可以被标记为"软件定义的"。有软件定义的网络、软件定义的存储、软件定义的计算、软件定义的数据中心等等。


因此，笔者认为 “软件定义汽车” 应该是在2007年之前源自IT界 ！并不是在2016年才被提出！

二、到底什么是软件定义汽车

接着

第2个问题：到底什么软件定义汽车？

为了搞清楚这个问题，我们将 “软件定义汽车” 拆成三段：

1）软件

2）定义

3）汽车

至此，延伸出以下问题：




先来看本节第一个问题：什么软件来定义汽车？


在汽车领域，软件主要分以下几类（这里，开发类的软件工具不在讨论范围之内）：


需要说明的是，其他软件如板载支持包（BSP）、Boot等软件因为与硬件相关度很大暂不在讨论范围内。

上图中的虚拟化技术，笔者曾看到：有人说hypervisor是一种软件虚拟化，笔者认为hypervisor是虚拟化硬件的，所以准确点说应该是：

hypervisor是一种硬件虚拟化技术，这种技术是一种软件。

除了hypervisor之外，还有一种叫做container的虚拟化技术，它是用来虚拟化OS的，因此可以称为是一种软件虚拟化技术。

那么本节中的第2个问题：软件定义汽车的什么？

在讨论软件定义汽车的什么之前，我们先暂定 “软件定义汽车” 中的 “软件” 是代表汽车相关的所有软件及软件技术。

汽车包含非常多的东西，有网络、架构、功能、软件、线束、硬件、乃至螺丝、车架、轮胎等等。

那么软件能定义汽车的什么呢？螺丝、车架？不沾边。 笔者认为，软件定义汽车更多的是指定义汽车功能

因为有了仪表显示功能，我们可以看到续航、车速等 因为有了电池管理功能，我们可以为汽车充放电 因为有了自动驾驶功能，我们可以手离开方向盘等等

但是返回来看本节中的第1个问题：什么软件定义汽车？所有的软件都是在定义这些功能吗？不是的，就像有的朋友会说，之前就没有基础软件，应用软件跟基础软件是在一起的，都是应用软件。所以，笔者认为能够定义汽车功能的是应用软件。

至此，我们初步回答了本节的第3个问题：应用软件定义汽车功能！

此外，我们不禁要问：

软件定义汽车，那什么来定义软件？

软件和架构到底是什么关系，是否是架构定义软件？另外，我们上文提到了软件定义网络，这又该如何理解？接下来我们看看

“软件、硬件、架构、网络的恩怨情仇”！

三、软件、硬件、架构、网络的 “恩怨情仇”

接着

第3个问题：到底是软件定义架构？还是架构定义软件？

为了搞清楚这个问题，我们需要先来捋一捋 “软件” 与 “架构” 这两个概念，由于架构本身就包含很多内容，因此，笔者也将 “网络” 与
“硬件” 加入进来一起捋捋！


当然，这里涉及的软件、硬件等仅限在汽车电子范围内。车架、轮胎等硬件不在讨论范围内！在研究软件、硬件、架构、网络之间的关系时，会涉及以下几个概念：功能、通信、系统。


“功能” 与 “通信” 的概念比较好理解，它们与 “网络” 、"软件"息息相关！ 而 “系统”
一般是指若干个部分相互联系，相互作用所形成的某些功能整体，在后文中也会提及。


笔者试着绘制了软件、硬件、架构、网络这几个概念之间的关系，如下图。 图片 图2 软件/硬件/架构/网络关系图


从上图中可以看出，存在了概念与概念之间的交叉，如 “网络” 与 “架构” 交叉产生的 “网络架构”！让我们来一一介绍！

01 软件

我们尝试将图2软件部分内容继续细化，分为两部分：一部分是软件架构，另一部分是除软件架构之外的软体部分！


结合第二节图1提到的与汽车相关的软件，我们比较容易理解软体部分。但在研究软件架构时，会有以下问题产生：
什么是软件架构？软件架构包含哪些内容？ 有哪些软件架构？


笔者认为，软件架构是由软件元素之间的依赖关系组成！软件架构一般包含软件组件、端口、接口以及它们之间的互联关系等！AUTOSAR就是一个很好的例子！但是，需要说明的是，AUTOSAR体系较为膨大，它包含有 “软件架构” 这层概念在其中，笔者认为，正如其名一样，AUTOSAR更准确的来说是一种 “系统架构”！


汽车领域的软件架构如图3所示，主要有以下几种：


1）应用软件架构：由应用软件之间的依赖关系等所组成


2）基础软件架构：由多个基础软件组件及其之间的关系组成


3）OS内核架构：主要包括巨内核、微内核、混合内核以及XNU


4）服务架构：一种软件模板化的设计思路，这里的软件更多的是指应用软件！


5）SOA：一种面向服务的模板软件架构


需要注意的是，笔者认为SOA是一种模板软件架构，真要归类，应该是服务架构、基础软件架构、应用软件架构的交叉！


还有一个是诊断服务，由于诊断服务自身是属于服务的范畴，所以会涉及服务架构的概念！但是它不完全属于架构的范围！所以笔者认为是一个
“脚踏两只船” 的角色！

02 硬件

图2的硬件同样划分为两部分：

一部分是硬件架构

一部分是硬体部分。


硬体部分比较容易理解，有ECU、电子电路、线束等（非架构），那么这问题又来了： 什么是硬件架构？ 硬件架构包含哪些内容？


硬件架构是根据整车要实现的功能，按照一定的划分规则，比如空间布局，规划出相应的控制部件，同时考虑部件之间的连接关系，依赖关系。如图4所示，硬件架构主要包括以下几种：


1）硬件组件架构：通过电路图描述ECU的所有内部方面。如电源、接地、微控制器、总线接口、存储器等等


2）电子电路架构：定义物理组件的电气特性及互连


3）线束架构：包含硬件架构中所有线路的连接。如插头连接器、接头等等


4）硬件几何架构：描述车辆中所有安装空间和安装位置等


5）内核架构：一般是指处理器（芯片）的核架构，如ARM的Cotex-A系列等


需要注意的是，笔者认为在设计ECU时，所产生的 “ECU架构” 隶属于硬件组件架构的部分！

03 网络

严格来说，网络架构、CAN总线、车联网、以太网等等都应该属于网络的范畴，网络架构设计，需要收集产品需求，针对不同的功能需求，数据交互量级规划不同网段，选择网络协议，不同网段的网络系统设计，分配网络负载，重点考量协议限制条件。


如图5所示，从大方向上，我们将 “网络” 划分为三个区域，分别是： 功能网络 网络架构 通信网络





如上图5所示，网络架构主要包含三种：


1）逻辑功能架构


" 逻辑功能架构 "是功能网络和网络架构的交集！


什么是逻辑功能架构？包含哪些内容？


逻辑功能架构定义了以软件或硬件实现的功能网络，包含逻辑组件(如传感器、执行器和逻辑功能)的规范。另外，还指定了接口和连接。逻辑功能架构中的元素可以映射到应用层以及底层软件或硬件架构。


有的朋友可能也发现了一个问题，为什么逻辑功能架构是竖着的，因为逻辑功能架构也涉及软件与硬件的部分，因此，逻辑功能架构应该是横跨
“软件”、“硬件”、"架构"以及 “网络” 的一个存在。这也是为什么有些朋友认为它属于 " 系统架构 "的原因！


当然，横跨 “软件”、“硬件”、“架构” 以及 “网络” 另一个存在便是 “通信网络架构”！


2）通信网络架构


通信网络架构是什么？包含哪些内容？


笔者认为，通信网络架构定义了软件组件如何跨硬件边界交换数据，指定了硬件网络中的物理信号等！描述软硬件之间的通信关系！


3）硬件网络架构


顾名思义，硬件网络架构是 " 硬件 “、” 网络 “以及” 架构 “三者的交叉！那么： 什么是硬件网络架构？包含哪些内容？


笔者认为硬件网络架构描述硬件组件或物理设备之间的逻辑连接的网络结构，如描述网络总线类型、每种网络类型的通信等。


接着我们来看看功能网络。


在功能网络中，除了” 逻辑功能架构 "外，功能网络与软件交集的部分便是 “软件功能网络”，与硬件交集的部分便是 “硬件功能网络”。那功能网络需要做什么事情：


笔者认为，在分布式系统中，需要通过功能网络描述来进行硬件与软件设计之间的分离；系统分解；以及通过将整个系统划分可管理的块来了解整个系统！


同理，在通信网络中，我们可以看到 “软件通信网络” 与 “硬件通信网络”


可能有的朋友会问，CAN、以太网在哪？笔者认为，它们大部分的概念是在 " 通信网络 "中，当然，还有朋友可能抠字眼说：CAN标准，以太网标准文档属于通信的范畴，这里就不做详细的讨论了！


当然，CAN、以太网等是一种通信网络，必然也有覆盖 " 通信网络架构 "这一层概念，所以，笔者认为，类似于这种总线通信，都是狠角色，脚踏四只船，“软件”、“硬件”、“架构”、"网络"均有涉及！


CAN、车载以太网等更多的是属于车内网，跟车内网并行的还有车云网、车际网等，这里就不做过多的解释！这也是笔者将 “车内网” 竖着放的原因！


接下来，我们再来稍微完善一下 "架构"的部分。

04 架构

在研究之前，我们先来回顾一下什么是架构：


架构是一个系统的基本结构，它包含组成系统的组件，组件和组件之间的相互关系，组件与环境之间的关系，以及指导系统设计和演化的原理！（来自IEEE
Standard 1471）


上文中，我们也研究了架构与 “软件” “网络” “硬件” 之间的交叉，即：“软件架构” 、
“网络架构”、“硬件架构”！除此之外还有很多各种各样的架构。笔者这里再将几种常见的拿出来进行研究：

1）电子电气架构

相信很多朋友也发现了，在上文中，笔者并没有过多的提到电子电气架构（EEA），那为什么呢？其一是笔者相信很多朋友对电子电气架构很了解！


其二我们从电子电气架构的概念出发来看一下：EEA代表整车电子电气系统的顶层，是E/E各子系统设计开发、网络开发、功能开发、系统交互的整车解决方案！（笔者这里并没有采用一开始由德尔福提出的EEA的概念，一开始EEA的概念对当前的汽车电子而言有些不适配）！


回过头来对照一下我们的图5，笔者认为EEA是涉及"软件架构"、“网络架构”、"硬件架构"等的概念，是一个系统层面的概念，所以，笔者认为它是横跨
“软件”、“网络”、"硬件"乃至 “功能”、"通信"等的存在！

2）系统架构

什么是系统架构？UML对系统架构的定义是：系统的组成结构，包括系统分解的组成部分，它们的关联性，交互，机制和指导原则，这些都是提供系统设计的信息。


一个比较好的例子上述笔者提到的AUTOSAR。就CP AUTOSAR而言，主要包括以下部分： 分层的软件架构 开发方法论 标准化的接口 就AP AUTOSAR而言，跟CP AUTOSAR相似，它也包含上述三部分，但是，需要注意的是，AP AUTOSAR所描述软件架构并不跟CP AUTOSAR一样有严格的层级划分。而是偏向于一种模块化的软件架构！ 同时，AP AUTOSAR还多提供了一个叫做AP（Adaptive Platform Demonstrate）的包。该APD中主要包含用于演示的代码包，工具等。但是，仅AUTOSAR会员可获取！


这也正如笔者之前所说，AUTOSAR涉及软件架构的概念，但它更准确的来说是一个 “系统架构”。 而 “系统架构” 也同样涉及 “软件”、“网络”、"硬件"乃至 “功能”、"通信"的概念！


还有一些其他的不常见的架构，这里就不做过多的解释！


至此，我们就基本完成了 “软件”、“硬件”、“架构”、"网络"这几个概念之间的关系！ 接着，我们将问题2与问题3一起拿来研究：


第2个问题：到底什么是软件定义汽车？ 第3个问题：到底是软件定义架构还是架构定义软件？

四、软件为汽车赋能

结合我们的总览图，如果硬要用 “定义” 这个词，倒也能找出几个有关系的：

逻辑功能架构 “定义” 软件功能网络与硬件功能网络

通信网络架构 “定义” 软件通信网络与硬件通信网络


还有，我们的应用软件架构、基础软件架构等，如果硬是用 "定义"这个词，似乎也可以沾上边：

应用软件架构 “定义” 应用软件

基础软件架构"定义" 基础软件


这时候，可能有的朋友会说，不管是逻辑功能架构、通信网络架构还是应用软件架构、基础软件架构，都属于架构，而不管是软件功能网络还是软件通信网络还是应用软件、基础软件都属于软件，所以：


架构定义软件！


如果是这样，那是不是也可以这样理解： 通信网络架构属于 "网络"的概念，而软件通信网络是 "软件"的部分，所以：


网络定义软件！


当然不行，我们接着往下看，上面提到了逻辑功能架构和通信网络架构 “定义” 这个，定义那个的，那么： 逻辑功能架构和通信网络架构又由谁来定义？


这时候，可能会想到一个比较好的词：需求：

需求 “定义” 逻辑功能架构

需求 “定义” 通信网络架构


这样就完了吗？


我们将所有软件打包，包括应用软件、基础软件等等，以及交叉后产生的通信软件等，结合 "定义"这个词，我们可以通过软件来决定一些内容！比如，如何通信，信号传输等！，这似乎能解释得通以下几个点：

软件 “定义” 硬件网络架构

软件"定义" 通信(网络)

软件 “定义” 功能(网络)


这里，硬件网络架构属于架构，通信网络自身也包含有通信网络架构的概念，所以，是不是可以说：


软件定义架构！


还有，不管是硬件网络架构、还是通信网络，它们都属于 "网络"这个概念的范畴，所以，是不是又可以得出一个说法：


软件定义网络！


当然将 “功能” "通信"的概念落地或者实际化后，还能产生以下说法：

软件 “定义” 用户体验

软件 “定义” 功能等


回过头来再想一想，应用软件架构是由应用软件元素之间的依赖关系所组成的框架，那么，是不是用 "驱动"或者其他的词来描述更恰当呢？我们结合 “定义” 这个词，尝试完善一下我们的图6，看能否得出一张 "软件定义汽车"下的总览图：





这个时候，可能 “硬件” 就有些不太舒服了，“硬件” 可能会觉得你们几个定义来定义去的，“我” 又算什么？


硬件当然不可缺少，它是软件的承载，软件需要运行在硬件之上。正如之前笔者的一位朋友所说：软件脱离硬件后，是没有真实世界效应（Real world effect）的！当然，这就属于另一层次的话题，不在 “定义” 的范围内了！


回过头来，我们再来看本节最开始的两个问题：


到底是软件定义架构还是架构定义软件？


笔者认为这两者之间一定存在交叉，不存在所谓的谁完全定义谁的说法！

到底什么是软件定义汽车？

笔者认为，这是在一定条件下才能成立的一种以偏概全的说法！笔者并不认可 "软件定义汽车"的说法，因为在智能网联汽车的大背景下，软件的灵活度与发展的空间更大。也正因如此，软件与大数据、云端等的结合也有了更多可以挖掘的空间。


所以，笔者认为与其一直停留 “软件定义汽车” 的噱头上，不如谈谈：

有哪些软件技术可以在汽车上使用？

结合这些软件技术能为汽车带来哪些 “能力”？

结合软件技术以及规范等如何推进汽车EEA的发展？

这也正是本系列的来源以及想要分享的内容！ 接下来，《搞一下汽车电子》会结合上述几个问题，来分享《搞一下软件为汽车赋能》系列！


同时，搞一下汽车电子也已经上线了SOA、APAUTOSAR进阶应用、新架构下的软件技术、整车以太网技术四个系列，每个系列13期内容，来更深一步的与大家交流分享，详情请点击：


《搞一下汽车电子 2021全年52期 线上workshop》


本期分享就到这里，阅读原文可查看所有系列分享，我们下期见！

联系我们

微信：shactiontech
邮箱：[email protected]