江苏龙网

  1. 首页 > 生活 > >

汽车|干货 | 软件定义汽车模式下车载软件的正向设计方法( 六 )


在选项是连续值的情况下 ， 输出并没有实质性的困难 ， 只需要告诉用户取值范围就好了 。 但是选择具体数值的输入方式会比较困难 ， 我们留待以后的研究进行解决 。
输入方式提示是告诉用户采用什么输入方式来进行选择 。 这一部分和意愿选项输入单元的输入方式设计需要保持一致 。
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模式下 ， 由于硬件控制组件的标准化 ， 交互模块设计完成后可以调用部件库里的硬件控制组件 ， 从而直接驱动硬件 。


推荐阅读


上一篇：汽车|什么时候买车最实惠便宜？

下一篇：新能源|实现即插即充，广汽新能源与南北电网合作