业务 ↔ 技术桥梁 · Embedded product-boundary experiment
Explores the boundary from vehicle acquisition and canonical signals to operator-facing product decisions.
这是对项目组合与源代码的解读，并非客户、部署、认证或成果声明。
Vehicle telemetry is only useful when acquisition, signal semantics, connectivity, diagnostics, user experience, and operational responsibility form one product boundary.
Separate embedded acquisition, canonical signal mapping, application APIs, and user surfaces before adding assistant or predictive behaviour.
Embedded source, API and user surfaces, a Rust normalisation core, and a trace-replay fixture for DBC, CAN, and canonical mapping.
Signal quality, offline behaviour, update safety, hardware limits, and user validation return to feature scope, architecture, support, and release criteria.
源码证据
A vehicle-data prototype spanning API, user surfaces, embedded source, and a Rust signal-normalisation core. The implemented record supports trace and fixture work; vehicle, hardware, and fleet validation remain outside it.
详细技术快照以英文维护。
代码仓库证据不等同于客户、部署、认证或成果证据。
架构
三个源代码边界：嵌入式采集、规范信号映射与 API，以及面向用户的遥测与助手界面。
仅为源代码图：一层可能代表已实现代码、适配器边界或文档设计，并不证明已配置生产服务。
嵌入式源代码呈现 OBD-II/CAN 采集、选定信号、运动输入、缓冲和更新边界。不声称具备量产硬件，也不声称已完成车辆验证。
源代码呈现移动端、网页端、流式传输和数据接入界面。它们的端到端延迟、可靠性和现场可用性需要在目标硬件和网络上验证。
源代码呈现一个基于 Mistral 的助手，用通俗语言解释原始 CAN 数据：行程摘要、驾驶行为评分，以及预测性维护假设和异常假设。其输出需要另行进行数据质量验证和运营验证。
痛点所在
为什么车辆数据尚未被充分利用
现代车辆会生成丰富的 OBD-II 数据，但驾驶员和车队管理者没有可上手的工具来解读这些数据。
诊断、行程跟踪、燃油经济性和安全评分各用一套独立的应用，缺乏统一的智能层。
故障往往在问题被发现之前就已发生。没有预测性预警，没有健康评分，也没有趋势分析。
无法向你的车提问。没有自然语言界面来理解驾驶习惯或车辆健康状况。
功能
从原始 OBD-II 数据到面向用户遥测的源代码界面
仅为源代码范围：条目可能描述代码、已记录适配器或已配置工作流，并不表示生产服务正在运行。
01
源代码呈现选定的 OBD-II PID 与模式（当前数据、冻结帧、DTC、VIN）、通过 NMEA 获取的 GPS、IMU 输入，以及 WebSocket + SSE 流式传输。覆盖范围与速率未经验证。
02
源代码呈现行程起止的自动检测、路线记录、行程统计、回放，以及包含成本分析的行程历史。这些均未在车辆上验证。
03
源代码基于急刹车、急加速、急转弯和碰撞等驾驶事件对安全评分进行建模，并带有平顺性、车速和生态驾驶的子评分。阈值未在车辆上验证。
04
源代码呈现 DTC 读取/清除、冻结帧分析和车辆健康评分。预测性维护的输出需要另行验证。
05
源代码呈现一个用于就车辆数据进行自然语言提问的助手，它使用大型语言模型并采用 SSE 流式响应。其输出需要另行验证。
06
嵌入式源代码以 ESP32-S3（双核 240MHz）为目标平台，搭配 CAN/TWAI、u-blox GPS、MPU6050 IMU、WiFi 802.11 b/g/n 和 BLE GATT。燃料类型（汽油、柴油、混合动力、PHEV、BEV、氢能）和 OTA A/B 回滚已在源代码中建模。不声称已完成硬件验证或车辆验证。
源代码建模了什么
经审阅的代码对选定的 OBD-II/CAN 信号和一个规范映射层进行建模。可用性、速率、单位和含义因车辆而异，需要在测试夹具、台架和车辆上进行验证。
仅为仓库表面：可用性、完整性、性能与运营适用性需要另行验证。
PID 0D源代码呈现用于行程、阈值和地理围栏逻辑的车速输入。不声称在各种车辆上的速率与精度。
PID 0C源代码呈现作为发动机负荷代理指标的发动机转速输入，并带有针对失火、lambda 漂移和变速箱磨损的基线漂移假设。它不是经过验证的先行指标。
PID 11源代码呈现节气门位置输入（%），与 RPM 和车速一起用于激进驾驶评分、行为辅导和急加速事件逻辑。它未在车辆上验证。
PID 05源代码呈现冷却液温度输入和异常假设。它不是早期预警的保证，也不是诊断结论。
PID 0F源代码呈现 ECU 燃油计算所需的空气密度输入。动力下降分析或核查冷进气宣称等诊断用途，需要针对具体车辆的验证。
PID 0B源代码呈现作为发动机负荷测量（自然吸气 + 涡轮）的进气歧管压力输入。增压曲线、负荷-RPM 和拖挂车应力视图属于设计范围，而不是经过验证的分析。
PID 2F源代码呈现油箱液位输入（%），用于加油检测、液位突降盗窃预警，以及对照车速积分所得里程的单次行程 MPG 逻辑。不声称速率与精度。
PID 14源代码呈现空燃比输入。长期漂移是关于三元催化器劣化、lambda 传感器老化或未经授权的燃油系统改装的一项假设，而不是诊断结论。
MODE 03源代码呈现诊断码接入和通俗语言解释工作流。所支持的模块和所提示的原因需要针对具体车辆的验证和专家验证。
ONBOARD源代码呈现 ESP32 端的 IMU 输入，用于急刹车、急转弯、碰撞和路面颠簸事件逻辑，独立于 CAN 数据。检测以及在不支持 OBD 的车辆上的使用，均未经验证。
GNSS源代码呈现 GPS 与蜂窝定位输入，用于用户自定义的区域（家、车场、客户现场）、进入/离开预警和离线缓存。现场表现未经验证。
OTA源代码呈现固件版本、分阶段更新和回滚的设计层面。不声称存在已签名的生产发布版本或设备车队更新记录。
技术栈
所列技术仅标识仓库依赖项或适配器表面，并不证明存在活动集成或部署。
源代码
Vectis AI 源码原型——包括后端、前端、移动应用和固件——可应请求提供。
如需访问源代码，请签署保密协议。这是一项标准的法律手续。
需要为你的车队或 IoT 平台获取战略性 AI 指导？我的咨询服务可以提供帮助。
合作
如果你是车队运营者、汽车 OEM 或 IoT 合作伙伴，正在评估将 AI 用于车辆数据，请联系我讨论这项决策。
从演示走向可靠运营。订阅 Physical AI 新读物。
随时可取消订阅。绝无垃圾邮件。