这是一个创建于 192 天前的主题，其中的信息可能已经有所发展或是发生改变。
内容节选自小米官方发布:
{
同时，我们的专项组也将在警方的许可与指导下，与事故受难者家属取得联系，全力协助善后事宜，并提供支持与帮助。
我们将目前所知并提交给警方的信息，摘要公布如下：
3 月 29 日 22:27:17 NOA 激活，车速 116km/h
3 月 29 日 22:28:17 轻度分心报警
3 月 29 日 22:36:48 NOA 发出脱手预警提示“请手握方向盘”
3 月 29 日 22:44:24 NOA 发出风险提示“请注意前方有障碍”，发出减速请求，并开始减速
3 月 29 日 22:44:25 NOA 被接管，进入人驾状态，方向盘往左转角 22.0625 度，制动踏板开度 31%
3 月 29 日 22:44:26 方向盘往右转角 1.0625 度，制动踏板开度 38%
3 月 29 日 22:44:26-28 之间车辆与水泥护栏发生碰撞
3 月 29 日 22:44:28 车端 Ecall 触发
3 月 29 日 22:44:39 车端 Ecall 接通，确认事故发生，并报警、呼叫 120 急救服务
3 月 29 日 22:45:06 与车主取得联系，确认非车主驾驶
3 月 29 日 22:47:15 调配 120 成功
3 月 29 日约 23 时许 120 抵达现场
}
对以上内容我有个设想: 是否存在在事故初步报道阶段择选择性报道事实的可能? 作为程序员我绝对不相信日志等级只到秒级, 明明就连方向盘转角都是小数点后四位的数据了
100km 每小时的时速,如果选择只公布到秒级,可操作和想象空间很大. 目前大家都说智驾被接管后 2 秒撞车, 这能否算是被误导了
打个比方, 如果 24 秒 80 发现有问题, 结合人的反应时间是 0.3 秒,如果 25 秒半接管, 那也就是总共不到一秒, 那如果撞车在 26 秒 20 也是有可能的吧
小米公布了一系列的事实: 主驾驶并非购车车主; 事故发生前十几分钟有分心报警; 秒级日志; 方向盘转角而不是轮上转角
我能理解现在属于事故早期阶段调查取证比较困难, 但总体认为这封披露的初步报道有"说对自己有利的"嫌疑
顺便问一下大家, 道路施工限速路段 , NOA 未能降低至道路限速是不是车企应该改进的方向, 甚至更进一步直接要求退出 NOA 人为接管
{
同时，我们的专项组也将在警方的许可与指导下，与事故受难者家属取得联系，全力协助善后事宜，并提供支持与帮助。
我们将目前所知并提交给警方的信息，摘要公布如下：
3 月 29 日 22:27:17 NOA 激活，车速 116km/h
3 月 29 日 22:28:17 轻度分心报警
3 月 29 日 22:36:48 NOA 发出脱手预警提示“请手握方向盘”
3 月 29 日 22:44:24 NOA 发出风险提示“请注意前方有障碍”，发出减速请求，并开始减速
3 月 29 日 22:44:25 NOA 被接管，进入人驾状态，方向盘往左转角 22.0625 度，制动踏板开度 31%
3 月 29 日 22:44:26 方向盘往右转角 1.0625 度，制动踏板开度 38%
3 月 29 日 22:44:26-28 之间车辆与水泥护栏发生碰撞
3 月 29 日 22:44:28 车端 Ecall 触发
3 月 29 日 22:44:39 车端 Ecall 接通，确认事故发生，并报警、呼叫 120 急救服务
3 月 29 日 22:45:06 与车主取得联系，确认非车主驾驶
3 月 29 日 22:47:15 调配 120 成功
3 月 29 日约 23 时许 120 抵达现场
}
对以上内容我有个设想: 是否存在在事故初步报道阶段择选择性报道事实的可能? 作为程序员我绝对不相信日志等级只到秒级, 明明就连方向盘转角都是小数点后四位的数据了
100km 每小时的时速,如果选择只公布到秒级,可操作和想象空间很大. 目前大家都说智驾被接管后 2 秒撞车, 这能否算是被误导了
打个比方, 如果 24 秒 80 发现有问题, 结合人的反应时间是 0.3 秒,如果 25 秒半接管, 那也就是总共不到一秒, 那如果撞车在 26 秒 20 也是有可能的吧
小米公布了一系列的事实: 主驾驶并非购车车主; 事故发生前十几分钟有分心报警; 秒级日志; 方向盘转角而不是轮上转角
我能理解现在属于事故早期阶段调查取证比较困难, 但总体认为这封披露的初步报道有"说对自己有利的"嫌疑
顺便问一下大家, 道路施工限速路段 , NOA 未能降低至道路限速是不是车企应该改进的方向, 甚至更进一步直接要求退出 NOA 人为接管
第 1 条附言 192 天前
感谢 40 楼, 大家可以查看
https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=CC68F6BFD3E104560914271598AFE8C8
GB 39732-2020 汽车事件数据记录系统
P19 附录 A 表 A.1 数据元素格式,了解 EDR 应监测, 采集和记录的数据元素格式
当然采集 ≠ 公告中要体现, 公告是面向大众的, 也要考虑单位统一, 再或者, 别的问题
https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=CC68F6BFD3E104560914271598AFE8C8
GB 39732-2020 汽车事件数据记录系统
P19 附录 A 表 A.1 数据元素格式,了解 EDR 应监测, 采集和记录的数据元素格式
当然采集 ≠ 公告中要体现, 公告是面向大众的, 也要考虑单位统一, 再或者, 别的问题
 | 1 gy0624ww 192 天前 秒级这个确实有掩盖嫌疑 |
 |
 | 3 myarsenal 192 天前  11 要求毫秒级日志，应该是程序员才会提出的质疑了 |
 | 4 whisp 192 天前 毫秒级的日志不会实时上报服务端吧，在本地损毁没保存下来 |
 | 5 kokerkov 192 天前 毫秒级有什么意义？ |
 | 6 oALwp9HWJ28EJ3be 192 天前 我爸问我毫秒什么意思 |
 | 7 sq125 192 天前 4 没开过智驾的车，我就想知道，网上铺天盖地的家属怎么知道车门打不开的？手机 app 上会提示车门锁死了吗？怎么都在说这个？ |
 | 9 worldgg 192 天前 毫秒级日志应该有内部相关信息，就像正常开发的 app 的日志，对外提供日志信息也是提供 info 级别的日志，能够描述当时的情况足以，不可能提供到 debug 级别的日志 |
 | 10 nuansediao 192 天前 靓仔们，系统如何记录到 120 到达现场的？当时不都断电了吗。 |
 | 11 Felixchen1062 OP @whisp Date 或时间相关的 API 默认或常用都是毫秒级时间戳吧, 你上传到云端也是毫秒级的事件才对吧(不是所有事件, 而是这个事件发生的精确时间 ) 上传到服务端秒级日志在现代系统里是正常情况吗 |
