首页 > 汽车 > > 正文
2020-08-14 16:51:07

车载软件可以作为独立的软件被主机厂管理

导读 软件定义汽车开发模式的最大特点就是车载软件的发布和车型发布分离开。这样做的好处在于车型的硬件生命周期可以延长,而车载软件的发布时间

软件定义汽车开发模式的最大特点就是车载软件的发布和车型发布分离开。这样做的好处在于车型的硬件生命周期可以延长,而车载软件的发布时间可以非常的灵活。要做到车载软件和车型发布的分离,就需要引入主机厂自主管理车载软件开发的模式。这种模式是以车载软件成为独立产品为代表的,在与之相对的传统开发模式下,并没有独立的软件产品的概念,所有的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。

2、用户体验软件产品(UESP)的构成

用户体验软件产品(UESP)包含三个构成要素,分别是场景,服务,交互。通过分析,我们会发现所有的UESP都是在特定的场景下,调用一些服务的组合,按照一定的交互方式向用户提供服务。

除了场景,服务,交互之外,用户需求也是设计UESP时需要重点考虑的,因为它是设计UESP的目的,所有UESP都是为了满足用户需求而产生的。虽然用户需求并不出现在UESP要素中,但它却是隐藏在产品设计背后的真正驱动力。

UESP通过对场景的识别来判断或者猜测用户的需求(产品设计者在设计时需要把用户需求和场景做对应),因此场景被引入为UESP的构成要素。场景的识别包含两种方式,一种是用户意愿的自主表达,另一种则是场景识别,即基于场景识别算法自动进行识别。

场景的识别和服务的提供都依赖交互手段的采用,也就是用户意愿表达和服务的提供都离不开交互手段的应用,无论这种交互手段是点击按键,拧旋钮,语音或者手势控制,还是文字信息,音视频服务或者HUD。所以交互也是UESP的重要构成要素。

UESP的三个构成要素关系可参见图2。

3、UESP三要素的分析

为了研究UESP的设计方法,就必须要对场景,服务和交互这三个要素深入分析。

3.1 场景

场景就是状态,是汽车,汽车使用者或者外部条件的多种状态的组合。

汽车状态包括汽车的所有机械部件,电子部件,软件组件的状态,以及它们之间的庞大的组合。汽车状态还包括与其产品属性相关的生命周期状态和与其财产属性相关的权属状态。

汽车使用者状态可以细分为包括但不限于的身体姿态,心理状态,生理状态和社会身份等等。多位汽车使用者同时在汽车上出现本身也构成了更为复杂的社交状态。

外部状态可以细分为包括但不限于的时间,地理位置,天气状态,交通状态,通信环境状态等。

前面提到过,UESP的设计是为了满足特定的用户需求。需求由汽车使用者的需求或者汽车的需求所构成,两者都是与特定的场景相关联的。由于用户需求无法在产品中直接得到体现,所以我们通过定义特定场景来间接反映出用户的特定需求。

比如我们要设计一款UESP,加油服务产品。在汽车油量低时这款产品会主动向驾驶者提供周围的加油站位置。这个产品的需求就是汽车的加油需求。而场景就是汽车的油量状态低于一定比例时,比如20%。我们可以通过传感器定量判断“汽车油量低于20%”这个场景是否出现,这样场景就可以被测量和管理。因此我们把这个状态定义为汽车需要加油的场景。当然我们也可以把所剩油量不同状态分别对应于急迫程度不同的加油需求。 仅仅有油量状态还不够,因为我们还需要知道汽车的位置,这样才能查找周围的加油站。加油服务产品的需求,场景和状态的关系见图3。通过匹配急迫程度不同的加油需求和加油站里车辆的距离,还可以设计出更加精细,更有实用价值的场景加油产品。这就是高德导航里的Range on的设计原理。

实际场景会涉及很多维度,很多变量,变量的取值范围也会很广泛。因此针对复杂的场景研究,我们可以考虑采用场景状态相空间的概念,见图4。

从图4可以看出来,有时候场景对应于场景状态相空间中的一个点。有的时候,场景也可能对应于状态相空间中的多个点或者区域,见图5。比如四个车门的开合状态和使用者的位置状态(车内或者车外)(这一场景可以用于设计PEPS系统)。

在实际的场景设计中,当涉及的维度较少时,状态矩阵可以被引入到方法中。比如上面提到四个车门开合状态所构成的不同场景,见图6。

场景状态相空间和状态矩阵提供分析了场景分析,场景设计的工具。

场景设计就是找到场景状态相空间的一个子集,把它和需要满足的特定需求建立起对应关系。这种对应关系的设定很多时候依靠的是产品经理的常识或者直觉。但是对于复杂场景和隐蔽需求之间的关系,仅仅靠常识或直觉是不够的,这时候基于历史大数据的分析是可能有效的方法。

