c48ae896a4
- Updated cost model to show: (Platform Base) + (Per-VIN × VINs) - Platform base: 176 cores / 896GB RAM (Kafka, ClickHouse, MongoDB, Redis, PostgreSQL, gateway, monitoring) - Per-VIN marginal: 50mc / 82MB per vehicle - Added RESOURCE USAGE MODEL and COST FORMULA sections to report - Added CPU (mc) and RAM (MB) columns to TOP COST VEHICLES table - Updated README with new report output - virtual-vehicle: documented Vault cert TTL error troubleshooting
72 lines
3.1 KiB
Markdown
72 lines
3.1 KiB
Markdown
# Virtual Vehicle Simulator
|
|
|
|
A lightweight vehicle simulator that generates CAN telemetry and sends it to the cloud gateway.
|
|
|
|
## Background
|
|
|
|
This service replaces the older `project-ai/tools/k8s-socket-can` tool. We rewrote it because:
|
|
|
|
1. **Simpler deployment** - Pure Go service that runs in K8s without SocketCAN kernel dependencies
|
|
2. **No hardware requirements** - The original required a CAN interface or vcan setup; this generates synthetic frames
|
|
3. **Cloud-native** - Designed for K8s from the start, uses the shared cloud-services build/deploy pipeline
|
|
4. **Self-registering** - Automatically registers with manufacturer API and handles certificate provisioning
|
|
5. **Configurable** - VIN prefix, send interval, and endpoints all configurable via env vars
|
|
|
|
The original k8s-socket-can was designed for testing with real CAN hardware or Linux vcan interfaces. For demo/testing purposes where we just need telemetry flowing through the system, this lightweight simulator is more practical.
|
|
|
|
## Overview
|
|
|
|
This service simulates a connected vehicle (T.Rex) by:
|
|
1. Registering with the manufacturer API to get certificates
|
|
2. Connecting to the gateway via WebSocket with mTLS
|
|
3. Generating and sending CAN frames
|
|
|
|
## Configuration
|
|
|
|
| Env Var | Description | Default |
|
|
|---------|-------------|---------|
|
|
| MANUFACTURER_URL | URL for vehicle registration | http://gateway:8077/manufacture/manufacturer |
|
|
| GATEWAY_WS_URL | WebSocket URL for gateway | ws://gateway:8077/session |
|
|
| API_KEY | API key for manufacturer endpoint | - |
|
|
| VIN_PREFIX | Prefix for generated VIN | VIRTUAL |
|
|
| SEND_INTERVAL_MS | Telemetry interval in ms | 1000 |
|
|
|
|
## CAN Frame IDs
|
|
|
|
| CAN ID | Description |
|
|
|--------|-------------|
|
|
| 0x100 | Speed |
|
|
| 0x101 | RPM |
|
|
| 0x102 | Battery SOC |
|
|
| 0x103 | Battery voltage |
|
|
| 0x104 | Temperature |
|
|
| 0x105 | GPS latitude |
|
|
| 0x106 | GPS longitude |
|
|
| 0x200 | Door status |
|
|
| 0x201 | Light status |
|
|
| 0x300 | HVAC |
|
|
|
|
|
|
## Troubleshooting
|
|
|
|
### 503 Error - Vault Certificate TTL Issue
|
|
|
|
If the service returns a 503 and logs show a Vault error like:
|
|
|
|
```json
|
|
{"level":"error","message":"manufacturer API returned 503: {\"message\":\"Vault unable to create certificate, status code: 400 {\\\"errors\\\":[\\\"cannot satisfy request, as TTL would result in notAfter 2034-02-01T02:34:43.379661987Z that is beyond the expiration of the CA certificate at 2032-04-10T20:21:59Z\\\"]}\\n\",\"error\":\"Service Unavailable\"}"}
|
|
```
|
|
|
|
This happens when the certificate TTL requested (8 years) would extend beyond the CA certificate's expiration date. The manufacturer service requests a cert that expires in 2034, but the Vault CA expires in 2032.
|
|
|
|
**Fix options:**
|
|
|
|
1. **Reduce the PKI role TTL in Vault** *(non-disruptive - only affects new certs)*:
|
|
```bash
|
|
vault write pki/roles/vehicle-cert ttl=17520h max_ttl=17520h # 2 years
|
|
```
|
|
2. **Extend the CA certificate** - Regenerate the Vault PKI CA with a longer validity period *(disruptive - all existing certs need reissue)*
|
|
3. **Rotate the CA** - Create a new CA with extended validity *(disruptive - requires cert reissue)*
|
|
|
|
On dev-cluster, the CA was created with a ~10 year validity but the cert TTL request pushes past that.
|