| 12 Felixchen1062 OP @sq125 家属所有的关于驾驶室相关内容都是主观推断, 我们作为程序员还是要听事故报告和分析车机的日志才对 在这里, 我们不讨论家属的行为 只讨论小米官方披露的信息 |
| 13 Felixchen1062 OP @worldgg 目前的情况就是我觉得秒级的日志无法还原这样高速的紧急事故现场, 一秒和两秒的差距还是蛮大的, 对于 100+车速来说 另外对于日志时间单位我想请教, 你们对外系统你们提供日志会只提供秒级而不是更精确的时间吗? 我觉得这和日志等级 info debug warn balabla 无关吧 时间单位不是统一的吗 |
 | 14 Vaspike 192 天前 @nuansediao 这里应该是小米中心服务器端处理的日志了吧 |
| 15 Felixchen1062 OP @tokoy 我想知道的是现代电动车是否有能力公布毫秒级的事故日志, 旧的油车没有这么复杂的系统, 真的很难查证, 别的新能源国产我相信也有这个能力做(做没做我不清楚), 但我觉得单就时间单位来说, 这一点对小米应该不算难事, 你有能力做但你不做,说原因是大家也没做那也不合适对吧 天天 debug 和日志打交道, 真的感觉这个秒级日志真的分析不出个什么头绪来, 试想一下你的日志全是秒级的咋看嘛 |
 | 16 leimu012 192 天前 @nuansediao 都已经约 23 时了，应该是 120 那边提供的信息吧，要是车的摄像头记录的那就是准确时间了 |
 | 17 forgottencoast 192 天前 |
 | 19 FreddyLiu 192 天前 以后车上也配备一个黑匣子 |
 | 20 Leon777 192 天前 我看你是想难为平均学历中专的网友们 |
 | 21 meghoul 192 天前 7 毫秒级对驾驶人来说有啥意义啊？ 我感觉大家有点过于关心/分析发布的日志了，其实痛点还是下面几个： 1. 电车电池太容易自燃 2. 不完全的智驾让人麻痹大意放松对车的操控 3. 事故后电车的车门难开 |
 | 22 000sitereg 192 天前 via Android 很多人连毫秒都不知道啥。 另外人开车做的动作 秒是合适的单位。发现危险，抬脚挪到刹车，踩下去。一系列动作能在 1 秒内完成？ 别拿赛车手来说，不具备实际意义。 |
