Update from Sync Service
This commit is contained in:
FNS Service
@@ -0,0 +1,16 @@
|
||||
1. 开发前
|
||||
- [ ] 匹配信号、赛博坦和SOA
|
||||
- [ ] 确认所需数据上报和落表情况
|
||||
2. 开发中
|
||||
- [ ] 确认信号连续性，是变化上传还是周期上传
|
||||
- [ ] 确认信号是否多个节点上传的情况
|
||||
- [ ] 确认信号的物理和逻辑范围
|
||||
3. 开发后
|
||||
- [ ] 确认获得的值逻辑性正确
|
||||
- [ ] 保证计算了全部的原始信号
|
||||
- [ ] 保证逻辑计算准确性
|
||||
- [ ] 确认计算后时间的连续性，并且无重复
|
||||
- [ ] 确认计算后业务上相关的数据之间关系符合业务逻辑，如加和相等，包含关系中子项和不超过父项和
|
||||
- [ ] 确认调度逻辑正确性
|
||||
- [ ] 确认插入数据时间和分区正确
|
||||
- [ ]
|
||||
@@ -0,0 +1,6 @@
|
||||
- 今日完成：
|
||||
- 与云思创智进行交流，要注意云思创智的人员能力，同时其车端能力较差，模型需要较大的算力才可使用；
|
||||
- 更新人体健康中台立项材料；
|
||||
- 明日计划：
|
||||
- [x] 与健康有益交流
|
||||
- [x] 修改驾驶评价部分的离线模型，想办法提升速度
|
||||
@@ -0,0 +1,8 @@
|
||||
- 今日完成任务
|
||||
- 完成健康有益和[鹰瞳科技](https://www.airdoc.com/)的交流，考虑后序推进将鹰瞳科技的产品移植到车上；
|
||||
- 推进修复驾驶行为离线模型，目前15天用时4分钟；
|
||||
- 明日任务：
|
||||
- [x] 与东南大学交流；
|
||||
- [x] 与车端网联所确定周期需求；
|
||||
- [ ] 完成离线模型的效率提升；
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
- 今日完成任务：
|
||||
- 研究通过DataSourceV2自定义spark写入tdengne的数据源(只负责写入)；
|
||||
- 明日任务：
|
||||
- [x] 联系健康有益，提供详细需求文件，并邀请到现场讲解；
|
||||
- [x] 联系TDengine，恢复数据库license；
|
||||
- [ ] 完成自定义TDengine数据源的开发；
|
||||
- [x] 反馈手机APP原型设计问题；
|
||||
- [x] 催车端网联所上会；
|
||||
- 其他待完成的任务：
|
||||
- [ ] 问新能源院，A new项目空调加热及电池热管理的工作模式；
|
||||
- [x] 调整云端模型的行程判定逻辑；
|
||||
- [ ] 云端模型测试；
|
||||
- [ ] 车端模型测试；
|
||||
@@ -0,0 +1,10 @@
|
||||
- 今日完成工作
|
||||
- 联系健康有益，提供详细需求文件，并邀请到现场讲解；
|
||||
- 反馈手机APP原型设计问题；
|
||||
- 更新PRD；
|
||||
- 重新设计云端模型逻辑；
|
||||
- 准备明天的汇报；
|
||||
- 明日任务：
|
||||
- [x] 完成自定义TDengine数据源的开发；
|
||||
- [x] 调整行程判定逻辑；
|
||||
- [x] 汇报模型开发进展；
|
||||
@@ -0,0 +1,5 @@
|
||||
- 今日完成工作
|
||||
- 工作汇报；
|
||||
- 完成模型行程判定逻辑修改；
|
||||
- 明日计划工作
|
||||
- [ ] 完成自定义TDengine数据源的开发；
|
||||
@@ -0,0 +1,44 @@
|
||||
1. 数据预处理：
|
||||
1. 异常值：
|
||||
1. 基于业务逻辑：各物理测量值不可超过物理限制；
|
||||
2. 基于统计的：3σ标准；
|
||||
2. 归一化；
|
||||
3. 特征选择：
|
||||
1. 基于车辆动力学基础知识，参考论文、官方统计数据及友商对标；
|
||||
2. 基于相关性分析；
|
||||
2. 驾驶行为评价指标体系如何选择、验证：
|
||||
1. 选择：基于车辆动力学基础知识，参考论文、官方统计数据及友商对标；
|
||||
2. 验证：
|
||||
1. 安全：基于保险公司的出险数据，参考了交通部交通事故原因统计数据；
|
||||
2. 能耗：基于车辆行驶的实际油耗数据，取相同地区、在近似的天气环境下、空调使用等等条件下，比较不同油耗区间车辆的驾驶行为指标数据；
|
||||
3. 舒适性：未能找到比较合适的验证方法因此模型未上线；
|
||||
3. 驾驶事件识别模型：
|
||||
1. 模型：
|
||||
1. 驾驶工况：
|
||||
1. 以2分钟切分工况段；
|
||||
2. 根据最大方向盘转角、最大方向盘转角速度和最大侧向加速度三个变量区分直行和侧向工况，根据不同车速点做聚类(kmeans)，就分两类(直行和侧向)，车速点 40，60，80，100(要求车速大于15小于100km/h)；
|
||||
3. 直线工况：根据不同车速范围划分加速度阈值，取90百分位的加速度值作为阈值基础，取0.5m/s2作为回滞；
|
||||
4. 侧向工况：换道、车道保持、转向和其他，支持向量机(高斯核、OVO(没有数据不平衡的问题，总共是(4*(4-1)/2)6个分类器)、软间隔、hinge损失函数)，指标 最大侧向加速度、最大质心转向角度、最大方向盘转角、方向盘转角速度；
|
||||
2. 换道、车道保持：隐马尔可夫模型(高斯混合)，指标：车速、侧向加速度、方向盘转角、方向盘转角速度；
|
||||
2. 训练、验证数据采集：实车实验，can信号收集，实验工况记录及视频录像；
|
||||
3. 验证指标：
|
||||
1. 换道、转向：四类：换道、车道保持、转向和其他，log损失函数
|
||||
4. 驾驶风格识别模型：
|
||||
1. 模型：
|
||||
1. 数据指标：当车速大于15km/h，且总行驶里程大于10km，最大加速度、平均车速(不计怠速时间)、加速度方差、平均车速方差、最大冲击度、最大冲击度方差、每公里急加速次数/急减速次数、最大方向盘转角速度；
|
||||
2. 数据预处理：
|
||||
1. 归一化；
|
||||
2. PCA；
|
||||
3. kmeans聚类；
|
||||
4. 验证：找同事开车进行实车验证，由其他同事打分；
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
1. ~~主成分分析~~
|
||||
2. 因子分析 抽样适合性检验,bartlett球形检验
|
||||
3. SVM 调参
|
||||
4. kmeans咋选的聚类类别数；
|
||||
5. D-S 证据理论
|
||||
@@ -0,0 +1,29 @@
|
||||
1. 北极星指标：
|
||||
1. ASD里程渗透率(性能方面)；
|
||||
2. ASD订阅率(商业化方面)；
|
||||
2. 一级指标：
|
||||
1. 性能方面：
|
||||
1. 单次接管可行驶里程，接管：方向盘、制动、系统开关；
|
||||
2. 特别场景下表现：
|
||||
1. 变道场景；
|
||||
2. 路口通行；
|
||||
3. 主辅路切换；
|
||||
4. 上下匝道；
|
||||
2. 商业化方面：
|
||||
1. 买断率
|
||||
3. 二级指标：
|
||||
1. 性能方面：
|
||||
1. 高速、高架、城市单次接管可行驶里程
|
||||
2. 场景表现：
|
||||
1. 变道：转向灯、导航(下匝道)、避障、效率(超车)、选道(根据用户偏好)、高速驶入快车道(选道的一种)
|
||||
2. 路口通行：红绿灯左转、右转
|
||||
3. 上下匝道：
|
||||
1. 高速、高架上匝道
|
||||
2. 高速、高架下匝道
|
||||
4. 主辅路切换(只在高精地图覆盖)：
|
||||
1. 切换成功率
|
||||
|
||||
智驾方面我主要是参与了一部分ASD性能评价体系的搭建，ASD性能评价体现的北极星指标是ASD里程渗透率，就是ASD激活的行驶里程/ASD可用的行驶里程；这个指标主要是反应了用户对ASD系统的接受度，因此我们针对可能影响用户接受度的性能指标做了拆分，一级指标为单次接管的可行驶里程和特定场景下的表现，如变道成功率、路口左转右转的成功率、主辅路切换成功率、上下匝道成功率等；二级指标主要是对一级指标的场景细化，单次接管可行驶里程拆分为高速、高架、城市三种场景，变道拆分为转向灯换道、导航换道(下匝道)、避障换道、效率换道、选道(高速驶入快车道)；路口通行：左转、右转；上下匝道：高速上匝道，高架上匝道，高速下匝道，高架下匝道；此外，会有一些专门的用户操作分析，比如出现事故车辆的危险操作分析
|
||||
|
||||
接管：
|
||||
1. 退出到人工：按键、制动踏板、方向盘、加速踏板(加速踏板要超时)
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
mindmap-plugin: basic
|
||||
---
|
||||
|
||||
# 2023年工作
|
||||
|
||||
## 悦驾CLUB
|
||||
- 云端
|
||||
- 模型
|
||||
- 测试
|
||||
- 数据库
|
||||
- 切换到时序库
|
||||
- 性能测试报告√
|
||||
- Spark中Custom DataSource开发
|
||||
- 数据库架构调整
|
||||
- 行程业务数据库设计
|
||||
- 接口
|
||||
- 修复bug
|
||||
- 性能测试
|
||||
- 车端
|
||||
- 边缘计算模型
|
||||
- 新增评价逻辑
|
||||
- 模型测试
|
||||
- 手机APP
|
||||
- HMI设计
|
||||
- UE设计
|
||||
- 原型问题反馈
|
||||
- 开发计划排期
|
||||
- UI设计
|
||||
- 开发计划排期
|
||||
- 前端开发
|
||||
- 开发计划排期
|
||||
- 接口对接
|
||||
- 确认接口情况
|
||||
- GPS信息接口形式确认
|
||||
- APP
|
||||
- 开发
|
||||
- 测试
|
||||
- 手机APP
|
||||
- HMI设计
|
||||
- UE设计
|
||||
- 原型问题反馈
|
||||
- 开发计划排期
|
||||
- UI设计
|
||||
- 开发计划排期
|
||||
- 前端开发
|
||||
- 开发计划排期
|
||||
- APP
|
||||
- 开发
|
||||
- 测试
|
||||
## 人体健康
|
||||
- 立项
|
||||
- 材料修改和提交
|
||||
- 汇报
|
||||
- 供应商定点
|
||||
- 寻找新供应商
|
||||
- 跟云思约时间
|
||||
- 确定供应商
|
||||
- 算法开发
|
||||
## DMS/OMS算法开发
|
||||
- 人脸关键点检测
|
||||
- 人体健康指标提取
|
||||
@@ -0,0 +1,71 @@
|
||||
## 一、悦驾CLUB开发
|
||||
|
||||
### 1.1 云端
|
||||
- [ ] 1.1.1 模型开发
|
||||
- [x] 行程判定逻辑修改
|
||||
- [ ] 时序数据库迁移
|
||||
- [x] 自定义DataSource开发
|
||||
- [x] 重新设计数据库结构
|
||||
- [ ] 确定周期数据库是否需要迁移
|
||||
- [ ] ***GPS点怎么办？***
|
||||
- [ ] 1.1.2 模型测试
|
||||
- [ ] 模型准确性测试
|
||||
- [ ] 行程划分、行程事件统计是否准确
|
||||
- [ ] 建立模拟的kafka topic检验准确性
|
||||
- [ ] 周期行程统计结果是否准确
|
||||
- [ ] 小贴士、评价是否准确
|
||||
- [ ] 模型性能测试
|
||||
- [ ] 实时行程延时
|
||||
- [ ] 接口延时
|
||||
- [ ] 周期行程计算延迟
|
||||
### 1.2 车端
|
||||
- [ ] 1.2.1 模型开发
|
||||
- [ ] 驾驶行为评价模型
|
||||
- [ ] 三急阈值实验
|
||||
- [ ] 修改超速识别方法，引入TSR识别的超速车速
|
||||
- [ ] 增加疲劳、分心和愤怒驾驶的识别，尤其是开始和结束时间
|
||||
- [ ] 补充FCW报警次数等信息
|
||||
- [ ] 修改安全驾驶评分计算公式
|
||||
- [ ] 能耗分配模型
|
||||
- [ ] 确定空调、电池热管理的计算方法
|
||||
- [ ] 1.2.2 模型测试
|
||||
- [ ] 驾驶行为模型测试
|
||||
- [ ] 驾驶行为事件识别的准确性，包括次数和持续时间
|
||||
- [ ] 驾驶行为评价模型的运行速度
|
||||
- [ ] 能耗分配模型测试
|
||||
- [ ] 能耗分配计算的准确性
|
||||
- [ ] 能耗分配模型的运行速度
|
||||
### 1.3 接口
|
||||
- [ ] 1.3.1 接口开发
|
||||
- [ ] 与车端网联所对接接口需求
|
||||
- [ ] 将行程接口迁移到时序数据库
|
||||
- [ ] bug修复
|
||||
- [ ] 1.3.2 接口测试
|
||||
- [ ] 准确性测试
|
||||
- [ ] 性能测试
|
||||
### 1.4 前端
|
||||
- [ ] 1.4.1 车机APP开发
|
||||
- [ ] 原型图设计修改
|
||||
- [ ] UI资源释放
|
||||
- [ ] 与边缘计算通讯拉通
|
||||
- [ ] APP开发
|
||||
- [ ] 1.4.2 手机APP开发
|
||||
- [ ] 原型图设计修改
|
||||
- [ ] UI资源释放
|
||||
- [ ] 接口对接
|
||||
- [ ] APP开发
|
||||
- [ ] 1.4.3 测试
|
||||
- [ ] 数据准确性测试
|
||||
- [ ] 性能测试
|
||||
- [ ] 车机实时驾驶行为更新频率测试
|
||||
- [ ] 手机APP数据查询速度测试
|
||||
## 二、人体健康开发
|
||||
### 2.1 供应商交流
|
||||
- [ ] 邀请意向供应商到南京现场交流
|
||||
- [ ] 科思创动
|
||||
- [ ] 确定时间
|
||||
- [x] 云思创智
|
||||
- [x] 健康有益
|
||||
- [x] 确定时间
|
||||
### 2.2 项目立项
|
||||
- [ ] 催保万全
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,3 @@
|
||||
1. 看看目前下钻都做了什么；
|
||||
2. 对于每个责任部门的IPTV分析，考查是否有突变增大的情况；
|
||||
3. 先分析以下目前IPTV较高的零件和供应商；
|
||||
@@ -0,0 +1,3 @@
|
||||
1. 冬季续航打折评价：
|
||||
1. 每%SOC对应释放的电量，这个应该和用SOC反推标称容量区别在哪里；
|
||||
2.
|
||||
@@ -0,0 +1,9 @@
|
||||
1. 背景：有用户使用SE权限给极越01充电后，再使用极越01的对外放电功能为其他车辆充电；
|
||||
2. 目标：找出可能的违规使用SE权限的案例；
|
||||
3. 假设：
|
||||
1. 违规用户一定是SE用户；
|
||||
2. 违规用户的充电量应明显高于正常用户；
|
||||
3. 违规用户的行驶里程与其充电量明显不成比例；
|
||||
4. 可能的特征：
|
||||
1. 动力电池输出电量与电机电耗、DCDC电耗和热管理电耗差值较大；
|
||||
2. 日均充电次数高，每次平均充电量大(充电起始SOC);
|
||||
@@ -0,0 +1,7 @@
|
||||
1. 目前策略：
|
||||
1. 充电后的续航里程：根据历史能耗和可用能量计算可用的续航里程，同时要求计算得出的续航里程值不小于标称续航\*SOC的一半;
|
||||
2. 行驶中的续航里程：根据历史能耗和剩余可用能量计算可用的续航里程，若SOC上升则续航里程也上升，但如果上升里程小于5km的时候不实施；
|
||||
2. 可能衍生的问题：
|
||||
1. 在充电前能耗较低显示的续航里程较多，之后行驶时，能耗升高，导致续航里程下降过快；
|
||||
2. 由于存在50%的续航里程显示限制，可能导致行驶时续航里程下降过快；
|
||||
3.
|
||||
@@ -0,0 +1,29 @@
|
||||
#### 2023年12月12日版本
|
||||
1. 背景：
|
||||
1. 目前以连续的usegmode划分行程，无法准确地反应用户的用车习惯，一个行程应包括上车准备，行驶，临时停车，行驶，下车前动作，下车锁车几个部分
|
||||
2. 应该将连续的多段usegmode合并到一个行程中
|
||||
3. 要解决的问题是以何种规则合并比较合理
|
||||
2. 划分行程合理性的依据：
|
||||
1. 假设大多数用户是通勤需求；
|
||||
2. 参考《2023年度中国主要城市通勤监测报告》；
|
||||
1. 分析用户所在地，放一个饼图；
|
||||
2. 说明用户大多在主要城市，可以参考报告中的通勤时间和通勤距离；
|
||||
3. 不合理的划分会引起的问题：
|
||||
1. 行程数过多；
|
||||
2. 行程时间和里程过短；
|
||||
4. 报告内容：
|
||||
1. 现有划分方式下行程个数分布，平均行程时间和里程分布；
|
||||
2. 行驶状态usgmode之间间隔分布，去除连续的时间；
|
||||
3. 按新划分方式下行程个数分布，平均行程时间和里程分布；
|
||||
4. 使用工作日的行程次数、行驶时长和行程里程与报告中的通勤时间和通勤距离相比，确定合理性；
|
||||
5. 同时列一下整周的行程次数、行驶时长和行程里程；
|
||||
|
||||
|
||||
#### 2023年12月12日后版本
|
||||
1. 目标：
|
||||
1. 行程划分基础：以连续的usage mode=2，11，13划分行程，仅设置极短的间隔时间来合并用户异常的快速上下电操作和数据上的异常情况；
|
||||
2. 确定极短的间隔时间是多短比较好；
|
||||
2. 分析内容：
|
||||
1. 连续的usage mode=2，11，13合并行程后，较短的0和1的时间分布情况，并根据分布情况确定几个待选的合并间隔；
|
||||
2. 根据上面确定的待选合并间隔确定最终的行程合并方案，要考虑行程的次数分布、行程行驶里程和时长，对比不同间隔下，短时间行程(如5分钟以内)的行程的(行程时长)分布变化；
|
||||
3. 要给出一些特殊case的分析，如星亮给的两辆车以及行程合并后两次行程间隔较短的车辆情况，探讨其行程没有被合并是否合理；
|
||||
@@ -0,0 +1,4 @@
|
||||
1. 都有哪些种类
|
||||
1. 误激活换档器，什么叫误激活换档器，激活换档器之后，档位未变
|
||||
2. 误换档，档位持续时间为1s。
|
||||
3.
|
||||
@@ -0,0 +1,6 @@
|
||||
### 要回答的问题：
|
||||
|
||||
|
||||
1. 用户使用自动挡的意愿？明日使用自动挡时长占比来计算？
|
||||
2. 为什么用户会退出雨刮的自动挡？天气情况如何？车速情况如何？
|
||||
3. 退出后用户是调到哪个档位？
|
||||
@@ -0,0 +1,22 @@
|
||||
1. 目的：探索预估续航的准确性
|
||||
2. 评价标准：单次行程中续航里程的变化情况（~~变化速率，跳变情况，~~续航里程的变化情况，与实际里程之间的差距），行程前后实际里程与预估里程的差距
|
||||
3. 数据量：取10日至16日的行程进行计算
|
||||
4. 总体情况：
|
||||
1. 准确性分布
|
||||
1. 里程的影响
|
||||
2. 温度的影响
|
||||
3. 热管理功率的影响
|
||||
4. 驾驶模式的影响：平均车速，最大车速，车速方差，平均加速度，最大加速度，加速度方差，平均减速度，最大减速度，减速度方差，驾驶激烈评价
|
||||
2. 跟随性分布
|
||||
1. 同上;
|
||||
5. 特殊案例探查
|
||||
1. 实际里程远长于预估里程
|
||||
2. 实际里程远短于预估里程
|
||||
3. 行程中预估里程增长
|
||||
4. 预估里程长时间不变／下降过慢
|
||||
5. 行程中预估里程变化与实际里程差距过大
|
||||
6. 问题
|
||||
1. 如何定义下降速度
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
1. 整车工程对接
|
||||
1. 建立对标数据库，至少包括存储空间、总布置对标数据；
|
||||
2. 开发能量管理相关看板，至少包括车辆能耗、能量流、续航里程、小电池补电；
|
||||
3. 售后相关数据支持
|
||||
|
||||
1. 触点产品
|
||||
1.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,33 @@
|
||||
- 整车工程工作责任
|
||||
- 内饰：内饰硬件、结构件开发，安全气囊、安全带、内灯、智能表面
|
||||
- 进入系统：门及其控制器开发，数字钥匙和NFC钥匙开发
|
||||
- 外饰：外饰硬件、结构件开发，外灯、窗等
|
||||
- 底盘
|
||||
- 三电
|
||||
- 热管理
|
||||
- 整车集成
|
||||
- 可能的业务需求
|
||||
- 需求定义阶段：
|
||||
- 用户使用习惯统计
|
||||
- 驾驶习惯，用车习惯，充电习惯
|
||||
- 功能使用习惯
|
||||
- 对标数据
|
||||
- 对标数据库
|
||||
- 爬虫，这个需要我们写么？
|
||||
- 功能开发阶段
|
||||
- 试验车异常情况监控
|
||||
- 开发结果验证
|
||||
- 模型评价与调优，这个主要是数据支持，指标计算
|
||||
- 上市交付后
|
||||
- 故障监控
|
||||
- 大面积故障识别
|
||||
- 单车故障排查
|
||||
- 专项故障调查
|
||||
- 用户使用情况
|
||||
- 重点功能渗透率
|
||||
- 重点功能指标劣化异动监控和分析
|
||||
- 不同版本变更前后差异反馈
|
||||
- 人员需求：
|
||||
- 内饰，外饰，进入系统：一人，主要工作：建立维护相关系統对标数据库；编写爬虫获取数据；统计计算用户对内外饰和进入系统的使用习惯，相关系统重点功能的渗透率；与业务方共同制定功能评价指标体系，并建立对应数据集；监控关键指标异动，支持专项功能优化和故障排查；
|
||||
- 三电，热管理：一人，主要工作：统计用户的用车习惯，如行程里程和时长；车辆能耗、续航里程数据分析，建立续航里程、能耗异常监控看板，为续航里程模型优化提供数据支持；编写算法识别不同工况边界条件；支持专项问题优化和排查；
|
||||
- 底盘，整车集成：一人，主要工作：建立维护相关系统对标数据库；监控车辆制动、转向和悬架系统故障情况，支持专项故障排查，单车故障调查及重大事故调查工作；支持NVH分析与优化
|
||||
@@ -0,0 +1,7 @@
|
||||
1. 使用模式和充电状态时间融合：
|
||||
1. 先确定为什么有的充电状态结束时间是null，计划填充当日23:59:59
|
||||
2. 对充电状态的开始和结束时间进行格式化；
|
||||
3. 将使用模式开始和结束时间，充电状态的开始和结束时间union all；
|
||||
4. 分别对开始时间和结束时间排序，并用row_number赋予行号rn；
|
||||
5. 将开始时间和结束时间进行left join，条件为 vid相等，且rn相等；
|
||||
6. 使用lead、lag串行重新配对开始和结束时间；
|
||||
@@ -0,0 +1,29 @@
|
||||
#### 2023年12月12日版本
|
||||
1. 背景：
|
||||
1. 目前以连续的usegmode划分行程，无法准确地反应用户的用车习惯，一个行程应包括上车准备，行驶，临时停车，行驶，下车前动作，下车锁车几个部分
|
||||
2. 应该将连续的多段usegmode合并到一个行程中
|
||||
3. 要解决的问题是以何种规则合并比较合理
|
||||
2. 划分行程合理性的依据：
|
||||
1. 假设大多数用户是通勤需求；
|
||||
2. 参考《2023年度中国主要城市通勤监测报告》；
|
||||
1. 分析用户所在地，放一个饼图；
|
||||
2. 说明用户大多在主要城市，可以参考报告中的通勤时间和通勤距离；
|
||||
3. 不合理的划分会引起的问题：
|
||||
1. 行程数过多；
|
||||
2. 行程时间和里程过短；
|
||||
4. 报告内容：
|
||||
1. 现有划分方式下行程个数分布，平均行程时间和里程分布；
|
||||
2. 行驶状态usgmode之间间隔分布，去除连续的时间；
|
||||
3. 按新划分方式下行程个数分布，平均行程时间和里程分布；
|
||||
4. 使用工作日的行程次数、行驶时长和行程里程与报告中的通勤时间和通勤距离相比，确定合理性；
|
||||
5. 同时列一下整周的行程次数、行驶时长和行程里程；
|
||||
|
||||
|
||||
#### 2023年12月12日后版本
|
||||
1. 目标：
|
||||
1. 行程划分基础：以连续的usage mode=2，11，13划分行程，仅设置极短的间隔时间来合并用户异常的快速上下电操作和数据上的异常情况；
|
||||
2. 确定极短的间隔时间是多短比较好；
|
||||
2. 分析内容：
|
||||
1. 连续的usage mode=2，11，13合并行程后，较短的0和1的时间分布情况，并根据分布情况确定几个待选的合并间隔；
|
||||
2. 根据上面确定的待选合并间隔确定最终的行程合并方案，要考虑行程的次数分布、行程行驶里程和时长，对比不同间隔下，短时间行程(如5分钟以内)的行程的(行程时长)分布变化；
|
||||
3. 要给出一些特殊case的分析，如星亮给的两辆车以及行程合并后两次行程间隔较短的车辆情况，探讨其行程没有被合并是否合理；
|
||||
@@ -0,0 +1,20 @@
|
||||
1. 指标体系
|
||||
1. 充电操作
|
||||
1. 充电时段，开始和结束的时段（工作日和休息日），充电时长，低收费时段和高低费时刻
|
||||
2. 充电桩类型
|
||||
3. 充电开始SOC,充电结束SOC
|
||||
4. 平均充电量
|
||||
5. 充电目标SOC分布
|
||||
2. 充电间隔
|
||||
1. 两次充电之间的行驶里程分布
|
||||
2. 两次充电之间行驶次数
|
||||
3. 平均充电间隔分布，按季节区别
|
||||
~~4. 能否知道为了充电的平均行驶里程~~
|
||||
3~~. 预约充电
|
||||
1. 预约充电的使用频率
|
||||
2. 预约的充电时段
|
||||
3. 预约充电的设置源，手机和屏幕~~
|
||||
4. 其他
|
||||
1. 充电次数与电池健康度关系
|
||||
~~5. ~~预约充电和直~~接充电的差别
|
||||
1. ~~充电开始时间的差别~~~~
|
||||
@@ -0,0 +1,19 @@
|
||||
1. 外灯自动档使用时长
|
||||
1. 时间段
|
||||
2. 阳光量
|
||||
3. 环境光量
|
||||
4. 车速
|
||||
5. 手动切换的次数
|
||||
1. 开启次数
|
||||
2. 关闭次数
|
||||
2. 自动远光灯
|
||||
1. 时间段
|
||||
2. 阳光量
|
||||
3. 环境光量
|
||||
4. 车速
|
||||
5. 白天黑夜状态
|
||||
6. 跟车距离
|
||||
7. 对向车距离
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
1. 空调自动模式设置率：
|
||||
1. 自动模式组成：
|
||||
1. 风速自动控制模式设置率
|
||||
2. 吹风自动控制模式设置率：
|
||||
1. 主驾吹风自动控制模式设置率
|
||||
2. 副驾有人且吹风自动控制模式设置率
|
||||
3. 内外循环自控制模式设置率
|
||||
2. 外部影响因素：
|
||||
1. 内外温度差（座舱内温度- 环境温度）
|
||||
2. 环境温度
|
||||
~~3. 地域~~
|
||||
~~4. 时间段~~
|
||||
5. 湿度
|
||||
6. 阳光量
|
||||
7. 电池SOC
|
||||
8. PM 2.5
|
||||
9. 空气质量
|
||||
10. 雨量大小，是否下雨
|
||||
11. 用户设置的空调温度
|
||||
12.
|
||||
@@ -0,0 +1,37 @@
|
||||
1. 车门电动开启渗透率：
|
||||
1. 影响因素：哪些客观因素影响用户使用
|
||||
1. 时空因素：
|
||||
1. 地域
|
||||
2. 出行时间（tbd）
|
||||
2. 用车习惯：
|
||||
1. 用车频率
|
||||
3. 用车目的，如网约车？（tbd）
|
||||
2. 流失率：用户为什么关闭电动开门设置，***用户可能不会关闭设置***
|
||||
1. 地域因素
|
||||
2. 车门电动开启完成率：
|
||||
1. 时空因素：
|
||||
1. 时间段
|
||||
2. 地域因素
|
||||
2. 失败原因：
|
||||
1. 解锁失败原因
|
||||
2. 移动失败原因
|
||||
3. 手动干预原因 ***目前的无手动干预指门开，门不处在最小位置且门未上报向外移动受阻，开启过程中停止，如果手动拉到指定位置也算成功***
|
||||
3. 不同触发源的成功率
|
||||
4. 不同位置的成功率
|
||||
3. 车门电动关闭完成率：
|
||||
1. 与开启相同
|
||||
|
||||
流失原因分析：
|
||||
1. 失败率较高
|
||||
1. 故障：
|
||||
1. 解锁故障
|
||||
2. 移动故障
|
||||
1. 破冰失败
|
||||
3. 手动干预原因：开或停止门
|
||||
1. 停止后手动干预，有障碍物／无障碍物
|
||||
2. 防夹触发后，手动干预
|
||||
|
||||
2. 出现／接近现事故
|
||||
1. 未检测到障碍物时门开受阻或停止
|
||||
3. 开门情况不满意
|
||||
1. 开门速度较慢→开门速度跳变
|
||||
@@ -0,0 +1,7 @@
|
||||
1. 雨刮自动模式时长占比
|
||||
1. 雨量大小
|
||||
2. 阳光量
|
||||
3. 时间段
|
||||
4. 地域
|
||||
5. 手动干预的方向（快或慢）
|
||||
6. 车速
|
||||
@@ -0,0 +1,3 @@
|
||||
1. 问题：
|
||||
1. 热管理能耗和PTC能耗、压缩机能耗和水泵能耗之间的关系
|
||||
2.
|
||||
Reference in New Issue
Block a user