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

docs(platform): define vehicle service platform blueprint

Browse Source
This commit is contained in:
lingniu
2026-07-04 16:09:51 +08:00
parent 19f260d94a
commit 0c7910d6b9
3 changed files with 331 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -12,15 +12,19 @@ Every primary workflow should answer a vehicle-level question first, then allow
## Primary Screens
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.
The platform navigation should use vehicle-service language rather than protocol-product language:
1. Operations Cockpit: vehicle service KPI summary, service status distribution, live map preview, alert queue, data quality, and link health.
2. Live Monitor: map-first current vehicle monitoring with online/offline state, abnormal highlights, source freshness, and a dense vehicle table.
3. Vehicle Center: table-first vehicle registry, binding state, source coverage, service status, and missing-source governance.
4. Vehicle Detail: one vehicle service file with identity, latest realtime state, source evidence, history, raw, mileage, alerts, quality evidence, and copyable diagnostics.
5. Trajectory Replay: historical location playback with AMap polyline, playback marker, controls, 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.
7. Alert Events: alert trigger records, affected vehicles, rule evidence, manual state, notification state, and escalation readiness.
8. Statistics: daily/range mileage, online rate, offline duration, data completeness, and source consistency.
9. Ops Quality: GB32960, JT808, Yutong MQTT, Kafka, NATS, Redis, TDengine, MySQL, AMap, gateway, and runtime health.
See `docs/vehicle-platform-blueprint.md` for the detailed page-level blueprint and phased implementation plan.
## Domain Principle
@@ -57,11 +61,18 @@ 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.
- The AMap security code must stay server-side in production. The browser should receive `AMAP_SECURITY_SERVICE_HOST`, not the raw security code.
- Realtime monitor shows current vehicle points, clustering or bounded point rendering, online/offline color, abnormal highlights, selected vehicle highlight, and source freshness.
- Trajectory playback shows historical polyline, start/end markers, current playback marker, playback controls, 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.
AMap credentials supplied by operations must be configured through ECS environment variables:
- `AMAP_WEB_JS_KEY`: public Web JS key served through `/app-config.js`.
- `AMAP_SECURITY_JS_CODE`: private security code kept by the API service.
- `AMAP_SECURITY_SERVICE_HOST=/_AMapService`: frontend proxy path used by the AMap loader.
## Alert And Notification Scope
Alert events are first-class product records, but notification delivery can be implemented incrementally.