| 23 worldgg 192 天前 4 @Felixchen1062 首先我不是电车行业的，然后我们数据库存储的日志时间肯定是到毫秒的，我相信小米那边肯定也是，对外提供信息是什么样的首先看对方是谁。如果用户需要秒级的，我们就提供到秒级。小米发布在网上的时间也明显也是经过格式化处理后的。而且他发稿面对的用户群体大部分也只是普通人，不是程序员，所以秒级日志足以，3 月 29 日 22:44:26-28 这种描述明显也是人为写的。我觉得实际情况可能是，公关部门根据技术部们提供的后台日志信息，写了这篇稿子而已，按照非技术人员的思维，一般也就时间写个时分秒而已。 |
 | 24 div class="sep3"> loading 192 天前 是不是要像飞机那样有个黑匣子？ |
 | 25 leonleung 192 天前 3 因为公告是对全体人的，而不是只是对程序员团体的 lol |
| 26 JZ8ZW193q6W9Awgy 192 天前 起码 50%的人不知道毫秒啥意思 。。。 |
 | 27 Rickkkkkkk 192 天前 毫秒不准，意义不大。 |
 | 28 R18 192 天前 因为没有。有也是在车机上存储 ，毫秒级日志上云？ |
 | 29 mingtdlb 192 天前 大概率是他故意的，正常记录的很详细，我印象中不止记录到毫秒级别 |
