shishengliang/lingniu-vehicle-ingest
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(platform): define vehicle service center direction

Browse Source
This commit is contained in:
lingniu
2026-07-04 11:48:57 +08:00
parent b03f9b1a3a
commit 2ba30b21cd
2 changed files with 135 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

65
vehicle-data-platform/docs/product-spec.md
View File

@@ -4,15 +4,23 @@
The UI is a professional vehicle data operations console. It uses Semi UI as the component base, a restrained gray-white control-room palette, dense but readable tables, right-side drawers for detail, and blue-cyan accents for primary actions. It should feel closer to a cloud data console than a marketing dashboard.
## Product North Star
The platform is a vehicle service center. GB32960, JT808, and Yutong MQTT are ingestion evidence for the same vehicle, not three separate product surfaces. A user should be able to search one VIN, plate, or phone number and understand whether that vehicle is online, where it is, what its latest state is, how reliable its mileage is, and which source produced each piece of evidence.
Every primary workflow should answer a vehicle-level question first, then allow protocol-level drill-down only when diagnosis or raw evidence is needed.
## Primary Screens
1. Dashboard: KPI summary, protocol distribution, vehicle map preview, quality issues, and link health.
2. Vehicles: table-first identity and vehicle registry.
3. Realtime: table/map switch for current vehicle state.
4. Vehicle Detail: identity header and tabs for latest state, history, raw, mileage, and quality.
5. History: location and raw-frame query workspace.
6. Mileage: daily and range mileage analysis.
7. Quality: data quality and link health workspace.
1. Dashboard: vehicle service KPI summary, service status distribution, map preview, alerts, data quality, and link health.
2. Vehicle Service: table-first vehicle registry, binding state, source coverage, and service status.
3. Realtime Monitor: map/table switch for current online vehicles and abnormal vehicles.
4. Vehicle Detail: one vehicle profile with latest state, sources, history, raw, mileage, alerts, and quality evidence.
5. Trajectory Playback: location history with map track playback and table evidence.
6. History Query: historical locations, raw frames, and flattened parsed fields with pagination and field trimming.
7. Alert Events: alert trigger records, affected vehicles, notification state, and evidence links.
8. Statistics: daily/range mileage, online rate, data completeness, and source consistency.
9. Ops Quality: Kafka, NATS, Redis, TDengine, MySQL, gateway, and writer health.
## Domain Principle
@@ -30,6 +38,49 @@ Dashboard and vehicle-list summary cards should expose both `单源车辆` and `
`暂无来源车辆` is also a first-class governance entry. It represents bound vehicles that have no current GB32960, JT808, or Yutong MQTT source evidence, and should route directly to the `no_data` vehicle service filter.
## Vehicle Service Workflow
Global vehicle search accepts VIN, plate, JT808 phone, or known source identifier. The resolved vehicle context should travel across the whole product:
- Realtime monitor opens the current position and source freshness for that vehicle.
- Trajectory playback opens the same VIN and selected time window.
- History query opens raw and parsed evidence for the same VIN.
- Statistics opens daily or range mileage for the same VIN.
- Alert events opens active and historical alerts for the same VIN.
- Vehicle detail acts as the hub that links all of the above.
The user should rarely need to choose a protocol before choosing a vehicle. Protocol filters are secondary and are used for source diagnosis, cross-source comparison, and raw frame verification.
## Map Capability
The product uses AMap as the map provider for production map rendering.
- Web JS key is injected through frontend runtime config, not hard-coded into source.
- API/server key is kept in backend or ECS environment configuration.
- Realtime monitor shows current vehicle points, online/offline color, abnormal highlights, and source freshness.
- Trajectory playback shows historical polyline, start/end markers, current playback marker, and the table row that backs the selected point.
- Alert events can highlight affected vehicle locations when the alert has valid coordinates.
- If AMap is unavailable or not configured, pages must fall back to coordinate preview instead of blocking the workflow.
## Alert And Notification Scope
Alert events are first-class product records, but notification delivery can be implemented incrementally.
- Phase 1: alert list, severity, trigger time, affected vehicle, evidence links, and manual status.
- Phase 2: notification channels such as email, webhook, or enterprise chat.
- Phase 3: escalation policy for unresolved data breakage and affected-user notification.
Alerts should cover source offline, no realtime update, location missing, mileage abnormality, raw parse failure, binding missing, and cross-source inconsistency.
## Statistics Scope
Statistics must stay vehicle-first and evidence-backed:
- Daily mileage and range mileage should link back to trajectory and raw evidence.
- Online rate should be computed by vehicle and then broken down by source.
- Data completeness should report missing location, mileage, SOC, speed, and source freshness.
- Source consistency should compare GB32960, JT808, and Yutong MQTT only when the same VIN has multiple sources.
## Interaction Rules
- Tables are the default data surface.