- 主题:为什么说特斯拉的行车数据是遮掩的，挑选的，并且美化的
你这个分析的好，有道理。后台数据绝不是这么几条，肯定是有选择的挑出来的。
真正的数据，时间间隔应该是固定的，并且间隔很小才对。
一般数据应该会暂存本地一份，上传一份。本地是滚动删除的，删除间隔应该会很大，比如半年，至少也得是一个月，因为这类文本数据本来就没有多大，特别是本地存储，也会是压缩方式保存，这就更小了。
所以等着看特斯拉提供的数据吧。
【 在 motour 的大作中提到: 】
: 以某车的can log为例，我挑三个信号出来放大。车速、加速踏板、刹车踏板。什么时候踩的电门，什么时候踩的油门，对应什么车速，踩的力度多少，是不是都非常清晰？
:
: [upload=1][/upload]
: ...................
--
FROM 175.190.122.*
数据上传应该不是完全实时的，应该是本地先存储，然后压缩上传。至于时间间隔，可能是一分钟或几分钟。
这些信息没有多大的，都是一些文本的数据，压缩后就更小了。所以保存即使再多的数据也是完全无压力的。
【 在 moudy 的大作中提到: 】
: 基本同意你的观点，但是我深刻怀疑tesla有没有随时随地记录车总线的数据
: 这些数据基本5ms到10ms更新一次，一辆车光CAN总线就十几条，tesla这类新型车还有以太网backbone，想完整记录数据难度其实不小。tesla公布的这些估计都是从uds里抓出来data identifier，离CAN总线原始数据差好多
: 这也是我在另外一个帖子里说tesla应该ota一个有余力的ecu来记录这些数据
--
FROM 175.190.122.*
哦，那我确实不了解。
不可以把这些数据先传到车机的磁盘上，然后再用车机程序上传到服务器吗？并且在车机的磁盘上做压缩并滚动保存。上传时，也是上传压缩后的数据。文本的压缩率非常大的，上传原始数据非常不划算。
对车机来说，这些传感器之类也只算是一个外设吧，这样车机从外设读取数据，应该是个非常常规的操作，没有任何难度。
所以我还是想不明白难在哪里了。
上传日志太多确实会导致服务器端压力过大，所以不可能是保持长连接实时上传。所以才需要按定时压缩成包上传。
我也做过互联网公司的日志后期处理，一天几T数据不算太大吧？特斯拉车子现在的保有量也不算大，能上百万吗？百万个客户端应该还不算太多的。
【 在 moudy 的大作中提到: 】
: 上传是要花钱的。几百万辆车，每辆车每天上传1M数据就是几T的数据。我给厂家做过上传数据的项目，那真是一个字节一个字节的算的，远没有你想的那么舒服。
: 本地滚动啥的说明你不知道车上这些ECU是啥级别。
: 比如当前雷达处理用的S32R274, 对一般的ECU需求来说已经是很nb的CPU了，双核180MHz, 2M（没错2048K)闪存，1.5M内存
: ...................
--
FROM 175.190.117.*
上传数据的地方，应该是在车机系统里吧？如果是这样，那完全没必要把数据写到外设的flash中啊，传到车机中有什么难的吗？保存在车机的硬盘中有什么难的吗？
我很久以前做过嵌入式监测设备里的程序开发，我的数据是直接用程序上传到中心端的，根本不会写到本地flash中。
flash中，我只是把程序烧进去，好像我就没往flash中写什么东西。不知道为什么都十几年过去了，怎么还要往flash中写数据？？？
【 在 moudy 的大作中提到: 】
: tesla对flash是典型的往死里用。这些FSD车主是beta车主，自然更狠的压榨。
: ECU项目一个特别重要的就是flash生命周期控制。一辆车要按20年寿命算,64M闪存每秒钟不能超过100K的写入。
: 现在的新能源平台都大方起来的，终于用GB来配闪存了，就这样Tesla闪存写废了换ECU的事已经出现不少了......
: ...................
--
FROM 175.190.117.*
哦，这个有道理。可能是这个原因了.
【 在 moudy 的大作中提到: 】
: 我觉得tesla有技术能力，车上那个大屏车机也有硬件能力做这个，我也主张他们收集数据，甚至应该一个车机收集常规数据，另一个车机收集其它佐证类数据。比如主车机收集轮上读到的车速，刹车踏板角度，另一个车机收集gps车速，减速度及刹车泵压力之类的。
: 我就是思考能不能读到
: 一般车机这些娱乐系统要和刹车等安全性系统隔离开。不然，比如车机被天窗漏雨搞挂了，把刹车总线短路了，那刹车系统就掉线了。安全设计不会允许这种事情发生的。
: ...................
--
FROM 175.190.117.*
这个不是这样的吧。
数据上传肯定不会是实时的。应该是每几分钟压缩一个包上传一次。所以即使断网一小时也没关系，网好了把本地保存的数据上传了就行了嘛。
至于你说的设备中的数据本身存不下也是不存在的，设备和车机肯定可以连接啊，设备把数据传到车机中总是可以的吧。除非像你说的，整个日志上传就不会经过车机，完全是设备自己搞定那就没办法了。
如果是我来设计系统，会把车机做为一个冗余，所有数据会存在车机中一份，即使设备自己能上传，我也会在车机中做滚动保存。一旦设备自己没有上传数据，就可以把车机中的数据上传过去，这样就可以多一层保证数据不会丢失。这也是很自然的设计啊，没道理不这样做。
这样的话，设备中也不需要写flash了，没必要了。
所以数据是完全不可能丢失的。
【 在 moudy 的大作中提到: 】
: 车是移动的啊，没法保证随时在线，数据就得缓存起来。不然回头用户说tesla刹不住，tesla说你隧道里撞的，数据漏记了一大段，这不立马被人喷死。
: 车机也不会把这个发不出去的数据放内存里，车上ecu的内存都是量身定制的容量，哪有这么富裕。
:
--
修改:hellogg FROM 175.190.117.*
FROM 175.190.117.*
车上的系统啊，这系统没有磁盘吗？肯定有吧。是个安桌系统吧。上边能听音乐，下程序，为啥不能保存数据呢。
【 在 moudy 的大作中提到: 】
: 问题是你说的“本地保存”是个怎么样的操作？车上肯定没有硬盘给你用，我觉得也没可能放内存里。那不就只剩flash了？传到车机里也是存到车机flash里哦
--
FROM 175.190.122.*
哦。至少车机的flash空间应该大些，这样数据就不会总是写在同一物理位置，坏的可能就会降低吧。
没弄过现在这些东西，不了解了。
【 在 moudy 的大作中提到: 】
: tesla咋可能用安卓，估计是个嵌入式linux系统。磁盘是逻辑层面上的东西，底层不还是flash么。
: 车机的问题是得按照20年寿命设计。咱们手机可不是按这个标准造的，基本上五年后坏了也没人心疼。车机七年坏了都要被骂。
: :
--
FROM 175.190.122.*