| 30 R18 192 天前 你的日志也只是事件发生时候产生日志，事件没有发生你也不会有日志呀。 包括 EDR 数据，记录也只是记录大于某个差量的日志 |
 | 32 xdzhang 192 天前 其实很多情况下撞了车门都难开，并不只是电车的车门。 |
 | 34 JontyChen 192 天前 发公关微博又不是发调查报告，只讲重点就行了 至于里面有没有隐瞒那就看信不信了。。 |
 | 35 Trepverter 192 天前 op 分析有理 |
 | 37 pkoukk 192 天前 var log messages 也就到秒级，为啥非要到毫秒？ |
 | 38 momo1pm 192 天前 你反应能超越毫秒级？不然有什么意义？ |
 | 39 abubun 192 天前 3 月 29 日 22:44:39 车端 Ecall 接通，确认事故发生，并报警、呼叫 120 急救服务 这个时候为什么不打开车门？？ |
 | 40 avrillavigne 192 天前 1 https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=CC68F6BFD3E104560914271598AFE8C8 GB 39732-2020 汽车事件数据记录系统 |
 | 41 evan9527 192 天前 如果数据对自己不利，你会发出来吗？ |
 | 42 privil 192 天前 有的，经常看拜托了老司机很多案例都是有百毫秒级数据的。 |
 | 44 cabing 192 天前 毫秒也打不开车门啊 |
 | 45 zhovy 192 天前 via Android 你如果去小米内网的服务器上查看车辆数据肯定是精确的细细的 所有信息都可以查到 so 你发的这也是小米团队发出来要给公布所有人看 且公布这些信息肯定要经过法务 警方 甚至大领导所有人签字才能公布的 |
 | 47 bitmin 192 天前 3 看到好几条说 `毫秒级日志上云？` 的评论，这种人还是程序员吗，宽容一点说就是没写过日志 |
 | 48 xyfan 192 天前 5 日志肯定是毫秒级，但发布出来的信息肯定要经过权衡，事实上我都有些怀疑目前小米公布的这些信息，小米是否真的有权利公布给公众。我还在 V2 看见帖子说 Ecall 是否有录音，Ecall 我敢保证所有车企绝对 100%录音并长期保留，因为如果真的出了事故这是第一手资料，但是车企肯定没有资格自行公布通话录音，这涉及到多方的隐私，随意公布无疑是对家属的二次伤害。所以就楼主提到的问题，我相信日志是毫秒级，但车企没有资格完整公布，至少要得到车主及家属的认可才能公布给公众，否则就只能提供给警察等公权力机构用于事故调查。 |
 | 50 songche 192 天前 @Felixchen1062 #15 有没有可能并不需要程序员从库里导出数据，这种数据运营人员直接从管理平台查询导出就好了，一般管理平台的时间格式展示格式都是到秒的吧  |
 | 52 ccover 192 天前 @leonleung 毫秒很有意义，比如 24.999 ，和 24.001 相差将近 1 秒了，而这次事故中反应时间也才 2 秒。 @Rickkkkkkk 你是说毫秒和服务端不准吗？我理解这个不需要和服务端同步到这个级别，只需要车机的毫秒读数（间隔）是正确的就行，大家关心的都是各个状态之间的时间间隔，不会关心车子到底是北京时间 xx 24 秒刹车还是 25 秒刹车，相对时间是正确的就行了 |
 | 53 superrichman 192 天前 有没有可能是微博字数限制 |
 | 54 leasingzong 192 天前 @abubun Ecall 接通，服务中心呼叫没人回应或者只有苦痛的呻吟声就能判断事故发生，服务中心 - 报警 呼叫 120 。 这些并不能判断当时车上人是否能够自行开门下车。 |
| 55 Rickkkkkkk 192 天前 @ccover 打日志本身的消耗就是毫秒级别的，这个误差不可控， 所以说毫秒不准。你说的相对先后也是不准的，现在多核的操作系统，不同核之前没有绝对的先后之分。 |
 | 56 vmebeh 192 天前 via iPhone 我觉得得用飞秒，从量子级开始复盘这次事故 |
| 57 vmebeh 192 天前 via iPhone 补个 |
| 58 leasingzong 192 天前 @yhxx 事故发生后 汽车厂家后台都会主动拨通车载 Ecall 的。。。是服务中心的人主动拨通车载的 Ecall |
 | 59 RogerL 192 天前 你不考虑误差么，EDR 规范里面制动踏板采样频率最低 2Hz ，每秒就采集两次，最大误差就 500ms 了 |
| 60 ccover 192 天前 @Rickkkkkkk #55 日志打印耗时，前后也不会差太多，而且真正记录的话，时间戳是作为日志内容记录的，而不是看日志打印的时间是什么时候 |
| 61 Rickkkkkkk 192 天前 @ccover 简单讲，两个不同线程调用的 unixtime 返回的结果毫秒级别是无法判定先后的。 |
 | 62 wp2wyx 192 天前 汽车层面的一些响应，确实要求很严格，我老婆做汽车电子的，有时候听她说调试什么东西都是按纳秒计时间的 |
 | 63 xiangbohua 192 天前 几毫秒对人类来说有区别，但是不大。这个车祸提前一毫秒发出预警对这三个人也没有什么帮助 |
