全部项目

商业摘要已提供本语言版本。产品详细流程和技术证据以英语维护。

物理 AI 与机器人

Vectis AI

将分散的车辆信号连接到一致的产品边界。

采集、信号定义、API 和操作员体验彼此脱节。有用的功能需要一条贯穿这些环节的可追溯路径。

出行产品和嵌入式工程负责人

查看完整流程讨论您的使用场景

具有明确软件及固件边界的软件原型

A signal interpretation trace
Input
Authorised CAN trace and DBC definition
Meaning
Normalised signal and unit
Consumer
An API and operator workflow
Validation
Trace fixtures; vehicle evidence still needed
Decision logic and control flow

Explore the reasoning

Select one signal and the operator decision it should support.

Engage now
A signal-to-workflow map and the evidence needed to evaluate the connected-product boundary.
Inspect
Source prototype with software and firmware boundaries
Backend unit and integration tests for the application and telemetry boundaries.
Still to validate
Advanced multiplexing and firmware C code generation remain incomplete; build targets do not establish deployed Node, mobile or browser integrations.
Complete hardware-in-the-loop, vehicle-in-the-loop, field-fleet, update-safety, data-quality, and operational validation.

源码审查日期

The decision behind the system

How does a vehicle signal become a useful product?

A vehicle-data prototype connecting embedded acquisition, CAN/DBC signal normalisation, APIs and user-facing telemetry workflows.

Vectis explores the signal-to-product boundary for connected vehicles. Its job differs from cross-machine coordination or learned robot behaviour.

Signals with meaning

The Rust UVAL core parses DBC, decodes CAN frames and maps VSS identifiers into canonical signals. Node and WebAssembly build targets support evaluation.

Connected workflows

API and mobile surfaces explore trips, telemetry, diagnostics, geofencing and assistant interactions.

Software meets firmware

Embedded source and trace-replay fixtures expose acquisition, connectivity and update boundaries for evaluation.

Read the complete system walkthrough

  1. Choose

    Select one signal and the operator decision it should support.

  2. Normalise

    Replay an authorised trace and follow CAN/DBC interpretation into a canonical signal.

  3. Connect

    Inspect how the API and user-facing workflow consume the signal and handle missing information.

  4. Validate

    Identify data-quality, connectivity and hardware evidence required before vehicle or fleet use.

See all evidence and limits

Inspect the source, test conditions and operating limits in the technical record.

查看技术记录与证据

业务 ↔ 技术桥梁 · Embedded product-boundary experiment

Turn raw vehicle signals into a bounded, testable product system.

Explores the boundary from vehicle acquisition and canonical signals to operator-facing product decisions.

这是对项目组合与源代码的解读，并非客户、部署、认证或成果声明。

  1. 01

    业务压力

    Vehicle telemetry is only useful when acquisition, signal semantics, connectivity, diagnostics, user experience, and operational responsibility form one product boundary.

  2. 02

    产品决策

    Separate embedded acquisition, canonical signal mapping, application APIs, and user surfaces before adding assistant or predictive behaviour.

  3. 03

    技术记录

    Embedded source, API and user surfaces, a Rust normalisation core, and a trace-replay fixture for DBC, CAN, and canonical mapping.

  4. 04

    证据回流

    Signal quality, offline behaviour, update safety, hardware limits, and user validation return to feature scope, architecture, support, and release criteria.

仓库／运行时边界

本页解读的是独立项目仓库中的源代码。源代码存在，并不表示该项目作为服务运行在 hyperion-consulting.io 内。

访客及客户数据的 AI 处理限于通过受治理的欧盟端点使用 Mistral。所有者授权的 Helio、搜索及 Product Council 流程已启用。独立的公开来源编辑流程使用 Anthropic，并以受治理的 Mistral 作为备用；该流程不接收网站咨询、客户文档或访客对话。远程 AI 不可用时，确定性工具仍可使用。

源码证据

源码实际能够证明什么

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.

详细技术快照以英文维护。

成熟度
Source prototype with software and firmware boundaries
证据审查
源码快照截至

产品与架构决策

  • Separate device acquisition, canonical signal mapping, APIs, and operator-facing product surfaces.
  • Normalise DBC/CAN inputs into a canonical signal layer before product logic consumes them.
  • Treat offline behaviour, update safety, and hardware abstraction as explicit architecture boundaries.

可核验的证据

  • Backend unit and integration tests for the application and telemetry boundaries.
  • Embedded source with C-level tests for selected firmware logic.
  • Rust UVAL source for DBC parsing, CAN decoding and VSS mapping, with Node and WebAssembly build targets and a trace-replay integration fixture.

声明边界

  • Advanced multiplexing and firmware C code generation remain incomplete; build targets do not establish deployed Node, mobile or browser integrations.
  • No hardware-in-the-loop, vehicle-in-the-loop, OEM, safety-certification, or field-fleet record is asserted.
  • Predictive-maintenance and assistant outputs require separate data-quality and operational validation.

代码仓库证据不等同于客户、部署、认证或成果证据。

架构

从 OBD-II 接口到通俗易懂的洞察

