电子商务网站建设研究,微信代理运营,山东平台网站建设公司,官方网站优化价格自动驾驶产品开发流程 在讲自动驾驶产品经理之前#xff0c;先简单了解一下自动驾驶的开发体系。如上图所示#xff0c;从产品需求开始#xff0c;经由系统需求、系统架构、软件需求、软件架构#xff0c;最终分解到软件代码实现模块#xff0c;再经由MIL、SIL、HIL、VIL完…自动驾驶产品开发流程 在讲自动驾驶产品经理之前先简单了解一下自动驾驶的开发体系。如上图所示从产品需求开始经由系统需求、系统架构、软件需求、软件架构最终分解到软件代码实现模块再经由MIL、SIL、HIL、VIL完成各个测试最终完成自驾产品的设计开发。其中产品需求便是由产品经理负责产品经理的一切活动都是围绕产品需求开展的。
自动驾驶产品经理工作职责
上面讲了产品经理的核心工作是产品需求但具体应该如何做呢下面我们详细介绍一下产品经理在整个开发体系中的具体工作内容内容如下
法规解读
众所周知自动驾驶当前还是一个比较敏感的话题政府对于此类产品一般会出台一些政策甚至有些国家将一些法规列入强标例如:UN R79如果不满足法规你的产品都不会让你上市。此外法规也在一定程度上反应了政府的态度及行业发展趋势一个合格的自动驾驶产品经理必然需要熟知相关法规在设计初期就要将其考虑进去否则设计出来也只能是个Demo无法作为产品去量产相关法规如下
当了解上述法规之后需要将跟自驾相关的内容拆解出来形成法规点检清单CheckList方便后边点检功能设计是否符合相应法规要求除以上内容外产品经理还会作为法规标准工作组成员定期参与法规的制定与评审及时了解行业动态进行产品调整
竞品对标
俗话说“知己知彼百战不殆”只有认清对手实力才能有更好的应对策略同时对手也能让我们更好的认清在同行中的位置。特别强调一点由于设计前期所有想法都停留在纸面对标竞品是验证设计思路的最好渠道
对标渠道
竞品分析的渠道有很多例如 1.竞品车型的用户手册 2.网上的一些测评视频 3.相关发布会 4.测评公众号 5.租赁车辆实车测评 6.购买相关测评报告 …等等 不过我还是比较推荐亲历亲为自己测过印象才能深刻并且在测评过程中也会对功能有新的认知与理解
对标内容
这里主要讲一下对标的内容 1.硬件系统方案 2.功能配置 3.相关交互逻辑【功能开启、激活、抑制、中断、退出、故障】 4.运营方案 5.亮点场景 备注如果有测试设备可以量化相关参数
对标报告
针对对标活动中所产生的原始视频、对标报告最好建立竞品数据库方便以后的查找同时后续如果有其他人也要对标免得重复去测
用户调研
用户调研的主要目的是挖掘用户的原始需求通过分析用户的需求为自驾产品附能
调研方法
调研方法有很多例如 1.问卷调查 2.头脑风暴 3.用户访谈 4.数据分析 …等等
调研结果
在经过调研活动后最终收集的可能都是一些比较口语化、模糊化的原始需求有些需求可能根本就不合理这时候产品经理需要将原始需求进行筛选、转化将有效需求筛出来同时将其转化为产品功能产品功能是对用户需求的专业化描述适用于工程开发
产品规划
在经过N次的调研及分析之后最终产品经理会形成一份根据用户需求转化而来的产品功能清单对于这些功能产品经理的主要职责是管理具体描述为定义优先级【哪些功能比较重要、或者哪些功能性价比较高】、分析可行性【哪些功能合理但是当前技术能力做不了】、功能后续迭代计划Roadmap【哪些功能需要后续OTA、以及后续OTA的时间节点】 示例
产品需求输出
针对产品规划中具备实现条件的产品经理将以产品需求文档【FRD或PRD】的形式正式输出给下游作为工程开发目标其内容主要包括功能概述、设计运行条件、功能场景、人机交互、性能要求此文档的作用是向下游描述清楚产品的三个特性【你的产品能解决用户的哪些需求用户如何使用你的产品怎么做才能让用户用的好】下面我们针对文档具体内容进行描述
功能概述
主要描述这个功能的外在表现示例高速导航驾驶辅助H-NOP指的是驾驶员在高速公路和城市快速路驾车行驶时在开启并设置导航路径的情况下系统可自动进行车辆的横纵向运动控制实现跟随导航路径的自动驾驶。高速导航驾驶辅助功能可以实现跟车行驶、居中行驶、拨杆变道、自动上下匝道、导航变道、超车变道等功能以实现高速点到点的场景覆盖
设计运行条件
设计运行条件(Operational Design Condition)简称ODC其表示功能能够正常运行所依赖的外部条件包括道路、交通、天气、光照、车辆状态、驾乘人员状态及其他状态示例如下
功能场景
在定义了设计运行条件之后相当于功能运行的大框架定了只要满足ODC定义的条件功能就能运行但真正落地需要细化到具体的场景例如ODC定义了高速H-NOP功能只要满足高速有高精地图功能就能正常运行但如何运行需要明确出来需要分析在这个ODC大框架下有哪些场景比如高速有上匝道、超车、下匝道、按路线导航等场景这些都需要解决功能才能运行所以此章节主要描述功能所需要解决的场景及应对的策略
导航变道【示例】 导航变道需满足以下功能要求 1 变道触发【触发的前提到达变道触发点满足变道要求】 ——变道触发点定义 ●当位于最左侧车道时于距离通视三角区端点(1000500*N)米处发起变道N代表从最左侧车道驶入最右侧车道的变道次数其他车道的发起距离以200米梯度逐级递减 ●无论道路结构如何最右侧车道都以通视三角区端点为准 ——变道要求 ●变道范围内不存在静止障碍物 ●当前车速35km/h ●前方4秒范围内相邻车道宽度2.8米 ●前方4秒范围内跨越车道线为虚线或虚实线 ●前方4秒范围内当前车道曲率半径150米 ●转向拨杆位于中间位置 ●距离上次变道完成无论成败时间5秒 ●距离NOP开始时间5秒 ●用户未进行横向Override ●未触发脱手警报 ●目标车道后方空间不得小于下图计算所得Scritical ●目标车道GAP预测2秒GAP前车时距≥1sTTC≥4sGAP后车时距≥2sTTC≥6s 2 变道确认【确认方式与变道模式关联】 ●推荐变道系统发起变道请求不会去激活转向灯待驾驶员确认后激活转向灯并执行变道【变道确认方式拨打同侧转向灯】 备注若车辆达到接管点则不再请求驾驶员确认转而发送接管请求 ●自主变道系统发起变道请求自动激活转向灯 3 变道执行 ●系统激活拨打转向灯后导航变道功能运行居中功能抑制 ●车辆向目标车道的横向移动不得早于拨打转向灯后1秒 ●整个变道过程应作为一个连续运动完成 ●变道前半段前轮未压线驾驶员拨打转向灯后3至5s内完成 ●变道后半段后轮压线需在5s内完成 ●变道完成后居中功能恢复 ●转向灯应在整个变道过程中保持激活状态在恢复居中功能后的0.5s内自动熄灭 ●如果需要完成多次变道才能达到目标车道需要在一次变道成功后车辆姿态摆正后再次尝试下一次变道 4变道抑制【根据变道过程分3种情况】 ●未执行横向移动前车辆进入变道抑制状态最多持续至接管请求点 ●执行变道前半段返回原车道 ●执行变道后半段继续执行变道【若无法完成变道则触发接管请求】
变道抑制条件存在以下几种 ●目标车道条件不满足不满足变道所需空间要求 ●第三车道条件不满足与第三车道车辆存在竞争性变道 ●车道线不满足变道期间存在实线、目标车道车道线丢失 5变道取消【根据变道过程分3种情况】 ●未执行横向移动前系统关闭转向灯 ●执行变道前半段系统关闭转向灯并返回原车道 ●执行变道后半段系统不关闭转向灯继续执行变道【若无法完成变道则触发接管请求】
变道取消方式 ——主动取消 ●反向拨打转向灯拨杆 ●反向转动方向盘【超越系统所需的横向控制力不得大于50N】 ——被动取消【不满足以下条件之一】 ●车速35km/h ●自车到达接管请求点 6 导航任务风险提示 ●若系统到达接管请求点时仍未执行变道则发出变道接管提示请求驾驶员自行变道 ●若驾驶员未进行自行变道以致错过路口则自动降级至ICA功能 7接管请求 ●系统检测到碰撞风险TTC3S时进行接管请求 8变道优先级 ●变道避障导航变道超车变道 ●当车辆处于导航变道作用区间内时超车变道受抑制系统将不再触发超车变道
人机交互【功能使用】
人机交互是个大课题下面将讲解如何一步步完成人机交互设计
交互通道梳理
在定义人机交互前最先做的事便是将整车所具备的交互通道及相关参数明确出来
交互内容及交互方式梳理
在定义人机交互前需要明确功能在使用过程中哪些是需要与用户进行信息交互的以及通过什么样的交互方式去进行交互。其中交互信息包括设置项、功能开启、激活、功能场景相关提示、功能抑制、中断、退出、故障交互方式包括视觉、听觉、触觉、用户操作等
之后简单列下表将功能交互的框架轮廓先做出来 在这个过程中最重要的是对交互内容的梳理在此期间需要明确正常流及各种异常流以及相关交互对产品经理的要求相对高一些就拿功能激活来讲就存在用户激活成功和激活失败两种情况产品经理需要明确哪些条件会造成激活失败以及激活失败之后如何提示用户示例如下 功能激活方式需要用户手动操作 正常流功能激活成功提供视觉声音提示 异常流功能激活失败提供视觉声音提示
当存在以下异常条件之一时功能激活失败 1ODD不满足 2主驾安全带未系 3驾驶员踩制动 4行驶速度超过150km/h 5车辆处于非D挡 6四门两盖任一处于打开状态 7车辆不稳定ESC/ABS/TCS/EBD激活 8胎压异常胎压过高、过低 9自车发生碰撞 10AEB激活 11方向盘转角过大 12车辆航向角与道路方向偏差过大 13自车横向加速度过大 14转向灯打开 15双闪灯打开 16不在高精地图覆盖区域之内 17系统故障含传感器 18关联ECU故障含转向、制动、驱动 19脱手惩罚模式
当所有的正常流与异常流分析完成后便可得到功能交互的基本框架下一步需要将交互细化明确形成详细交互方案
交互方案
经过上面步骤我们已经知道哪些场景需要给用户视觉提示哪些需要给用户听觉提示以及整车有哪些交互通道现在需要根据交互方式选取合适的交互通道把交互策略细化出来例如功能激活成功需要提供视觉听觉提示仪表/中控/HUD等交互通道都是支持视觉提示我们可以选择仪表进行视觉提示仪表支持视觉提示方式可以是文言弹窗、图标、场景重构SR、3D动画、3D模型渲染我们可以选择一个或几个听觉提示可以使用仪表自带的喇叭最终我们可以细化出交互方案如下
——功能激活成功 ●状态图标显示NOP蓝色图标 ●文言提示“请握住方向盘准备随时接管” ●声音提示激活成功提示音音色“咚咚咚”升降调提示一声 ●场景重构SR显示蓝色中央引导线
性能要求
针对产品设计中对产品性能及体验有关键影响的参数需要明确其要求 以上仅为单个自驾功能的产品需求文档在实际开发过程中需要对每个或每类自驾功能都需要出一份《产品需求文档》涉及功能如下
产品需求承接
当产品经理完成以上功能的产品需求文档之后下一步工作就需要把产品需求传递给下游支持下游开发设计下游单位包括HMI部门、功能安全、系统、测试下面将描述一下相关承接内容
HMI部门
产品经理最终形成的交互方案包括仪表显示、中控显示、声音、3D模型、3D动画效果等这些都需要HMI部门支持才能实现由于每个部门的关注点不一样不可能让所有部门去将每个功能的产品需求文档都认真阅读一遍这样不现实也会浪费大家时间因此需要产品经理针对性的把相关需求提炼出来形成额外的一些文档相关文档如下
UE交互文档
关于显示类的需要生成一份UE交互文档这份文档有两个用途1.方便HMI部们根据UE做相应的UI设计2.交互方案一般需要经过多方评审打和UE交互文档可以很方便的进行评审。不过个人更喜欢以交互流程图的形式去输出这样可以让其他人员更容易理解功能交互策略逻辑性较强。
在这里推荐几个比较好用的UE设计工具Axure、Figma、墨刀
备注界面设计工具基本都是HTML、CSS、JAVASCRIPT语言的封装工具的使用其实就是对属性的自定义感兴趣的小伙伴可以去菜鸟教程简单看下语言使用可以提升对界面设计工具的理解及使用
音源文件需求
需要明确声音的音色、频率、音调、类型最简单的方式是可以自己录一个声音作为参考这样需求承接的相对快些有些声音通过语言真的很难表达出来相关部门收到需求后会进行相应音源的设计
3D模型需求
需要明确3D模型的类型【例如人、骑行者、汽车等】、面数、相关组件等支持HMI部门设计相关3D模型
3D动画效果需求
需要明确3D动画的含义、效果样式最好有可以附加参考图方便HMI部门作3D效果设计
功能安全
功能安全部门会针对产品经理输出的产品需求文档进行分析结合整车安全分析相关功能安全等级并提出功能安全相关要求产品经理需要结合此要求复查产品设计并与功能安全部门达成一致意见
系统部门
系统是产品的主要承接方承担产品的实现系统需要认真阅读产品需求文档需要明确产品经理的需求在承接过程中产品经理与系统将持续对接保证系统能够完全承接自己的需求系统的工作主要包括系统架构设计、系统需求输出【内部状态机、外部关联系统需求】、信号实现逻辑在这个过程中产品经理需要与系统共同评审系统需求同时参与信号逻辑设计确保自己的需求能够完全被承接
测试部门
当产品经理输出产品需求文档之后测试部门将根据其撰写测试文档用于产品实现的跟踪与核查产品需求仅为测试的一部分除此之外测试也会结合系统需求以及信号实现逻辑等进行测试及问题描述
走查
当各部门完成产品需求承接后就进入开发阶段在这个过程中产品经理会定期进行走查掌控产品实现状态走查形式可以是实车体验也可以根据测试部门反馈结果进行了解
新技术、新方案交流
对于同一产品或功能实现方案可能存在差异并且有些方案可以很大程度上提升产品的竞争力例如最近提出的无图化NOP方案可以在一定程度上解决对高精地图的依赖提升NOP的适用范围针对此类新技术产品经理会组织相关方交流讨论确定技术方案及时进行产品迭代
寄语
当你看到此处你应该对自驾产品经理已经有了一个比较完整的认知希望可以帮助现在的你或将来的你同时也欢迎自驾相关的小伙伴私信交流一起成长 ————————————————————————————————