UESP涉及的场景往往比较复杂,研究场景设计的方法,我们需要研究最小颗粒度的场景,我们称之为元场景。元场景就是可以被识别的最小车辆部件的状态,或者人员和环境可以被识别的最小状态。

比如单个车门的开合状态就是一个元场景,而几个门的开合状态就不是。比如驾驶员饥饿就是一个元场景,而驾驶员身体不舒服(因为不舒服可以包含饥饿和其他很多元场景)就不是。元场景的的结构可以描述为:

{对象:{状态值集合}}

就像场景的定义一样,元场景对象包含汽车部件,汽车使用者和外部环境的各种因素。

状态值集合可能有一些离散值构成,也可能是连续值集合。车辆状态的元场景往往是用车载传感器来征测的,所以状态值往往是传感器侦测的数值。当然元场景也可能与执行器对应,这样的话状态值就执行器的状态数值。

3.2服务

本设计方法中的服务包括车载功能和第三方服务。

车载功能是指汽车部件通过软件控制所实现的,可以被驾乘人员所感知的能力,比如车窗可以开合,灯光可以亮灭,可以语音识别等等。这里强调的车载功能需要区别于完整的UESP,因为完整的UESP是有场景触发条件的,而车载功能只是能力,需要设计了场景触发条件才成为UESP。

UESP可以有很多车载功能组成,因此与元场景类似,我们也需要研究最小颗粒度的功能,我们称之为元功能。元功能就是可以识别,可以用软件控制的车载部件的最小功能。它的结构可以描述为:

或者是:{对象:{物理量类型},{状态值集合}

类似于元场景的结构,这里的状态值集合可以是离散值,也可以是连续值集合。离散值对应于比如门窗的开合状态,音响的开关状态。连续值就对应于空调温度,或者音量。车载元功能大都是和车载执行器件相关的。

UESP涉及的第三方服务指的是汽车通过车联网获取的第三方能力,这些能力主要表现为信息服务,可能包括传统的CP/SP的服务,也可能包括未来V2X时代来自于交通设施和其他交通参与者提供的信息。这些信息主要由文本,图片,音频和视频构成。类似于元功能,我们也需要提出第三方元服务的概念,以作为UESP设计会用到的基础对象,它的结构可以描述为:

或者是:{元服务来源:{元服务类型},{内容格式},{元服务内容}}

比如天气查询服务就可能描述为:服务商名字+天气服务+文本+“内容”。

3.3 交互

一个完整UESP产品的交互是由多个相似周期组成的,其结构可以描述为:

{交互周期1;交互周期2;交互周期3;...},每一个交互周期的结构是:

{输入单元,输出单元}。综合到一起就是:

三个周期只是UESP的典型结构,并不是每一个UESP产品都必须有这三个周期,有的可能只有一个,也有的可能需要四个,甚至更多。UESP产品所包含的交互周期的数量,可以称为交互层级或者交互深度。(有关交互深度的研究不在本文范围中)。交互设计的目标是让交互周期数量越少越好,也就是交互层级越少越好。无论UESP有几个交互周期,第一个交互周期始终是存在的,而且是比较特殊的,因为它代表着用户对UESP的发起。

输入单元是使用者或者场景识别算法对车提供输入的环节,属于车辆感知范畴,出现在场景判断中,用于功能或者服务的触发。UESP的发起必然通过两种方式。第一种方式是用户主动表达自己的意愿,依靠的手段包括但不限于实体按键,遥控(遥控器或者手机),语音命令,手势识别等等控制。第二种方式是用户没有主动表达意愿情况下,UESP根据场景识别的算法判断出设计的场景已经出现。这两种情况在输入单元中都会涉及,但本文主要分析第一种情况。

输出单元是车辆对用户提供输出的环节,作为用户输入的反馈,出现在功能或服务提供的过程中,用于确保UESP按照用户意愿去提供服务。输出单元主要用于询问用户是否确定提供服务(确认),或者是对不同服务选项的选择(多项选择),以及服务过程本身(提供服务)。

从UESP的交互结构图可以看出来,一共有四种类型的输入和输出单元,分别是功能发起输入单元,意愿选项输出单元,意愿选项输入单元,服务内容输出单元。

功能发起输入单元只会出现在第一个交互周期,通常用于功能的发起。意愿选项输出单元大多是要求用户确认意愿或者为用户提供服务选项,可以出现在除了最后一个交互周期的任何一个交互周期中。意愿选项输入单元通常用于用户对意愿或者服务选项进行确认或选择。服务内容输出选项则是开始提供服务。