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

feat(platform): align console with vehicle operations center

Browse Source
This commit is contained in:
lingniu
2026-07-04 18:53:52 +08:00
parent 48642726aa
commit 504a49a13c
8 changed files with 70 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -2,7 +2,7 @@
## Visual Direction
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.
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 and mature fleet telematics platform than a marketing dashboard.
## Product North Star
@@ -12,19 +12,21 @@ Every primary workflow should answer a vehicle-level question first, then allow
The current product goal is to evolve toward a production vehicle data management center, comparable to mature fleet IoT and telematics platforms: realtime monitoring, trajectory replay, historical evidence query, alert triggering and notification, statistics, and production operation quality all serve the same vehicle object.
The product must not expose GB32960, JT808, and Yutong MQTT as three final products. They are acquisition paths. The final product is a vehicle service that answers online state, current location, historical trajectory, source reliability, alert responsibility, and statistical evidence for one vehicle.
## Primary Screens
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.
2. Live Monitor: map-first current vehicle monitoring with online/offline state, abnormal highlights, source freshness, AMap readiness, 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, auto play/pause, speed controls, and table evidence.
5. Trajectory Replay: historical location playback with AMap polyline, playback marker, auto play/pause, speed controls, gap detection, mileage evidence, 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, rule evidence, manual state, notification state, and escalation readiness.
8. Notification Rules: alert trigger rules, notification targets, channels, escalation windows, acceptance criteria, and copyable runbooks.
9. Statistics: one vehicle-service statistics workspace covering daily/range mileage, online rate, offline duration, data completeness, and source consistency.
7. Alert Events: alert trigger records, affected vehicles, rule evidence, manual state, notification state, escalation readiness, and recovery evidence.
8. Notification Rules: alert trigger rules, notification targets, channels, escalation windows, acceptance criteria, affected-user scope, and copyable runbooks.
9. Statistics: one vehicle-service statistics workspace covering daily/range mileage, online rate, offline duration, data completeness, source consistency, and exportable evidence.
10. 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.
@@ -77,6 +79,7 @@ AMap should be treated as infrastructure for vehicle operations, not only as a v
- History query: location evidence can open the same coordinate in the map context.
- Alert events: vehicle location at trigger time should be shown when longitude and latitude are available.
- Ops quality: map key readiness, security proxy readiness, and frontend loader failures should be visible.
- Statistics: mileage and online-rate anomalies should link back to a map/time-window context so operators can verify whether the issue is vehicle behavior or source data loss.
AMap credentials supplied by operations must be configured through ECS environment variables:
@@ -85,6 +88,12 @@ AMap credentials supplied by operations must be configured through ECS environme
- `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.
Supplied AMap production credentials must be applied on ECS only:
- API service key: configure as `AMAP_API_KEY`.
- Web JS key: configure as `AMAP_WEB_JS_KEY`.
- Web JS security code: configure as `AMAP_SECURITY_JS_CODE`.
## Alert And Notification Scope
Alert events are first-class product records, but notification delivery can be implemented incrementally.