DSM

Driver State Monitoring,驾驶员状态监测

定义

DSM(Driver State Monitoring,驾驶员状态监测)通过车内红外或可见光摄像头与 AI 算法(人脸检测、眼动分析、头部姿态等)识别驾驶员疲劳、分神、抽烟、打电话、未系安全带等状态,及时发出声光预警,保障行车安全。DSM 是商用车、网约车、两客一危等场景的强制或推荐配置,与 ADAS 共同构成主动安全体系。

DSM 通常集成于 DVR 或独立模块,通过 T-Box 将告警数据、抓拍图片上报至 FMS。欧盟 AEBS 法规要求商用车配备 DSM,国内部分省市对两客一危、网约车也有类似要求。物联网卡为 DSM 告警上报、远程配置、OTA 升级提供连接。

技术特点

DSM 采用计算机视觉与深度学习,可识别 PERCLOS(眼睑闭合度)、视线偏离、打哈欠等疲劳特征。支持本地预警与云端分析,告警数据可用于车队安全管理、保险理赔、事故责任认定。与 DVR 集成时可实现告警触发视频上传。

应用场景

DSM 应用于商用车、物流车、公交、网约车、出租、两客一危等。典型场景包括:疲劳驾驶预警、分神预警、驾驶行为分析、车队安全管理、保险 UBI 等。达希物联为 DSM 车载系统提供物联网卡、专用 APN、流量套餐及车联网解决方案。

本地预警不能被上传失败关掉

驾驶员状态监测里,物联网卡负责把告警、抓拍和参数变更送到车队平台,不负责在驾驶员面前发出那一声提醒。提醒由车内算法在本地完成。技术含义是:图片没传上去,疲劳提醒仍然必须响;提醒策略下发失败,应继续使用上一版已经在车上生效的策略,而不能变成“没有策略就不监测”。卡的中断可以延迟管理可见性,不能延迟安全动作。若系统把云端应答当成本地告警的开关,隧道里的疲劳将不会被提醒,出隧道后再补一张照片,对当时的驾驶没有帮助。

使用条件是车内时钟可靠,告警记录带上速度、位置和时间,抓拍能在本地队列里等到蜂窝恢复。队列要限制图片体积和数量,优先保留高等级事件,避免一张高清图堵住后续的全部告警。参数下发要有版本号和确认,司机或现场人员不能在无记录的情况下把功能关掉。卡与车辆、终端序列号绑定,换车或换终端时告警归属跟着改。夜间红外与白天可见光的策略不同,远程切换失败不应让摄像头停用。隐私上要明确哪些图片离开车辆、保留多久、谁可以调阅,诊断日志不要额外带上与告警无关的连续视频。

容易出错的是用平台告警数量考核设备是否工作。平台数量受覆盖影响,本地声光次数才反映监测是否开启。另一类是升级算法时要求先擦除旧模型,下载失败后设备既无新模型也无旧模型。还有把 DSM 图片和行车录像放进同一条不限速的补传,管理人员点播视频时疲劳抓拍被推迟到班次结束。摄像头被遮挡仍显示通信在线,平台没有遮挡事件,会以为驾驶员一直正常。验收应在本地触发一次可重复的告警,同时屏蔽蜂窝,确认声光仍发生,恢复后平台只有一条且时间是触发时刻。告警如何与录像对齐见 ADAS 与 DVR 融合上传,录像设备见 DVR。

本地提醒次数和平台收到次数分列。两者不一致时先看队列和覆盖,不要把驾驶员标记为设备未开启。摄像头遮挡、红外失效和算法关闭都是独立事件,通信在线不能抵消这些事件。策略版本写在每条告警上,便于解释为什么同一动作有时提醒、有时不提醒。升级包下载失败必须回退到上一版可运行的模型,禁止出现空模型仍显示在线。图片队列设置上限,超出时丢掉低等级并记录丢弃,不丢掉尚未提醒的本地事件,因为本地提醒本来就不依赖队列。调阅权限和保存期限按车辆用途区分,诊断用的连续画面默认不上传。换车或换终端时把未发送告警导出到新设备或直接标记为留在旧终端,避免新卡把旧车的疲劳记录继续上报。夜间抽查一次无网络条件下的提醒,确认声光和本地记录都在,平台记录可以晚到,但时间必须是当时。

遮挡事件持续存在时,不要等图片上传成功才在平台显示。本地已经知道摄像头被挡住,就应先把这个状态送出或至少保留待传标志。策略关闭若来自远程,关闭命令本身要有回执;没有回执就视为未关闭,车上继续按原策略提醒。换司机不换车时,告警仍归车辆,不把上一名司机的未传记录改记到新人名下。


相关术语

返回物联网卡专业术语