Update from Sync Service
This commit is contained in:
Binary file not shown.
@@ -0,0 +1,14 @@
|
||||
---
|
||||
|
||||
excalidraw-plugin: parsed
|
||||
tags: [excalidraw]
|
||||
|
||||
---
|
||||
==⚠ Switch to EXCALIDRAW VIEW in the MORE OPTIONS menu of this document. ⚠== You can decompress Drawing data with the command palette: 'Decompress current Excalidraw file'. For more info check in plugin settings under 'Saving'
|
||||
|
||||
|
||||
## Drawing
|
||||
```compressed-json
|
||||
N4IgLgngDgpiBcIYA8DGBDANgSwCYCd0B3EAGhADcZ8BnbAewDsEAmcm+gV31TkQAswYKDXgB6MQHNsYfpwBGAOlT0AtmIBeNCtlQbs6RmPry6uA4wC0KDDgLFLUTJ2lH8MTDHQ0YNMWHRJMRZFAFZFFjIkT1UYRjAaBABtAF1ydCgoAGUAsD5QSXw8LOwNPkZOTExyHRgiACF0VABrQq5GXABhekx6fAQQAGIAM1GxkABfCaA==
|
||||
```
|
||||
%%
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
doc_type: hypothesis-highlights
|
||||
url: 'https://www.zhihu.com/tardis/zm/art/366993073?source_id=1003'
|
||||
---
|
||||
# additive attention与dot-product attention
|
||||
|
||||
## Metadata
|
||||
|
||||
- Title: additive attention与dot-product attention
|
||||
|
||||
- Reference: https://www.zhihu.com/tardis/zm/art/366993073?source_id=1003
|
||||
|
||||
- Category: #source/article🗞
|
||||
|
||||
- Tags:
|
||||
|
||||
## Highlights
|
||||
|
||||
- “加型注意力机制”与“点积型注意力机制”最大的区别就是解码器隐状态与编码器输出的编码的交互过程,也就是两者关系大小的评估过程。在这里传统编码-解码结构使用了一个全连接神经网络结构,意味着两者的关系是加和的关系。因为我们知道全连接神经网络的公式是 ,如果将解码器的隐状态 和编码器每一步的隐状态 分别视作全连接神经网络的 和 的话,计算公式显然为 ,显然这里解码器隐状态与编码器输出编码的交互方式为加和。
|
||||
|
||||
|
||||
|
||||
- 矩阵 和矩阵 、 的交互为矩阵的乘积,所以这里解码器隐状态与编码器输出编码的交互方式为乘积。
|
||||
|
||||
|
||||
|
||||
- 根据Transformer论文的说法,加型注意力机制和点乘注意力机制有着相同的计算复杂度,但点乘注意力机制运算可以使用高度优化的并行矩阵乘法代码,会更快也更节省空间。
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
- [x] 闻香识女人
|
||||
- [x] 42号传奇
|
||||
- [x] 触不可及
|
||||
- [ ] 指环王
|
||||
- [ ] 教父
|
||||
- [ ] 阿甘正传
|
||||
- [ ] 美丽人生
|
||||
- [ ] 末代皇帝
|
||||
- [ ] 蝙幅侠:黑暗骑士
|
||||
- [ ] 天堂电影院
|
||||
- [ ] 美丽心灵
|
||||
- [ ] 血战钢锯岭
|
||||
@@ -0,0 +1,15 @@
|
||||
## 必须的
|
||||
|
||||
- [ ] 儿童安全座椅
|
||||
- [ ] 爬爬垫
|
||||
- [ ] 围栏
|
||||
- [ ] 婴儿保险
|
||||
- [ ] 重疾
|
||||
- [ ] 意外
|
||||
- [ ] 小额医疗
|
||||
|
||||
|
||||
## 没啥用的
|
||||
|
||||
- [ ] 子擎loong传感器
|
||||
- [ ] 窗帘伴侣
|
||||
@@ -0,0 +1 @@
|
||||
1.
|
||||
@@ -0,0 +1,29 @@
|
||||
|
||||
## 学习内容
|
||||
|
||||
1. 投资知识: 投资知识要主动学习,目标为读懂财报可以在感兴趣的赛道中选取合适的企业,再通过技术指标和量化分析确定入/离场时间;
|
||||
- [ ] 财报分析
|
||||
- [ ] 技术指标
|
||||
- [ ] Python量化
|
||||
|
||||
2. 带娃知识:带娃知识要主动学习,要让宝宝能健康成长,并且爸妈不焦虑;
|
||||
- [ ] 每月大运动目标
|
||||
- [ ] 每月益智游戏
|
||||
- [ ] 喂养方法
|
||||
|
||||
3. 专业知识:这个主要通过工作中学习获取,要及时进行总结;
|
||||
1. 数据库
|
||||
1. 数据库基础
|
||||
2. SQL优化
|
||||
2. 数理统计
|
||||
|
||||
4. 个人兴趣
|
||||
1. IT技术
|
||||
1. 个人服务器维护
|
||||
2. Linux知识
|
||||
3. 编程能力
|
||||
4. rime维护
|
||||
2. 智能家居
|
||||
1. 米家极客版
|
||||
2. Hass
|
||||
3. 军事和历史
|
||||
@@ -0,0 +1,34 @@
|
||||
## 1. 工作内容
|
||||
|
||||
1. 空调屏幕操作便利性: ^8f1112
|
||||
1. 与yajia交流完成,按原内容完成温度等操作所需步骤和时间 [[2024年9月11日#^173d6f]]^7547e8
|
||||
2. 能量流宽表的验证[[2024年9月11日#^d1a013]]: ^6c1d4f
|
||||
1. 热管理低压侧能耗有问题;
|
||||
2. 驾驶信息(车速、加速度等)有问题;
|
||||
3. 售后判则线上表:
|
||||
1. 还需要验证一下 柴工改完的结果[[2024年9月11日#^02a71e]]; ^c82f87
|
||||
4. 胎压检测需求: ^ee8cca
|
||||
1. 需要跟业务方要一下tcam log的解析方式[[2024年9月11日#^4033ba]];
|
||||
2. 需要梳理一下还需要哪些信号;
|
||||
5. 洗车模式渗透率:
|
||||
1. *已完成报告;* ^b399be
|
||||
6. 看板开发:
|
||||
1. 调整了电动开门模式使用的字段[[2024年9月11日#^4b33f9]];
|
||||
1. 要检查一下电动开门渗透率是否正常;
|
||||
2. 对出行分析看板增加了需要的字段[[2024年9月11日#^3f1dd4]]; ^1d7422
|
||||
1. 需要在看板上增加筛选项;
|
||||
7. 能耗售后报告内容更新:
|
||||
1. 与康建沟通了需求; ^e6f389
|
||||
8. 待开展工作:
|
||||
1. KC数据库PDF解析; ^a6d34a
|
||||
1. 主要是解决pandas操作Excel的问题[[2024年9月11日#^2990a0]]
|
||||
2. 探查方向盘按键控制播放功能占比[[2024年9月11日#^1c4ba4]]:
|
||||
1. 更新看板,增加到看板上;
|
||||
|
||||
## 2. 生活
|
||||
1. 今天又没有健身;
|
||||
2. 提醒老婆约下周的按摩;
|
||||
3. 坐班车好像还是挺舒服的~
|
||||
|
||||
## 3. 阅读
|
||||
1. 继续阅读《一本书读懂财报》;
|
||||
@@ -0,0 +1,31 @@
|
||||
## 1. 工作内容
|
||||
|
||||
1. 空调屏幕操作便利性:
|
||||
1. 调整了所需操作时间和步骤的数据底表[[2024年9月13日#^636e6e]]; ^173d6f
|
||||
2. 售后判则线上表:
|
||||
1. 验证完成,待柴工维护业务数据owner; ^02a71e
|
||||
2. 搭建看板[[2024年9月13日#^b67cea]];
|
||||
3. 胎压检测需求:
|
||||
1. 继续对接tcam log的解析方法,考虑要不要拉个会[[2024年9月13日#^71091c]]; ^4033ba
|
||||
4. 看板开发:
|
||||
1. 完成电动开门渗透率的调整; ^4b33f9
|
||||
2. 完成出行分析看板所需内容的增加; ^3f1dd4
|
||||
5. KC数据库PDF解析[[2024年9月13日#^10b927]]:
|
||||
1. 完成解析,需要总结一下用到的函数(pd.melt等) ^2990a0
|
||||
6. 待开展工作:
|
||||
1. 能量流宽表的验证[[2024年9月13日#^120775]]; ^d1a013
|
||||
2. 探查方向盘按键控制播放功能占比:
|
||||
1. 更新看板,增加到看板上[[2024年9月13日#^7928e4]]; ^1c4ba4
|
||||
3. 给生管和质量使用的view写一个仓颉任务,以方便查看[[2024年9月13日#^2ab874]];
|
||||
7. **工作中待改进内容**:
|
||||
1. 多项任务切换不太明确,一项任务完成或受阻的时候不知道下一步该干啥;
|
||||
|
||||
## 2. 生活
|
||||
1. 今天健身啦,快走25分钟,明天记得穿运动鞋;
|
||||
2. 提醒老婆约下周的按摩;
|
||||
3. 要研究一下孩子的保险;
|
||||
1. 先看看卜卓家娃的保险;
|
||||
|
||||
## 3. 阅读
|
||||
1. 继续阅读《一本书读懂财报》;
|
||||
1. 试着分析一下均胜电子和德赛西威的还债能力;
|
||||
@@ -0,0 +1,30 @@
|
||||
## 1. 工作
|
||||
|
||||
1. 售后判则线上表[[2024年9月18日#^4dc5c5]]: ^b67cea
|
||||
1. 看板搭建中,需要验证日报看板数据准确性;
|
||||
2. 重新搭建周报看板;
|
||||
3. 胎压检测需求[[2024年9月18日#^2fe7ee]]:
|
||||
1. tcam log接入持续沟通中; ^71091c
|
||||
4. 能量流宽表的验证[[2024年9月18日#^636c62]]:
|
||||
1. 空调使用的这些平均值问题很大; ^120775
|
||||
5. KC数据库PDF解析:
|
||||
1. 等待葛工的结论; ^10b927
|
||||
6. 空调屏幕操作便利性[[2024年9月18日#^94c130]]:
|
||||
1. 图都已经出完了,要把报告写出来; ^636e6e
|
||||
7. 待开展工作:
|
||||
1. 给生管和质量使用的view写一个仓颉任务,以方便查看; ^2ab874
|
||||
2. 生管实时表哪些字段要能重新写成null[[2024年9月18日#^31e0bf]];
|
||||
3. 生管实时表中有哪些案例同步日期和实际日期对不上;
|
||||
4. 看板需求:
|
||||
1. 车辆配置看板加入极越07的信息;
|
||||
2. 充电分析看板上增加充电桩类型、充电量分布;
|
||||
3. 唐锐需求: ^7928e4
|
||||
1. 方向盘按键控制播放功能占比;
|
||||
2. 用户出行时行程开始的环境温度;
|
||||
|
||||
## 2. 生活
|
||||
1. 买了新的模型,感觉不错;
|
||||
|
||||
## 3. 阅读
|
||||
1. 继续阅读《一本书读懂财报》;
|
||||
1. 试着分析一下均胜电子和德赛西威的还债能力;
|
||||
@@ -0,0 +1,26 @@
|
||||
## 1. 工作
|
||||
|
||||
1. 售后判则看板搭建:
|
||||
1. 已完成看板的搭建[[2024年9月19日#^48b288]]; ^4dc5c5
|
||||
2. 胎压检测需求:
|
||||
1. tcam log接入持续沟通中,确定tcam log可以解析,还是卡在时间戳上[[2024年9月19日#^35a13b]]; ^2fe7ee
|
||||
3. 空调屏幕操作便利性:
|
||||
1. 报告写好了,需要和yajia再对一下; ^94c130
|
||||
4. 能量流宽表的验证:
|
||||
1. 需要尽快把验证报告写好交给ruiwei; ^636c62
|
||||
5. 生管实时表哪些字段要能重新写成null:
|
||||
1. 确定只有锁单时间可以变回null; ^31e0bf
|
||||
6. 电池寿命影响因素分析:
|
||||
1. 已经写好了取数逻辑,需要写报告[[2024年9月19日#^1b5f8d]];
|
||||
2. 跟jian.kang商量一下行程车速的分布的怎么处理;
|
||||
7. 待开展工作:
|
||||
1. 给生管和质量使用的view写一个仓颉任务,以方便查看; ^2ab874
|
||||
2. 生管实时表中有哪些案例同步日期和实际日期对不上;
|
||||
3. 看板需求:
|
||||
1. 车辆配置看板加入极越07的信息[[2024年9月19日#^726de5]];
|
||||
2. 充电分析看板上增加充电桩类型、充电量分布;
|
||||
3. 唐锐需求: ^7928e4
|
||||
1. 方向盘按键控制播放功能占比;
|
||||
2. 用户出行时行程开始的环境温度;
|
||||
## 2. 阅读
|
||||
1. 读完了《一本书读懂财报》;
|
||||
@@ -0,0 +1,24 @@
|
||||
## 1. 工作
|
||||
|
||||
|
||||
1. 售后判则看板搭建:
|
||||
1. 进一步调整了口径;
|
||||
2. 需要和业务进一步拉齐,确定口径[[2024年9月23日#^1b1f42]]; ^48b288
|
||||
2. 胎压检测需求:
|
||||
1. tcam log可以接入了[[2024年9月23日#^a86b36]]; ^35a13b
|
||||
3. 电池寿命影响因素分析:
|
||||
1. 确定好了需求[[2024年9月23日#^3d6d1f]]; ^1b5f8d
|
||||
4. 车辆配置看板加入极越07的信息:
|
||||
1. 已经确定好了数据源[[2024年9月23日#^a1c758]]; ^726de5
|
||||
5. 2.0版本ASD能耗对比:
|
||||
1. 已经写好了取数的SQL,还需要跑2.0升级后的数据[[2024年9月23日#^d1c9ef]];
|
||||
6. 待开展工作:
|
||||
1. 给生管和质量使用的view写一个仓颉任务,以方便查看; ^2ab874
|
||||
2. 生管实时表中有哪些案例同步日期和实际日期对不上[[2024年9月23日#^106312]];
|
||||
3. 看板需求:
|
||||
1. 空调屏幕操作便利性报告要和yajia对一下[[2024年9月23日#^f0f01d]];
|
||||
2. 尽快把能量流宽表验证报告写好交给ruiwei;
|
||||
3. 充电分析看板上增加充电桩类型、充电量分布[[2024年9月23日#^92f3bd]];
|
||||
4. 唐锐需求: ^7928e4
|
||||
1. 方向盘按键控制播放功能占比;
|
||||
2. 用户出行时行程开始的环境温度[[2024年9月23日#^42ff84]];
|
||||
@@ -0,0 +1,38 @@
|
||||
## 1. 工作
|
||||
|
||||
1. 售后判则看板搭建:
|
||||
1. 拉齐了业务方,确定了口径; ^1b1f42
|
||||
2. 需要修改逻辑;
|
||||
2. 胎压检测需求:
|
||||
1. 继续沟通tcam解析方法; ^a86b36
|
||||
2. 需要整理一下其他指标的取数方法;
|
||||
3. 电池寿命影响因素分析:
|
||||
1. 已完成报告; ^3d6d1f
|
||||
2. 后续增加看板内容;
|
||||
4. 车辆配置看板加入极越07的信息:
|
||||
1. 完成看板的搭建; ^a1c758
|
||||
2. 尚缺少选装包(方向盘和轮辋)的配置信息,待郭老师补上;
|
||||
5. 2.0版本ASD能耗对比:
|
||||
1. 已完成报告; ^d1c9ef
|
||||
6. 生管实时表中有哪些案例同步日期和实际日期对不上:
|
||||
1. 取数完成,1:1的时候确定一下23点过点,第二天0点同步数据的算不算问题; ^106312
|
||||
7. 空调屏幕操作便利性报告:
|
||||
1. 已与yajia沟通; ^f0f01d
|
||||
2. 增加单词调整温度区间分布;
|
||||
8. 充电分析看板上增加充电桩类型、充电量分布:
|
||||
1. 已在看板上添加; ^92f3bd
|
||||
9. 用户出行时行程开始的环境温度:
|
||||
1. 已在看板上添加; ^42ff84
|
||||
10. 待开展工作:
|
||||
1. 给生管和质量使用的view写一个仓颉任务,以方便查看;
|
||||
2. 唐锐需求:
|
||||
1. 方向盘按键控制播放功能占比;
|
||||
2. 空调下面两个出风口水平开启量;
|
||||
3. 售后抱怨报告更新;
|
||||
4. 尽快把能量流宽表验证报告写好交给ruiwei;
|
||||
|
||||
## 2. 明日工作重点
|
||||
|
||||
1. 把售后判则看板逻辑更新好;
|
||||
2. 完成能量宽表验证报告;
|
||||
3. 提供胎压检测其他指标的取数方法;
|
||||
@@ -0,0 +1,32 @@
|
||||
## 1. 工作内容
|
||||
|
||||
1. 完成了屏幕上操作空调所需时长的出图,已经发给yajia;
|
||||
1. Next Step:与yajia交流,确定需求,完成报告其余部分;[[2024年9月10日#^7547e8]]
|
||||
2. 开始了能量流宽表的验证:
|
||||
1. 电池热管理能耗有问题;[[2024年9月10日#^6c1d4f]]
|
||||
3. 售后判则线上表:
|
||||
1. *完成验证工作;* [[2024年9月10日#^c82f87]]
|
||||
2. 接下来是搭建看板;
|
||||
4. 胎压检测需求:
|
||||
1. *沟通需求;*
|
||||
2. *WTI报警有埋点数据;*
|
||||
3. TCAM日志需要接入,需要梳理一下还需要哪些信号;[[2024年9月10日#^ee8cca]]
|
||||
5. 洗车模式渗透率:
|
||||
1. *找好了语音和屏幕的埋点内容;*
|
||||
2. 下一步需求取数,写报告;[[2024年9月10日#^b399be]]
|
||||
6. 待开展工作:
|
||||
1. 能耗售后报告内容更新;[[2024年9月10日#^e6f389]]
|
||||
2. 康建看板需求搭建;[[2024年9月10日#^1d7422]]
|
||||
3. KC数据库PDF解析;[[2024年9月10日#^a6d34a]]
|
||||
1. 主要是解决pandas操作Excel的问题
|
||||
|
||||
## 2. 生活
|
||||
|
||||
1. 今天是2周年的结婚纪念日;
|
||||
2. 要了婴儿推车的优惠;
|
||||
3. 又没做锻炼;
|
||||
|
||||
## 3. 阅读
|
||||
1. 整理了一下豆瓣上的信息;
|
||||
2. 继续阅读《一本书读懂财报》;
|
||||
3.
|
||||
@@ -0,0 +1,5 @@
|
||||
在注意力机制中,key是用于参考的信息,通常是由Encoder产生的表示数据,它与查询向量(query)共同用于计算当前位置下上下文向量(context vector)的权重。对于原始输出的key(比如,CNN中的feature map),往往需要通过一些变换(如一个全连接层)将维度缩小,以通过query和key之间的相似度计算了解关注的位置。
|
||||
|
||||
具体来说,Encoder中的输出通常是一个二维矩阵,其维度为[batch_size, hidden_size],其中hidden_size表示representation的大小。当我们将Encoder的输出作为key时,首先需要为key定义权重向量(weight vector),来描述当前query与key的相似度。由于key的输入维度至少是hidden_size才能提取出有意义的信息,因此通常会将hidden_size的维度扩展至2倍,即2*hidden_size。
|
||||
|
||||
这种做法的主要目的是增加模型的表达能力,通过增加key的维度,可以更好地捕捉到query和key之间的暗示关系,进而提高模型的性能。同时,这种做法也可以通过增加参数数量使模型更加复杂。不过对于使用不同类型的Encoder或Decoder,key维度(或其他变换操作)可能会有所改变,具体操作以实际模型为准。
|
||||
@@ -0,0 +1,17 @@
|
||||
|
||||
## AARRR海盗模型
|
||||
|
||||
海盗模型是用户分析的经典模型,它反映了增长是系统性地贯穿于用户生命周期各个阶段:
|
||||
|
||||
A 拉新(Acquisition): 通过各种推广渠道,以各种方式获取目标用户,并对各种营销渠道的效果评估,不断优化投入策略,降低获客成本。
|
||||
- 涉及关键指标例如 新增注册用户数、激活率、注册转化率、新客留存率、下载量、安装量等,我们通过这些指标就可反应出获取目标用户的效果是怎样的。
|
||||
|
||||
A 活跃(Activation):活跃用户指真正开始使用了产品提供的价值,我们需要掌握用户的行为数据,监控产品健康程度。这个模块主要反映用户进入产品的行为表现,是产品体验的核心所在。
|
||||
|
||||
- 涉及关键指标例如 DAU/MAU 、日均使用时长、启动APP时长、启动APP次数等。通过这些指标可以反映出用户的活跃情况。
|
||||
|
||||
R 留存(Retention):衡量用户粘性和质量的指标。涉及关键指标例如 留存率、流失率等。通过这些指标可以反映出用户的留存情况。
|
||||
|
||||
R 变现(Revenue): 主要用来衡量产品商业价值。涉及关键指标例如 生命周期价值(LTV)、客单价、GMV等。这些指标可以反映出产品的商业价值。
|
||||
|
||||
R 推荐(Referral):衡量用户自传播程度和口碑情况。涉及关键指标例如 邀请率、裂变系数等。
|
||||
@@ -0,0 +1,176 @@
|
||||
---
|
||||
doc_type: hypothesis-highlights
|
||||
url: 'https://www.cnblogs.com/cxuanBlog/p/14917187.html'
|
||||
---
|
||||
|
||||
# MQTT 协议是个啥?这篇文章告诉你! - 程序员cxuan - 博客园
|
||||
|
||||
## Metadata
|
||||
- Author: [cnblogs.com]()
|
||||
- Title: MQTT 协议是个啥?这篇文章告诉你! - 程序员cxuan - 博客园
|
||||
- Reference: https://www.cnblogs.com/cxuanBlog/p/14917187.html
|
||||
- Category: #article
|
||||
|
||||
## Page Notes
|
||||
## Highlights
|
||||
|
||||

|
||||
|
||||
- 还有一个优势就是 MQTT 在客户端容易实现,而且具有易用性,非常适合当今资源有限的设备。
|
||||
|
||||
- MQTT 协议与 HTTP 相比具有一个明显的优势:数据包开销较小
|
||||
|
||||
- pub/sub 最重要的方面是 publisher 与 subscriber 的解藕
|
||||
|
||||
- 空间解耦
|
||||
- 时间解藕
|
||||
- 同步 Synchronization 解藕
|
||||
|
||||
- 发布/订阅模式消除了传统客户-服务器之间的直接通信,把通信这个操作交给了 broker 进行代理,并在空间、时间、同步三个维度上进行了解藕。
|
||||
|
||||
- pub/sub 比传统的客户端-服务器模式有了更好的拓展,这是由于 broker 的高度并行化,并且是基于事件驱动的模式。事件驱动中的程序流程会由诸如用户操作(点击鼠标、键盘)、传感器输出或者从其他程序或传递的消息事件决定。- 事件驱动编程是图形用户界面和其他应用程序比如 Web 中使用的主要范式,这些应用程序能够响应用户输入执行某些操作为中心,这同时也适用于驱动程序的编程 。
|
||||
|
||||
- broker 能够对消息进行过滤,使每个订阅者只接收自己感兴趣的消息:
|
||||
|
||||
- 基于主题的过滤:每条消息都会有一个 topic ,接收客户端会向 borker 订阅感兴趣的 topic,订阅后,broker 就会确保客户端收到发布到 topic 中的消息
|
||||
|
||||
- 基于内容的过滤 :broker 会根据特定的内容过滤消息,接受客户端会经过过滤他们感兴趣的内容。这种方法的一个显著的缺点就是必须事先知道消息的内容,不能加密或者轻易修改
|
||||
|
||||
- 基于类型的过滤
|
||||
|
||||
- 为了发布/订阅系统的挑战,MQTT 具有三个服务质量级别,你可以指定消息从客户端传到 broker 或者从 broker 传到客户端,在 topic 的订阅中,会存在 topic 没有 subscriber 订阅的情况,作为 broker 必须知道如何处理这种情况。
|
||||
|
||||
- 订阅发布模式与消息队列模式区别
|
||||
- 在传统的消息队列模式中,一条消息会存储在消息队列中等待被消费,每个传入的消息都存储在消息队列中,直到它被客户端(通常称之为消费者)所接收,如果没有客户端消费消息的话,这条消息就会存在消息队列中等待被消费。但是在消息队列中,不会存在消息没有客户端消费的情况,但是在 MQTT 中,确存在 topic 无 subscriber 订阅的情况。
|
||||
|
||||
- 在传统的消息队列模式中,一条消息只能被一个客户端所消费,负载会分布在队列的每个消费者之间;而在 MQTT 中,每个订阅者都会受到消息,每个订阅者有相同的负载。
|
||||
|
||||
- 在传统的消息队列模式中,必须使用单独的命令来显式创建队列,只有队列创建后,才可以生产或者消费消息;而在 MQTT 中,topic 比较灵活,可以即时创建。
|
||||
|
||||
- MQTT基本概念
|
||||
- MQTT Client
|
||||
- publisher 和 subscriber 都属于 MQTT Client。
|
||||
|
||||
- 发布和订阅的功能也可以由同一个 MQTT Client 实现。
|
||||
|
||||
- MQTT 客户端是指运行 MQTT 库并通过网络连接到 MQTT broker 的任何设备,这些设备可以从微控制器到成熟的服务器.
|
||||
|
||||
- MQTT Broker
|
||||
- broker 负责接收所有消息,过滤消息,确定是哪个 client 订阅了每条消息,并将消息发送给对应的 client,broker 还负责保存会话数据,这些数据包括订阅的和错过的消息。broker 还负责客户端的身份验证和授权。
|
||||
|
||||
- MQTT 是基于 TCP/IP 协议基础之上的,所以 MQTT 的 client 和 broker 都需要 TCP/IP 协议的支持。
|
||||
|
||||
- MQTT链接
|
||||
- MQTT 的连接总是在 client 和 broker 之间进行,client 和 client 之间并不会相互连接。如果要发起连接的话,那么 client 就会向 broker 发起 CONNECT 消息,代理会使用 CONNACK 消息和状态码进行响应
|
||||
|
||||
- 一旦 client 和 broker 的连接建立后,broker 就会使客户端的连接一直处于打开状态,直到 client 发出断开命令或者连接中断。
|
||||
|
||||
- 消息
|
||||
- MQTT 的消息报文主要分为 CONNECT 和 CONNACK 消息。
|
||||
|
||||
- CONNECT
|
||||
|
||||
- 为了初始化连接,需要 client 向 broker 发送 CONNECT 消息
|
||||
|
||||
- 一个 MQTT 客户端发送一条 CONNECT 连接,这条 CONNECT 连接可能会包含下面这些信息
|
||||
|
||||

|
||||
|
||||
- ClientId:显而易见,这个就是每个客户端的 ID 标识,也就是连接到 MQTT broker 的每个 client。
|
||||
|
||||
- 这个 ID 应该是每个 client 和 broker 唯一的,如果你不需要 broker 持有状态的话,你可以发送一个空的 ClientId,空的 ClientId 会没有任何状态。在这种情况下,ClientSession 需要设置为 true,否则将会拒绝连接。
|
||||
|
||||
- CleanSession:CleanSession 会话标志会告诉 broker client 是否需要建立持久会话。在持久会话 (CleanSession = false)中,broker 存储 client 的所有订阅以及服务质量(Qos) 是 1 或 2 订阅的 client 的所有丢失的消息。如果会话不是持久的(CleanSession = true),那么 broker 则不会为 client 存储任何内容并且会清除先前持久会话中的所有信息。
|
||||
|
||||
- Username/Password :MQTT 会发送 username 和 password 进行 client 认证和授权
|
||||
|
||||
- LastWillxxx :LastWillxxx 表示的是遗愿,client 在连接 broker 的时候将会设立一个遗愿,这个遗愿会保存在 broker 中,当 client 因为非正常原因断开与 broker 的连接时,broker 会将遗愿发送给订阅了这个 topic(订阅遗愿的 topic)的 client。
|
||||
|
||||
- keepAlive:keepAlive 是 client 在连接建立时与 broker 通信的时间间隔,通常以秒为单位。这个时间指的是 client 与 broker 在不发送消息下所能承受的最大时长。
|
||||
|
||||
- CONNACK
|
||||
- 当 broker 收到 CONNECT 消息时,它有义务回复 CONNACK 消息进行响应
|
||||
|
||||
- CONNACK 消息包括两部分内容
|
||||
|
||||

|
||||
|
||||
- SessionPresent:会话当前标识,这个标志会告诉 client 当前 broker 是否有一个持久性会话与 client 进行交互。 SessionPresent 标志和 CleanSession 标志有关,当 client 在 CleanSession 设置为 true 的情况下连接时,SessionPresent 始终为 false,因为没有持久性会话可以使用。如果 CleanSession 设置为 false,则有两种可能性,如果 ClientId 的会话信息可用,并且 broker 已经存储了会话信息,那么 SessionPresent 为 true,否则如果没有 ClientId 的任何会话信息,那么 SessionPresent 为 false。
|
||||
|
||||
- ReturnCode:CONNACK 消息中的第二个标志是连接确认标志。这个标志包含一个返回码,告诉客户端连接尝试是否成功。连接确认标志有下面这些选项。
|
||||
|
||||
- 消息类型
|
||||
|
||||
- 发布
|
||||
|
||||
- MQTT 使用的是基于 topic 主题的过滤。每条消息都应该包含一个 topic ,broker 可以使用 topic 将消息发送给感兴趣的 client。除此之外,每条消息还会包含一个负载(Payload),Payload 中包含要以字节形式发送的数据。
|
||||
|
||||
- MQTT 是数据无关性的,也就是说数据是由发布者 - publisher 决定要发送的是 XML 、JSON 还是二进制数据、文本数据
|
||||
|
||||
- MQTT 中的 PUBLISH 消息结构如下
|
||||
|
||||

|
||||
|
||||
- Packet Identifier:这个 PacketId 标识在 client 和 broker 之间唯一的消息标识。packetId 仅与大于零的 Qos 级别相关
|
||||
|
||||
- TopicName:主题名称是一个简单的字符串,/ 代表着分层结构
|
||||
|
||||
- Qos:这个数字表示的是服务质量水平,服务质量水平有三个等级:0、1 和 2,服务级别决定了消息到达 client 或者 broker 的保证类型,来决定消息是否丢失
|
||||
|
||||
- RetainFlag:这个标志表示 broker 将最近收到的一条 RETAIN 标志位为true的消息保存在服务器端(内存或者文件)。MQTT 服务器只会为每一个 Topic 保存最近收到的一条 RETAIN 标志位为true的消息
|
||||
|
||||
- Payload:这个是每条消息的实际内容
|
||||
|
||||
- Dupflag:这个标志表示该消息是重复的并且由于预期的 client 或者 broker 没有确认所以重新发送了一次。
|
||||
|
||||
- 当 client 向 broker 发送消息时,broker 会读取消息,根据 Qos 的级别进行消息确认,然后处理消息。处理消息其实就是确定哪些 subscriber 订阅了 topic 并将消息发送给他们。
|
||||
|
||||
- 发布消息的 client 不会知道是否有人对发布的消息感兴趣,同时也不知道多少 client 从 broker 收到了消息。
|
||||
|
||||
- 订阅
|
||||
|
||||
- client 会向 broker 发送 SUBSCRIBE 消息来接收有关感兴趣的 topic,这个SUBSCRIBE 消息非常简单,它包含了一个唯一的数据包标识和一个订阅列表
|
||||
|
||||

|
||||
|
||||
- Packet Identifier:这个 PacketId 和上面的 PacketId 一样,都表示消息的唯一标识符。
|
||||
- ListOfSubscriptions:SUBSCRIBE 消息可以包含一个 client 的多个订阅,每个订阅都会由一个 topic 和一个 Qos 构成。订阅消息中的 topic 可以包含通配符。
|
||||
|
||||
- 确认消息
|
||||
- client 在向 broker 发送 SUBSCRIBE 消息后,为了确认每个订阅,broker 会向 client 发送 SUBACK 确认消息。这个 SUBACK 包含原始 SUBSCRIBE 消息的 packetId 和返回码列表。
|
||||
|
||||

|
||||
|
||||
- 发布 - 订阅 - 确认消息,这三种消息的示意图如下。
|
||||
|
||||

|
||||
|
||||
- 退订
|
||||
|
||||
- SUBSCRIBE 消息对应的是 UNSUBSCRIBE 消息,这条消息发送后,broker 会删除关于 client 的订阅。
|
||||

|
||||
|
||||
- 确认退订
|
||||
|
||||
- 取消订阅也需要 broker 的确认,此时 broker 会向 client 发送一个 UNSUBACK 消息。
|
||||
|
||||

|
||||
|
||||
- 退订和确认退订的流程如下
|
||||
|
||||

|
||||
|
||||
- Topic
|
||||
|
||||
- MQTT Topic 非常轻量级,client 在发布或订阅之前不需要先创建所需要的 Topic,broker 在接收每个 Topic 前不用进行初始化操作。
|
||||
|
||||
- 当客户端订阅 Topic 时,它可以订阅已发布消息的确切 Topic,也可以使用通配符来同时订阅多个 Topic
|
||||
|
||||
- 单级通配符可以替换 Topic 的一个级别,+ 号代表 Topic 中的单级通配符
|
||||
|
||||
- 多级通配符涵盖多个 Topic,# 代表 Topic 中的多级通配符。为了让 broker 能够确定和哪些 Topic 匹配,多级通配符必须作为 Topic 中的最后一个字符放置,并以 / 开头
|
||||
|
||||
- 当 client 订阅带有多级通配符的 Topic 时,不论 Topic 有多长多深,它都会收到通配符之前 Topic 的所有消息。如果你只将 Topic 定义为 # 的话,那么你将会收到所有的消息。
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
1. 开发前
|
||||
- [ ] 匹配信号、赛博坦和SOA
|
||||
- [ ] 确认所需数据上报和落表情况
|
||||
2. 开发中
|
||||
- [ ] 确认信号连续性,是变化上传还是周期上传
|
||||
- [ ] 确认信号是否多个节点上传的情况
|
||||
- [ ] 确认信号的物理和逻辑范围
|
||||
3. 开发后
|
||||
- [ ] 确认获得的值逻辑性正确
|
||||
- [ ] 保证计算了全部的原始信号
|
||||
- [ ] 保证逻辑计算准确性
|
||||
- [ ] 确认计算后时间的连续性,并且无重复
|
||||
- [ ] 确认计算后业务上相关的数据之间关系符合业务逻辑,如加和相等,包含关系中子项和不超过父项和
|
||||
- [ ] 确认调度逻辑正确性
|
||||
- [ ] 确认插入数据时间和分区正确
|
||||
- [ ]
|
||||
@@ -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. 退出到人工:按键、制动踏板、方向盘、加速踏板(加速踏板要超时)
|
||||
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.
|
||||
@@ -0,0 +1 @@
|
||||
基于DMS和OMS摄像头的呼吸暂停检测-
|
||||
@@ -0,0 +1,16 @@
|
||||
1. 已经通过了DDAW(蔚来(ET7海外)、大通海外车型),正在做E-NCAP;
|
||||
2. RX5、哪吒U和U pro是在8155(cDSP上)做SDK,蔚来是orin做SDK;
|
||||
3. smart上做到ASIL-B,计划年底量产,做整体的供应商,包括软件和硬件;
|
||||
4. 与上汽在谈一个低成本过DDAW的方案,目标成本400;
|
||||
5. 自研的推理框架;
|
||||
6. 视线检测可以做到点APP和点中控屏,;
|
||||
7. 儿童检测有视觉和雷达融合方案,Mini EYE认为纯视觉能拿1分,融合方案能拿3分;
|
||||
8. 算力占用,
|
||||
9. 2022和2023年的DDAW有区别,了解一下;
|
||||
10. 有座舱自标定系统,需要在座舱顶棚上有锚点,锚点不能被遮盖;
|
||||
11. 儿童可以做到正负3岁的误差;
|
||||
12. 手势识别可以做平面的动态手势,需要深度信息的不太好做;
|
||||
13. 计划明年Q2-Q3拿到功能安全ASIL-B的认证;
|
||||
14. 利用人脸关键点检测与HUD的投影范围做联动;
|
||||
15. 在蔚来做了云端的faceid的注册算法;
|
||||
16. 整体的高温测试,测试在高温下摄像头性能裂化时的算法情况;
|
||||
@@ -0,0 +1,12 @@
|
||||
1. 未动的DMS算法需要检测整个时间窗口中所有信息;
|
||||
2. 若一路做正常检测,一路做插帧硬件资源无法支持;
|
||||
3. 未动有DMS监控方案;
|
||||
1. SOS侧算法向 MCU发送监控信息;
|
||||
2. 只能检测SOC侧算法失效;
|
||||
3. DMS监控算法放在MCU侧安全岛;
|
||||
4. 错误码的保存,若DMs算法错误,TDA4也挂了,怎么办(系统会提供整体的方案检测);
|
||||
5. 对外依赖都是硬件驱动,摄像头读取和CNN加速驱动;
|
||||
6. Pse 52的接口需要内部确认→未动.
|
||||
7. 插帧对算法的影响
|
||||
8. A核上开发环境是ap
|
||||
9. 确认工具链的授权
|
||||
@@ -0,0 +1,8 @@
|
||||
1. 由于依赖上下文,单帧插入无法监控DMs软件问题
|
||||
2. ADAs的感知算法也在非功能安全域运行
|
||||
3. 只把控制逻辑放到安全域,感知部分放到非功能安全域→需要确认
|
||||
4. 安全域的监控项都有什么?→提供清单
|
||||
5. 安全域和非安全域的代码量比例→提供统计,数量级
|
||||
6. 提供软件架构图
|
||||
7. 评估pse52接口是否能支持控制逻辑及感知算法
|
||||
8. 是否能从安全运行时访问加速器
|
||||
@@ -0,0 +1,5 @@
|
||||
1. 安全域中没有办法访问 openvx加速器
|
||||
2. 安全域和通用域有硬隔离
|
||||
3. 放在安全域中需要的依赖→评估
|
||||
4. 拆分的话,该如何拆分,能监控哪些失效
|
||||
5. 链路上比较关注的内容→与海霞姐沟通
|
||||
@@ -0,0 +1,13 @@
|
||||
感知层
|
||||
|
||||
- 生命特征感知
|
||||
- 慢病指标,心血管,糖尿病风险,酒精,抑郁症,心率不齐(待验证)
|
||||
- 实时亚健康指标
|
||||
- 实时心理指标
|
||||
|
||||
应用层
|
||||
- 实时应用
|
||||
- 长程应用
|
||||
- 健康管理→健康关爱、健康干预、健康报告
|
||||
- 今年年底交付,明年5-6月量产
|
||||
- 明年一月有内部版本
|
||||
@@ -0,0 +1,9 @@
|
||||
硅谷成立,国内独立运营
|
||||
|
||||
大数据平台的部署问题
|
||||
|
||||
|
||||
|
||||
手环硬件定制
|
||||
|
||||
数据来源为
|
||||
@@ -0,0 +1,48 @@
|
||||
>这是原始记录,整理后的记录请见:
|
||||
>[[2023年2月10日商泰交流(整理)]]
|
||||
|
||||
|
||||
## DMS开发
|
||||
|
||||
1. 人脸识别、疲劳、分神、视线追踪
|
||||
2. 情绪(几种)
|
||||
3. 年龄:
|
||||
4. 性别:
|
||||
5. 手势识别(几种):
|
||||
1. 静态:6钟
|
||||
2. 动态:5种
|
||||
6. OMS(遗留物检测、宠物检测)
|
||||
7. 特征点:多少?
|
||||
8. FaceID:车外可以么?没做过
|
||||
9. 注视亮屏:视线落点?可以做
|
||||
10. 疲劳分几级,定义逻辑?2级,根据眼睛开合程度和打哈气次数;
|
||||
12. 年龄的精度?识别年龄段更有意义;
|
||||
13. 宠物种类,遗留物种类;
|
||||
14. 隐私保护;
|
||||
15. 人体生理指标?
|
||||
17. hard case识别
|
||||
18. 只剩一个眼睛?可以;
|
||||
19. 无响应的驾驶员识别?没做过
|
||||
20. 功能安全?没做过
|
||||
21. TI和xinqing的芯片;做过TDA4的AD产品;心擎的没做过;
|
||||
22. 移植到新平台大致需要3-6个月;
|
||||
23. 开源数据、自己采的数据、商业数据;有平台做预标注,人工调整(外包加自己);几十万的数据量级;
|
||||
24. faceID支持多人种识别;
|
||||
25. 有驾驶员存在检测;
|
||||
26. 分神以头部姿态为主、辅以视线;
|
||||
27. 雷达(成本):100-200元;
|
||||
29. 有没有海外认证经验;没有
|
||||
30. 有没有应用层的经验;有
|
||||
31. DMS支持的安装位置:
|
||||
1. A柱;
|
||||
2. 方向盘管柱;
|
||||
3. 中控台上方;
|
||||
4. 内后视镜;
|
||||
32. OMS支持的安装位置:
|
||||
1. 内后视镜;
|
||||
2. IVI屏幕上方
|
||||
3. IVI屏幕下方;
|
||||
33. DMS和OMS融合的方案有么?
|
||||
34. 白盒范围:
|
||||
1. 数据集?不包括
|
||||
2. 标注平台?可以谈
|
||||
@@ -0,0 +1,55 @@
|
||||
1. 与一汽合作:
|
||||
1. 红旗展车,旗境舱更新(参与23年4月上海车展);
|
||||
2. 解放:卡车司机的健康管理方案;
|
||||
3. 与商汤有合作;
|
||||
4. 华为手机的相机卡路里识别、
|
||||
2. 技术介绍:
|
||||
1. BTCM理论;
|
||||
2. 健康档案(测评加报告):
|
||||
1. 线下,体检中心等;
|
||||
2. 线上,传感器、智能穿戴等;
|
||||
3. 问卷量表;
|
||||
3. 千人千方案;
|
||||
4. 执行反馈;
|
||||
3. 底层库可以每年重构,并按3-5年付费;
|
||||
4. 比亚迪也在做;
|
||||
5. 库可以以黑盒的方式部署到一汽云;
|
||||
1. 部署;
|
||||
2. 维护;
|
||||
6. 智能座舱解决方案:
|
||||
7. 生态资源;
|
||||
8. 健康管理:研究风险,不给出结论;
|
||||
9. 301医院,因为心脑血管疾病比较强;
|
||||
10. 心理指标缺乏统一的逻辑,准确性可能受限;
|
||||
11. 酒驾等可以放入异常状态的检测,但是可能无法准确地识别出是酒驾还是亢奋等情况;
|
||||
12. 分析用药和潜在疾病等信息对驾驶员的可能影响(与互联网医院等机构合作,获取可能的药物信息);
|
||||
13. 健康推荐:
|
||||
1. 膳食营养;
|
||||
2. 运动健康;
|
||||
3. 生活起居;
|
||||
4. 医学体检;
|
||||
14. 心理类的推荐:
|
||||
1. 自有音乐(自主研发的音乐信息);
|
||||
2. 调用外部库的时候需要匹配第三方的标签信息;
|
||||
3. 科普文章;
|
||||
4. 冥想;
|
||||
5. 运动信息;
|
||||
15. 医疗辅助的服务费用是按次进行收费,有一个起订量;
|
||||
16. 微医、京东健康;
|
||||
17. 生态资源:
|
||||
1. 康健数字化健康管理研究院;
|
||||
2. 专家资源:曾强、武阳丰、王燕芳、闫爽;
|
||||
3. 食物营养数据库(120w);
|
||||
4. 运动数据库;*高速堵车时做个娱乐的内容*
|
||||
5. 特色理疗数据库(2247条);
|
||||
6. 科普知识数据库(10w+条);
|
||||
7. 健康风险评估模型;
|
||||
|
||||
- 待办任务
|
||||
- [ ] 介绍材料(公司、方案介绍)
|
||||
- [ ] 聊一下感知部分的算法内容
|
||||
- [ ] 确定费用的方式
|
||||
- [ ] **汇报材料增加一个整体的方案介绍**
|
||||
- [ ] 构建数据中台、业务中台
|
||||
- [ ] 膳食指南查一下
|
||||
- [ ] 以车载环境为主
|
||||
@@ -0,0 +1,4 @@
|
||||
1. 检测视网膜的信息检测心血管、脑部肿瘤、糖尿病等疾病风险;
|
||||
2. 设备已经通过二类医疗器械认证,算法拿到三类认证(医疗诊断级);
|
||||
3. 用图标展示疾病风险的改变;
|
||||
4.
|
||||
@@ -0,0 +1,23 @@
|
||||
1. 总体情况:
|
||||
1. 穿戴技术医疗化;
|
||||
2. 传感技术生物化;
|
||||
2. 医疗级的可穿戴设备;
|
||||
3. (可穿戴设备)脉搏、血氧、心电、体温、血压和体成分;
|
||||
4. 心率变异性和老年痴呆的相关性;
|
||||
5. 认知功能:
|
||||
1. 儿童认知测试;
|
||||
|
||||
6. 医疗检测:
|
||||
1. 检测中耳炎(插入式传感器);
|
||||
2. ECG检测;
|
||||
3. 脑电检测,人机共驾;
|
||||
|
||||
7. 心率要达到和华为手环差不多的精度;
|
||||
|
||||
8. 基于视听觉的生理心理多模检测:
|
||||
1. 生理信号:语音和图像;
|
||||
2. 行为信号
|
||||
9. 车载无感健康检测系统:
|
||||
1. 集成在方向盘中的传感器;
|
||||
10. 真实世界的事件和驾驶员的反应;
|
||||
11. 从反应时间来确定驾驶员的一些状态信息;
|
||||
@@ -0,0 +1,18 @@
|
||||
1. 癫痫疾病检测:
|
||||
1. 需要PPG原始信号、动作信号;
|
||||
2. 房颤:
|
||||
1. PPG和ECG原始信号,指原始的波形图;
|
||||
2. 使用rPPG信号的话需要调整算法,精度会降低;
|
||||
3. 居家养示范基地
|
||||
|
||||
4. 实时生理、心理状态评估;
|
||||
1. 异常状态判断;
|
||||
2. 压力、疲劳打分;
|
||||
3. 实时驾驶状态评估:结合图像表情();
|
||||
5. 中期:个人数据库:
|
||||
1. 建立个性化的精准生理参数基准线;
|
||||
6. 长期:
|
||||
1. 全天候生理指标检测;
|
||||
2. 生态引入;
|
||||
3. 健康风险评估;
|
||||
7.
|
||||
@@ -0,0 +1,2 @@
|
||||
1. TOF摄像头可以用来判断眼睛的3D位置,可以和AR HUD联动;
|
||||
2.
|
||||
@@ -0,0 +1,6 @@
|
||||
1. 通过按钮激活系统;
|
||||
2. 安装于车外B柱位置,通过LED灯和装饰灯显示识别结果;
|
||||
3. 按钮需要接30电;
|
||||
4. 虹软已经完成的算法在TDA4上跑;
|
||||
5. TOF摄像头中心较亮,四周亮度会有衰减;
|
||||
6. 精确性:FAR=1ppm,FRR=1%;
|
||||
@@ -0,0 +1 @@
|
||||
1.
|
||||
@@ -0,0 +1,9 @@
|
||||
1. E702 DMS考虑仪表屏下方案;
|
||||
2. 3月底要有一版软件,需要有服务层的内容,仅针对8155;
|
||||
3. **健康的应用场景,是否有静态检测的需求;**
|
||||
4. 数据采集需要3周,训练还需要一个月;
|
||||
5. **健康的开发周期还需要确认;**
|
||||
6. 健康的开发人员:高勇, gaoyong@senseauto.com;
|
||||
7. 功能安全对接人:白晓宇;
|
||||
8. **功能安全,DIA、实验计划确认;**
|
||||
9.
|
||||
@@ -0,0 +1 @@
|
||||
1.
|
||||
@@ -0,0 +1,6 @@
|
||||
1. 异常场景
|
||||
2. 得分曲线,没有逻辑上的引导性
|
||||
3. 排名展示相对比例
|
||||
4. dock栏,卡片
|
||||
5. 阈值评审
|
||||
6.
|
||||
@@ -0,0 +1,18 @@
|
||||
1. 目前能做的指标和精度
|
||||
1. 心率、呼吸、血压
|
||||
2. 被试者保持静止、光照固定
|
||||
3. 可以对动作做一些补偿,可以依据关键点做补偿
|
||||
2. 精度评价方法
|
||||
1. 指标:MAE、MAPE和RMSE
|
||||
3. 数据情况,是否可以共享
|
||||
1. 用的都是开源数据集
|
||||
2. 公司有标注的云平台
|
||||
3. 19年长春资助开发的平台
|
||||
4. 数据采集方法
|
||||
1. 有其他项目的数据采集经验
|
||||
5. 是否有嵌入式的移植经验
|
||||
1. 算法可以部属在安卓中,使用经典的分析方法;
|
||||
6. 人数:复旦:医疗组,博士4,硕士6;
|
||||
|
||||
- 利用机器视觉识别医疗动作是否合理
|
||||
-
|
||||
@@ -0,0 +1,35 @@
|
||||
>原始记录请见
|
||||
>[[2023年2月10日商泰交流]]
|
||||
>
|
||||
1. 功能
|
||||
1. 可实现的功能:
|
||||
1. 人脸识别(FaceID),可实现活体检测,可实现多人种检测,承诺在20ms内完成识别,没做过车外人脸识别功能;
|
||||
2. 疲劳驾驶识别,给通用做的项目分为两级,以眼睛开合程度和打哈气的频率确定;
|
||||
3. 分神检测:以头部姿态检测为主,以视线追踪为辅,在demo演示中,头部大转角(仅剩一只眼睛在图像内容)也可以检出分心;
|
||||
4. 危险动作检测:可检测喝水、抽烟、打电话;
|
||||
5. 视线追踪:承诺可实现视线落点检测,可实现注视亮屏等功能;
|
||||
6. 面部属性:可实现情绪检测、性别检测、年龄检测;
|
||||
7. 手势识别:可检测静态手势6种、动态手势5种;
|
||||
8. OMS:可实现遗留物检测和宠物检测;
|
||||
9. 儿童遗留检测:使用毫米波雷达,安装位置大致处于B柱上方,通过检测心率、呼吸等指标实现;
|
||||
10. 驾驶员存在检测:可实现;
|
||||
11. 摄像头遮挡检测:可实现,通用项目已做;
|
||||
12. 隐私保护:可以实现对特定内容的模糊处理,PPT展示了车外摄像头对人物、车牌等目标的模糊处理;
|
||||
2. 缺乏的功能:
|
||||
1. 人体健康;
|
||||
2. 功能安全;
|
||||
2. 工程经验
|
||||
1. 项目经验:量产项目集中在通用车型,目前已有量产产品完成开发;
|
||||
2. 系统整合:承诺可以实现在QNX、Android和Linux上的算法集成;
|
||||
3. 有量产经验的功能:疲劳检测、分神检测、危险动作检测、摄像头遮挡、面部属性;
|
||||
4. 有量产经验的芯片:高通、安霸、瑞萨等,**TDA4系列上做过ADAS功能,没做过DMS内容,完全没做过芯擎的芯片**,移植到新的芯片平台需要时间**3-6个月**;
|
||||
5. 没有欧标和ENCAP经验,DDAW和ADDW正在计划适配;
|
||||
6. 没有功能安全经验;
|
||||
7. 测试平台:有自建的测试平台,可实现自动化测试和预标注,测试后会输出测试报告;
|
||||
8. 数据来源:包括三部分,开源数据集、外购数据集和自采数据集,数据量在几十万;
|
||||
9. 数据标注:使用有测试平台做预标注,之后由人工确认和调整(外包加自己);
|
||||
10. 有应用层的开发经验,可实现到指定车速激活等功能;
|
||||
3. 开源内容
|
||||
1. 算法;
|
||||
2. 测试和数据标注平台;
|
||||
3. **不包括数据集**;
|
||||
@@ -0,0 +1,7 @@
|
||||
|
||||
> 对接人:何云廷
|
||||
|
||||
1. 安全指标需要一个合适的展示方式;
|
||||
2. 行驶里程变化趋势,按天统计;
|
||||
3. 月报、周报设计问题,月报是否应该和周报的内容保持一致,还是按月推送;
|
||||
4. 行程总结是否增加一个关闭的选项;
|
||||
@@ -0,0 +1,4 @@
|
||||
1. 新能源所有车的平均能耗信息是否增加;
|
||||
2. 动力经济性,王燕(系统集成);
|
||||
3. 周一的时候显示上周内容;
|
||||
4. 在车机上增加轻量的单次历史行程查询;
|
||||
@@ -0,0 +1,9 @@
|
||||
1. 标签增加解释内容,考虑正面标签;
|
||||
2. 行车小贴士的文本内容,我们先出,之后再讨论;
|
||||
3. 只显示未读的第一条,全已读后显示第一条;
|
||||
4. 排名的展示可能设计隐私问题,是否考虑取消;
|
||||
5. 行程轨迹可能存在性能问题,是否考虑取消;
|
||||
6. DMS和ADAS的信息展示,是否改成提示类的信息;
|
||||
7. 历史最高能耗意义不大,历史最低改成提示类信息;
|
||||
8. 历史行驶是否做限制;
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
1. 行驶轨迹问题,请车端网联所正式评估,若无法实现上飞刃会评审;
|
||||
2. 排名页面,引入授权弹窗,要考虑实现接口;
|
||||
3. DMS、ADAS和历史最低能耗信息展示接受建议,改为提示类信息;
|
||||
4. 历史单次行程限制在半年内, 周期限制在一年内;
|
||||
@@ -0,0 +1,2 @@
|
||||
1. 生理监测现在给奇瑞做;
|
||||
2.
|
||||
@@ -0,0 +1,6 @@
|
||||
1. 总结弹窗:
|
||||
2. 手机:
|
||||
1. 标签:标签可以分期上;
|
||||
2. 排名:实际意义不大;
|
||||
3. 大迭代跟车型,小迭代可以多次更新;
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
- 找供应商讨论应用场景;
|
||||
- 产品规划在前,技术支撑在后,项目落地最后;
|
||||
- 座舱健康,声音健康、光健康、人体健康;
|
||||
- 传感器归智能驾驶管;
|
||||
@@ -0,0 +1,8 @@
|
||||
1. 增加;
|
||||
2. GPS点先试一下效果,问一下刘雨恒;
|
||||
3. 瞬时能耗的值,
|
||||
4. 新能源对平均能耗显示的意见;
|
||||
5. 指标和算法的对应关系;
|
||||
6. 行程总结:
|
||||
1. 展示的等级太强;
|
||||
2. 弹出时机;
|
||||
@@ -0,0 +1,24 @@
|
||||
1. 要包含:硬件——摄像头,软件的部署位置——车还是云,产品表达;
|
||||
2. 策划要完整;
|
||||
3. 联动座舱功能设备,场景提示;
|
||||
4. 驾驶员失能情况下,联动智能驾驶系统;
|
||||
5. 平台化设计,每年度平台化产品能力计划,技术支撑需求;
|
||||
6. 产品分级,按成本区分;
|
||||
7. 确定不同算法、硬件支持的精度等内容;
|
||||
8. 目标车型之一:解放长途运输车;
|
||||
9. 在框架确定之后,人体健康按照总体目标进行立项;
|
||||
10. 按阶段目标推进产品上线;
|
||||
11. 场景设计,相关的责任;
|
||||
13. 人体健康随舒享座舱立项,不单独立项;
|
||||
14. 定义为体检初筛的等级;
|
||||
15. 成熟驾驶员模型研究;
|
||||
16. 一期目标先做实时的内容,长期健康风险放到后面做;
|
||||
|
||||
|
||||
- [ ] 启动与供应商技术交流,探讨产品形态、场景设计;
|
||||
- [ ] 17. 雷达的研发、摄像头的数据
|
||||
18. 是否监测整车,或仅驾驶员;
|
||||
19. 算力和能耗的情况;
|
||||
20. 算法:
|
||||
1. 全车调度算法,各功能协同;
|
||||
2. 健康识别后,后续应该进行的内容;
|
||||
@@ -0,0 +1 @@
|
||||
1.
|
||||
@@ -0,0 +1,7 @@
|
||||
1. 行程总结不建议
|
||||
1. 和仪表信息多数是重复的
|
||||
2. 车机单次的历史行程不上了,只上周报;
|
||||
3. **月报也不要,有继承性,可视效果可能不太好,指标和周报重复较多;**
|
||||
4. 实时信息的指标项还是想放上;
|
||||
5. 疲劳驾驶、分心、愤怒显示策略;
|
||||
6. 平均车速、最长行驶里程、最高车速;
|
||||
@@ -0,0 +1,3 @@
|
||||
- [ ] 整理人体健康感知算法需求
|
||||
-
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
1. 项目要分为三个层次:
|
||||
1. 数据获取
|
||||
2. 算法实现
|
||||
3. 产品应用
|
||||
|
||||
2. 数据获取部分:
|
||||
1. 由产品目标提出需要哪些数据,由数据需求匹配传感器需求;
|
||||
2. PRD要论证所有可能的传感器选型,并分阶段实现;
|
||||
3. 会上讨论过的传感器:
|
||||
1. 摄像头
|
||||
2. 雷达:雷达要明确布置和性能、尺寸参数等;
|
||||
3. ECG传感器:要明确布置和使用方法;
|
||||
4. 智能穿戴;
|
||||
|
||||
3. 算法实现:
|
||||
1. 算法要分级别,要明确每个级别的算法需要什么技术实现;
|
||||
2. 算法要能明确提出对数据的需求;
|
||||
3. 算法的核心是要研究如何准确的平均人的状态;
|
||||
|
||||
4. 产品应用:
|
||||
1. 产品应用要分等级:
|
||||
1. 提示
|
||||
2. 联动座舱环境
|
||||
3. 干预:
|
||||
1. 在线医疗协助,帮助用户缓解症状等;
|
||||
2. 自动驾驶接管;
|
||||
2. 要开发可以展示的产品Demo;
|
||||
|
||||
5. 领导的其他要求:
|
||||
1. 目前阶段要明确项目要干什么,干到什么程度;
|
||||
2. 立项中要体现产品应用的内容;
|
||||
3. 明确技术采购范围;
|
||||
@@ -0,0 +1,3 @@
|
||||
1. 人体健康算法
|
||||
2. 人脸关键点
|
||||
3. 训练环境创建
|
||||
@@ -0,0 +1 @@
|
||||
1.
|
||||
@@ -0,0 +1,11 @@
|
||||
- 人体健康
|
||||
- 立项材料
|
||||
- 驾驶行为
|
||||
- 产品形态
|
||||
- 接口对接
|
||||
- 测试
|
||||
- 服务器
|
||||
- CICD
|
||||
- 算法
|
||||
- 传统方法
|
||||
- 深度学习
|
||||
@@ -0,0 +1,38 @@
|
||||
[手机APP视频](https://myonemanager.lzybetter.repl.co/picbed_big/filebed/e40qlG069TdhNZWtpiRyTqOIRIVFJQ6XiGdRYV0L0oE.mp4)
|
||||
|
||||
丰田手机APP统计驾驶行为信息,包括:
|
||||
|
||||
- 首页
|
||||
|
||||
- 急加速
|
||||
|
||||
- 急减速
|
||||
|
||||
- 急转向
|
||||
|
||||
- 单次行程
|
||||
|
||||
- 行程地图,包括起止地点及不良驾驶行为发生地点
|
||||
|
||||
- 行程开始时间
|
||||
|
||||
- 行程结束时间
|
||||
|
||||
- 行程开始地点
|
||||
|
||||
- 行程结束地点
|
||||
|
||||
- 急加速
|
||||
|
||||
- 急减速
|
||||
|
||||
- 急转向
|
||||
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
@@ -0,0 +1,13 @@
|
||||
亚洲龙在熄火时,仪表中会弹出上面的内容,包括:
|
||||
|
||||
- 行驶距离
|
||||
|
||||
- 总时间
|
||||
|
||||
- 燃油经济性
|
||||
|
||||
- 总评分
|
||||
|
||||
- 起步、巡航、停车三个阶段的评价
|
||||
|
||||

|
||||
@@ -0,0 +1,15 @@
|
||||
几何C车机上提供了一个较为简单的驾驶行为评价产品,提供如下功能:
|
||||
|
||||
- 驾驶评分;
|
||||
|
||||
- 行驶里程;
|
||||
|
||||
- 行驶时长;
|
||||
|
||||
- 急加速、急减速、急转弯和超速次数统计;
|
||||
|
||||
- 驾驶评分计算规则为:初始分80,如没有发生三急一超事件,则分数随驾驶时长上升,满分100,如果发生三急一超则扣除响应分数;
|
||||
|
||||

|
||||
|
||||

|
||||
@@ -0,0 +1,76 @@
|
||||
### 哪吒
|
||||
|
||||
合众/哪咤提供名为驾驶达人的车机产品,功能包括:每月的行驶里程、减少碳排放量、行驶时长、驾驶习惯、百公里电耗、充电情况等;
|
||||
|
||||
#### 功能入口
|
||||
|
||||
在哪咤U5 pro车型中,驾驶达人为一个单独的APP,可以在应用界面进入;
|
||||

|
||||
|
||||

|
||||
|
||||
#### 功能介绍
|
||||
|
||||
哪咤驾驶达人产品分三个功能模块:驾驶达人、每日排行和月度PK赛
|
||||
|
||||
##### 新用户
|
||||
|
||||
新用户需要达到一定里程之后才会展示内容
|
||||

|
||||
|
||||
##### 驾驶达人
|
||||
|
||||
驾驶达人模块提供按月统计的:
|
||||
|
||||
- 总行驶里程;
|
||||
|
||||
- 单次行驶最长里程;
|
||||
|
||||
- 单日最常里程;
|
||||
|
||||
- 每月行驶里程;
|
||||
|
||||
- 累计减少碳排放统计;
|
||||
|
||||
- 称号;
|
||||
|
||||
- 急加速和急减速次数统计;
|
||||
|
||||
- 车辆闲置次数;
|
||||
|
||||
- 百公里电耗;
|
||||
|
||||
- 低电量行驶次数;
|
||||
|
||||
- 充电习惯:高温充电次数、低温充电次数、总充电次数、慢充次数和快充次数;
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
|
||||
##### 每日排行
|
||||
|
||||
哪咤的排行分为两种,按里程和按电耗排名:
|
||||
|
||||
- 电耗排名
|
||||
|
||||

|
||||
|
||||
- 里程排名
|
||||
|
||||

|
||||
|
||||
##### 月度PK赛
|
||||
|
||||
月度PK赛提供月度排名查询和月度报告:
|
||||
|
||||
- 月度排名查询
|
||||
|
||||

|
||||
|
||||
- 月度报告:提供历史各月份的行驶里程、减少碳排放量、行驶时长、驾驶习惯、百公里电耗、充电情况等信息
|
||||
|
||||

|
||||
@@ -0,0 +1,47 @@
|
||||
大众提供的手机APP中提供了驾驶风格识别,并引导用户改善驾驶风格以获得最佳能耗
|
||||
|
||||
大众的手机APP主要是引导驾驶员改善驾驶风格以获得最佳能耗表现,内容包括:
|
||||
|
||||
- 行程开始地点
|
||||
|
||||
- 行程结束地点
|
||||
|
||||
- 开始时间
|
||||
|
||||
- 结束时间
|
||||
|
||||
- 行驶里程
|
||||
|
||||
- 开始里程
|
||||
|
||||
- 结束里程
|
||||
|
||||
- 平均车速
|
||||
|
||||
- 最大车速
|
||||
|
||||
- 油耗
|
||||
|
||||
- 评分
|
||||
|
||||
- 总评分
|
||||
|
||||
- 发动机转速
|
||||
|
||||
- 加速
|
||||
|
||||
- 减速
|
||||
|
||||
- 车速
|
||||
|
||||
- 空调
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
@@ -0,0 +1,19 @@
|
||||
奔驰在国外推出了一个名eco-coach的手机应用,其通过一些列的挑战成就引导驾驶员改善驾驶习惯,包括:
|
||||
|
||||
- 纯电行驶占比
|
||||
|
||||
- 充电次数
|
||||
|
||||
对个人数据,其按5日、5周、5个月的周期进行统计,包括:
|
||||
|
||||
- 燃油消耗
|
||||
|
||||
- 二氧化碳排放量
|
||||
|
||||
- 电耗
|
||||
|
||||
- 纯电行驶占比
|
||||
|
||||

|
||||
|
||||

|
||||
@@ -0,0 +1,60 @@
|
||||
### 奔驰
|
||||
|
||||
奔驰在S级和C级车辆上推出了Eco display功能,用于向驾驶员展示其驾驶行为对车辆能耗的影响,并在S级车型上提供一个”ECO Assist“功能,引导驾驶员改善驾驶行为;
|
||||
|
||||
#### 功能入口
|
||||
|
||||
奔驰的Eco display功能可以在仪表和HUD(S级)上显示;
|
||||
|
||||
#### 功能介绍
|
||||
|
||||
##### C级车型
|
||||
|
||||
显示驾驶行为对能耗的影响,参与评价的驾驶行为包括:
|
||||
|
||||
- 加速度:当隔段填满,且颜色变为绿色,表示加速较为缓和,有利于节能。当隔段不满,且颜色变为灰色,表示加速较为激进,不利于节能;
|
||||
|
||||
- 减速度:当隔段填满,且颜色变为绿色,表示减速较为缓和,有利于节能。当隔段不满,且颜色变为灰色,表示减速较为激进,不利于节能;
|
||||
|
||||
- 车速稳定性:当隔段填满,且颜色变为绿色,表示车速较为稳定,有利于节能。当隔段不满,且颜色变为灰色,表示车速变化较大,不利于节能;
|
||||
|
||||
<div align="center"><img src=https://myonemanager.lzybetter.repl.co/picbed_big/picbed/84ed5412e00f6663d404061c4601931b.png></div>
|
||||
|
||||
##### S级车型
|
||||
|
||||
1. ECO Display
|
||||
|
||||
显示驾驶行为对能耗的影响及节能评分等级:
|
||||
|
||||
- 标记1显示节能评分等级,其从行程开始进行评价,行程开始五颗星均为空,如果驾驶行为有利于节能,则五颗星会依次填满;
|
||||
|
||||
- 标记3显示了有利于节能的驾驶风格区域;
|
||||
|
||||
- 标记2显示一个可以前后移动的球,当这个球位于节能驾驶风格区域时,球显示为绿色,否则显示为橙色;
|
||||
|
||||
ECO Display认为有利于节能的驾驶行为包括:
|
||||
|
||||
- 在正确的时机减速;
|
||||
|
||||
- 车速保持稳定;
|
||||
|
||||
- 加速较为柔和;
|
||||
|
||||
<div align="center"><img src=https://myonemanager.lzybetter.repl.co/picbed_big/picbed/ec81ef0297ad4c2e83e8b0141a5b301e.png></div>
|
||||
|
||||
|
||||
2. ECO Assist
|
||||
|
||||
ECO Assist功能通过识别行驶工况并评价驾驶员的驾驶行为,并提供驾驶员改善驾驶习惯以获得最佳的能耗体验;
|
||||
|
||||
- 标识1表示推荐驾驶员放松加速踏板;
|
||||
|
||||
- 标识2表示驾驶员可以通过改善驾驶习惯来获得更低的能耗;
|
||||
|
||||
- 系统可以识别的路况包括:环岛、S弯、急转弯、T字路口、下坡、前方有车辆、限速;
|
||||
|
||||
<div align="center"><img src=https://myonemanager.lzybetter.repl.co/picbed_big/picbed/2d62274ff1cd490d0ac00e6549a919b9.png></div>
|
||||
|
||||
<div align="center"><img src=https://myonemanager.lzybetter.repl.co/picbed_big/picbed/1855db60983b0e391d6346400fc713d3.png></div>
|
||||
|
||||
[奔驰S级用户手册](https://myonemanager.lzybetter.repl.co/picbed/filebed/S-Sedan%20Owners%20Manual.pdf)
|
||||
@@ -0,0 +1,15 @@
|
||||
奥托立夫开发了一个名为Driving Avatar的手机APP,评价驾驶行为对行车安全的影响,指标包括:
|
||||
|
||||
- 平顺驾驶
|
||||
- 驾驶预判
|
||||
- 专注驾驶
|
||||
- 合法驾驶
|
||||
|
||||
|
||||

|
||||

|
||||
|
||||
|
||||

|
||||
|
||||

|
||||
@@ -0,0 +1,42 @@
|
||||
### 宝马
|
||||
|
||||
宝马在5系和7系车型上推出了名为”ECO PRO“的功能,引导驾驶员改善驾驶行为以改善能耗,同时推出了”Driving style analysis“功能;
|
||||
|
||||
#### 功能入口
|
||||
|
||||
1. ECO PRO功能可以通过实体按键开启;
|
||||
|
||||
2. Driving style analysis功能位于娱乐屏;
|
||||
|
||||
#### 功能介绍
|
||||
|
||||
##### ECO PRO功能
|
||||
|
||||
ECO PRO通过实体按键开启后显示驾驶行为及驾驶风格的建议
|
||||
|
||||
- 如下图所示,表示可以通过调整驾驶风格来获得额外的续航里程;
|
||||
<div align="center"> <img src =https://myonemanager.lzybetter.repl.co/picbed_big/picbed/47e93dccc05dca2b70fc1d7fa5060790.png> </div>
|
||||
|
||||
- 如下图中,当双箭头为蓝色,表示当前驾驶风格有利于节能;当双箭头为灰色,表示应该调整驾驶风格;
|
||||
<div align="center"> <img src=https://myonemanager.lzybetter.repl.co/picbed_big/picbed/d7ebc58575486aa51f94933e5044c64f.png> </div>
|
||||
|
||||
- 如下图中箭头表示应该较小加速踏板开度;
|
||||
|
||||
<div align="center"> <img src=https://myonemanager.lzybetter.repl.co/picbed_big/picbed/f280d63070fe834b43e90fd21c926a81.png></div>
|
||||
|
||||
- 其他指示灯
|
||||
<div align="center"> <img src=https://myonemanager.lzybetter.repl.co/picbed_big/picbed/5aea8b6aa273b358624a60c43620424c.png></div>
|
||||
|
||||
##### Driving style analysis
|
||||
|
||||
展示驾驶员影响能耗的驾驶行为统计:
|
||||
|
||||
- 预判次数;
|
||||
|
||||
- 加速次数;
|
||||
|
||||
- 通过节能驾驶增加的剩余驾驶里程;
|
||||
|
||||
<div align="center"> <img src=https://myonemanager.lzybetter.repl.co/picbed_big/picbed/0126d79f955e7082d9e71bfa6d2b971e.png></div>
|
||||
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
|
||||
1. 基本情况:2021年11月1日上线,根据驾驶员在辅助驾驶系统激活时的表现对驾驶员进行扣分,满分100,12个月为一个周期重置分数,对于得分较低的推送提醒、考试等,如果智驾分被扣到0分,驾驶员必须通过考试才能继续使用辅助驾驶系统;
|
||||
总体来说是引导驾驶员正确使用辅助驾驶系统的一个评分系统,并不评价驾驶员的其他方面行为;
|
||||
|
||||
2. “智驾分”界面
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
|
||||
3. "智驾分"扣分项:每位车主的“智驾分”满分都是100分,每12个月为一个周期,在智能辅助驾驶状态下,车主的错误操作将会形成扣分项,一旦分数被减到0,车主必须重新考试才能使用智能辅助驾驶功能。
|
||||
|
||||
4. 积分方法和周期:
|
||||
频繁触发脱手一级提醒或者长时间脱手二级提醒;
|
||||
当系统发出接管提示后,用户未及时接管车辆(如系统发出“前方施工,立即接管”或“立即减速,请求接管”等);
|
||||
当天连续行驶4小时后仍开启智能辅助驾驶功能,会触发疲劳驾驶提醒;
|
||||
驾驶过程中频繁/长时间不注意路面情况,会触发一级/二级分神提醒。
|
||||
|
||||
此外,系统将自动判断以上行为的危险程度,根据不同危险程度扣减不同分值,扣减分值越高代表该行为危险程度越高,分数会在隔天发生变动。
|
||||
|
||||
5. 奖惩机制:
|
||||
惩罚:
|
||||
查看正确智驾操作图示;
|
||||
阅读功能使用安全须知;
|
||||
完成相关行为安全答题;
|
||||
参加安全考试(分数扣减为0分时,用户须再次完成安全考试,才能重新获取100智驾分)。
|
||||
奖励:为了鼓励高分用户(个人智驾分阶段剩余分值在90分以上),未来可以优先获得小鹏OTA公测权益。
|
||||
|
||||
6. 功能介绍
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||

|
||||
@@ -0,0 +1,103 @@
|
||||
相信很多鹏友已经收到了小P推送的能耗报告,被其他车主打败的鹏友是不是该温柔一点对待自己的G3呢?哈哈,其实能耗高与低也不用过于在意,只要按照自己最适合的驾驶方式去开车就好啦!当然了,如果我们多了解一些关于“能耗”方面的知识和建议,适当调整一些驾驶习惯的话,是能够大大延长续航的哦。所以,下面给你揭开“能耗报告”的面纱吧!
|
||||
|
||||
一、能耗报告是如何生成的?
|
||||
|
||||
统计和计算整车的能耗报告,需要G3具备较高的电气化水平,其中包括动力总成、电子电器、温控等多个与能耗息息相关的系统。这些系统实时将数据传输给车联网平台进行统计和计算,根据复杂的算法将各个系统的能耗做统计分类,并用图形化的方式表达出来。
|
||||
|
||||
能耗报告目前固定每周一生成,总结上周车辆的能耗表现,并推送到小鹏APP。要生成能耗报告,有个前提哦,这个前提就是上周开车要达到一定里程。如果里程达不到最低要求,不能真正反映出开车过程的能耗综合表现。
|
||||
|
||||
小P除了在APP每周向你推送能耗报告之外,在大屏上也会根据每日能耗表现,进行提醒。两者区别如下:
|
||||
|
||||
1、在APP推送的能耗报告倾向于总结、回顾和建议,以“周”为时间单位统计数据,可以看到最近几周的能耗趋势等信息。
|
||||
|
||||
2、在大屏推送的能耗消息,倾向于能耗异常提醒。在你每日能耗表现较好/较差、进步/退步等情况下才会进行提醒,希望能帮你及时发现问题和提供建议。它以“日”为时间单位统计数据。目前大屏以“日”为单位的能耗报告暂时没有固定入口,只有收到提醒消息时才能看到哦。
|
||||
|
||||
二、能耗报告怎么阅读?
|
||||
|
||||
能耗报告即将发布新版本,小P这里给大家提前透露下。新版本能耗报告增加了不少数据内容,也有很多指标和数字哦。为方便大家更好的理解,小P在这里给大家介绍下这些数据信息的含义吧。
|
||||
|
||||
1、APP端能耗报告:
|
||||
|
||||
APP端能耗报告,总共有5部分数据内容,分别如下。
|
||||
|
||||
周能耗总结
|
||||

|
||||
|
||||
小P会对你本周的能耗各项数据进行归纳性总结,方便大家快速了解能耗的总体表现。其中的能耗勋章,根据这周的能耗水平对应获得,一共有5个等级,由高到低分别是:传说右脚、黄金右脚、白银右脚、青铜右脚和任性右脚。让我们一起朝着【传说右脚】发起挑战吧。
|
||||
|
||||
周能耗趋势
|
||||
|
||||

|
||||
|
||||
小P会为你记录最近几周的能耗水平,让你直观看到最近一段时间的能耗趋势是怎么样的。从这个趋势,你可以看到自己能耗表现是进步了呢、还是退步了呢、还是停滞不前了呢?小P也会给出相应的点评和建议。
|
||||
|
||||
除了记录你最近几周的能耗水平,小P也会根据你的能耗表现,为你量身定制下周的能耗目标,一起努力完成目标吧。
|
||||
|
||||
之外,小P还为你提供当前这周跟能耗相关的几个相关数据,方便你整体上了解这周的开车情况。分别如下:
|
||||
|
||||
行驶距离:指你本周累计行驶的距离,单位是公里,就是这周开了多少公里;用车时长:指你本周累计的驾车时长,单位是分钟,就是这周开车多少时间;百公里能耗:指你本周的百公里能耗水平,单位是kWh/百公里;电量焦虑线:指你近一个月充电时平均剩余的电量比例,单位是百分比,就是近一个月以来,你一般会在电量剩余多少的时候会充电。
|
||||
|
||||
周能耗诊断
|
||||

|
||||
|
||||
小P会对你本周的能耗分布进行统计,在这里你可以看到能耗主要用在了哪些地方。并且你可以跟鹏友圈平均水平进行对比,发现自己的优点和问题。小P也会根据分布情况,给出能耗诊断意见。这里面的指标稍微专业一些,我逐个跟大家解释下。
|
||||
|
||||
行车消耗占比:该指标统计在开车过程中动力消耗相关的电量使用,分母是本周能量消耗总量。一般情况来说,频繁加减速会增加耗能,要注意驾驶平顺哦;
|
||||
|
||||
空调消耗占比:该指标统计空调相关的电量使用,分母是本周能量消耗总量。一般情况来说,空调温度设置过低、长时间开启外循环、空调加热等都会增加能耗哦;
|
||||
|
||||
其他消耗占比:该指标统计除动力和空调之外的电量使用,分母是本周能量消耗总量。主要是一些电子电器部件的电量使用,例如座椅加热、大灯、大屏、仪表盘、还有一些车内部的各种电子元器件,都会有电量消耗呢;
|
||||
|
||||
能量回收占比:该指标统计开车过程中的能量回收效果,分母是本周能量消耗总量。能量回收有三个等级,一般情况下能量回收等级越高回收效果越好,但是回收效果也取决你的驾驶习惯、路面情况等各种因素,具体可以了解下用户手册该功能的介绍。
|
||||
|
||||
周最佳能耗行程
|
||||
|
||||

|
||||
|
||||
小P为你记录了本周能耗最低的3次行程,方便你回顾最棒的行驶路程。这里小P只统计了行驶距离大于5公里的行程,这样的行程能更加合理的反映出能耗水平。
|
||||
|
||||
美好的事情或许总是发生在最不经意的路程之上呢,一起探索吧!
|
||||
|
||||
周能耗大神榜
|
||||
|
||||

|
||||
|
||||
小P统计了本周鹏友圈能耗表现最棒的99位大神,只有周行驶距离超过50公里的用户才能上榜哦。一起来冲击这个荣誉榜吧!
|
||||
|
||||
周能耗报告分享
|
||||
|
||||

|
||||
|
||||
能耗报告最后有一个分享按钮,你可以点击进行分享。分享时候,我们自动帮你进行截图处理,方便你以图片方式分享到鹏友圈,大家一目可阅哦。
|
||||
|
||||
特别提醒:点击按钮分享报告时,考虑到数据实用性,默认只会分享【小P总结】、【能耗概况】、【能耗诊断】3部分数据内容,【最佳行程】、【大神榜】不会包含在分享图片里面。如果要分享全文,要辛苦你进行截长图咯。
|
||||
|
||||
2、大屏端能耗报告:
|
||||
|
||||
大屏端能耗报告的数据项跟APP端基本一致,但是信息相对精简一些。因大屏跟手机的屏幕大小不一,阅读习惯不同,所以信息呈现样式也有所不同。
|
||||
|
||||
数据统计口径上也有所区别,大屏端上的数据,都是以“日”为时间单位的,统计每日的能耗表现。报告总共有3部分,分别如下:
|
||||
|
||||
日能耗概况
|
||||
|
||||

|
||||
|
||||
主要呈现用户当日的用车基本情况。主要有4个指标,分别是:用车时长:该指标统计当日的累计开车时长,单位是分钟,就是开了多长时间的车;行驶距离:该指标统计当日的累计行驶距离,单位是公里,就是开了多少距离;百公里能耗:该指标统计当日的平均能耗水平,并折算成以百公里为单位;碳减排:该指标相对油车来说,当日的开车距离会为地球碳减排的量,单位是克。
|
||||
|
||||
日能耗分布
|
||||
|
||||

|
||||
|
||||
主要呈现当日的能耗分布,各项数据指标的定义跟APP端的能耗报告中的一致,只是统计时间范围有所不同,这里是统计每日的,APP端统计的是每周的。
|
||||
|
||||
日能耗趋势
|
||||
|
||||

|
||||
|
||||
主要呈现你每天的能耗水平趋势,还可以和整个鹏友圈的平均水平进行对比哦。
|
||||
|
||||
日能耗报告分享
|
||||
|
||||

|
||||
|
||||
如果你希望分享日能耗报告,可以通过小鹏APP进行扫码分享哦。手机扫码后,看到的日能耗报告,信息还会更加丰富一些哦,样式也有所不同,期待你的探索和分享,希望你能喜欢。
|
||||
@@ -0,0 +1,40 @@
|
||||
小鹏P7手机APP中的能耗报告统计上一周的能耗情况,包括:
|
||||
|
||||
- 本周里程
|
||||
|
||||
- 本周能耗
|
||||
|
||||
- 能耗成本
|
||||
|
||||
- 能耗分析,展示本周能耗的变化情况
|
||||
|
||||
- 能耗排行,排行变化情况
|
||||
|
||||
- 我的能耗变化趋势
|
||||
|
||||
- 同配置车友均值
|
||||
|
||||
- 能耗诊断
|
||||
|
||||
- 能耗可下降空间
|
||||
|
||||
- 能耗表现亮点
|
||||
|
||||
- 本周和上周的对比情况
|
||||
|
||||
- 中高速行驶
|
||||
|
||||
- 驾驶行为
|
||||
|
||||
- 能量回收强度
|
||||
|
||||
- 路况和环境
|
||||
|
||||
- 低速行驶
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
|
||||

|
||||
@@ -0,0 +1,59 @@
|
||||
## 1. 取消情况
|
||||
|
||||

|
||||
|
||||
已剪辑自: [https://bbs.xiaopeng.com/qa/102555](https://bbs.xiaopeng.com/qa/102555)
|
||||
|
||||
2. 发布官方介绍
|
||||
|
||||
行程报告即将出炉了!这是继能耗报告后,小P推出的另一款产品。通过行程报告,帮助大家了解自己的行程表现、洞察自己的驾驶习惯。从中,若能针对一些不良驾驶行为,予以规避纠正,对驾驶安全可是大大助益哦。
|
||||
目前已有部分内测用户先行体验咯。在这里,小P提前给大家揭开行程报告的面纱吧!
|
||||
一、行程报告如何生成?
|
||||
行程报告的生成需要小P具有很强的实时数据处理能力,这样才能保证在你行程结束后数分钟内进行报告的生成和推送。同时,小P还需要在纷繁复杂的电子信号中练就火眼金睛,发现各式各样的不良驾驶行为或习惯,为你的安全驾驶保驾护航。
|
||||
行驶距离超过5公里以上的行程才会生成行程报告,符合条件的行程结束后,会向APP推送报告消息。点击消息,可以查阅本次行程的报告,通过报告上面的《历史行程》按钮,可以查看往期的报告。
|
||||
二、如何理解行程报告?
|
||||
行程报告主要由“小P总结”、“行程概况”、“驾驶诊断”3部分组成。
|
||||
|
||||
“小P总结”,是对本次行程的简要分析和总结,方便你快速获取报告结论。
|
||||
|
||||
“行程概况”,为本次行程的数据概要,方便你整体了解行程的核心数据表现。
|
||||
|
||||
“驾驶诊断”,为行程报告的核心内容,将对你本次出行的驾驶技术进行评分,评分越高代表你的驾驶技术越出色、驾驶安全系数越高哦!
|
||||
|
||||
1、小P总结
|
||||
|
||||

|
||||
|
||||
小P会对你本次行程进行归纳性总结,方便大家快速了解行程的总体表现,以及需要注意的驾驶行为。其中,小P驾驶技术认证得分来自于“驾驶诊断”,得分越高代表驾驶技术越出色、驾驶安全系数越高;你也可以跟鹏友圈比一比哦。
|
||||
|
||||
2、行程概况
|
||||
|
||||

|
||||
|
||||
小P会为你记录本次行程的核心数据表现,方便你回忆本次行程的概况。同时,小P还为你记录了全程车速变化情况,你可以从中发现此次行程的时间,是不是大部分浪费在堵车或等人上了呢?
|
||||
|
||||
|
||||
行驶距离:指本次行程的累计行驶的距离,就是开了多少公里。
|
||||
|
||||
用车时长:指车辆出发时间-车辆下电时间,车辆出发时间从首次车速大于0开始计算。
|
||||
|
||||
百公里能耗:指本次行程的平均百公里能耗水平,单位是kWh/百公里。
|
||||
|
||||
平均车速:指你开车过程的平均车速,车辆停止过程不纳入计算。
|
||||
|
||||

|
||||
|
||||
小P会对你本次行程的驾驶技术进行诊断,你可以从中发现自己哪方面的得分高了还是低了,也可以跟鹏友圈平均水平对比,看看自己的差距。点击《诊断详情》,还可以查阅本次行程更加细节的行为表现哦!
|
||||
目前小P的驾驶技术诊断主要包含4个方面,分别为:平安驾驶、规范驾驶、平稳驾驶、高效停车。每方面还有多个评估指标,每个指标都有独立的得分、且有不同的权重,最后综合得分根据各个指标得分乘以权重计算得出。满分是100分,一起冲击吧!
|
||||
|
||||
平安驾驶:指与生命安全密切相关的高危驾驶行为发生情况平安驾驶目前包括4个评估指标,分别是:急刹车次数、急加速次数、急转弯次数和超高速驾驶距离。其中,超高速驾驶指车速大于危险车速值,不是指大于道路限速值哦。
|
||||
|
||||
规范驾驶:指不符合道路安全驾驶规范的行为发生情况。规范驾驶目前包括2个评估指标,分别是:未系安全带行驶距离、未保持安全车距行驶次数。其中,各指标含义如名称所述内涵。
|
||||
|
||||
平稳驾驶:指影响车辆行驶过程稳定性的行为发生情况。平稳驾驶目前包括3个评估指标,分别是:快速经过颠簸路段距离、车辆打滑次数、车速顿挫次数。“快速经过颠簸路段”指车速大于一定值前提下,经过坑洼、不平等路面时且产生足够车身晃动的行为。“车辆打滑”指车速大于一定值前提下,四个轮胎车速不一、出现打滑的行为。“车速顿挫”指未能合理保持车速平滑地变动,刹车/加速造成车速发生突变、身体感到“顿挫感”的行为。
|
||||
|
||||
高效停车:衡量车主停车的效率。高效停车目前包括2个评估指标,分别是:停车用时、倒车次数。其中,倒车次数指倒车期间挂R挡的次数。
|
||||
|
||||
“驾驶诊断”是小P的核心能力之一,旨在帮助各位鹏友提升驾驶安全系数。目前诊断模型仍在持续完善和迭代中,评估指标还会增加,指标口径也会不断调优。若有不精准的地方,还望各位鹏友多多提意见!
|
||||
|
||||

|
||||
@@ -0,0 +1,26 @@
|
||||
日产在leaf电动车上提供名为”Energy usage informantion display“的应用,以展示车辆能耗的分布;
|
||||
|
||||
#### 功能入口
|
||||
|
||||
”Energy usage informantion display“位于”MENU“->“Info”->“EV Info”->“Energy Usage”
|
||||
|
||||
#### 功能介绍
|
||||
|
||||
”Energy usage informantion display“提供以下功能:
|
||||
|
||||
- 剩余里程“Driving Range”;
|
||||
|
||||
- 关闭空调获得的行驶里程“Turn off Climate Control”;
|
||||
|
||||
- 电机能耗“Electric Motor”:电机消耗的能量和制动能量回收的能量;
|
||||
|
||||
- 空调能耗“Climate Control”:空调消耗的能耗;
|
||||
|
||||
- 其他系统能耗“Other Systems”:其他系统的能耗;
|
||||
|
||||
<div align="center"><img src=https://myonemanager.lzybetter.repl.co/picbed_big/picbed/2374aed8679279f14ac7dd205fe8300d.png></div>
|
||||
|
||||
<div align="center"><img src=https://myonemanager.lzybetter.repl.co/picbed_big/picbed/93e4ac2f402a11bebcc20a5d5c5141a9.png> </div>
|
||||
|
||||
|
||||
[日产leaf用户产品手册](https://myonemanager.lzybetter.repl.co/picbed/filebed/2020-nissan-connect-leaf.pdf)
|
||||
@@ -0,0 +1,27 @@
|
||||
### 本田
|
||||
|
||||
本田在旗下的插电混动车辆上推出了ECO SCORE和ECO Driving display功能,指导驾驶员保持经济驾驶;
|
||||
|
||||
#### 功能入口
|
||||
|
||||
eco score和eco driving display功能均在仪表中显示;
|
||||
|
||||
#### 功能介绍
|
||||
|
||||
##### ECO SCORE
|
||||
|
||||
ECO SCORE提供实时和行程两种评分,均采用类似树的形式进行展示
|
||||
|
||||
1. 实时评分:展示该行程中实时的驾驶行为对能耗的影响;
|
||||
|
||||

|
||||
|
||||
2. 行程评分:在行程结束时显示,显示该行程中驾驶行为对能耗的影响,下方的进度条用于展示全生命周期驾驶行为对能耗的影响;
|
||||
|
||||

|
||||
|
||||
##### Eco Driving Display
|
||||
|
||||
用于引导驾驶员改善其驾驶行为;
|
||||
|
||||

|
||||
@@ -0,0 +1,39 @@
|
||||
欧拉好猫车型提供了驾驶评价和能耗助手两个功能;
|
||||
|
||||
#### 功能入口
|
||||
|
||||
好猫的用户手册提到了两种类型的多媒体主机,两种类型的多媒体主机,驾驶行为产品入口位置不同;
|
||||
|
||||
##### 类型一
|
||||
|
||||
类型一主机提供一个名叫能耗助手的APP,可以在常驻菜单中进入;
|
||||
|
||||

|
||||
|
||||
##### 类型二
|
||||
|
||||
现场展示车辆中,驾驶评分功能位于个人中心界面
|
||||
|
||||

|
||||
|
||||
#### 功能介绍
|
||||
|
||||
##### 类型一
|
||||
|
||||
类型一多媒体主机的能耗助手APP,其包含能耗信息、驾驶行为评价、能量流和充电设置四项功能:
|
||||
|
||||
1. 能耗信息:提供续航里程、剩余电量、平均能耗、即时能耗和电机功率的统计;
|
||||
|
||||
|
||||

|
||||
|
||||
2. 驾驶评价:提供评分、行驶里程和急加速、急减速次数统计,以及驾驶建议功能;
|
||||
|
||||
|
||||

|
||||
|
||||
##### 类型二
|
||||
|
||||
类型二多媒体主机仅提供驾驶评分功能:展示驾驶评分总分、急加速和急减速次数统计,以及行驶里程。其用户手册说类型二多媒体主机也提供驾驶建议,但是实车上未找到该功能入口。
|
||||
|
||||

|
||||
@@ -0,0 +1,188 @@
|
||||
|
||||
[office](byqh7VdpgzX-tShcS4_BWPXg36V8H5O924VG9dJ6RII.mp4)
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
入口:驾驶行为分析位于负一屏卡片中,卡片包含内容:
|
||||
|
||||
- 本次行驶里程
|
||||
|
||||
- 行驶时长
|
||||
|
||||
- 能耗
|
||||
|
||||
- 费用
|
||||
|
||||
- 驾驶行为评分
|
||||
|
||||
- 安全性
|
||||
|
||||
- 节能性
|
||||
|
||||
- 文明度
|
||||
|
||||
- 环保度 包括四个页面:
|
||||
|
||||
- 本次行程
|
||||
|
||||
- 我的行程
|
||||
|
||||
- 我的成就
|
||||
|
||||
- 数据统计
|
||||
|
||||
|
||||

|
||||
|
||||
本次行程中提供当前行程的驾驶行为评分:
|
||||
|
||||
- 总分
|
||||
|
||||
- 行程开始时间
|
||||
|
||||
- 行驶里程
|
||||
|
||||
- 行驶时长
|
||||
|
||||
- 行驶能耗
|
||||
|
||||
- 费用
|
||||
|
||||
- 安全评分
|
||||
|
||||
- 急加速
|
||||
|
||||
- 急刹车
|
||||
|
||||
- 急转弯
|
||||
|
||||
- 安全带未系
|
||||
|
||||
- 疲劳驾驶
|
||||
|
||||
- 节能评分
|
||||
|
||||
- 平均车速
|
||||
|
||||
- 平稳指数
|
||||
|
||||
- 怠速时长
|
||||
|
||||
- 文明指数
|
||||
|
||||
- 转向灯指数
|
||||
|
||||
- 变道指数
|
||||
|
||||
- 环保指数
|
||||
|
||||
- 空调使用
|
||||
|
||||
- 耗能指数
|
||||
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
我的行程包括两级页面
|
||||
|
||||
- 历史行程选择,包括
|
||||
|
||||
- 最近一次行程评分展示及排名;
|
||||
|
||||
- 历史行程列表
|
||||
|
||||
- 开始时间
|
||||
|
||||
- 里程
|
||||
|
||||
- 时长
|
||||
|
||||
- 能耗
|
||||
|
||||
- 费用
|
||||
|
||||
- 总评分
|
||||
|
||||
- 历史行程详情
|
||||
|
||||
- 总评分
|
||||
|
||||
- 排名
|
||||
|
||||
- 评级
|
||||
|
||||
- 分项评分
|
||||
|
||||
- 安全性
|
||||
|
||||
- 节能型
|
||||
|
||||
- 文明度
|
||||
|
||||
- 环保度
|
||||
|
||||
- 驾驶建议
|
||||
|
||||
- 行程轨迹地图
|
||||
|
||||
- 起点
|
||||
|
||||
- 终点
|
||||
|
||||
- 行驶里程
|
||||
|
||||
- 行驶时长
|
||||
|
||||
- 能耗
|
||||
|
||||
- 费用
|
||||
|
||||
|
||||

|
||||
|
||||
我的成就,包括:
|
||||
|
||||
- 月度评分
|
||||
|
||||
- 总评分
|
||||
|
||||
- 安全性
|
||||
|
||||
- 节能型
|
||||
|
||||
- 文明度
|
||||
|
||||
- 环保度
|
||||
|
||||
- 评级
|
||||
|
||||
- 排名
|
||||
|
||||
- 最高成就
|
||||
|
||||
- 历史最高分及评级,获得日期
|
||||
|
||||
- 排名
|
||||
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
数据统计包括四个统计项
|
||||
|
||||
- 驾驶评分:按月展示每天的总评分变化曲线
|
||||
|
||||
- 驾驶里程:按月展示每天的行驶里程变化曲线,明确标记纯电行驶里程
|
||||
|
||||
- 耗电/油:按月展示每天的耗油和耗电量
|
||||
|
||||
- 每日费用:按月展示每天的电费和油费变化曲线
|
||||
@@ -0,0 +1,52 @@
|
||||
比亚迪汉车机上提供了驾驶行为分析功能
|
||||
|
||||
#### 功能入口
|
||||
|
||||
该功能位于个人界面;
|
||||
|
||||

|
||||
|
||||
#### 功能介绍
|
||||
|
||||
该驾驶行为分析功能包含四大模块:本次行程、我的行程、我的成就和数据统计
|
||||
|
||||
##### 本次行程
|
||||
|
||||
本次行程页面展示实时驾驶行为评价,提供以下信息:
|
||||
|
||||
- 急加速、急减速和急转弯次数统计;
|
||||
|
||||
- 平均车速;
|
||||
|
||||
- 未系安全带时长;
|
||||
|
||||
- 车速平稳指数;
|
||||
|
||||
- 疲劳驾驶情况;
|
||||
|
||||
- 怠速时长;
|
||||
|
||||
- 总评分;
|
||||
|
||||
- 安全评分;
|
||||
|
||||
- 节能评分;
|
||||
|
||||
- 文明指数;
|
||||
|
||||
- 环保指数;
|
||||
|
||||
- 行驶里程;
|
||||
|
||||
- 行驶时长;
|
||||
|
||||
- 电耗和预计费用;
|
||||
|
||||
|
||||

|
||||
|
||||
##### 我的行程
|
||||
|
||||
我的行程展示历史行程信息、评分、排名等信息;
|
||||
|
||||

|
||||
@@ -0,0 +1,22 @@
|
||||
在XC40和C40纯电款车型上,沃尔沃推出了名为”Range assistant“的功能,引导驾驶员实现经济驾驶;
|
||||
|
||||
#### 功能入口
|
||||
|
||||
”Range assistant“可以从应用中心进入;
|
||||
|
||||
#### 功能介绍
|
||||
|
||||
”Range assistant“功能提供如下信息:
|
||||
|
||||
- 剩余里程估计;
|
||||
|
||||
- 平均能耗;
|
||||
|
||||
- 能耗影响因素:车速、驾驶风格、空调
|
||||
|
||||
- 三个影响因素周围均有一个刻度线表示三者对能耗的影响,当其刻度线颜色由蓝变为黄色时,表示该影响因素对能耗影响较高;
|
||||
|
||||
<div align="center"><img src=https://myonemanager.lzybetter.repl.co/picbed_big/picbed/3feef5f060f1941619dfebab7282a700.jpeg></div>
|
||||
<div align="center"><img src=https://myonemanager.lzybetter.repl.co/picbed_big/picbed/dacdae8f8b6101a5f7170168dbe4476b.jpeg></div>
|
||||
|
||||
[沃尔沃range assistant介绍](https://myonemanager.lzybetter.repl.co/picbed_big/filebed/289321_Optimise_the_range_of_your_fully_electric_Volvo_with_new_Range_Assistant.pdf)
|
||||
@@ -0,0 +1,16 @@
|
||||
V1.0
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
V1.2/V2.0
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
@@ -0,0 +1,29 @@
|
||||
*官网地址:https://www.tesla.com/support/safety-score#version-1.2
|
||||
|
||||
特斯拉安全得分1.2版本:
|
||||
1. 评价指标:
|
||||
1. **autopilot未激活的里程中**,每1000英里的前向碰撞报警,该值的上限是117.5/1000miles;
|
||||
2. 急减速,减速度超过0.3g识别为急减速,计算急减速**次数**(1.0中为时长)在减速次数(大于0.1g)中所占比例,autopilot激活中的急减速不计入,该值的上限为10.9%;
|
||||
3. 急转向,侧向加速度超过0.4g识别为急转向,计算急转向**次数**\(1.0中为时长\)在所有转向次数(侧向加速度大于0.2g)中所占比例,autopilot激活中的急转向不计入,该值的上限是22.9%;
|
||||
4. 不安全跟车,计算在车速大于50mph时,headway小于1s的行驶时长占headway小于3s的行驶时长,autopilot激活中的不安全跟车不计入,该值的上限为63.2%;
|
||||
1. headway计算为,两车相对距离除两车相对速度,表征前车突然制动,本车的反应时间;
|
||||
5. 辅助驾驶系统强制退出,表示用户在启用autopilot期间没有把手放在方向盘上或者分神,该值只有0和1两个可能值,当出现辅助驾驶系统强制退出时记为1,否则为0;
|
||||
6. **深夜行驶时长,在晚上10点到凌晨4点的行驶时长占总行驶时长的比例,如行程是跨天的,那么行程会被归到行程结束的那天,不论是否启用了autopilot深夜行驶的时间都将被计入,该值的上限为29.3%;**
|
||||
|
||||
2. 评价公式:
|
||||

|
||||

|
||||
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
官网:
|
||||
https://www.tesla.com/support/safety-score#version-1.2
|
||||
@@ -0,0 +1,44 @@
|
||||
*官网地址:https://www.tesla.com/support/safety-score#version-2.0*
|
||||
|
||||
特斯拉安全得分2.0版本:
|
||||
1. 评价指标:
|
||||
1. 前向碰撞预警:autopilot未激活的里程中,每1000英里的前向碰撞报警,该值的上限是130.7/1000miles;
|
||||
2. 急减速,减速度超过0.3g识别为急减速,计算急减速在减速(大于0.1g)中所占比例,autopilot激活中的急减速不计入,**对于autopilot电脑3.0以上的车辆,当车辆识别到交通灯为黄灯时,其急减速也不计入**,该值的上限为5.8%;
|
||||
3. 急转向,侧向加速度超过0.4g识别为急转向,计算急转向在转向过程(侧向加速度大于0.2g)中所占比例,autopilot激活中的急转向不计入,该值的上限是15.7%;
|
||||
4. 不安全跟车,计算在车速大于50mph时,headway小于1s的行驶时长占headway小于3s的行驶时长,autopilot激活中的不安全跟车不计入,该值的上限为64.2%;
|
||||
1. headway计算为,两车相对距离除两车相对速度,表征前车突然制动,本车的反应时间;
|
||||
5. **超速行驶,计算车速大于85mph的行驶时长占总行驶时长的比例,该值的上限为7.6%;**
|
||||
6. 深夜行驶时长,在晚上10点到凌晨4点的行驶时长占总行驶时长的比例,如行程是跨天的,那么行程会被归到行程结束的那天,**深夜行驶中,在晚上10点到凌晨4点的不同时段行驶的权重不同**,不论是否启用了autopilot深夜行驶的时间都将被计入,该值的上限为15.2%;
|
||||
7. 辅助驾驶系统强制退出,表示用户在启用autopilot期间没有把手放在方向盘上或者分神,该值只有0和1两个可能值,当出现辅助驾驶系统强制退出时记为1,否则为0;
|
||||
8. **不系安全带行驶:计算当车速大于10mph时,不系安全带的行驶时长占总行驶时长的比例,该值的上限为4.1%;**
|
||||
|
||||
2. 评分公式:
|
||||

|
||||

|
||||
|
||||
3. 深夜出行的权重:
|
||||

|
||||
|
||||

|
||||
|
||||
仅对有夏令时的市场有效的规定,行驶时长是按照行程结束的地点的时区计算的。若行程中出行夏令时转换,深夜出行时间会记录为早上10点到下午4点之间的行驶时长。
|
||||

|
||||
|
||||
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
|
||||
@@ -0,0 +1,189 @@
|
||||
**导读:**
|
||||
|
||||
本文由类星频道授权发布,作者为Chris Zheng。
|
||||
|
||||
上月末,期待已久的Tesla OS v2021.32.22 和特斯拉 App v4.1 版本更新,新更新的版本中更新了FSD 完全自动驾驶 Beta 版申请按钮」和「安全评分 Beta 版」两个功能,基于这两个功能,特斯拉在数据驱动业务的维度向前跨越了一大步。
|
||||
|
||||

|
||||
|
||||
简单来说,美国地区选装了 FSD 的特斯拉车主可以在系统更新至 2020.32.22 后点击「申请完全自动驾驶能力 Beta 版」,系统内置的「特斯拉保险计算器」会运行「安全评分 Beta 版」,待系统连续 7 天认定驾驶员驾驶习惯安全可靠后,该车即可收到 FSD Beta 的推送更新。
|
||||
|
||||

|
||||
|
||||
从 FSD 的全栈算法、公测用户的运营扩张乃至衍生的特斯拉 UBI(Usage-based insurance)车险,这一整个闭环的业务,特斯拉全部转向了基于数据驱动的机器学习。由此,特斯拉开启了全面升维的竞争。
|
||||
|
||||
_**1**_
|
||||
|
||||
**安全评分Beta版**
|
||||
|
||||
之所以将「安全评分 Beta 版」放在开头介绍,是因为无论是「FSD 完全自动驾驶 Beta 版申请按钮」还是「特斯拉保险」,都是以「安全评分」为根基的业务。那么,什么是「安全评分」?
|
||||
|
||||
据特斯拉的介绍,「安全评分」根据 5 个与安全相关的指标对特斯拉车主的驾驶行为进行评估,特斯拉将基于这些数据预测当事车主的驾驶习惯在未来驾驶车辆发生碰撞的可能性。
|
||||
|
||||
「安全评分」的目的是为驾驶员提供透明度和对其驾驶行为的反馈。「安全评分」介于 0 和100 之间,分数越高表明驾驶越安全,特斯拉认为绝大多数司机的评分应当 ≥ 80 分。
|
||||
|
||||
那 5 个「安全相关的指标」分别是什么呢?
|
||||
|
||||
驾驶员对车辆的操作控制无外乎横向和纵向控制两大维度,其中横向控制主要通过往左右打方向盘来实现,纵向控制通过加速和制动踏板实现。特斯拉「安全评分」的 5 个指标也逃不出这三大执行操作:
|
||||
|
||||
每千英里前方碰撞预警触发率(下记为 A)
|
||||
|
||||
一个冗长但并不难理解的名词,每驾驶 1000 英里,驾驶员未介入而特斯拉 Autopilot 系统认为可能发生碰撞,从而触发「前方碰撞预警」的次数。
|
||||
|
||||

|
||||
|
||||
急刹车(下记为 B)
|
||||
|
||||
一个比值。特斯拉的定义是在驾驶行程中,刹车减速度超过 0.3 g(相当每过一秒钟车速下降超过 6.7 mph(10.78 km/h)),除以刹车减速度超过 0.1 g(相当于每过一秒钟车速下降超过 2.2 mph(3.54 km/h))的比值。
|
||||
|
||||
猛转向(下记为 C)
|
||||
|
||||
同样是一个比值。特斯拉的定义是在驾驶行程中,车辆左/右加速度超过 0.4 g(相当于每过一秒钟车辆向左/右的速度增加超过 8.9 mph(14.32 km/h)),除以车辆左/右加速度超过 0.2 g(相当于每过一秒钟车辆向左/右的速度增加超过 4.5 mph(7.24km/h))的比值。
|
||||
|
||||
不安全跟车(下记为 D)
|
||||
|
||||
D 是一个动态值。Autopilot 根据本车速度、前车速度和两车间的距离判断。计算方法为当前车突然刹停,驾驶员做出反应并刹停所需的时间长度。D 的定义为反应时间低于 1 秒除以反应时间低于 3 秒的比值。此外,D 只有车速在 50 mph(80.47 km/h)才会被记录。
|
||||
|
||||

|
||||
|
||||
强制退出 Autopilot(下记为 E)
|
||||
|
||||
特斯拉车主都知道,Autopilot 会在连续警告三次均得不到驾驶员的响应后退出,当驾驶员双手脱离方向盘或分心驾驶后,系统将发出警告。E 的定义是 5 个指标中最为简单的一个:如果驾驶行程中 Autopilot 出现强制退出,记为 1,否则记 0。
|
||||
|
||||
特斯拉有一个 PCF(Predicted Collision Frequency,预测碰撞频率)计算公式,将上述 A、B、C、D、E 五个数值计入如下公式,即可得出 PCF 值。
|
||||
|
||||

|
||||
|
||||
安全评分 = 115.382324 - 22.526504 × PCF
|
||||
|
||||
你一定想问,这 8 个精确到小数点后 6 位的数都是怎么来的。特斯拉表示,当前公式都是基于 60 亿英里车队数据的统计模型得出的。
|
||||
|
||||
到这里,其实你已经能看出,这个「安全评分」并不简单。基于已有的 60 亿英里车队数据,准确地分辨出哪些车主的驾驶习惯良好,听上去就不是个轻松的事情,事实上,从首批车主的体验反馈看,连特斯拉也低估了 Ta 的难度。
|
||||
|
||||
_**2**_
|
||||
|
||||
**FSD内测规模如何有序扩张**
|
||||
|
||||
自 2020 年 10 月 21 日特斯拉首次公测 FSD Beta 至今,围绕特斯拉 FSD 一个相当广泛的质疑是,FSD Beta 公测的车队规模一直保持在 2000 辆上下。没有进入美国更多的州,也没运行在更多的 FSD 车型上。
|
||||
|
||||

|
||||
|
||||
这和大众对特斯拉 FSD 的预期相去甚远,世界不需要另一个可扩展性严重受限的自动驾驶系统。过去 5 年来,Waymo、Cruise 们都没能带给我们惊喜,而特斯拉几乎是唯一一家直到 2021 年仍然「逢自动驾驶必谈 Scalability」的主流自动驾驶玩家。
|
||||
|
||||
但在质疑背后,特斯拉一直在以近乎疯狂的效率迭代着 FSD Beta 的全栈算法,不夸张地说,从 2020 年 10 月至今,超 20 个大小版本迭代后的 FSD Beta 10.1 已经发生了脱胎换骨的变化。这一点从 8 月 19 日的特斯拉 AI Day 大会亦可看出端倪。
|
||||
|
||||

|
||||
|
||||
今天,FSD Beta 进阶到了一个尴尬的境地:一方面,特斯拉需要更多、更丰富的场景,以加快加速算法的迭代,这意味着更大规模的公测车队;另一方面,FSD Beta 虽然已经取得了巨大的改进,但 Ta 还不够好,至少不足以放心地让特斯拉将之推送到每一辆 FSD 车上。
|
||||
|
||||
在这片技术的无人区中,包括美国在内的全球各地监管机构,对自动驾驶技术多是抱以支持和鼓励发展的宽松监管态度,却并没有就自动驾驶系统如何有序、安全、可控地扩展到每一辆车上给出详细的管理办法。
|
||||
|
||||
这是技术跑在监管前的窘境,首批 2000 名公测车主易选(实际上也不是那么容易),20000 名呢?200000 名呢?今天,特斯拉在全球的保有量已经超过了 2000000 辆。这是一个非常棘手的问题。
|
||||
|
||||
于是特斯拉基于 60 亿英里的车队数据得出的统计模型做出了安全评分 Beta。
|
||||
|
||||

|
||||
|
||||
然后特斯拉的 Autopilot、座舱和 App 团队协作,面向美国的 FSD 车主同时推送 Tesla OS v2021.32.22 和特斯拉 App v4.1 版本更新。
|
||||
|
||||
不过,和特斯拉的第一版智能召唤 Beta、第一版自动辅助导航驾驶(NoA)Beta 甚至第一版 FSD Beta 一样,第一版的安全评分体验之差,开发之 Beta 超出了不少车主的预期。
|
||||
|
||||
例如,知名特斯拉博主 @TeslaJoy 和 @Scott Wainner 都表示,驾驶员并没有违反上述 5 个指标,仅仅是基于 Autopilot 或 NoA 驾驶了一段行程,就会被「安全评分」判定为存在「急刹车」、「猛转向」或「不安全跟车」行为,将分数扣掉。两位博主暴露的问题在于,由于版本过于 Beta,特斯拉开发的自动驾驶算法甚至不能通过特斯拉「安全评分」的考验。
|
||||
|
||||

|
||||
|
||||
由于安全评分的标准过于苛刻,大量车主选择谨慎驾驶以避免被扣分。外媒 Electrek 甚至给出了这样的标题:到处都是慢吞吞的特斯拉(Slow Teslas everywhere)。
|
||||
|
||||

|
||||
|
||||
知名赛道爱好者、Model S Plaid 车主 Dragtimes 在零接管的情况下被打出了 5 分的低分。
|
||||
|
||||

|
||||
|
||||
另一位特斯拉车主、通用旗下自动驾驶公司 Cruise 产品副总裁 Oliver Cameron 表示,如果一个致力于实现从 A 到 B 的自动驾驶产品,运行时给你的压力要比你自己开车压力还大,那 Ta 可能不是个好产品。
|
||||
|
||||

|
||||
|
||||
_**3**_
|
||||
|
||||
**「安全评分」的想象力**
|
||||
|
||||
「安全评分」的想象力不止于此。「安全评分」的本质,在于通过对驾驶员驾驶行为尽可能细颗粒度的拆解与统计,有效地预测车辆在未来的事故率。
|
||||
|
||||
驾驶数据越丰富、驾驶场景越细致、「安全评分」的预测准确性就越高。Elon 曾经说过,与传统汽车保险公司竞争的核心在于信息的准确性。得益于特斯拉全球第一大智能电动汽车制造商的地位,特斯拉坐拥业内最丰富也最详细的车队数据。从业务角度看,特斯拉对汽车保险公司的打击是降维的。
|
||||
|
||||
特斯拉进入汽车保险领域,这是比有序扩张 FSD 内测规模重要得多的新业务,这也是为什么,运行「安全评分」的主体名叫特斯拉保险计算器。
|
||||
|
||||

|
||||
|
||||
此外,特斯拉保险的全面推开还会有反向教育驾驶员,从而进一步降低事故率的潜力。Elon 认为,人们会为了更低的保费学习更谨慎的驾驶车辆。「这就像……如果你想为保险支付更多费用,你可以(高风险驾驶),但如果你想少付费,那请不要那么疯狂。人们会做出选择」。
|
||||
|
||||
当然,这一切的前提是特斯拉做得足够好,以当前铺天盖地的针对「安全评分」的吐槽来看,现有的汽车保险公司不仅没有感到压力,甚至差点笑出了声。
|
||||
|
||||
但特斯拉一点不慌。不仅不慌,特斯拉很可能在推送前就预知了这样的反馈。
|
||||
|
||||
因为特斯拉除了在博客中提到「随着我们获得更多的用户和数据洞察,我们希望在未来对公式进行迭代」,在上线当天,Elon 也特别提到目前还是一个非常 Beta 的版本,「安全评分」将随着时间的推移而进化,以更准确地预测事故率。
|
||||
|
||||

|
||||
|
||||
事实上,特斯拉对「安全评分」的布局甚至早于 FSD Beta 公测。在 2020 年 7 月 22 日的特斯拉 Q2 财报会议上,Elon 公开招聘「革命性精算师」:
|
||||
|
||||
我特别欣赏一些精力充沛的精算师,我非常尊重精算师这个职业。你们的数学很好,请加入特斯拉,特别是如果你对保险行业的缓慢节奏感到恼火并想做出改变,这儿就是你要去的地方,我们需要革命性的精算师。
|
||||
|
||||

|
||||
|
||||
Elon 没开玩笑。今天,特斯拉建立起了一支精算师团队,Title 真的就叫革命性精算师(Revolutionary Actuary)。在特斯拉「革命性精算师」的职位描述中,有两条要求让人印象深刻,一是和「数据科学家」协作,二是熟练掌握Python,拥有开源机器学习库和框架,例如 Scikit-learn、PyTorch 和 Tensorflow 的应用经验。
|
||||
|
||||
特斯拉「数据科学家」隶属于车队分析(Fleet Analytics)团队,特斯拉称这是一支规模虽小但发展迅速的中央团队,赋能其他业务团队以改进产品,使特斯拉车主更安全。
|
||||
|
||||
特斯拉要求「数据科学家」要具有强大的机器学习和软件工程基础,拥有多种机器学习模型的开发经验,基于开源技术处理 PB(Petabyte,千万亿字节)级的时间序列数据。
|
||||
|
||||
特斯拉在中国也放出了「数据科学家」的职位,但对于特斯拉中国而言,相比算法,更重要的也许是先解决「数据原料」的问题。
|
||||
|
||||
Elon 在 2021 年世界互联网大会乌镇峰会上表态,特斯拉已经在中国建立了数据中心,用来存储中国业务产生的所有数据。包含生产数据、销售数据、服务数据和充电数据,所有个人身份信息都安全的存储在中国国内,不会转移到海外。
|
||||
|
||||

|
||||
|
||||
在展台背景板上,特斯拉更详细地向中国政府和消费者解释了「如何处理客户个人信息和车辆数据」:
|
||||
|
||||
收集:合法合规、最小必要、公开透明原则
|
||||
|
||||
存储:完全存储在中国境内,通过数据加密、鉴权、访问控制等技术确保存储安全
|
||||
|
||||
传输:通过数据加密,专用证书体系确保传输过程安全
|
||||
|
||||
删除:用户有权撤销自己的数据及数据使用授权
|
||||
|
||||
跨境:个人身份信息不出境。需要出境的重要数据均经主管部门批准后进行
|
||||
|
||||

|
||||
|
||||
随着车队规模的持续增长,数据驱动开始越来越多的植入特斯拉的产品与工程。
|
||||
|
||||
2016 年 10 月,特斯拉开始基于车队数据,用机器学习算法驱动 Autopilot 辅助驾驶系统,逐步提高越来越多的场景下的驾驶自动化率。
|
||||
|
||||
2019 年 10 月,特斯拉基于车队数据中的 100 万张照片,训练出了机器学习算法 Deep Rain 神经网络,用以识别不同强度的雨量工况并匹配自动雨刮频率。
|
||||
|
||||

|
||||
|
||||
2020 年 5 月,特斯拉基于储能电池 Powerwall、Powerpacks 和 Megapacks 的集群数据,推出了机器学习能源交易平台 Autobidder 和机器学习能源优化引擎 Opticaster,到 2021 年 5 月,Autobidder 平台上管理着超过 1.2 GWh 的电池资产,Opticaster 积累了超 1 亿小时的运营经验,为全球数千名特斯拉客户提供了数千万美元的价值。
|
||||
|
||||
2021 年 9 月,特斯拉基于 60 亿英里的车队数据推出了驾驶安全性评估软件「安全评分」,根据 Elon 的说法,在特斯拉保险之前,「安全评分」将首先评估和指引 FSD Beta 公测规模的扩张,从下周起,FSD Beta 公测车队将以 1000 辆/天的速度快速扩张。
|
||||
|
||||
2021 年 9 月,Elon 接受特斯拉车主的提议,决定基于车队数据训练一个新的深度神经网络,用以自动化控制各种工况下的特斯拉汽车空调,例如在堵车、山火烟雾、土路和暴雨时启动空气循环。
|
||||
|
||||
在过去,无论是辅助驾驶、自动雨刮还是能源交易&场景优化、汽车保险软件,无一例外是「由软件工程师手动编写规则」(软件 1.0)运行,在特斯拉,「数据驱动的机器学习」(软件 2.0)正在变得无孔不入。
|
||||
|
||||

|
||||
|
||||
通过定义所需行为的数据集和深度神经网络架构和不同的权重,特斯拉相信第一版奇差无比的机器学习性能会变得更强,最终全面超越人类工程师编写的规则。
|
||||
|
||||
「越来越多的软件 1.0 被软件 2.0 取代,软件 1.0 吞噬世界,软件 2.0 吞噬软件 1.0。从长远来看,这种范式的前景是光明的,因为越来越清晰的是,当我们开发通用人工智能的时候,Ta 肯定会基于软件 2.0。」
|
||||
|
||||
这是一种全新的研发哲学,特斯拉高级 AI 总监 Andrej Karpathy 于 2017 年在一篇博客中提出,博客的标题就叫,软件 2.0。
|
||||
|
||||
**END**
|
||||
|
||||
**入群申请**
|
||||
|
||||
无人车情报局交流群开放喽~~自动驾驶、高精度定位、高精度地图和ADAS四类技术交流群欢迎大家申请。备注“姓名-公司/学校/单位-职位/专业”将会优先审核通过哦~~
|
||||
@@ -0,0 +1,9 @@
|
||||
用车:
|
||||
|
||||
**1. 用车月报**
|
||||
|
||||
本次更新后,主用车人可以在旅程列表中查看到2019年开始每个月的用车报告。本月月报一般会在下月初的第一天生成,大家可以通过切换月份就能找到当月报告。月报数据来源于云端数据服务聚合,所以可能个别情况下与实际车辆数据略有偏差。
|
||||

|
||||
|
||||
此外,因为月报是粗颗粒度的数据聚合,因此无论当月是否有用车、车辆的旅程功能是否开启,云端都会生成月度使用报告,供大家在需要时查看。相关用车排行的产品也已经在计划中,要给研发同学们继续加鸡腿了。
|
||||

|
||||
@@ -0,0 +1,33 @@
|
||||
大家好,NIO App 4.1.0已经在各大应用商店陆续上线了。本次升级,旅程页面上线用车排行榜功能,新增单次旅程瞬时能耗曲线的展示,惊喜商城支持领取和使用优惠券。
|
||||
|
||||
**一、爱车**
|
||||
|
||||
**1. 新增“用车排行榜”功能**
|
||||
|
||||
本次上线的“用车排行榜”功能,将与旅程月报一起,为大家提供更多维度的用车数据,大家可以通过“爱车-旅程-排行”进入。
|
||||
|
||||
本期提供的是以月为统计周期的榜单,涵盖了里程数据和电耗数据,支持“全国排行”和“城市排行”。需要说明的是:一、车辆数据都统计在主用车人名下,因此榜单显示的是主用车人的头像。二、为了尊重隐私,“用车排行榜”功能默认为关闭状态,在第一次进入排行页面时可选择是否参与。选择参与后,用车数据和排名会出现在榜单中,后续也可点击排行页面右上角的“榜单设置”进行更改。
|
||||
|
||||
大家如果有更多榜单建议和想法,欢迎在评论区留言。
|
||||
|
||||

|
||||
|
||||
**2.新增单次旅程瞬时能耗曲线展示** ^d2983f
|
||||
|
||||
在旅程页面,我们增加了单次旅程的瞬时能耗曲线展示,方便大家回顾在这段旅程中车辆的瞬时能耗和动能回收的情况,从而更全面地了解自己的驾驶行为,同时建立能耗预期。
|
||||
|
||||
大家可在页面中查阅到最近1年的能耗数据。需要注意的是,由于存在部分场景下离线数据无法及时同步到云端和统计的情况。单次能耗的显示数据和实际数据会有一定出入。另外,因历史数据同步需一定时间,如大家要查看5月及之前的单次旅程能耗数据,可在6月15日之后查询。
|
||||
|
||||

|
||||
|
||||
**二、惊喜商城支持领取和使用优惠券**
|
||||
|
||||
新版本的惊喜商城支持领取和使用优惠券啦。大家可以在商城首页、商品详情页等多个页面领取优惠券。
|
||||
|
||||

|
||||
|
||||
下单支付时,系统会默认选中账户中符合使用条件且优惠力度最大的一张优惠券,大家也可以点击“优惠券”一栏,查看和更换优惠券。
|
||||
|
||||
此外,「爱车」页面,优化了操作后备箱开启后的提示说明。朋友页面中,群聊会话上线了“群公告”功能,大家再也不用担心错过群内重要信息了。
|
||||
|
||||
以上就是本次升级的主要内容,期待大家及时更新体验。
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user