| 64 xiangbohua 192 天前 @sq125 我的推测还是要把责任往车企上推以换取最大的赔偿，不过目前我没看到实锤证据说车门打不开的，更多的是“三个人在车内不可能不开门”这种推断。 不知道有没有确凿的证据，我指的是像之前 M7 那种有人在门外拉但是没拉开的。 |
| 65 xiangbohua 192 天前 @FreddyLiu 现在就有啊，我记得从哪一年出长的车都强制要求配备了已经。 |
 | 66 chairuosen 192 天前 4 总共 2 秒反应时间，秒级数据误差能有 50%，楼上还一堆人问毫秒有什么意义？ |
 | 67 mogutouer 192 天前 背后数据肯定是毫秒级的啊，发布公告如果毫秒不影响那就肯定是发秒的啊，你们程序员咋当的 |
 | 68 zt5b79527 192 天前 1 @meghoul 弄清事情的真相，才有可能针对性的改进，有可能为以后电车研发生产增加一个经典的参考案例。 其实最重要的，这事儿牵扯到人命，有必要还原细节，还家属/厂商一个清白。 按你这个说法，我也可以这么说： 我觉得大家有点过于关心/分析马航马航 MH370 和黑匣子里记录的日志了，其实痛点还是下面几个： 1. 飞机事故时，乘客安全难以保障 2. 远程遥控让机长麻痹大意放松对飞机的操控 3. 事故后飞机的舱门难开 |
| 69 zt5b79527 评论区一群反应时间到不了 1s 以内的 V2er 真实笑死个人 |
 | 70 gamblor 192 天前 真是有病的问题，对于 99%的人来说，22:28:17:594 ，他们都不知道后面的 594 是什么意思！ |
 | 71 hefish 192 天前 你们该黑的继续黑，该洗的也使劲洗。。我就看看。。。 |
 | 72 kinkin666 192 天前 差的不是几毫秒的问题，1.001 秒也可以吻合小米公布的这个通告，但这和普遍认为的 2 秒还是有差距的 即使说到底是驾驶员的责任，而且这儿讨论的也不是法律吧 ~ 按#40 贴的 GB39732-2020 的附表 A ，报文里面只记到秒，且精度为 1 ，落盘的原始数据里没有毫秒数据，没有刻意隐瞒毫秒这个细节。 如果小米愿意刨开肚子看看吃了几碗粉的话，还有至少两个办法： 1. 假设网络传输为每个日志报文附加的延迟时间相对稳定，那么服务端收到的连续报文的日志（假设有）的毫秒差可以参考 2. 落盘入库了总有顺序号、流水号之类的东西吧（假设有），就算前面套上了点东西形成并发的情况，也可以假设车辆早发送的早落盘，迟发送的迟落盘，看最关键的两条日志的流水号隔了多少也能看出点名堂 |
 | 73 zgqjava 192 天前 这秒级其实也不太精准，没人能验证真实性 |
 | 74 wulili 192 天前 这就有点吹毛求疵了，日志记录也许是毫秒级别的，但是很多操作都是宏观上的，肯定会有误差。 比如，“方向盘往左转角 22.0625 度”，“制动踏板开度 31%”，这些事件难道一定得精确发生在某一毫秒吗？？方向盘和制动踏板的操作都是缓慢的，精确到毫秒级别去记录它意义并不大，NOA 接管状态的切换肯定也会有延迟，要经过内部各个系统的状态变更，不可能几毫秒的时间就完全切换过来了。 |
 | 75 Akiya 192 天前 2 @Rickkkkkkk #55 日志时间通常是微秒级，谁家打日志是毫秒级啊 |
| 76 Akiya 192 天前 @momo1pm #38 0.1 秒和 0.5 秒的差距是很大的， 短跑运动员听枪响到起步是一般是 0.1 到 0.2 秒，如果 0.5 秒才反应过来那就不用跑了 |
| 77 Rickkkkkkk 192 天前 |
 | 78 ptaooo 192 天前 因为“摘要公布如下” |
