摘要：
软件定义汽车（SDV）开发模式对主机厂自主管理车载软件开发提出了不同于传统模式的全新要求。文章提出了用户体验软件产品（UESP）的概念，并且分析了UESP与Feature之间的关系，得出了UESP是SDV模式下主机厂软件开发的关注重点这一结论。文章针对SDV模式下的UESP的产品结构，设计方法进行了较深入分析，并对UESP的设计工具乃至开发环境提出了初步建议。
Abstract:
Software-defined vehicle (SDV) development model is different from the traditional model in the development of vehicle software. This paper puts forward the concept of user experience software product (UESP) and analyzes the relationship between UESP and Feature, and draws the conclusion that UESP is the focus of software development for OEMs under the mode of SDV. This paper analyzes the product structure and design method of UESP in SDV mode, and puts forward some preliminary suggestions for UESP design tools and even development environment.
关键词：软件定义汽车（SDV），Feature, 用户体验软件产品（UESP），场景，元场景，功能，元功能，服务，元服务，交互，交互周期，交互层级，输入单元，输入方法，输入点，输出单元，场景库，部件库，服务库
KEY WORDS: Software defines vehicle (SDV), feature, user experience software product (UESP), scene, meta-scene, function, meta-function, service, meta-service, interaction, interaction cycle, interaction hierarchy, input unit, input method, input point, output unit, scene library, component library, service library
正文
软件定义汽车开发模式的最大特点就是车载软件的发布和车型发布分离开。这样做的好处在于车型的硬件生命周期可以延长，而车载软件的发布时间可以非常的灵活。要做到车载软件和车型发布的分离，就需要引入主机厂自主管理车载软件开发的模式。这种模式是以车载软件成为独立产品为代表的，在与之相对的传统开发模式下，并没有独立的软件产品的概念，所有的Feature是依靠多个ECU来协同完成的，也因此由多个供应商来开发和管理代码。
在SDV的模式下，车载软件才可以作为独立的软件被主机厂管理。因此车载软件的设计就成为了主机厂必须面对的课题，而这些工作原本大都是由部件供应商来完成的。同时作为独立产品的车载软件也需要独立的物理运行环境，这就是域控制器出现的原因之一。
本文将针对SDV开发模式下的车载软件设计进行研究，并提出设计方法。这一设计方法也是建立主机厂车载软件正向开发体系的重要部分。
研究车载UESP的设计方法既是为了提高整车正向开发能力，也是为实现软件定义汽车建立可遵循的规范，更为软件定义汽车的技术体系构成提供了基础，同时也为主机厂从传统汽车开发模式向软件定义汽车的开发模式过渡提供指引。
1、用户体验产品的概念
用户体验产品（User Experience Product，简称UEP）是指搭载在汽车上，能够被用户感知，进而影响到用户体验的刻意设计出来的一切汽车特性。
UEP包含但不限于汽车造型，颜色，尺寸, 部件（比如后掀背门），加速产生的推背感，防夹车窗，自动驾驶的TJA，智能钥匙或者是迎宾系统等等。
用户体验软件产品（User Experience Software Product, UESP）则是专指UEP中需要软件实现其功能的那一部分汽车特性。前面提到的加速产生的推背感，防夹车窗，TJA，智能钥匙，迎宾系统就属于UESP的范畴，因为他们都需要软件来实现其功能。其他的颜色，造型就仅仅属于普通的UEP。
本文中的正向开发设计方法就是针对UESP的正向开发过程的。
传统汽车设计中，Feature（特性或者卖点）是很重要的概念。在本方法中，Feature等同于UEP。Feature（即UEP）通常包含单部件的功能或者多部件协同完成的功能组合。多部件协同完成的功能组合（比如前面提到的TJA）通常都需要软件的参与，所以属于UESP。单部件功能中有一些（比如防夹车窗）也需要软件才能完成，所以也属于UESP。其他不需要软件实现的单部件功能（比如手动掀背门）就不属于UESP。这些概念之间的关系参见图1。
（图1）
2、用户体验软件产品（UESP）的构成
用户体验软件产品（UESP）包含三个构成要素，分别是场景，服务，交互。通过分析，我们会发现所有的UESP都是在特定的场景下，调用一些服务的组合，按照一定的交互方式向用户提供服务。
除了场景，服务，交互之外，用户需求也是设计UESP时需要重点考虑的，因为它是设计UESP的目的，所有UESP都是为了满足用户需求而产生的。虽然用户需求并不出现在UESP要素中，但它却是隐藏在产品设计背后的真正驱动力。
UESP通过对场景的识别来判断或者猜测用户的需求（产品设计者在设计时需要把用户需求和场景做对应），因此场景被引入为UESP的构成要素。场景的识别包含两种方式，一种是用户意愿的自主表达，另一种则是场景识别，即基于场景识别算法自动进行识别。
场景的识别和服务的提供都依赖交互手段的采用，也就是用户意愿表达和服务的提供都离不开交互手段的应用，无论这种交互手段是点击按键，拧旋钮，语音或者手势控制，还是文字信息，音视频服务或者HUD。所以交互也是UESP的重要构成要素。
UESP的三个构成要素关系可参见图2。
图2
3、UESP三要素的分析
为了研究UESP的设计方法，就必须要对场景，服务和交互这三个要素深入分析。
3.1 场景
场景就是状态，是汽车，汽车使用者或者外部条件的多种状态的组合。
汽车状态包括汽车的所有机械部件，电子部件，软件组件的状态，以及它们之间的庞大的组合。汽车状态还包括与其产品属性相关的生命周期状态和与其财产属性相关的权属状态。
汽车使用者状态可以细分为包括但不限于的身体姿态，心理状态，生理状态和社会身份等等。多位汽车使用者同时在汽车上出现本身也构成了更为复杂的社交状态。
外部状态可以细分为包括但不限于的时间，地理位置，天气状态，交通状态，通信环境状态等。
前面提到过，UESP的设计是为了满足特定的用户需求。需求由汽车使用者的需求或者汽车的需求所构成，两者都是与特定的场景相关联的。由于用户需求无法在产品中直接得到体现，所以我们通过定义特定场景来间接反映出用户的特定需求。
比如我们要设计一款UESP，加油服务产品。在汽车油量低时这款产品会主动向驾驶者提供周围的加油站位置。这个产品的需求就是汽车的加油需求。而场景就是汽车的油量状态低于一定比例时，比如20%。我们可以通过传感器定量判断“汽车油量低于20%”这个场景是否出现，这样场景就可以被测量和管理。因此我们把这个状态定义为汽车需要加油的场景。当然我们也可以把所剩油量不同状态分别对应于急迫程度不同的加油需求。 仅仅有油量状态还不够，因为我们还需要知道汽车的位置，这样才能查找周围的加油站。加油服务产品的需求，场景和状态的关系见图3。通过匹配急迫程度不同的加油需求和加油站里车辆的距离，还可以设计出更加精细，更有实用价值的场景加油产品。这就是高德导航里的Range on的设计原理。
图3
实际场景会涉及很多维度，很多变量，变量的取值范围也会很广泛。因此针对复杂的场景研究，我们可以考虑采用场景状态相空间的概念，见图4。
图4
从图4可以看出来，有时候场景对应于场景状态相空间中的一个点。有的时候，场景也可能对应于状态相空间中的多个点或者区域，见图5。比如四个车门的开合状态和使用者的位置状态（车内或者车外）（这一场景可以用于设计PEPS系统）。
图5
在实际的场景设计中，当涉及的维度较少时，状态矩阵可以被引入到方法中。比如上面提到四个车门开合状态所构成的不同场景，见图6。
图6
场景状态相空间和状态矩阵提供分析了场景分析，场景设计的工具。
场景设计就是找到场景状态相空间的一个子集，把它和需要满足的特定需求建立起对应关系。这种对应关系的设定很多时候依靠的是产品经理的常识或者直觉。但是对于复杂场景和隐蔽需求之间的关系，仅仅靠常识或直觉是不够的，这时候基于历史大数据的分析是可能有效的方法。
UESP涉及的场景往往比较复杂，研究场景设计的方法，我们需要研究最小颗粒度的场景，我们称之为元场景。元场景就是可以被识别的最小车辆部件的状态，或者人员和环境可以被识别的最小状态。
比如单个车门的开合状态就是一个元场景，而几个门的开合状态就不是。比如驾驶员饥饿就是一个元场景，而驾驶员身体不舒服（因为不舒服可以包含饥饿和其他很多元场景）就不是。元场景的的结构可以描述为：
{对象：{状态值集合}}
就像场景的定义一样，元场景对象包含汽车部件，汽车使用者和外部环境的各种因素。
状态值集合可能有一些离散值构成，也可能是连续值集合。车辆状态的元场景往往是用车载传感器来征测的，所以状态值往往是传感器侦测的数值。当然元场景也可能与执行器对应，这样的话状态值就执行器的状态数值。
3.2服务
本设计方法中的服务包括车载功能和第三方服务。
车载功能是指汽车部件通过软件控制所实现的，可以被驾乘人员所感知的能力，比如车窗可以开合，灯光可以亮灭，可以语音识别等等。这里强调的车载功能需要区别于完整的UESP，因为完整的UESP是有场景触发条件的，而车载功能只是能力，需要设计了场景触发条件才成为UESP。
UESP可以有很多车载功能组成，因此与元场景类似，我们也需要研究最小颗粒度的功能，我们称之为元功能。元功能就是可以识别，可以用软件控制的车载部件的最小功能。它的结构可以描述为：
图7
或者是：{对象：{物理量类型}，{状态值集合}
类似于元场景的结构，这里的状态值集合可以是离散值，也可以是连续值集合。离散值对应于比如门窗的开合状态，音响的开关状态。连续值就对应于空调温度，或者音量。车载元功能大都是和车载执行器件相关的。
UESP涉及的第三方服务指的是汽车通过车联网获取的第三方能力，这些能力主要表现为信息服务，可能包括传统的CP/SP的服务，也可能包括未来V2X时代来自于交通设施和其他交通参与者提供的信息。这些信息主要由文本，图片，音频和视频构成。类似于元功能，我们也需要提出第三方元服务的概念，以作为UESP设计会用到的基础对象，它的结构可以描述为：
图8
或者是：{元服务来源：{元服务类型}，{内容格式}，{元服务内容}}
比如天气查询服务就可能描述为：服务商名字+天气服务+文本+“内容”。
3.3 交互
一个完整UESP产品的交互是由多个相似周期组成的，其结构可以描述为：
{交互周期1；交互周期2；交互周期3；...}，每一个交互周期的结构是：
{输入单元，输出单元}。综合到一起就是：
图9
三个周期只是UESP的典型结构，并不是每一个UESP产品都必须有这三个周期，有的可能只有一个，也有的可能需要四个，甚至更多。UESP产品所包含的交互周期的数量，可以称为交互层级或者交互深度。（有关交互深度的研究不在本文范围中）。交互设计的目标是让交互周期数量越少越好，也就是交互层级越少越好。无论UESP有几个交互周期，第一个交互周期始终是存在的，而且是比较特殊的，因为它代表着用户对UESP的发起。
输入单元是使用者或者场景识别算法对车提供输入的环节，属于车辆感知范畴，出现在场景判断中，用于功能或者服务的触发。UESP的发起必然通过两种方式。第一种方式是用户主动表达自己的意愿，依靠的手段包括但不限于实体按键，遥控（遥控器或者手机），语音命令，手势识别等等控制。第二种方式是用户没有主动表达意愿情况下，UESP根据场景识别的算法判断出设计的场景已经出现。这两种情况在输入单元中都会涉及，但本文主要分析第一种情况。
输出单元是车辆对用户提供输出的环节，作为用户输入的反馈，出现在功能或服务提供的过程中，用于确保UESP按照用户意愿去提供服务。输出单元主要用于询问用户是否确定提供服务（确认），或者是对不同服务选项的选择（多项选择），以及服务过程本身（提供服务）。
从UESP的交互结构图可以看出来，一共有四种类型的输入和输出单元，分别是功能发起输入单元，意愿选项输出单元，意愿选项输入单元，服务内容输出单元。
功能发起输入单元只会出现在第一个交互周期，通常用于功能的发起。意愿选项输出单元大多是要求用户确认意愿或者为用户提供服务选项，可以出现在除了最后一个交互周期的任何一个交互周期中。意愿选项输入单元通常用于用户对意愿或者服务选项进行确认或选择。服务内容输出选项则是开始提供服务。
3.3.1 功能发起输入单元可以抽象为：
{目标功能；输入方式；输入点}。
先谈谈输入方式。第一大类输入方式是物理按键输入，包含实体按键和屏幕软键两种方式。实体按键和屏幕软键都可以出现在车载上，遥控器上，手机上或者智能家居的设备上。而按键形式可以包含开关，挡位选择，旋钮。第二大类输入方式是语音输入，这也是目前非常流行的输入方式，原因当然是它属于人类最自然的交互方式之一。第三大类输入方式是身体姿态输入，包括手势识别，眼动识别或者其他目前还没有发明的用人体姿态变化来实现输入的方式。
虽然功能发起输入单元属于第一交互周期，但是这三大类输入方式在其他交互周期的中也是一样的。
输入点是指具体的输入方式中承载明确输入目的的某个按键，某句语音指令，某个手势动作或某个眼球注视角度。
所以功能发起输入单元实际上就是把一个UESP功能的发起分配给某种（或者某几个）输入方式的某一个（或者某几个）输入点。
输入方式见图10。
图10
第一交互周期的功能发起输入单元的具体设计会面对两个重要问题。
第一个问题是，在用户准备启用某个UESP之前，他一定是知道这个功能存在的。那么怎么让用户知道这个功能存在呢？一些传统功能（比如空调，音响），已经布置在车载的物理按键上了，用户根据常识或者熟悉按键布置就可以了解。但是对于现在的智能网联汽车，功能越来越多，还出现了物理按键减少，合并，采用软按键的趋势，很多功能就不是那么一目了然的。在这样的状况下，如何让用户很容易地知道存在哪些UESP，并且知道如何启用这些UESP成为了问题。我们把这个问题称为UESP功能展现的完备性设计和可发现性设计。也就是说如何针对日益丰富的UESP功能设计出系统性的分类方法，合理的座舱按键布置，直观容易理解的输入方法，是座舱交互系统设计的重要课题。
第二个问题是输入方法的替代性问题和协同问题。输入方法有按键输入，语音输入，还有手势识别，眼动识别或者其他还没有被发明的输入方法。在UESP整个交互过程中，输入方法之间并不是完全可以相互替代的。（举例？）分析这些输入方法的差异，从而发挥各自最大作用和协同作用是很重要的。
3.3.2 意愿选项输出单元有两种情况，一种只是意愿确认（是或者否），一种则是选项提供，分别可以抽象为：
{服务意愿；{输出方式1；部件；参数}； {输出方式2；部件；参数}...；输入方式提示}
{服务选项；{输出方式1；部件：参数}:；{输出方式2；部件；参数}...；输入方式提示}
（第一交互周期的服务意愿和服务选项通常都是文本信息。）
服务意愿通常只有“是”和“否”两个选项。
服务选项则有两种情况，第一种情况下，选项是离散的，有两三种，到十几种，甚至更多，比如POI查询结果。另一种情况下，选项是连续值，比如要设定的空调温度。
输出方式可以按照视觉输出，听觉输出，体感输出来划分。视觉输出又可以按照信息格式来区分，比如文本，图片，动效，动画或者视频。与之对应的部件则是能够提供视觉输出的所有车载部件，比如车内外灯光，车内各个屏幕，仪表，HUD，甚至未来的透明车身和车窗显示器等等。视觉输出的参数则是文本的字体，大小，位置等等，图片的质量，位置，大小等等，视频的质量，位置，大小，码率等等。
类似的，听觉输出对应的部件包含车上的一切可以软件控制发出声音的部件，比如喇叭，音响，低速声音发生器等等，而参数就包括音质，音量，声效，声源位置等。
体感输出包括但不限于触感回馈，座椅震动，方向盘震动等。触感回馈可以告诉用户自己输入的有效性。座椅震动则可以用在提醒驾驶员在自动驾驶失效时对车辆的接管。体感输出通常只是作为辅助手段而出现。
输出方式见图11。
图11
设计意愿选项输出单元的目的就是要解决如何把服务意愿和服务选项分配给合适的输出方式，按照合适的参数在合适部件上，以供用户确认或者选择，最好还可以提示用户如何输入自己的选择。特定输出单元可以选择一种，也可以是两种或以上输出方式提供给用户。
当选项数量较多时，输出方式本身的局限性会暴露出来。首先语音播报不太适合选项较多的情况，因为播报完所有选项的时间太长了，用户会失去耐心，也不可能记得住。用视觉显示也会存在显示区域大小的限制，如果加上翻页的交互操作，又会增加交互的深度。但是这个矛盾的解决不在本文讨论。这个问题我们称之为输出方式的效率问题。（翻页操作其实也可以看作为选项的一种，所以仍然可以包括在本方法之中，只是增加了一个交互周期而已）
在选项是连续值的情况下，输出并没有实质性的困难，只需要告诉用户取值范围就好了。但是选择具体数值的输入方式会比较困难，我们留待以后的研究进行解决。
输入方式提示是告诉用户采用什么输入方式来进行选择。这一部分和意愿选项输入单元的输入方式设计需要保持一致。
3.3.3 意愿选项输入单元可以抽象为：
{服务意愿m；输入方式；输入点m}
{服务选项n；输入方式；输入点n}
本单元设计目标是针对意愿选项输出单元所提供每一个意愿和服务选项，按照其所提示的输入方法，设计输入方式和输入点。
有关输入方式和输入点的解释和前面功能发起输入单元是一致的。
需要注意的是无论服务选项是可数的离散值还是连续值，{服务选项n；输入方式；输入点n} 的结构都是适用的。当然也可以针对同一个选项，同时设计多种输入方式和输入点。
3.3.4 服务内容输出单元可以抽象为：
{服务内容；{输出方式1；部件；参数}； {输出方式2；部件；参数}...；输入方式提示}
服务内容输出单元与意愿选项输出单元的结构几乎是一样的。差别在于意愿选项大多是文本内容，而服务内容除了文本内容，还可以有图片，视频和音频。
需要注意的是服务内容输出单元，并不意味着交互的终结。因为在服务内容输出过程中，用户还可能产生一些新的需求，比如在听音乐过程中换曲，暂停等等。这些功能选项也属于服务内容的范畴，也需要进行输出方式的相关设计。
这个单元里的输入方式提示则是用于告诉用户在当前周期里，他可以做用什么输入方式做什么样的操作。这部分设计的困难与前面提到的UESP功能展现的完备性设计和可发现性设计是相似的。
4、UESP的产品结构
基于2和3的分析，UESP产品的的结构可以表示如下：
图12
这个结构为后面的设计环境，运行环境的分析提供了基础。
5、UESP的开发环境分析
在引入软件定义汽车开发模式之前，针对Feature的完整的开发环境是不存在的，也没有意义，因为大多数时候Feature是由几家供应商分头开发的，主机厂主要是管理需求。在传统模式下，主机厂可能会采用需求管理和功能分解的流程工具，用来管控给供应商的需求输入。
在软件定义汽车的模式下，与Feature对等的UESP成为了主机厂管理，开发的对象，由于其单一，独立的产品形态，客观上要求主机厂拥有能够有效开发UESP的开发环境。
在本文前面部分分析的基础上，研究UESP的开发环境和开发工具就成为了可能。
由于软件定义汽车开发模式在各主机厂还处于实践初期，因此UESP的开发环境就具有很大的市场价值，也将定义一个规模客观的全新市场领域。
UESP的开发环境主要由下面几个部分构成：软件主体设计工具，场景库，部件库和与服务库。
下面对每一部分，进行简要分析。
5.1 软件主体设计工具
设计工具是各主机厂的产品设计开发部门使用的，用于UESP产品的设计。设计工具包含两个主要部分，一个用于设计把特定场景和对应车载功能，第三方服务关联起来的决策软件模块，可以被称为决策模块设计。决策模块设计主要解决的问题是，基于以多种场景触发条件为输入的算法，决定调用车载功能和第三方服务的方式。决策模块可以包括简单的逻辑运算，时序判断和设计，也可以包含复杂的自动驾驶算法或者DMS（驾驶员监控系统）等。
主体设计工具的另一个部分可以被称为交互模块设计，用于设计人机交互的整个过程，负责把输入输出信息分配到不同的输入输出方式和部件，并且把设计规范固化在其中，可以被称为交互模块设计。注意第二部分交互模块设计不是简单交互界面设计，不同于传统的交互原型设计软件。在SDV模式下，由于硬件控制组件的标准化，交互模块设计完成后可以调用部件库里的硬件控制组件，从而直接驱动硬件。
交互模块设计主要解决的问题是，每一个交互周期的设计，需要具备针对每一个交互信息定义对应的交互部件，并且设定其交互参数的能力。
5.2 部件库
使用软件主体设计工具进行设计时，必然需要把车载功能设计到UESP中，因此需要用到部件库。部件库的设计要遵循完备性，系统性和平台性的原则。
5.3 服务库
使用软件主体设计工具进行设计时，必然需要把第三方服务设计到UESP中，因此需要用到服务库。服务库同样需要按照完备性，系统性和平台性的设计原则进行设计。
5.4 场景库
场景库要能够管理场景的完整生命周期，即创建，修改，删除和管理UESP所包含的场景。为了实现这个目标，场景库要能够访问部件库，因为根据前面3.1对场景的分析，场景大多是时候是由部件状态构成的。
UESP开发环境最好是在云环境中进行建设。
以上是对UESP开发环境的简单分析，详细分析内容不在本研究方法的范围内。
6、UESP的运行环境分析
UESP作为一个车载独立软件需要运行在明确的硬件上，这个硬件就是一个域控制器。座舱域控制器就是实现信息交互为目的的UESP所运行的硬件环境。其实域控制器的出现原因就在于在软件定义汽车模式下，独立存在的车载软件必须要有相应的硬件运行环境。
除了硬件运行环境之外，UESP还需要域控制器上的软件运行环境。这个软件运行环境主要指的是操作系统，以及可能需要的服务中间件。
另外为了保证新开发的UESP可以下发到已经销售出去的汽车上，还需要支持能够针对每一辆具体车辆升级的OTA系统。同时为了管理每一台车辆不同的升级状态，运行状态，付费状态，安全状态，还需要建设能够记录和管理每一台汽车软件和硬件状态的汽车数字镜像云。
软件定义汽车的开发模式是传统主机厂前所未遇的，因此UESP的正向开发设计方法也通过本文第一次提出来，而UESP的开发环境和运行环境则是更加前瞻性的思考。UESP的开发环境和运行环境将形成巨大的软件产业发展机会，其效应将不亚于其他传统开发模式下开发工具链。然而UESP运行环境和运行环境的详细分析内容不在本论文研究范围内。作者在后续论文将逐步阐述。
原文标题《符合软件定义汽车（SDV）开发模式的车载用户体验软件产品（UESP）正向开发设计方法》