三个源代码边界：嵌入式采集、规范信号映射与 API，以及面向用户的遥测与助手界面。

仅为源代码图：一层可能代表已实现代码、适配器边界或文档设计，并不证明已配置生产服务。

  1. 01

    第 1 层 — ESP32 OBD-II 采集源代码

    嵌入式源代码呈现 OBD-II/CAN 采集、选定信号、运动输入、缓冲和更新边界。不声称具备量产硬件，也不声称已完成车辆验证。

  2. 02

    第2层 — Rust UVAL与应用界面

    Rust UVAL核心解析DBC、解码CAN，并将VSS标识符映射为规范化信号。源码包含Node和WebAssembly构建目标及轨迹重放测试数据；移动端、浏览器和车辆的端到端行为仍需单独验证。

  3. 03

    第 3 层 — AI 洞察引擎

    源代码呈现一个基于 Mistral 的助手，用通俗语言解释原始 CAN 数据：行程摘要、驾驶行为评分，以及预测性维护假设和异常假设。其输出需要另行进行数据质量验证和运营验证。

源代码建模了什么

源代码中呈现的车辆信号路径

经审阅的代码对选定的 OBD-II/CAN 信号和一个规范映射层进行建模。可用性、速率、单位和含义因车辆而异，需要在测试夹具、台架和车辆上进行验证。

仅为仓库表面：可用性、完整性、性能与运营适用性需要另行验证。

PID 0D

车速

01

源代码呈现用于行程、阈值和地理围栏逻辑的车速输入。不声称在各种车辆上的速率与精度。

PID 0C

发动机转速

02

源代码呈现作为发动机负荷代理指标的发动机转速输入，并带有针对失火、lambda 漂移和变速箱磨损的基线漂移假设。它不是经过验证的先行指标。

PID 11

节气门位置

03

源代码呈现节气门位置输入（%），与 RPM 和车速一起用于激进驾驶评分、行为辅导和急加速事件逻辑。它未在车辆上验证。

PID 05

冷却液温度

04

源代码呈现冷却液温度输入和异常假设。它不是早期预警的保证，也不是诊断结论。

PID 0F

进气温度

05

源代码呈现 ECU 燃油计算所需的空气密度输入。动力下降分析或核查冷进气宣称等诊断用途，需要针对具体车辆的验证。

PID 0B

进气歧管压力

06

源代码呈现作为发动机负荷测量（自然吸气 + 涡轮）的进气歧管压力输入。增压曲线、负荷-RPM 和拖挂车应力视图属于设计范围，而不是经过验证的分析。

PID 2F

燃油液位

07

源代码呈现油箱液位输入（%），用于加油检测、液位突降盗窃预警，以及对照车速积分所得里程的单次行程 MPG 逻辑。不声称速率与精度。

PID 14

O₂ 传感器（Lambda）

08

源代码呈现空燃比输入。长期漂移是关于三元催化器劣化、lambda 传感器老化或未经授权的燃油系统改装的一项假设，而不是诊断结论。

MODE 03

ECU 故障码（DTC）

09

源代码呈现诊断码接入和通俗语言解释工作流。所支持的模块和所提示的原因需要针对具体车辆的验证和专家验证。

ONBOARD

IMU（加速度计 + 陀螺仪）

10

源代码呈现 ESP32 端的 IMU 输入，用于急刹车、急转弯、碰撞和路面颠簸事件逻辑，独立于 CAN 数据。检测以及在不支持 OBD 的车辆上的使用，均未经验证。

GNSS

地理围栏边界

11

源代码呈现 GPS 与蜂窝定位输入，用于用户自定义的区域（家、车场、客户现场）、进入/离开预警和离线缓存。现场表现未经验证。

OTA

固件状态

12

源代码呈现固件版本、分阶段更新和回滚的设计层面。不声称存在已签名的生产发布版本或设备车队更新记录。

技术栈

技术栈

所列技术仅标识仓库依赖项或适配器表面，并不证明存在活动集成或部署。

后端
Rust UVAL, DBC/CAN, VSS, Node / WebAssembly; Fastify, TypeScript, Prisma, PostgreSQL + TimescaleDB, Redis
AI
LLM API、流式 SSE、自然语言车辆查询
网页仪表盘
Next.js 14、Tailwind CSS、shadcn/ui、数据可视化
移动应用
React Native、Expo、NativeWind、BLE 配对、Detox E2E 测试
固件
ESP32-S3, ESP-IDF 5.x, FreeRTOS, CAN/TWAI, ISO-TP, GPS NMEA, MPU6050
基础设施
Docker、GitHub Actions CI、Vitest、JWT 认证、Swagger API 文档
Technical documents & controlled source access

源代码

探索代码

Vectis AI 源码原型——包括后端、前端、移动应用和固件——可应请求提供。

需签署 NDA

如需访问源代码，请签署保密协议。这是一项标准的法律手续。

与 Hyperion 合作

追踪一个信号到工作流程

梳理从信号到工作流程的映射，以及评估联网产品边界所需的证据。

请简要说明您的情况、限制条件和待作决策。开始工作前，我们会商定范围、责任和报价。

追踪一个信号到工作流程探索咨询服务