| 79 Akiya 192 天前 @Rickkkkkkk #77 获取时间的函数执行是纳秒级的，以人类视角可以认为没有误差 |
| 80 Rickkkkkkk 192 天前 |
 | 81 jikun 192 天前 今天晚上 8 点，小米有直播，请三方人员来讲解相关的数据 |
| 82 Akiya 192 天前 @Rickkkkkkk #80 你能不能有点操作系统的基本常识再来回？你说的这种情况只可能出现在 CPU 跑满的情况，这时候系统跟死机差别不大了，还用纠结什么日志吗 |
 | 83 9ki 192 天前 毫秒级数据应该不会公布给大众吧 |
 | 84 bellymars 192 天前 小米这个公告主要是为了甩锅，核心数据肯定是有的。秒是个相当粗的粒度，任何摄像头、雷达，采样都在 100hz 以上。 |
 | 85 sampeng 192 天前 为什么纠结这个呢。。 我的观点认为是 116 的速度什么车撞上基本是没活的可能。。因为碰撞测试都是 40-60 的速度来测的。116 的时速。就算减了 30%的力度去减速。只要最后的速度大于 60.基本就 GG 了。我更关心这个撞击前的速度，貌似没上报上来？ |
| 86 Rickkkkkkk 192 天前 @Akiya 你要不复习下操作系统是怎么做进程调度的。 |
 | 87 superBearL 192 天前 客户问你 XXX 系统是啥时候上线的？ 你应该是回答到某年某月某日就已经很详细了。并不需要告诉客户时分秒甚至毫秒 |
 | 89 Smallsun1231 192 天前 1 理论上的日志肯定是可以做到毫米级别的这毋庸置疑，但是小米官方能否在公告中披露这些信息我存疑。 之前看到一个说法不知道是否正确，事故导致三人死亡，按照现行的生产安全事故报告和调查处理条例来说算“较大事故”（当然，能不能卡得上该条例我个人依旧存疑），另外按照该条例的第三十四条来看，事故报告被行政机关接手后，应当由对应行政机关进行公布，小米官方是否有权进行更为详细的披露可能还有待商榷... 以下为引用条例详情及源。 第三十四条 事故处理的情况由负责事故调查的人民政府或者其授权的有关部门、机构向社会公布，依法应当保密的除外。 https://www.gov.cn/zwgk/2007-04/19/content_588577.htm |
 | 90 florentino 192 天前 @chairuosen 不是两秒吧, 辅助驾驶要求驾驶员全程盯着路面,有情况距离很远驾驶员就能看到的,反应时间肯定不止 2 秒, 什么? 没有注意路面? 开车不开路面的嘛 |
 | 91 moudy 192 天前 via iPhone @Felixchen1062 车规事件日志基本都是微秒级的时间戳。但是没必要放到公告里 |
| 93 moudy 192 天前 via iPhone @florentino 对的，我一直说看路的司机 2s 足够了，因为在-2s 时就已经满脑子问号想干预了。不看路的司机，再给 20s 也不一定够 |
| 96 gy0624ww 192 天前 1 看评论知道了 v 站里的水程序员有多少，智商也堪忧，说面向大众很多人不知道毫秒的，那就能保证都知道 NOA,ecall 是啥？ km h 是啥，方向盘转动角度为什么精确了小数点后那么多？ 这个披露的日志 就是该细的地方不一致。尽可能的减少责任。 |
 | 97 mosfet 192 天前 确实是选择性披露，不然为什么还有个 22.0625 度 从 116 开始刹车，如果 2.0S 碰撞速度是 97 ，可能 2.9S 的碰撞速度能<80 |
 | 99 queuey 192 天前 via iPhone 不说小米的事，单单就日志是秒还是毫秒让我怀疑 V 友们真是程序员吗 上传毫秒和上传秒精度对日志来说不都是一个时间戳吗…… 秒精度的日志我只能说是个灾难。但凡有点实际开发经验的人应该都不会有这种逆天言论 |
 | 100 zhaokun 192 天前 我在好奇公布这些信息的时候征得车主同意了没有？ |
Select Language