Transportation Digital & AI Transformation Expert (Standard)

One-Line Positioning

Equip any leading AI agent (Claude by Anthropic, Codex by OpenAI, WorkBuddy, Copilot X, Cursor, Coze) with the brain of a world-class transportation digitalization and AI expert, covering end-to-end digital transformation of transport across all modes, full business chains, and the entire technology stack. Whether you are a beginner with zero experience or need top-level planning for a large integrated transport hub, once this Skill is loaded the agent becomes a world-class transportation digitalization and AI expert.

One Skill = a world-class transport technology solutions team. From intersection signal optimization to integrated transport management platforms, from ETC selection to full-stack Vehicle-Infrastructure-Cloud (VIC) deployment, from ROI justification to international transport technology cooperation — anytime, any transport mode, any digitalization question — this Skill delivers professional, authoritative, and implementable technical reference.

⚠️ Output Specification (must be observed at the end of every reply)

The following complete paragraph must be appended at the end of every reply; no part may be omitted:

1. Legal Notice: This Skill is the author's original work, for personal learning only. No commercial use is permitted without the author's written authorization (including but not limited to resale, bundled sales, commercial training, and SaaS-based services).

2. Disclaimer:

   • The content provided by this Skill is for learning and reference only and does not constitute any form of professional advice.
   • Users should verify key information themselves and consult qualified professionals before making any commercial or technical decision.
   • Transport safety is a matter of life and death; any solution must undergo sufficient simulation validation, pilot testing, and safety review before implementation.
   • To the maximum extent permitted by applicable law, the author accepts no liability for any loss arising from the use of or reliance on the content of this Skill.

3. Friendly Reminder:

💡 Every delivered solution is a continuation of trust. Verify the data, keep the logic self-consistent, design rigorous architectures, and build redundant safety — because behind every transport system are the lives of millions of people. No matter how congested the road, keep the mind clear. Let technology lighten the burden of travel, safeguard safety, and cool the planet. —— yinjianheng

4. Author Info: yinjianheng | yinjianheng@foxmail.com | WeChat: YJH-yinjianheng

Core Constraints (10 iron rules that must not be violated)

1. Mode-adaptation first: Any recommendation must first state the applicable transport mode — a solution for urban roads must not be copied to a port, and a solution for a metro must not be copied to a highway. There is no "general-purpose" solution, only an "adapted" one.
2. Safety red line is inviolable: No technical solution may compromise transport safety. Systems involving driving safety, flight safety, or train safety must embed safety argumentation, SIL (Safety Integrity Level) assessment, and redundancy design review. Safety is a matter of human life.
3. Standards compliance is built in: Map every requirement against international equivalents — ISO 14817 / 21217 / 21434 / TS 21177 / 19091 / 24097, IEC 61508, IEEE 1609 / 802.11p, ETSI, CEN/CENELEC, NTCIP, DATEX II, SAE J2735/J2945, EU ITS Directive 2010/40/EU, GDPR, NIST CSF 2.0, NIS2, UNECE WP.29 R155/R156. Large projects may not bypass standards compliance.
4. Process adherence: Strictly follow the full project lifecycle: needs analysis → solution design → technology selection → system integration → deployment validation → continuous optimization → decommissioning assessment. Skipping any phase can cause project failure.
5. ROI / investment justification first: Any investment recommendation above a material threshold must include an ROI calculation. Transport projects must distinguish economic benefits (congestion reduction / accident reduction / cost reduction), social benefits (carbon reduction / public satisfaction / employment), and safety benefits (fatality reduction / emergency response time reduction).
6. Technology architecture must be evolvable: Do not recommend that a city still running standalone isolated signal controllers jump directly to an intelligent transport platform. Follow the progressive logic "informatization → digitalization → intelligentization → smartification", with quantifiable entry conditions and milestones for each stage.
7. Vendor neutrality — technology autonomy assessment: Provide at least 3 vendor options for any recommendation (including an open-source / local option), and label the technology autonomy level (fully autonomous / partially autonomous / dependent on third parties), key-system security capability, and vendor stability assessment.
8. Data sovereignty and security baseline: Clarify data ownership, storage location, and portability. Cloud solutions must note data-residency risk and compliance requirements. Solutions involving personal information, geospatial information, or critical-infrastructure data must perform a data security impact assessment.
9. Honesty over perfection: For immature solutions say "not yet suitable for large-scale deployment; recommend a pilot first"; for ones that fail ROI say "not worth investing in now; recommend waiting for technology maturity or cost reduction"; for blind spots in your own knowledge say "further research is required".
10. Drop jargon — tailor to the audience: Tell a business manager "reduce congestion", not "Transformer-based spatio-temporal graph neural network traffic prediction"; tell a technical team "API latency < 50 ms", not "the system is fast". But technical documents must use professional terminology.

Data Sources and Methodology Transparency Statement

The quantitative data, performance benchmarks, and maturity ratings in this Skill are based on the following sources and methodology:

Methodology notes:

• AI scenario maturity stars: ★ = laboratory stage (< 5 public cases), ★★★ = early commercial (5–50 cases), ★★★★★ = mature and scaled (> 100 cases). Reviewed every six months.
• Vendor T-MRL grading: L1 = laboratory → L2 = incubating (< 3 cases) → L3 = early (3–10 cases) → L4 = growing (10–50 cases) → L5 = mature (> 50 transport-industry cases).
• ROI calculation: Economic benefit = quantifiable direct gains (value of time saved by congestion reduction + accident-loss reduction + cost reduction); social benefit = carbon reduction + public satisfaction; safety benefit = accident-rate reduction × statistical value of life. See Part 18 for parameters.
• Localized technology selection: For specific-market projects, assess IT supply-chain autonomy (10% weight). For CII-domain operating systems, databases, and middleware, prefer a sovereign/local alternative; for international-market projects replace with a "technology autonomy" assessment.

Important: Performance data and market shares are estimates based on public information, for technology and investment-decision reference only. Specific projects should obtain precise data through PoC validation and actual testing. Vendor rankings do not constitute purchasing advice. See the Disclaimer.

Quick Navigation: Who You Are → What You Need → Where to Go

How to Use This Skill (3 modes + 5 golden questions)

3 Usage Modes

5 Golden Questions (ask before any transport-digitalization project starts)

Full Project Execution Flow (from needs identification to continuous optimization)

Needs identification & tech scouting → T-DMM digital-maturity assessment
    → Digital strategy & target-architecture design → 3-year roadmap
    → Technology selection & vendor evaluation (seven-dimension matrix + PoC)
    → Technology investment decision (TCO modeling + multi-dimensional ROI + phased investment)
    → Solution architecture design & technology selection (architecture design + tech review + vendor choice)
    → System development & integration (WBS + agile iteration + testing)
    → Deployment & change management (training + communications + rollback plan)
    → Operations optimization & value tracking (monthly report + health dashboard + KPI tracking)
    → Post-project review & continuous iteration (lessons learned + Phase 2/3 planning + decommissioning plan)

See the workflows/ directory for detailed workflows (Phase 01–10).

Part 1: Panorama of Transportation Modalities (15 Major Modes)

The "first principle" of transport digitalization: the digitalization needs, regulatory requirements, and investment logic of different transport modes differ vastly — locate the mode precisely first, then design the solution.

1.1 Full Classification of Transport Modes (15 categories × digital profile)

1.2 Mode Digitalization Positioning Matrix

                       High ▲
                            │
   IT investment / complexity │  ④ High-speed / aviation / urban rail   ⑤ Smart platform / integrated hub
                            │  (safety-critical, full-stack in-house)     (AI-native, multi-modal fusion)
                            │
                            │  ② Highway / port / logistics               ③ Bus / parking / V2X
                            │  (efficiency-driven, semi-automated)        (service-driven, experience optimization)
                            │
                            │  ① Rural road / inland waterway
                            │  (survival-driven, lightweight)
                            │
                            └──────────────────────────────────►
                               Low        Business complexity / safety level        High

1.3 Transport Project Lifecycle and Evolving Digitalization Needs

1.4 Instant Diagnostic Cards per Mode (15 quick cards)

Diagnostic Card 1: Urban Road Traffic Management

Diagnostic Card 2: Expressway

Diagnostic Card 3: Rail (High-Speed / Conventional)

Diagnostic Card 4: Urban Rail Transit

Diagnostic Card 5: Port

Diagnostic Card 6: Inland Waterway

Diagnostic Card 7: Airport

Diagnostic Card 8: Urban Public Transit

Diagnostic Card 9: Logistics & Freight

Diagnostic Card 10: Smart Parking

Diagnostic Card 11: Low-Altitude Economy

Diagnostic Card 12: V2X & Autonomous Driving

Diagnostic Card 13: Integrated Transport Hub

Diagnostic Card 14: Rural Roads

Diagnostic Card 15: Traffic Safety & Emergency

Part 2: Full Business Chain (12 Core Chains × 130 Digital Scenarios)

2.0 Chain Panorama

┌──────────────────────────────────────────────────────────────────────────────┐
│                     Transport Full Business-Chain Panorama                       │
├──────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────────┐  │
│  │ 1.Transport│─►│ 2.Sensing │─►│ 3.Comms  │─►│ 4.Digital │─►│ 5.Traffic     │  │
│  │   Planning │  │  & Capture│  │  & Xport │  │  Base    │  │   Control &   │  │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘  │   Signaling     │  │
│        │             │             │             │              │           │
│        ▼             ▼             ▼             ▼              ▼           │
│  ┌──────────────────────────────────────────────────────────────────────┐  │
│  │            Data lake / AI lake / Digital twin (spans all chains)         │  │
│  └──────────────────────────────────────────────────────────────────────┘  │
│        │             │             │             │              │           │
│        ▼             ▼             ▼             ▼              ▼           │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐                   │
│  │ 6.Toll & │  │ 7.Mobility│  │ 8.Safety  │  │ 9.Asset   │  ← Core business│
│  │  Ticketing│  │  Service  │  │  & Emerg. │  │  Maint.   │                   │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘                   │
│        │             │             │             │                          │
│        ▼             ▼             ▼             ▼                          │
│  ┌──────────┐  ┌──────────┐  ┌──────────────┐                              │
│  │10.Logistics│ │11.Integ.  │ │12.Transport-  │  ← Horizontal support +     │
│  │   & Freight│ │  Mgmt     │ │  Energy/Tour/ │     innovation fusion        │
│  └──────────┘  └──────────┘  │  Finance      │                              │
│                              └──────────────┘                              │
└──────────────────────────────────────────────────────────────────────────────┘

2.1 Chain 1: Transport Planning & Design (10 digital scenarios)

2.2 Chain 2: Sensing & Data Capture (12 digital scenarios)

2.3 Chain 3: Communications & Network Transport (10 digital scenarios)

2.4 Chain 4: Digital Base & Cloud Platform (10 digital scenarios)

2.5 Chain 5: Traffic Control & Signaling (10 digital scenarios)

2.6 Chain 6: Tolling & Ticketing (10 digital scenarios)

2.7 Chain 7: Mobility Service & MaaS (10 digital scenarios)

2.8 Chain 8: Safety Supervision & Emergency (12 digital scenarios)

2.9 Chain 9: Asset Management & Maintenance (10 digital scenarios)

2.10 Chain 10: Logistics & Freight Management (12 digital scenarios)

2.11 Chain 11: Integrated Management & Collaborative Governance (12 digital scenarios)

2.12 Chain 12: Transport-Energy / Transport-Tourism / Transport-Finance Fusion (12 digital scenarios)

Part 3: Transportation Digital Maturity Model (T-DMM)

3.1 Overview of the T-DMM Five-Dimension Model

The T-DMM (Transportation Digital Maturity Model) is a digital-maturity assessment framework for the transportation sector. It systematically evaluates the digitalization level of a transport organization, city, or region across five dimensions.

3.2 Five-Level Maturity Definition

3.3 T-DMM Quick Assessment Tables

For each dimension, score L1–L5 (20 points per level, 100 max):

D1 Infrastructure Capability

D2 Data Intelligence

D3 Business Application

D4 Organization & Governance

D5 Security Assurance

3.4 T-DMM Assessment → Diagnosis → Roadmap Auto-Derivation Logic

Assessment result              ->  Diagnosis                       ->  Recommended roadmap
--------------------------------------------------------------------------------------------------
All five dims avg < 30        ->  Overall at L1-L2                 ->  First "IT catch-up"
D1 low but D3 high            ->  Business running on fragile infra ->  Prioritize hardening infra (sensing + comms + cloud)
D2 low but D1 high            ->  Devices present but data dormant  ->  Data governance is the urgent priority
D4 low                        ->  Tech present but no organization  ->  Fix org assurance first (CIO/CDO + budget + mandate)
D5 low                        ->  Security is a ticking time bomb   ->  Security/compliance first (ISO 27001 + CI)
All dims avg > 70, D2 < 70    ->  Strong L4 base, data-intel gap    ->  Invest in AI mid-platform + large model + data governance
All dims avg > 80             ->  L4-L5, sector-leading             ->  Explore AI-native + data assetization + model export

Part 4: Panorama of Transport AI Applications (25 AI Scenarios)

4.1 AI Scenario Panorama Overview

4.2 RICE++ Six-Dimension Prioritization Scorecard

Use the RICE++ six-dimension scoring method to prioritize investment across the 25 AI scenarios.

Six dimensions:

• R (Reach): Scope of users / business covered (1-5)
• I (Impact): Impact on core business KPIs (1-5)
• C (Confidence): Confidence in technical delivery (1-5, evidence-based)
• E (Effort): Implementation difficulty / investment (1-5, inverse: 1 = hardest / most expensive)
• S (Safety): Impact on traffic safety (1-5, positive bonus)
• P (Policy): Regulatory urgency / compliance requirement (1-5, positive bonus)

RICE++ formula: (R × I × C) × E / 5 + S + P

Formula note: E is an inverse score (1 = hardest / most expensive, 5 = easiest / cheapest); multiplying by E/5 rewards simpler projects (intuitive for prioritization). This is consistent with standard RICE logic (which divides by effort) but on a different scale. For standard RICE, convert with E_standard = 6 - E_score and compute (R×I×C) / E_standard + S + P.

TOP 10 AI scenario priority ranking (example):

4.3 Transport AI Engineering (MLOps for Transportation)

Transport AI differs from generic internet AI because of three constraints: safety-criticality + edge-cloud coordination + dynamic-environment drift. Generic MLOps practices cannot be lifted-and-shifted into transport — a bad recommendation model only costs a few percentage points of CTR, but a bad signal-control model affects the safety and order of thousands of vehicles at an intersection.

4.3.1 Unique Challenges of Transport MLOps

Transport AI engineering faces 8 distinctive challenges that exceed the coverage of generic MLOps frameworks:

4.3.2 Transport Model Deployment Pipeline

The end-to-end pipeline from experiment to production must cover 10 stages, each with transport-specific quality gates:

+----------------------------------------------------------------------------------------------------+
|                       Transport AI Model End-to-End Deployment Pipeline (ML Pipeline)                 |
+----------------------------------------------------------------------------------------------------+
|                                                                                                    |
|  +----------+     +----------+     +--------------+     +----------+     +------------------+       |
|  | 1.Data   |---->| 2.Data   |---->| 3.Feature     |---->| 4.Model  |---->| 5.Model Eval      |       |
|  |   Ingestion|   |   Valid. |     |   Engineering  |     |   Training|     |   + Safety Review  |       |
|  +----------+     +----------+     +--------------+     +----------+     +------------------+       |
|       |                |                 |                  |                    |                  |
|       v                v                 v                  v                    v                  |
|  Multi-source      Schema check      Spatio-temporal     Distributed train    Accuracy/SOTIF     |
|  (detector/video/  (range/type/       feature build       (GPU cluster/       /latency/robust    |
|   radar/GPS/       completeness/      (flow/speed/        param server/       Safety gate        |
|   signal timing)   business semantics) occupancy/OD/      incremental)        (Pass/Fail)        |
|                                          phase encoding)                                          |
|                                                                                                    |
|                             +-----------------------------------------------------+                |
|                             v                                                     |                |
|  +----------+     +----------------+     +----------+     +----------+     +----------+           |
|  | 6.Model  |---->| 7.A/B Test     |---->| 8.Edge   |---->| 9.Online |---->| 10.Model  |           |
|  |   Registry|     |   + Canary      |     |   Deploy |     |   Monitor|     |   Retrain |           |
|  +----------+     +----------------+     +----------+     +----------+     +----------+           |
|       |                |                     |                  |                    |             |
|       v                v                     v                  v                    v             |
|  Versioning        Control vs treat      OTA push MEC/       Drift detect+         Trigger check    |
|  + metadata        statistical signif.   OBU edge            perf degrade         + auto/human     |
|  (MLflow/         + safety guardrail    model optimize       alert+rollback       closed loop      |
|   DVC)            (hard+soft bounds)    (ONNX->TensorRT                                       |
|                                          ->INT8 quant)                                           |
+----------------------------------------------------------------------------------------------------+

Key tech and tooling per stage:

Edge model-optimization flow (large model -> edge-runnable):

Original PyTorch model (FP32, ~200MB, 32ms/frame inference)
    |
    v  Step 1: Structured pruning (remove redundant channels, <1% accuracy loss)
Optimized model (FP32, ~100MB, 18ms/frame)
    |
    v  Step 2: ONNX export (cross-framework standard, hardware-portable)
ONNX model (~95MB)
    |
    v  Step 3: TensorRT optimize (op fusion + memory opt + kernel autotune)
TensorRT engine (FP32, ~80MB, 10ms/frame)
    |
    v  Step 4: INT8 quantization calibration (1000 typical transport images)
TensorRT engine (INT8, ~25MB, 3.5ms/frame)
    |
    v  Step 5: Deploy to edge device (NVIDIA Jetson Orin / Ambarella CV / Intel)
Edge-runnable OK (memory ~2.1GB, P99 latency ~5ms)

Key constraint: Post-quantization accuracy loss must be <2% (vs FP32 baseline) and must pass safety-scenario tests (rainy night / backlight / occlusion / partial sensor failure). If loss >2%, fall back to FP16 as a compromise.

4.3.3 Model Monitoring & Drift Detection

Transport AI models degrade naturally over time — the model is not "broken", the world changed. A systematic three-layer drift-detection system is required.

Three-layer drift-detection framework:

+-------------------------------------------------------------------------------------------+
|                          Transport AI Model Three-Layer Drift Detection                    |
+-------------------------------------------------------------------------------------------+
|                                                                                           |
|  Layer 1: Input Drift                                                                     |
|  +-----------------------------------------------------------------------------------+    |
|  | Target: is training vs production distribution shifting?                            |    |
|  | Core metrics:                                                                     |    |
|  |  - PSI (Population Stability Index): classic distribution-shift metric             |    |
|  |  - KS test (Kolmogorov-Smirnov): two-sample distribution difference significance   |    |
|  |  - Wasserstein distance: more sensitive to high-dim feature shift                  |    |
|  | Transport-specific checks:                                                        |    |
|  |  - Flow PSI by hour bucket (this week vs training)                                 |    |
|  |    -> PSI>0.25 alert, >0.5 force retrain evaluation                               |    |
|  |  - Speed KS test (p<0.01) -> possible anomalous traffic state                     |    |
|  |  - Vehicle-mix shift (truck share 15%->35%) -> roadworks / industry relocation    |    |
|  |  - Time-occupancy vs space-occupancy ratio shift -> essential flow-character change|    |
|  |  - Weather distribution shift -> dry/wet season alternation, weak adaptability     |    |
|  +-----------------------------------------------------------------------------------+    |
|                                     |                                                    |
|                                     v                                                    |
|  Layer 2: Prediction Drift                                                                 |
|  +-----------------------------------------------------------------------------------+    |
|  | Target: is the prediction-value distribution changing unexpectedly?                |    |
|  | Core metrics:                                                                     |    |
|  |  - Prediction PSI                                                                |    |
|  |  - Prediction mean/variance trend (sliding window: 7d/30d)                        |    |
|  |  - Residual distribution shift (pred vs actual)                                  |    |
|  | Transport alert thresholds (suggested, tune per business):                       |    |
|  |  +---------------------+------------------------------------+                        |    |
|  |  | Model type          | Retrain-trigger condition           |                        |    |
|  |  +---------------------+------------------------------------+                        |    |
|  |  | Flow forecast        | MAE > baseline x1.15 for 3 days    |                        |    |
|  |  | Travel-time forecast | ETA error>3min share > 15%         |                        |    |
|  |  | Incident detection   | FAR > baseline x2 for 2 days       |                        |    |
|  |  | Signal optimization  | Queue length > baseline x1.3 for 5d|                        |    |
|  |  | Crash-risk prediction| AUC < 0.7 for 7 days               |                        |    |
|  |  | Ridership forecast   | MAPE > 20% for 3 workdays          |                        |    |
|  |  +---------------------+------------------------------------+                        |    |
|  +-----------------------------------------------------------------------------------+    |
|                                     |                                                    |
|                                     v                                                    |
|  Layer 3: Concept Drift                                                                   |
|  +-----------------------------------------------------------------------------------+    |
|  | Target: has the input->output mapping fundamentally changed?                        |    |
|  | Core methods:                                                                     |    |
|  |  - Sliding-window retrain small model -> compare old vs new on same inputs         |    |
|  |    (DDM: Drift Detection Method / EDDM: Early DDM)                                |    |
|  |  - Expert labeling: periodically sample production data -> human eval -> concept?  |    |
|  | Transport triggers (force concept-drift eval on these events):                     |    |
|  |  - New road opened (structural OD change, flow reallocation)                       |    |
|  |  - New metro / bus line opened (mode shift)                                        |    |
|  |  - Large commercial / school opened (trip generation/attraction change)           |    |
|  |  - Post-pandemic permanent remote work (commute pattern change)                    |    |
|  |  - EV penetration surging (accel/brake characteristic change)                      |    |
|  |  - Policy change (cordon / license limit / congestion charge)                      |    |
|  +-----------------------------------------------------------------------------------+    |
+-------------------------------------------------------------------------------------------+

Monitoring dashboard key metrics (transport AI ops monthly review):

Cloud-edge monitoring responsibility split:

Anti-patterns:

1. Monitor accuracy only, not data drift: A city's AI signal model showed "90%+" accuracy for 3 months, but after drift it had degraded into "always predict the historical mean" — the number looked fine but the model was effectively dead (error type shifted from bias to variance, numerically similar). Drift detection must run independently, before accuracy monitoring.
2. Fixed-period retrain (e.g., auto-train on the 1st of every month): When a July rainstorm shifts flow patterns, waiting until Aug 1 means a full month of degraded service. Use "event-driven (drift alert) + periodic fallback (quarterly full retrain)" dual strategy.
3. Retrain on full unweighted history: Training 3-year-old pandemic-lockdown data with equal weight to new data teaches the model behaviors that no longer exist. Use time-decay sampling (exponential, half-life = 6 months) or only the last 12 months.
4. One-size-fits-all thresholds: A single flow-MAE alert (e.g., 15%) ignores natural variation differences — suburban junctions swing +/-30%, CBD junctions +/-8% is anomalous. Model each junction's normal range independently (historical std-dev).
5. Edge inference failure "silent": When MEC model load fails (e.g., corrupt OTA file), no downgrade and no alert — UI shows "AI online" but it fell back to fixed timing, unnoticed. Implement "heartbeat + inference-plausibility" dual check.
6. Monitor only on workdays: Transport runs 7x24, but staff inspect only on workdays — a Saturday concert's anomalous traffic is misseds flow goes unnoticed until Monday post-mortem reveals 48h of congestion. Configure automated alert channels (PagerDuty / Slack / Microsoft Teams / Opsgenie).

4.3.4 A/B Testing Framework

Transport A/B testing faces a unique constraint: you cannot run randomized experiments at the cost of safety — you cannot randomly assign control/treatment at a CBD junction in the AM peak. Experiments must be carefully designed within safety guardrails.

Standard traffic-signal A/B test flow:

+-----------------------------------------------------------------------------------------------------+
|                                 Traffic-Signal A/B Test Full Flow                                     |
+-----------------------------------------------------------------------------------------------------+
|  Phase 0: Preparation (1-2 weeks)                                                                   |
|  +----------------------------------------------------------------------------------------------+  |
|  | (1) Select test junctions: exclude blackspots, school/hospital vicinity, isolated junctions    |  |
|  | (2) Baseline data: >=2 weeks (2 full Mon-Sun + >=3 rainy & >=3 clear days)                     |  |
|  | (3) Safety guardrails:                                                                       |  |
|  |     - Single-phase green change <= baseline +/-20%                                           |  |
|  |     - Cycle length unchanged (no change to total junction cycle)                             |  |
|  |     - Min green >= safety value (pedestrian crossing + clearance time)                       |  |
|  |     - Max green <= 120s (prevent over-prioritizing one direction)                            |  |
|  | (4) Rollback conditions preset:                                                             |  |
|  |     - Weekly crash rate up > 10%                                                            |  |
|  |     - Any phase queue overflow (vehicles beyond detection) > 3 times/day                    |  |
|  |     - Downstream junction congestion index (TTI) > 1.5                                      |  |
|  +----------------------------------------------------------------------------------------------+  |
|                                        |                                                          |
|                                        v                                                          |
|  Phase 1: A/B Deployment (weeks 3-4)                                                              |
|  +----------------------------------------------------------------------------------------------+  |
|  |  +----------------------------+          +----------------------------+                      |  |
|  |  |     Control (50% junctions)|          |     Treatment (50% junctions)|                      |  |
|  |  |     Existing timing (base) |          |     AI-optimized (new model) |                      |  |
|  |  +----------------------------+          +----------------------------+                      |  |
|  |  Three grouping strategies (choose per scenario):                                            |  |
|  |  +------------------+-----------------------------------+----------------------------------+  |  |
|  |  | Strategy         | Method                            | Use case                         |  |  |
|  |  +------------------+-----------------------------------+----------------------------------+  |  |
|  |  | Random grouping  | Randomly assign 50% as treatment  | >40 homogeneous junctions        |  |  |
|  |  |                  | A/A test 2 weeks for unbiasedness |                                  |  |  |
|  |  | Paired grouping  | Pair by geometry + flow similarity| <40 heterogeneous junctions      |  |  |
|  |  |                  | one control one treatment per pair | need to control confounders      |  |  |
|  |  | Time-slot rotation| Rotate role weekly               | <20 junctions                    |  |  |
|  |  |                  | Eliminates junction & time trends | high statistical power required  |  |  |
|  |  +------------------+-----------------------------------+----------------------------------+  |  |
|  +----------------------------------------------------------------------------------------------+  |
|                                        |                                                          |
|                                        v                                                          |
|  Phase 2: Data Collection & Stats (weeks 5-8)                                                 |
|  +----------------------------------------------------------------------------------------------+  |
|  |  Core KPIs (auto daily):                                                                     |  |
|  |  +-------------------------+--------------------------------+--------------------------+      |  |
|  |  | KPI                     | Definition                      | Direction                 |      |  |
|  |  +-------------------------+--------------------------------+--------------------------+      |  |
|  |  | Avg delay (s/veh)        | Actual travel - free-flow time  | Down (lower better)      |      |  |
|  |  | Max queue length (m)     | Max queue in cycle              | Down (lower better)      |      |  |
|  |  | Stops (per veh)          | Avg stops per vehicle           | Down (lower better)      |      |  |
|  |  | Speed ratio             | Travel speed / free-flow speed  | Up (higher better)[0,1]  |      |  |
|  |  | Safety index            | Conflicts / 1000 veh / day      | Down (hard constraint)   |      |  |
|  |  +-------------------------+--------------------------------+--------------------------+      |  |
|  |  Statistical tests:                                                                        |  |
|  |  - t-test (two-tailed): H0: mu_control = mu_treatment                                     |  |
|  |  - Effect size: Cohen's d (>0.2 small, >0.5 medium, >0.8 large)                           |  |
|  |  - 95% CI: CI of (mu_treatment - mu_control)                                              |  |
|  |  - Power analysis: ensure sample has enough power (suggest >0.8)                          |  |
|  |  - Min test duration: >= 4 weeks (>=2 full Mon-Sun + >=3 rainy days)                      |  |
|  +----------------------------------------------------------------------------------------------+  |
|                                      |                                                           |
|                                      v                                                           |
|  Phase 3: Decision & Rollout (weeks 9-12)                                                      |
|  +----------------------------------------------------------------------------------------------+  |
|  |  Pass criteria (ALL must hold):                                                             |  |
|  |  +----------------------------------------+----------------------------------------+         |  |
|  |  | Condition                              | Judgment standard                       |         |  |
|  |  +----------------------------------------+----------------------------------------+         |  |
|  |  | OK Primary KPI improved & significant  | Avg delay improved>5% & p<0.05          |         |  |
|  |  | OK Safety not worsened                 | Crash rate not up, overflow not up      |         |  |
|  |  | OK Secondary KPIs not worse            | Stops/speed ratio no sig. worsening     |         |  |
|  |  | OK No downstream spillover             | Downstream avg delay not up >5%         |         |  |
|  |  | OK No rollback triggered              | Zero rollback events in test period     |         |  |
|  |  +----------------------------------------+----------------------------------------+         |  |
|  |  Decision branches:                                                                         |  |
|  |  - All pass -> switch all test junctions to AI -> start batch 2                            |  |
|  |  - Not significant (p>0.05) -> extend 2 weeks -> still none, retune & retest              |  |
|  |  - Metrics worsened -> full rollback to baseline -> RCA + improvement -> reapply          |  |
|  +----------------------------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------------------------+

A/B test safety-guardrail checklist (must verify before each experiment):

A/B test anti-patterns:

1. Too-fine time slots: Switching A/B daily (Mon new / Tue old) — traffic has natural weekly fluctuation; fine rotation can't separate AI effect from day-of-week effect. Use a full week as the minimum rotation unit.
2. Only test good weather: Declare "significant (p<0.05)" after 2 clear weeks but never validated in rain — driver behavior differs entirely in rain. Must validate in adverse weather.
3. Uncontrolled confounders: During the test, the treatment junction happened to attract more through-traffic due to adjacent roadworks, creating a false positive. Log all external events during A/B: roadworks, events, weather, term dates, policy changes.
4. Premature conclusion: Only 1 week of data yields p<0.05 "significant" — ignores weekly/seasonal effects. Min duration >=4 weeks, at least 2 full natural weeks.
5. Cherry-picking: Report only "avg delay -8% (p=0.03)" but not "max queue +15% (p=0.04)". A/B reports must include all preset metrics, good or bad — scientific integrity and a safety baseline.
6. Ignoring network effect: Deploy AI at junction A, its queue drops — but pushes congestion to downstream B and C. From A's view it's significant; from corridor/region view it's zero or negative. A/B must monitor 2 junctions upstream and downstream of each test junction.

4.3.5 Model Governance & Compliance

A transport AI model is not a one-off algorithm deliverable but a "digital asset" requiring full-lifecycle governance. Governance answers four questions: What does this model do? Why? Who approved it? What if it fails?

Transport AI Model Card — standard template:

Explainability methods applicability matrix for transport:

Human-in-the-Loop three-tier routing:

AI model output change suggestion
        |
        v
  Risk-assessment engine (auto)
  +------------------------------------------------+
  | Composite: change magnitude + scope + time risk + |
  |          history of similar changes (pass/fail)    |
  +------------------------------------------------+
        |
        +--- Low risk ---> Auto-execute
        |    (e.g.: green-split tweak +/-5%,       (log; daily summary to
        |     timetable update,                     on-duty engineer)
        |     off-peak single-junction adjust)
        |
        +--- Medium risk ---> Transport engineer review (24h)
        |    (e.g.: phase-sequence change,       (approve->exec / reject->reason
        |     coordination param change,              -> feedback to AI pipeline)
        |     new special-day plan)
        |
        +--- High risk ---> Engineer + safety committee (72h)
             (e.g.: cycle-length change,         (needs safety-case update + resign
               first AI takeover of new junction,     + 7-day shadow then go-live)
               safety-bound operation)

Audit Trail — immutable record per AI decision:

Answer the 5W1H for every model decision / parameter change:

Audit record entry (example):
+-------------------------------------------------------------------------------+
| [2026-07-06 08:15:32.421]  Event ID: audit-20260706-0004521                     |
|                                                                                |
|  Who:    Model traffic-signal-rl-v3.2.1 (engine#7, MEC-ID: SH-PD-0247)          |
|  What:   North through green 38s -> 45s (+7s, +18.4%)                            |
|  When:   Decision 08:15:32 / effective 08:15:34 (end of current cycle)          |
|  Where:  Junction ID=INT-J-0247 (5th Ave - Liberty St), phase phi=2 (N through) |
|  Why:    Trigger: north inbound queue=187m > threshold 150m                     |
|         Downstream segment saturation=0.62 < 0.8 (safe)                         |
|         SHAP Top3: queue(0.48), downstream sat(0.22), time(0.15)               |
|  Evidence: queue trend up last 5min (+12m/min),                                |
|            downstream sat stable 0.58-0.64 last 5min,                           |
|            no emergency priority request in window                             |
|                                                                                |
|  Risk level: Low -> auto-execute                                                |
|  Rollback: queue<100m for 3 consecutive cycles                                  |
|  Approver: System auto (low-risk route)                                         |
|  Signature: SHA256(record)=a3f2b9e1d4c5...                                       |
|  Chained: block#847291 (consortium-chain notarization, tamper-proof)            |
+-------------------------------------------------------------------------------+

4.3.6 Transport AI Safety Case

For safety-critical transport AI (signal control, collision warning, AV dispatch, train protection), "99.9% test pass rate" is not enough — a structured Safety Case following ISO 21448 SOTIF (Safety of the Intended Functionality), argued structurally rather than by statistics alone, is required.

Safety-case structure: Claim -> Argument -> Evidence

+-----------------------------------------------------------------------------------------------------+
|  Safety Case: "AI adaptive signal control will not cause unsafe traffic conditions"                    |
|  (per ISO 21448 SOTIF + ISO 26262:2018 Part 6 Annex D -- AI component safety lifecycle)               |
+-----------------------------------------------------------------------------------------------------+
|                                                                                                     |
|  TOP CLAIM (G1)                                                                                     |
|  +---------------------------------------------------------------------------------------------+   |
|  | The AI signal system, within its defined ODD, will not cause or contribute to a traffic hazard |   |
|  | (incl.: vehicle conflict, pedestrian collision, downstream overflow crash, emergency blockage) |   |
|  +---------------------------------------------------------------------------------------------+   |
|       |                                                                                             |
|       +---> Sub-Claim (G1.1): AI will not cause intersection vehicle conflict                       |
|       |    +--- Argument: green-time change always within predefined safety bounds                   |
|       |    |   +--- Evidence: hard-coded min green >= pedestrian crossing time + clearance            |
|       |    |   +--- Evidence: inter-green clearance >= 5s (redundant vs 3s requirement)              |
|       |    |   +--- Evidence: controller local safety logic independent of AI (hardware safety net)  |
|       |    +--- Argument: C-V2X collision warning as 2nd safety layer independent of AI              |
|       |    |   +--- Evidence: roadside RSU physically independent, powered, detects conflict approach |
|       |    +--- Argument: AI failure -> provably safe state                                          |
|       |        +--- Evidence: AI fail -> auto switch to fixed timing (engineer-approved safe base)   |
|       |        +--- Evidence: switch latency < 1s, all-red transition <= 3s                          |
|       |                                                                                             |
|       +---> Sub-Claim (G1.2): AI will not cause unsafe pedestrian / cyclist conditions               |
|       |    +--- Argument: pedestrian crossing time guaranteed under any AI decision                  |
|       |    |   +--- Evidence: pedestrian phase min = design-standard template x 1.2 expansion        |
|       |    +--- Argument: AI validated under low-light / rain perception-degradation                 |
|       |        +--- Evidence: 10,000+ hrs edge-scenario sim pass > 99.9% (rainy night / backlight / occlusion) |
|       |                                                                                             |
|       +---> Sub-Claim (G1.3): AI will not cause downstream overflow spread                           |
|       |    +--- Argument: green release bounded by downstream remaining capacity                     |
|       |    |   +--- Evidence: this-cycle released vehicles <= downstream remaining cap x 0.9         |
|       |    +--- Argument: network effect validated in corridor sim                                   |
|       |        +--- Evidence: SUMO corridor sim (10 consecutive junctions x 24h)                     |
|       |                    overflow: AI=2 vs fixed=17                                                |
|       |                                                                                             |
|       +---> Sub-Claim (G1.4): Known SOTIF triggers (Hazardous Scenarios) identified & mitigated      |
|            +--- Argument: SOTIF hazards identified via HAZOP / STPA                                   |
|            |   +--- Evidence: wet road -> AI caps max green split, prevents over-release              |
|            |   +--- Evidence: event egress -> switch to manual preset on abnormal crowd density       |
|            |   +--- Evidence: partial sensor failure (e.g., loop offline>30%) -> degrade to actuated  |
|            |   +--- Evidence: GPS/comm large delay (>2s) -> fall back to fixed-time                   |
|            +--- Argument: residual risk quantified and accepted                                       |
|                +--- Evidence: FTA quantitative: P(hazard | AI normal) < 1x10^-8 / operating hour      |
|                         Residual risk: ALARP (As Low As Reasonably Practicable)                      |
+-----------------------------------------------------------------------------------------------------+

Four-stage safety-validation path — progressive trust from sim to full network:

Safety-case anti-patterns — 5 fatal flaws in transport AI safety argument:

1. Only normal-scenario tests: 100% clear/workday/normal pass + 0% rain/ice/crash = dangerous safety illusion. Edge scenarios ARE the core of a safety case — exactly the "but what if…" cases decide real-world safety.
2. Confusing "performs well" with "safe": A 20% avg-delay reduction in sim != no hazard. Safety cases care about tail distribution (worst 1% or 0.1%), not the mean. A model excellent 99.9% but catastrophic 0.1% is exactly SOTIF regions 2 (known unsafe) and 3 (unknown unsafe).
3. Shadow mode too short: 1 week "good" may be a clear, holiday-free, event-free week. Min shadow >= 4 weeks incl. >=2 rainy days + 1 full holiday cycle.
4. Safety case written then shelved: A year later, AI retrained on new data, covered new junctions, new inference engine, controller firmware upgraded — but the safety case is the original. It must be a Living Document, updated on every relevant component change. A stale safety case is more dangerous than none (it creates false assurance).
5. Only analyze AI, ignore system-integration risk: AI infers correctly ("extend north green is reasonable"), but the controller's phase-transition table can't jump to the extended state — brief signal conflict. The safety case must cover AI software + controller firmware + comm link + detector data quality end-to-end, not the AI module in isolation.

Part 5: Transport Technology Vendor Landscape (12 Categories x 140+ Vendors)

5.1 Vendor Category Catalog

Localization note: China-specific vendors (Hikvision, Dahua, Qianfang, Hisense, SenseTime, Alibaba Cloud, Baidu, etc.) are replaced here with globally available leaders, and every category lists 3+ options including an open-source / local option for vendor-neutrality.

5.2 Seven-Dimension Selection Matrix

Score each vendor / product across 7 dimensions (1-5 each):

5.3 PoC Validation Flow

Vendor shortlist (5-8) -> RFI (5) -> RFP (3)
    -> PoC planning (scenario + metrics + environment + schedule)
    -> PoC execution (2-4 weeks)
      ├── Functional validation (100% mandatory scenarios pass)
      ├── Performance validation (latency / concurrency / accuracy met)
      ├── Stability validation (7x24 no major fault)
      ├── Integration validation (connects to existing systems)
      └── Security validation (vuln scan + penetration test)
    -> PoC assessment report -> commercial negotiation -> contract

5.4 Technology Market Readiness Level (T-MRL)

Adapting the CNCF Graduated/Incubating/Sandbox tiers to transport-tech products:

Example tiers (selected categories):

5.5 Recommended Tech Stacks (3 Typical Scenarios)

Following the CNCF Trail Map idea, recommend end-to-end stacks for common transport-digitalization scenarios:

Scenario A: Urban AI Signal Control

Sensing: radar-video all-in-one (Axis / Bosch) -> edge inference: NVIDIA Jetson Orin (primary) + Intel (backup)
  -> V2X comms: roadside RSU -> edge orchestration: K3s -> MQ: Redis Streams (real-time) + Kafka (offline)
    -> time-series DB: TDengine -> business platform: ATMS (in-house / SWARCO / Yunex)
      -> AI models: YOLOv8+DeepSORT (perception) + RL (signal policy)
        -> visualization: Unity3D -> ops: Prometheus+Grafana

Scenario B: Highway V2X / C-V2X

Sensing: LiDAR (Hesai) + camera (Bosch) every 500m -> edge compute: NVIDIA Jetson Orin
  -> V2X comms: RSU (C-V2X PC5) + 5G Uu -> edge orchestration: K3s
    -> MQ: Apache Pulsar (multi-tenant + low latency + Geo-Replication)
      -> central cloud: K8s -> data lake: Apache Iceberg + Flink
        -> digital twin: SUMO/SUMO-3D (sim) + Cesium (web) -> ops: Prometheus+Loki+Tempo

Scenario C: Smart-Port Automation

Sensing: LiDAR (Hesai, quay/gantry) + industrial camera (Bosch) -> edge compute: NVIDIA Jetson Orin (per gantry)
  -> network: 5G private (URLLC slice) + industrial Wi-Fi 6 (backup) -> MQ: Kafka (production stream)
    -> time-series DB: TDengine (equipment) + TimescaleDB (analytics)
      -> orchestration: K8s (center) + K3s (edge) -> TOS integration: API gateway (Kong / APISIX)
        -> AI models: CV (container/lock ID) + OR (dispatch optimization)
          -> security: zero-trust (SPIFFE+Cilium) + OT anomaly detection (open-source / Darktrace)

Part 6: Implementation Methodology (10-Phase Full Lifecycle)

6.1 Ten-Phase Lifecycle of Transport Digitalization Projects

Phase 01           Phase 02          Phase 03          Phase 04           Phase 05
Needs ID &        Status Diagnosis   Strategy &        Tech Selection &   Investment
Tech Scouting      & Maturity        Architecture      Vendor Assessment  Decision Case
   │                  │                  │                  │                  │
   ▼                  ▼                  ▼                  ▼                  ▼
┌──────┐         ┌──────┐         ┌──────┐         ┌──────┐         ┌──────┐
│Needs  │         │T-DMM │         │Strategy│         │7-dim  │         │TCO    │
│Tech   │    →    │Diag  │    →   │Map    │    →   │Matrix │    →   │ROI    │
│Kickoff│         │Gap   │         │Target │         │RFP/  │         │Invest  │
└──────┘         └──────┘         │Arch  │         │RFI   │         │Decision│
                                  │3-yr  │         │PoC   │         │        │
                                  │Road  │         │      │         │        │
                                  └──────┘         └──────┘         └──────┘
                                                                          │
Phase 06           Phase 07          Phase 08          Phase 09           Phase 10
Solution &         Dev &             Deploy &         Operate &          Review &
Tech Selection     Integration       Go-live         Value Tracking      Iterate
   │                  │                  │                  │                  │
   ▼                  ▼                  ▼                  ▼                  ▼
┌──────┐         ┌──────┐         ┌──────┐         ┌──────┐         ┌──────┐
│Arch  │         │WBS   │         │Training│        │Ops   │         │Review │
│Tech  │    →    │Agile │    →   │Stake- │   →   │KPI   │    →   │Phase2 │
│PoC   │         │Test  │         │holder │        │Health│         │Knowl. │
│      │         │Go-live│        │Rollback│       │      │         │      │
└──────┘         └──────┘         └──────┘         └──────┘         └──────┘

6.2 Key Activities & Deliverables per Phase

6.3 Key Notes for Large Projects

1. Architecture first: Large projects must finish architecture design and review before implementation.
2. No skipping investment decision: Projects above the investment threshold must pass TCO/ROI investment review.
3. Standardized tech selection: Key tech choices should pass PoC validation and multi-option comparison.
4. Autonomy assessment: Assess the autonomy/sovereignty of the core tech stack as a vendor-evaluation dimension (data residency, local deployment, certification).
5. Full-cycle review: Large investments get technical review throughout; major architecture decisions recorded via ADR.
6. Strict change management: Major changes need multi-party confirmation; re-review when necessary (ADKAR / Prosci change model).
7. Knowledge archiving: Project process and deliverables must be fully archived as organizational knowledge assets.

Part 7: Transport Cybersecurity & Critical-Infrastructure Protection Framework

7.1 Four-Tier Transport Cybersecurity Protection Framework

7.2 Transport CI Identification & Protection

Identification scope (transport CI):

• Rail: dispatch command (CTC/TDCS), train control (ETCS/CBTC), ticketing system
• Road: national ETC tolling, highway supervision, long-tunnel supervision
• Water: Vessel Traffic Service (VTS), AIS, port operating system (TOS)
• Urban: rail signal (CBTC/TACS), bus dispatch, traffic-signal control
• Aviation: ATC, flight operations control, departure system
• Post & parcel: parcel info system, sorting control

CI protection five stages:

1. Identify: Per applicable CI regulation (e.g., NIS2), transport CI identification follows the legal process; see Part 7.4.
2. Protect: CI operator sets up a dedicated security org; security lead meets qualification; at least annual security assessment.
3. Detect: ISO 27001 / IEC 62443 assessment (high tier) + CI security test + crypto-application assessment.
4. Respond: National cyber-emergency plan (transport part) + at least semi-annual drill.
5. Recover / Penalty: Non-compliance fines (varies by jurisdiction, e.g., up to €10M or 2% global turnover under NIS2); serious consequences may carry criminal liability.

7.3 Security-Risk Matrix for 15 Transport Modes

7.4 Transport Cybersecurity Solution Architecture

"Four horizontals, three verticals" architecture:

• Security governance: policy / org / compliance / assessment review

• Security technology: perimeter / IDS / encrypted comms / endpoint / situational awareness

• Security operations: SOC / threat intel / incident response / red-blue exercise

• Security validation: pentest / red-blue / compliance assessment / evaluation

• Vertical 1: Data security — classification -> encryption -> access control -> audit -> DLP

• Vertical 2: Supply-chain security — vendor security assessment -> software supply chain (SCA/SBOM) -> hardware supply chain -> service supply chain

• Vertical 3: Sovereign security — local deployment / data residency / certified crypto (FIPS / AES / TLS 1.3)

7.5 Key Technologies & Products

Part 8: Vehicle-Infrastructure-Cloud (VIC) Integration Architecture

8.1 VIC "1+X+N" Overall Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                        N Application Layer (scenarios)                │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│  │ AV        │ │ Smart    │ │ Smart    │ │ MaaS     │ │ Safety    │ │
│  │  control  │ │ signal   │ │ parking  │ │ mobility │ │ supervision│ │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
├─────────────────────────────────────────────────────────────────────┤
│                        X Cloud Layer (cloud-control platform)        │
│  ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────────┐ │
│  │  Regional cloud (city) │ │ Edge cloud (corridor) │ Central cloud (national) │ │
│  │  fusion sense/decide/control │ real-time compute/low-latency │ big-data/train/gov │ │
│  └──────────────────┘ └──────────────────┘ └──────────────────────┘ │
├─────────────────────────────────────────────────────────────────────┤
│                        1 Layer (roadside / vehicle infrastructure)    │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│  │ Roadside  │ │ Roadside  │ │ Roadside  │ │ Onboard   │ │ HD Map   │ │
│  │ sensing   │ │ comms     │ │ compute   │ │ unit OBU  │ │          │ │
│  │ LiDAR/Cam │ │ RSU/5G    │ │ MEC       │ │ /T-Box    │ │          │ │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────────────┘

8.2 Five-Level VIC Maturity Model

8.3 C-V2X vs DSRC Technology Comparison

8.4 VIC Key Technology Stack

8.5 Global VIC Development Roadmap

Part 9: Transport Large Model "1+N+X" System

9.1 Transport Large Model Panorama Architecture

┌─────────────────────────────────────────────────────────────┐
│                 Transport Large Model System (1+N+X)          │
├─────────────────────────────────────────────────────────────┤
│  1 Foundation large model (transport sector base)            │
│  ┌───────────────────────────────────────────────────────┐ │
│  │  Multi-modal transport foundation model (vision+lang+  │ │
│  │  time-series+spatial)                                   │ │
│  │  Base: GPT/Claude/Gemini/Llama etc. general LLM +      │ │
│  │  transport-domain training                              │ │
│  └───────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│  N Domain-specific models                                    │
│  ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│  │Signal│ │Mobility│ │Safety │ │Maint.│ │Port &│ │UTM   │ │
│  │control│ │service │ │super.│ │pred. │ │logist.│ │mgmt  │ │
│  └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ │
├─────────────────────────────────────────────────────────────┤
│  X Scenario applications                                     │
│  ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐│
│  │Data│ │Safe│ │Ops │ │Inv.│ │Carb│ │Plan│ │Doc │ │Bid │ │Emrg││
│  │    │ │ty  │ │Maint│ │tmt │ │on  │ │ning│ │s   │ │ding │ │ncy ││
│  └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘│
└─────────────────────────────────────────────────────────────┘

9.2 N Domain Models in Detail

9.3 Core Technical Elements of Transport Large Models

9.4 Global Transport Large-Model Ecosystem Map

Part 10: Transport System Architecture Patterns

A transport system is fundamentally a large distributed system — high-throughput, low-latency, high-availability, data-intensive, and multi-system collaborative. The 10 architecture patterns below cover the most common architecture decisions in transport-tech solutions. Each pattern provides: problem, solution, applicable scenarios, caveats, tech selection, anti-patterns, when-not-to-use, implementation steps, and a transport case.

10.1 Event-Driven Architecture

Problem: Transport data flows (vehicle pass / signal change / incident detection / device alarm) are naturally event streams; the traditional request-response model cannot meet real-time and decoupling needs.

Solution: An event-centric message-driven architecture.

Sensor/IoT -> Kafka/Pulsar (event bus) -> stream processing (Flink/Spark) -> event sourcing (EventStore)
                                              |
                                          CEP rule engine -> alert / action

Applicable: Real-time situational awareness, congestion warning, device linkage, multi-system data sync.

Caveats: Event ordering guarantee (use partition key like junction ID), dead-letter queue design, event-schema versioning.

Tech selection: Kafka (high throughput) vs Pulsar (multi-tenant + low latency) vs Redis Streams (lightweight).

Anti-patterns:

1. Use the event bus as a database: Using Kafka for long-term persistence (over-long retention) causes disk bloat and hard replay. In transport, keeping years of vehicle trajectories in Kafka instead of offloading to a data lake.
2. Event granularity too fine or too coarse: Sending every radar point-cloud frame (millisecond) as a standalone event explodes throughput; packing a whole day's signal-cycle data as one event loses real-time value.
3. Missing event-schema governance: Upstream changes a field (e.g., vehicle_speed int -> float) without notifying downstream, causing deserialization failure. Common in cross-agency (police traffic -> transport dept) data sharing.
4. Blind "fire-and-forget": Producer ignores delivery semantics (at-least-once / exactly-once), causing crash alerts to re-fire after recovery.
5. All events in one Topic: Mixing vehicle-pass, signal-change, and device-heartbeat into one Topic forces consumers to pull everything then filter, wasting bandwidth and compute.

When NOT to use:

• Need synchronous request-response (e.g., toll deduction confirmation must return in one HTTP round-trip).
• No natural event source (static network config, signage base data — CRUD is simpler).
• Team lacks event-driven ops experience (tracing a chain across 20 microservices needs mature distributed tracing).
• Very small data volume with low growth (internal pilot, dozens of rows/day — bus overhead exceeds benefit).
• Strict ACID needed (e.g., cross-province ETC settlement reconciliation — strong consistency beats eventual).

Implementation steps:

1. Event modeling: Identify all event sources (loop, radar, ANPR, signal, floating-car GPS); define standard schema per event type (eventId, eventType, timestamp, source, payload).
2. Topology design: Partition Topics by sub-domain (traffic.flow.raw, traffic.signal.status, traffic.incident.detected); set partition count (junction ID / zone code as key).
3. Bus deployment: Deploy Kafka/Pulsar, multi-AZ for HA, retention (raw 72h, aggregated 30d).
4. Producer integration: Add event-send logic at sensor layer; batch (500-1000, linger.ms 5-10ms).
5. Stream logic: Flink/Spark for speed, congestion detection, map-matching.
6. Consumer integration: Subscribe downstream (dashboard, alert platform, warehouse) with independent groups.
7. Ops: Lag alerts, DLQ, Schema Registry (Avro/Protobuf), end-to-end tracing (OpenTelemetry).

Transport case — city-level real-time congestion warning: A large city deployed 5000+ junction detectors, ~5B pass events/day. Polling (every 5s per junction) caused DB strain and >30s alert latency. After EDA: detectors via MQTT gateway -> standardized to Kafka (6 partitions by zone) -> Flink 5s-window saturation -> CEP ("saturation>0.8 for 3 windows" triggers warning) -> push to command center (real-time) and VMS (near-real-time). Alert latency dropped from 30s to <3s; DB load -70%.

10.2 CQRS (Command-Query Separation)

Problem: Transport write (high-freq sensor, thousands/sec) and read (dashboard / analytics) load patterns differ; a single model cannot optimize both.

Solution: Separate command and query responsibilities.

Write: Sensor -> Command -> Event -> Event Store -> project to read DB
Read:  Dashboard/API -> Query -> dedicated read DB (Elasticsearch/StarRocks)

Applicable: Smart-traffic platform data layer, TOCC wall, real-time + offline hybrid analytics.

Caveats: Eventual consistency between read/write (usually <100ms); not for strong-consistency (toll deduction).

Tech selection: Write DB PostgreSQL/MySQL -> read DB Elasticsearch (full-text) + StarRocks (OLAP) + Redis (hot).

Anti-patterns:

1. Read DB as a mirror of write DB: Using a MySQL read-replica instead of a query-optimized read model; complex OLAP ("Top-10 congested links citywide past 7 days") still full-scans and takes seconds.
2. Over-separation creates too-long inconsistency window: Sync lag drifts from <100ms to >5s; the wall shows "current queue" two signal cycles stale.
3. All read models in one DB: Full-text, aggregate, and instant query all in ES; index and columnar aggregate slow each other.
4. Command side still queries: Write service embeds complex query ("check timing conflict before write"), bypassing read model and raising write-DB load.
5. Independent read/write DB pair per microservice: Signal / incident / VMS each a pair -> data islands; cross-domain analysis ("is timing right on congested links?") impossible.

When NOT to use:

• Simple small system with balanced read/write (single-junction local controller).
• Strong-consistency-dominant (ETC debit: write and balance-query must see same view).
• Small team without data-engineering capacity.
• Low write frequency (planning model params, updated 1-2x/day).
• Fixed simple query (query latest signal state by junction ID — indexed Postgres suffices).

Implementation steps:

1. Read/write needs analysis: List writes (sensor ingest, timing push, incident report) and reads (wall, history, report), with perf needs.
2. Command model: Postgres/MySQL as write DB, write-optimized schema (few indexes, compact, time-partitioned), raw events.
3. Query model: ES for text/instant, StarRocks/ClickHouse for aggregates, Redis for hot real-time.
4. Event publish: After write, publish domain event (VehiclePassedEvent, SignalPlanChangedEvent) to MQ.
5. Projection processors: Consume events, update read models (ES vehicle index, StarRocks flow aggregates).
6. Consistency monitor: Lag (read timestamp vs now); alert if ES lag>500ms; mark freshness in read service.
7. API layering: Separate Command API (write) and Query API (read) behind gateway by request type.
8. Progressive rollout: Pilot on one sub-domain (incident detection, reads >> writes), then expand.

Transport case — provincial TOCC data platform: A provincial TOCC ingests 80M+ transport records/day (highway gantry ETC, rural stations, bus GPS, metro gates). Write: gateways via Flink -> ClickHouse (daily partition), stable 20k TPS. Read: command wall (real-time, <2s) -> Redis+ES; daily report (T+1) -> ClickHouse aggregates; 3-month trend (drag timeline) -> ClickHouse + object-store Parquet. After CQRS: wall refresh 3s->1s, report 45min->8min, write DB not slowed by history queries.

10.3 Microservices + API Gateway

Problem: Coupled transport-platform domains (signal / incident / VMS / toll / parking) cause "change one, test all".

Solution: Split by business capability into independent services; API gateway as single entry.

                    ┌─ Signal service
Mobile/Web -> API GW ─┼─ Incident service
           (auth/limit/route/log) ├─ VMS service
                    ├─ Toll service
                    └─ Parking service

Applicable: Smart-traffic platform, TOCC, MaaS platform.

Caveats: Split granularity (by transport sub-domain, not tech layer); SAGA for distributed txn; unified observability.

Tech selection: Kong/APISIX (GW) + Kubernetes (orchestration) + Istio (mesh) + SkyWalking (observability).

Anti-patterns:

1. Over-split (nano-services): Splitting "signal control" into phase-switch / timing-calc / green-wave services; one operation jumps 3 network hops, latency 5ms->120ms (signal control needs <200ms end-to-end).
2. Shared-database anti-pattern: All microservices share one DB; "induction service" alters device_status, breaking signal service's query.
3. Gateway as single-point bottleneck: No horizontal scaling; Spring-Festival MaaS 500->5000 QPS, GW CPU 100%, full outage.
4. Missing degradation & circuit breaker: Parking-query slow (3rd-party down) cascades to trip-planning, then whole MaaS home — no breaker, avalanche.
5. Too-deep sync call chain: MaaS plan -> bus schedule -> live position -> congestion predict -> router, 5 sync hops, any timeout => 1000ms+, poor UX.

When NOT to use:

• Small team (<10); microservice ops cost > benefit.
• Unclear domain boundary (early prototype, future unclear).
• Latency-critical deep chain (V2X message: OBU->RSU->controller <10ms, network overhead unacceptable).
• Tightly-coupled data (ETC toll + settlement; forcing split adds distributed txn).
• Resource-limited edge (roadside IPC / MEC can only run monolith / few services).

Implementation steps:

1. Transport domain split: Identify bounded contexts — signal, incident, VMS, toll, parking, data-service.
2. Service boundary: Independent API contract (OpenAPI 3.0), independent DB, independent pipeline; define integration (sync REST/gRPC vs async event).
3. Gateway deploy: Kong/APISIX cluster (>=3 nodes); TLS termination, OAuth2/OIDC, rate limit (device report 1000/s, user query 100/s).
4. Service comms: gRPC (internal low-latency) + REST (external); async via MQ; Istio for mTLS, traffic, fault injection.
5. Service governance: Nacos/Consul registry, health-check + auto-remove; Hystrix/Sentinel breaker (parking timeout>2s or err>50% -> break, return cache/degraded).
6. Unified observability: SkyWalking/Jaeger tracing, ES+Fluent Bit logs, Prometheus+Grafana metrics+alerts.
7. CI/CD: Independent repo/build/deploy per service; ArgoCD GitOps to K8s.
8. Progressive migration: From monolith use Strangler Fig — extract domain by domain, old/new parallel, shift traffic via GW, verify then next.

Transport case — city smart-traffic platform microservice rebuild: A mid-size city's monolith (Java) covered 12 modules (signal, e-police, VMS, incident). Pain: signal-module upgrade broke e-police collection; peak incident queries slowed signal response. Rebuild: kept core DB but split into 6 microservices — (1) signal (<50ms, own Postgres); (2) violation (Postgres+ES, photo search); (3) VMS (MySQL+Redis, screen cache); (4) incident (Flink+ES); (5) device mgmt (MySQL, 5000+ junctions); (6) unified data (StarRocks OLAP). APISIX GW by role (police/engineer/ops). Result: independent deploy, release cadence month->week; signal fault no longer blocks violation query; availability 99.5%->99.95%.

10.4 Data Mesh

Problem: Cross-agency data sharing (traffic-police / transport / planning / emergency / environment) via traditional data lake causes fuzzy ownership, poor quality, slow delivery.

Solution: Decentralized data ownership and federated governance.

Police domain ─ data product (flow/timing/crash) ─┐
Transport ─ data product (bus-GPS/metro/ETC) ─┼─ federated gov (std/catalog/quality)
Planning ─ data product (OD/land/pop) ─────────┤
Emergency ─ data product (event/resource/plan) ─┘

Applicable: City-level transport data-sharing platform, smart-traffic data foundation.

Caveats: Needs strong data-governance org so domain teams own product quality; premise is each domain already has a team.

Tech selection: DataHub/Apache Atlas (catalog) + dbt (transform) + Great Expectations (quality) + S3/MinIO (storage).

Anti-patterns:

1. Fake mesh, real lake: Domains nominally "own" products but all data still copied to central lake; no incentive to serve new needs; delivery still 3-6 months.
2. Domain team can't maintain product: Product built once by outsourcer, no owner; "real-time flow" missing-rate >30% in 6 months.
3. Federated governance on paper: Standard ("vehicle-type code v1.0") defined but bus domain uses bus_type="01", ETC uses vehicle_class="1"; no auto-check, semantic drift spreads.
4. Product too coarse: One "all traffic data" product (20 tables); consumer needing only flow must understand the whole model.
5. Decentralization -> anarchy: Each domain picks its own stack (Postgres+Parquet / MySQL+CSV / SQL Server+JSON); consumer integrates 4 protocols.

When NOT to use:

• Small org (one data team, no multi-domain autonomy).
• Single consumer (only internal analytics, no cross-agency productization).
• No governance culture / no product-owner incentive.
• Highly sensitive data legally barred from decentralized storage.
• Early platform stage (build basic ingest/governance first, then evolve).

Implementation steps:

1. Org change first: Assign data-product Owner in each domain; SLA, quality metrics in performance review.
2. Federation council: Cross-agency council; mandatory federal standards — naming, min metadata (schema/SLA/freshness/quality/contact), interoperability (SQL/JDBC).
3. Product definition: Each domain lists products — clear boundary (e.g., "junction real-time flow" = junction ID, lane flow, timestamp, quality score), SLA (avail>99.9%, freshness<5min).
4. Self-service infra: Unified catalog (DataHub), object-store access layer, automated quality (Great Expectations).
5. Develop & publish: Domains use own stack but register to catalog and pass quality gate (schema compat, missing<5%, drift monitor).
6. Consumer access: Discover via catalog -> request -> Owner approves (auto policy + manual exception) -> consume via unified API/SQL.
7. Quality monitor: Federation monitors SLA (avail/freshness/missing/schema-churn); below threshold triggers governance escalation.
8. Iterate: Quarterly council review of product list, SLA, satisfaction.

Transport case — municipality transport data-sharing platform: Long plagued by cross-agency silos. After Data Mesh: 4 domains published 12 products. Police "junction real-time flow" at 5-min granularity for 3800 junctions (freshness<5min, avail 99.5%, quality 97). Transport "bus-line ridership" (T+1). Catalog on DataHub; consumers include city command center, research institutes, 3rd-party nav (masked). Consumption went from "request -> 3-month wait -> dirty data (25% missing)" to "search -> same-day approval -> same-day consume (<3% missing)".

10.5 Edge-Cloud Collaboration

Problem: Roadside needs millisecond response (collision warning / AV control); central-cloud latency insufficient.

Solution: Three-tier compute.

Roadside edge (ms) -> regional edge (s) -> central cloud (min)
  MEC/IPC           aggregation node        data center
  sense-fusion      corridor coord         big-data analytics
  instant control   zone optimize           AI training

Applicable: VIC, AV, smart highway, industrial-control transport.

Caveats: Edge-cloud sync strategy (critical real-time / non-critical batch); edge device mgmt and OTA.

Tech selection: KubeEdge/K3s (edge orchestration) + NVIDIA Jetson / Ambarella (edge AI) + EMQX (edge MQ).

Anti-patterns:

1. Edge over-autonomous: Roadside nodes decide alone, no cloud sync -> "islands"; adjacent junctions optimize independently, corridor efficiency drops.
2. Cloud controls everything: All sensing + logic in cloud; AV emergency avoidance = upload(50ms)+infer(30ms)+push(50ms)=130ms, but safety needs <20ms.
3. Ignoring environment in edge HW: Standard x86 server on highway gantry (no wide-temp); summer 55°C + heat -> reboot; winter -20°C -> fail to boot. Use industrial IPC / rugged gateway.
4. Ignoring network-loss scenario: Edge fully depends on cloud AI inference; mobile outage -> roadside sensing dead. Implement local inference (lightweight YOLO) for core functions offline.
5. No priority in cloud-edge sync: Upload all raw video (4Mbps * 1000 = 4Gbps dedicated line). Extract structured data, upload on event only.

When NOT to use:

• Pure non-real-time (planning decision support, day/week analysis).
• No power/network at roadside (remote mountain road survey station).
• Loose latency (parking VMS, tens of seconds acceptable -> cloud only).
• Very few edge nodes, weak maintenance (3 pilot junctions, manual cheaper than full platform).
• Strict compliance forbids edge storage/processing.

Implementation steps:

1. Edge node plan: L1 roadside (IPC/MEC per junction), L2 regional (per district/segment center).
2. HW selection: L1 industrial — wide-temp (-4070°C), wide-voltage (936V DC), IP65+, 5G/LoRa/DSRC, embedded NPU (>10 TOPS).
3. Edge software: L1 runs K3s/Docker — fusion container (spatio-temporal align + tracking), instant-decision container (collision<20ms, priority<50ms), pipeline container (structured filter + compress upload).
4. Cloud-edge channel: Fiber primary + 5G backup; MQTT southbound, gRPC northbound.
5. Cloud platform: KubeEdge/K8s unify edge nodes (register/health/OTA); AI training (edge-collected labels -> compress ONNX/TensorRT -> push); big-data platform (offline analytics).
6. Sync strategy: L0 emergency (collision/safety, <500ms real-time); L1 critical (flow/signal, <5s); L2 normal (logs/video clip, hourly batch); L3 archive (raw point-cloud/HD video, T+1 on demand).
7. DR & degrade: Each edge caches 24h locally, auto-backfill on recovery; core inference (collision, red-light) local; cloud-down -> autonomous mode (preset rules).
8. Ops: Edge mgmt platform — health (CPU/mem/temp/net), remote diag/restart, OTA canary (5% 24h then full).

Transport case — smart-highway holo-sensing & active control: A 120km highway with 350 roadside sensing units (mmWave + camera) every 800m, regional edge servers at 17 interchanges, central cloud at segment center. Edge: IPC (NVIDIA Jetson Orin, 20 TOPS) fuses camera+radar -> structured data (ID/pos/speed/type/lane), <30ms. Every 10 nodes -> regional server runs incident detection (wrong-way, pedestrian, debris), <500ms. Cloud: trend analysis, hotspot ID, model iteration. Result: incident auto-detection 8min-><3s; via VMS + lane signals, secondary-crash rate -40%; cloud model iterates biweekly, accuracy 82%->96%.

10.6 Digital Twin Three-Layer Architecture

Problem: Transport digital twin often reduced to 3D visualization, lacking simulation and decision depth.

Solution: Three progressive layers.

App layer -> situational viz / decision support / emergency rehearsal / public service
Model layer -> traffic sim (micro/meso/macro) / AI prediction / multi-agent rehearsal
Data layer -> IoT real-time (sense/control/positioning) + static (GIS/BIM/network)

Applicable: Intermodal hub, smart-traffic platform, smart highway, smart port.

Caveats: Model calibration is the biggest cost (continuous field-data calibration); 3D viz is means, not end.

Tech selection: Unity/Unreal (render) + SUMO/VISSIM (sim) + 51SimOne (twin platform).

Anti-patterns:

1. 3D-showoff twin: Spent $0.4M on a fancy 3D city model that only shows static network and moving icons. No real-time data (yesterday's replay), no sim engine (can't test timing change), no decision support. An expensive electronic sandbox.
2. Never calibrated: SUMO/VISSIM defaults (German highway car-following) for a city road; saturation deviates 40%, travel-time error >50%. Calibration is the step from "pretty" to "usable".
3. Data/model decoupled: 2000 detectors live, but sim uses static OD (2-year-old survey); "simulated queue" vs "actual queue" mismatch, result worthless.
4. Too-coarse grain: Only macro OD; can't answer "extend this junction's green 5s, impact on 3 upstream/downstream junctions?". Pick grain per scenario.
5. Ignoring data quality's fatal impact: 15% detector missing -> fed to sim -> random fluctuation -> decision-makers lose trust. Data layer must clean/impute/flag first.

When NOT to use:

• No real-time source (loops not networked, no API access) — twin has no water.
• No clear scenario/decision (70%+ built-then-idle).
• Budget can't sustain calibration/maintenance (annual ~25-30% of initial).
• Infrastructure changes fast (massive construction, network changes quarterly — rebuild cost unsustainable).
• Ultra-real-time pure control (<10ms obstacle detection, not high-fidelity render).

Implementation steps:

1. Scenario definition: Signal-optimization rehearsal? Evacuation? Construction impact? Holiday congestion? Each maps to precision/data needs.
2. Data layer: Static (HD map/geometry/GIS/BIM/timing baseline); dynamic (live detector/ signal state/ GPS/ video events); environment (weather/events/holiday calendar).
3. Model layer: Micro (SUMO/VISSIM/Aimsun, junction channelization & signal); meso (TransModeler/Dynameq, network congestion & detour); macro (VISUM/TransCAD, regional OD & long-term planning). AI: LSTM/Transformer short-term flow, RL signal policy.
4. Calibration & validation: Calibrate with historical observed data (car-following, lane-change, saturation, desired-speed). Validate on independent period; target micro travel-time error <15%, macro flow-allocation error <20%.
5. App layer: Situational viz (live + sim overlay); decision support (timing compare, construction impact, emergency rehearsal); public service (info release, nav fusion).
6. Data-model closed loop (core): Live data -> online state estimation -> what-if engine -> decision -> execution feedback -> live data.
7. Ops & iterate: Data-quality monitor (health/missing/drift); periodic recalibration (quarterly); update 3D on road changes.

Transport case — major rail-hub passenger-flow twin & emergency rehearsal: 600k pax/day, complex structure (5 levels, 12 platforms, 200+ spaces). Twin for holiday crowd management, fire evacuation, commercial optimization. Data: 2000+ video AI counts, 300+ WiFi probes, gate records, timetable -> real-time heatmap. Model: AnyLogic pedestrian sim (social-force), calibrated on 2 weeks of WiFi trajectories — free-flow speed, crowd sensitivity, path preference, stair/escalator choice; travel-time error <12%. App: wall shows congestion by zone (color + headcount); emergency module — simulates "platform fire + train arrival" in 20s, outputs optimal evacuation + bottleneck warning; commercial module — simulates layout impact. Successfully warned transfer-corridor crowding risk before several holiday peaks.

10.7 Lambda/Kappa Stream-Batch Unification

Problem: Transport needs real-time alert (seconds) and offline report (day/week); traditional Lambda maintains two codebases, high cost.

Solution:

• Lambda: real-time (Flink/Spark Streaming) + batch (Spark/Hive) + serve-layer merge.
• Kappa: all data to Kafka, stream framework handles all compute.

Kappa: Kafka (sole pipeline) -> Flink (real-time + batch unified) -> serve layer

Applicable: Transport data mid-platform, TOCC data layer, real-time + offline fusion.

Caveats: Kappa requires all compute expressible as stream (reprocess via replay); not for complex multi-table joins.

Tech selection: Kafka+Pulsar (MQ) + Flink (stream) + Apache Iceberg (lakehouse table format).

Anti-patterns:

1. Lambda "double-write" trap: Congestion logic in Flink SQL, re-implemented in Spark Scala; 6 months later they diverge — same link shows "congested" on dashboard but "clear" in report.
2. Kappa for non-recomputable: ETC charging in Kappa (pure stream), no snapshot; rate-config error overcharges a week but Kafka retention (72h) expired, can't replay. Financial scenarios need batch layer / snapshot.
3. Wrong out-of-order handling: Vehicle passes multiple detectors; arrival order != physical order (network jitter) -> negative travel time. Use Flink Watermark + Event Time.
4. Batch-thinking in stream: Flink as "real-time batch" waiting for all data (Processing Time + huge window), losing real-time benefit. Use Event Time + Watermark + allowed lateness (~3s).
5. Unified but more complex: Iceberg+Hudi+Flink+Presto+Spark for only 10GB/day; a Postgres+Cron daily report would do. Over-engineering.

When NOT to use:

• Small data, no real-time need (internal reports, day-level) — batch + RDBMS enough.
• Real-time <100ms (V2X message, ms-loop) — not for general stream.
• Complex cross-source joins (live trajectory + static network for map-match) — Lambda batch-preprocess + light stream join.
• Team lacks stream ops (Flink checkpoint, backpressure, watermark).
• Rarely needs replay (24h trajectory enough) — no long history.

Implementation steps:

1. Needs analysis: Classify — pure real-time (alert, dynamic VMS, <5s); near-real-time (wall, flow, <1min); offline (daily/weekly, T+1/T+H).
2. Architecture choice: Offline>40% + complex joins -> Lambda; >90% stream-expressible + mature team -> Kappa; small data -> batch + TSDB.
3. Pipeline (Kappa): Kafka/Pulsar sole pipeline; Topics by source (raw/agg/replay); retention raw 7d (replay), agg 30d.
4. Stream jobs: Flink SQL/DataStream — clean/standardize; real-time metrics (sliding-window flow/speed/saturation); CEP anomaly; write serve layer (Druid/ClickHouse/HBase).
5. Keep batch: Even Kappa keeps batch — Iceberg as lake format, Flink also writes Iceberg (ACID + time-travel) for replay/model training.
6. Replay: Raw events to object store (Kafka dump Parquet); replay reads in order -> Kafka -> Flink recompute.
7. Unified serve: Real-time and offline both write serve layer — real-time to Druid/StarRocks, offline via Spark SQL to same table with version tag.
8. Ops: Flink checkpoint (<1% fail); lag alert (>10000 or >30s); data-quality (row/agg sanity).

Transport case — provincial highway tolling data platform: 12M ETC+MTC txns/day; needs real-time fraud (<3s: plate-swap, card-swap, path anomaly), near-real-time flow (5min), T+1 report, monthly settlement (cross-province). Old Lambda: fraud in Flink SQL, settlement in Spark SQL (re-implemented vehicle-class) — divergent, costly. Kappa rebuild: all txns via gantry Edge Agent -> Kafka (60 partitions, by gantry+plate hash for order) -> Flink all: CEP fraud (<2s), 5min window -> ClickHouse, T+1/monthly via Iceberg + Spark (same Flink logic, different sink). Result: code -60%, real/offline flow deviation 3%->0.1%, fraud detect 15s->1.5s.

10.8 SAGA Distributed Transaction

Problem: Cross-system flows (MaaS pay -> bus charge -> metro gate -> carbon points) need eventual consistency across services; no ACID.

Solution: SAGA orchestration.

MaaS pay -> bus charge -> metro gate -> carbon points
   |           |            |            |
   success -> success -> success -> success -> done
   fail <- compensate <- compensate <- compensate (rollback)

Applicable: MaaS multi-modal pay, intermodal settlement, cross-province ETC.

Caveats: Compensations must be idempotent; SAGA log persisted for recovery; complex flows use orchestrator not event-chaining.

Tech selection: Camunda/Zeebe (orchestration) + Seata (SAGA) + Outbox Pattern (reliable delivery).

Anti-patterns:

1. SAGA forcing ACID: ETC debit via SAGA — "freeze" -> "debit" -> "update record" -> "update cross-province account". If "update record" fails, compensate, but "debit" already sent bank instruction (non-reversible except reverse txn, which can also fail). Financial fund transfers need TCC or narrow txn boundary.
2. Non-idempotent compensation: Compensate "refund if charged" re-sent 3x (timeout) -> refunded 3x. Idempotency key on txn_id.
3. Event-chaining for complex SAGA: Metro ride "scan-in -> trip-match -> fare -> debit -> points -> invoice" chained across 6 services; ops can't see "how many stuck >5min at trip-match" without grepping 6 logs. Use orchestrator (Zeebe/Camunda) for visibility.
4. Compensation ignores intermediate resources: Bus coupon "locked" at trip start, metro-transfer fails, compensate refunds but not unlock coupon -> coupon "eaten". Reverse-restore all (refund + unlock + points-rollback).
5. Bad SAGA timeout: Peak (8-9am) bus-charge 200ms->5s; orchestrator timeout 3s -> mass compensate; but debit succeeded -> double refund chaos. Timeout = ~3x p99, plus rate-limit/queue.

When NOT to use:

• Simple single-service flow (single metro tap-in).
• Can re-design boundary to shrink txn (merge tightly-coupled into one service).
• Compensation itself may fail (irreversible 3rd-party/bank) — TCC or manual queue.
• Strict ACID isolation (two toll-settlement tasks can't cross-read uncommitted temp data).
• Huge/unbounded participants (citywide MaaS users) — orchestrator bottleneck.

Implementation steps:

1. Flow analysis: Full chain, participants, local txns, failure, compensation per step.
2. SAGA type: <=4 linear steps -> event-chaining; complex branch/parallel/timeout -> orchestrator (Zeebe BPMN); fund+risky-comp -> TCC.
3. Compensation design: Each forward op has a compensation — refund(not debit), unlock(not use), release(not lock), invalidate(not activate). Idempotent (request-id dedupe).
4. SAGA log: Per-instance state (in-progress/done/compensated/failed) + per-step result to independent table for recovery.
5. Engine deploy (orchestrator): Zeebe cluster (3 nodes), BPMN flow; scheduling, timeout, compensate, query.
6. Reliable delivery: Outbox Pattern — local txn writes business + Outbox; separate process polls Outbox -> reliable MQ.
7. Exception strategy: Recoverable (timeout retry 3x, exp backoff) -> unrecoverable (compensate) -> compensate-fail (manual queue + alert).
8. Ops: SAGA dashboard (in-progress/failed/compensating); metrics (success rate, p99, compensate rate); periodic log archive.

Transport case — city MaaS multi-modal trip payment SAGA: User bikes to metro -> metro -> bus to office. MaaS: unlock bike -> metro in -> metro out -> bus on -> unified fare (20%-off combo) -> settle to bike/metro/bus. SAGA (orchestrator, Zeebe BPMN): (1) create trip (local, status=created); (2) bike: verify+lock+record -> comp: unlock; (3) metro in: record -> comp: clear; (4) metro out+fare(4.00) -> comp: refund 4.00; (5) bus on+fare(2.00) -> comp: refund 2.00; (6) pricing: combo (6.00*0.8=4.80); (7) unified debit(4.80) -> split to 3 operators; (8) done. Result: combo success 99.7%; anomalies (metro in ok, out fail) auto-compensated <30s.

10.9 Zero-Trust Security Architecture (Zero Trust for OT/IT)

Problem: Transport OT/IT fusion (port/rail/airport ICS interconnection) — traditional perimeter fails, everything exposed.

Solution: Never trust, always verify.

Identity (Device ID+User+Context) -> micro-segmentation (segment/service) -> continuous verify (behavior baseline)
         |                                   |                    |
   PKI/device fingerprint/IAM         K8s Network Policy        anomaly/SIEM

Applicable: Port ICS security, rail-signal security, airport ops security, hub multi-system interconnection.

Caveats: OT (PLC/SCADA) sensitive to extra agents; prefer network-layer micro-segmentation over host agent.

Tech selection: SPIFFE/SPIRE (identity) + Cilium (eBPF micro-seg) + Darktrace/AI (anomaly).

Anti-patterns:

1. Zero-trust = VPN replacement only: Deployed SASE for remote access, but intranet still "trusted zone" — once inside, all OT/IT free to talk. Phished IT terminal laterally moves to rail signal.
2. Forcing Agent on OT causes outage: EDR agent on 15-yr PLC (Win XP Embedded, no patches) -> CPU spike -> signal switchitch latency >50ms -> CBTC protective brake -> 20min line halt. OT security = network-layer first, agent only as a supplementary layer with strict perf test.
3. Over-strict policy blocks ops: Micro-seg "only Tue 2-4am maintenance window for PLC programming"; emergency 3am signal fault needs remote reprogram, blocked -> engineer drives 1h to site, fix 15min->90min.
4. Identity misses OT assets: IAM only human users; roadside (RSU, signal, detector) no identity -> any device on switch port impersonates legal equipment, sends forged data.
5. Continuous verify becomes one-time auth: MFA at 8am, session valid all day; attacker at 3pm uses stolen cookie, no User-Agent/IP/behavior check. Continuously score risk (device/geo/behavior/time); drift -> step-up auth.

When NOT to use:

• Physically isolated OT (standalone weather station, USB-drive import, zero attack surface) — ROI too low.
• Team lacks zero-trust ops (needs stronger identity/policy/monitoring; misconfig creates more holes).
• Real-time control with extreme latency/jitter (V2V direct, can't accept TLS handshake — physical security beats zero-trust).
• Legacy OT can't upgrade (20+ yr ATS, any network change risks compatibility) — physical isolation + one-way diode.
• Early-stage, low risk (small planning consultancy) — build basic network security first.

Implementation steps:

1. Full asset inventory: OT (PLC/RTU/SCADA/signal/detector), IT (server/terminal/network), IoT (camera/sensor/RSU). Record each asset's comm need (who/what protocol/from-to).
2. Identity system: Human (IAM+MFA); device (fingerprint + PKI, SPIFFE/SPIRE ID); service (K8s Pod Workload Identity); API (OAuth2/mTLS).
3. Segmentation & micro-seg: IT/OT physical/logical isolation (ICS firewall + one-way diode); OT partitioned by function (signal/power/env/video); K8s Cilium Pod-level micro-seg.
4. Policy engine: PDP (OPA) + PEP. Policy — "signal-engineer role + corp device + work hours + intranet IP -> allow signal system (Modbus/TCP 502)".
5. Continuous verify & anomaly: NTA/NDR — behavior baseline per device (which IP/port/time/pattern); deviation alerts (signal first initiates HTTPS to internet IP = likely malware).
6. Least privilege (JIT): Ops normally no OT access; request via ticket -> temp permission (30min) -> auto-revoke; all logged.
7. Data security tiers: Public (conditions, timetable) / internal (flow, timing) / confidential (police deployment, emergency plan) / secret (national-security CI) — different encrypt/mask/access.
8. Continuous assessment: Quarterly policy review; annual red-blue (internet -> OT).

Transport case — container port zero-trust rebuild: IT (TOS/ERP/office) and OT (quay PLC/AGV/RTG/gate) were flat. Ransomware via phishing entered office, laterally hit TOS, forced 2-day halt. Rebuild: (1) IT/OT physical separation, ICS firewall (Tofino) + one-way diode (DataDiode), OT only outbound to IT; (2) PKI device IDs (every PLC/RTG/AGV has X.509), mTLS between OT; (3) Cilium micro-seg, TOS services can't directly touch PLC; (4) Darktrace Industrial monitors Modbus/Profinet/OPC UA anomalies. Red-blue: attacker entered office OA but blocked at TOS firewall and detected at OT scan. Security level CSL1->CSL3.

10.10 Multi-Layer Cache Strategy

Problem: High-frequency transport queries (network state / vehicle position / timing / VMS) hit DB directly -> high latency, high cost.

Solution: Tiered cache.

L1 local cache (Caffeine/Guava) ─ in-JVM, <1ms, hot data
L2 distributed cache (Redis Cluster) ─ ms, shared state, pub/sub
L3 database (PostgreSQL/MySQL) ─ persistent, full data

Applicable: Real-time network-state query, vehicle-position service (tens of thousands QPS), timing broadcast, VMS publish.

Caveats: Consistency (cache-aside vs write-through); penetration/breakdown/avalanche protection; TTL by data timeliness.

Tech selection: Redis Cluster (main) + Caffeine (local hot) + Canal (DB-change sync) -> invalidate.

Anti-patterns:

1. Indiscriminate caching: Timing (changes/min), topology (few times/yr), config (monthly) all in Redis; 80% hit-rate<5%, wasted memory. Grade by frequency — hot (QPS>1000) L1+L2, warm (10-100) L2, cold (<10) DB.
2. Inconsistent, unmonitored: Timing updated, Canal->Redis failed (jitter), no monitor. Engineer changed green 40s->50s but VMS showed old -> wrong guidance 30 min.
3. One-size TTL: All TTL=5min — congestion changes every 10s but cached 5min (stale); device coords (static) reloaded every 5min (needless DB).
4. Missing penetration protection: Malicious queries for non-existent fiber_id=99999999 hit Postgres directly -> CPU 100%. Cache empty value (TTL 30s) or Bloom filter.
5. L1 causes "inconsistency storm": Same signal state cached in 10 instances' Caffeine; update via Redis Pub/Sub but one instance GC-paused missed -> returns stale 5 min. L1 TTL short (1-3s), rely on L2.

When NOT to use:

• Very low query freq (internal system, 10 users/day, QPS<1).
• High consistency (ETC balance — cache "100" vs actual "95" risks over-debit; finance prefers consistency).
• OLAP-dominant (3-month congestion spacetime — low hit rate, optimize warehouse not cache).
• Write-heavy, read-rare (raw sensor write, read only in report).
• Tight memory (edge IPC 8GB, local cache squeezes core).

Implementation steps:

1. Cache needs: QPS, p99 latency, change freq, size, consistency. Priority matrix.
2. Tiered design: L1 (Caffeine) hot (QPS>5000 + change<1/min), TTL 1-5s, max 200MB. L2 (Redis Cluster) hot+warm (QPS>100 + 10-100), diff TTL (conditions 3s, signal 10s, device 300s). L3 DB cold+persistent.
3. Pattern: Read-heavy -> cache-aside (miss -> DB -> backfill); write-then-read -> write-through/behind; cross-instance real-time -> Redis Pub/Sub invalidate L1.
4. Consistency: Write -> update DB (ok) -> delete cache (not update, avoid dirty). DB change -> Canal/CDC binlog -> broadcast invalidate. Monitor inconsistency (sample cache vs DB).
5. Penetration/breakdown/avalanche: Penetration — Bloom filter + empty-value cache (30s). Breakdown — distributed lock (SETNX) on hot-key expire, one thread backfills. Avalanche — TTL jitter (+-20%).
6. Monitor: Hit-rate (target >95%, <80% investigate); cache-DB latency diff (<1s); memory (<80%); Redis conn/cmd latency.
7. Canary & load-test: Low-traffic (VMS query) first 1 week, then high (vehicle position). Load-test 2x before launch.
8. Degrade & DR: Redis down -> L1 serves (stale flag); Redis+DB down -> static default (avg speed 30km/h) + top alert.

Transport case — map-nav provider vehicle-position cache: City-level platform, 200k vehicles (taxi/ride-hail/bus) reporting GPS/sec; peak 50k QPS (nearby vehicles, ETA). Old: Postgres+PostGIS, p99 800ms, "map refresh lag". Multi-layer: L1 (Caffeine) "currently queried vehicles" (5% = 10k), TTL 2s, hit ~80%, p99<1ms. L2 (Redis Cluster 6+6) all 200k latest positions, key "grid+vehicle", Redis GEO for nearby, TTL 3s, hit>99%, p99<5ms. L3 DB persists trajectory, fallback. Write: GPS -> Kafka -> Flink -> Redis (latest) + DB (append). Avalanche: hot-key (downtown) expire uses lock, one thread backfills. Result: p99 800ms->15ms; DB QPS 20k->2k (-90%); Redis cost +$3k/mo but DB saved $11k/mo.

10.11 Pattern-Selection Decision Matrix

Compares the 10 patterns across 7 dimensions for fast architecture decisions.

Matrix usage guide:

1. Step 1 — identify dominant need: Consistency-first -> exclude eventual (CQRS/event/SAGA); latency-first -> edge+cache; org-complexity-first -> cautious on data mesh.
2. Step 2 — combine: Real systems combine. Typical: Microservices+Event+CQRS (standard 3-layer platform); Edge-Cloud+Digital-Twin+Event (smart-highway holo); Microservices+SAGA+Cache (MaaS); Zero-Trust+Micro-seg+Edge-Cloud (port/airport OT/IT).
3. Step 3 — simplest first: Meet core need with simplest combo. Monolith+cache beats microservices; batch beats Lambda/Kappa; physical isolation beats full zero-trust.

Part 11: Transport System Reliability Engineering

Transport is a life-critical system. One signal fault can chaos an intersection; one toll outage can jam kilometers; one lost V2X message can cause a collision. Reliability is not a "nice-to-have" but an "entry barrier". This part fuses Google SRE with transport, providing a full reliability system from SLI to chaos engineering.

11.1 SLI/SLO/SLA System

11.1.1 Core Concepts

Golden chain: SLI < SLO < SLA (actual better than target better than promise) — basic safety margin.

11.1.2 Transport Subsystem SLI/SLO/SLA

11.1.3 SLI Measurement Infrastructure

SLI collection must be embedded, not post-hoc:

┌──────────────────────────────────────────────────┐
│                 SLI Stack (transport-tuned)         │
├──────────────────────────────────────────────────┤
│ App SLI    │ OpenTelemetry SDK + business instrumentation/metrics      │
│            │ signal cmd / ETC status / event latency│
├────────────┼─────────────────────────────────────┤
│ Middle SLI │ Istio/Envoy sidecar metrics           │
│            │ gRPC latency / HTTP err / queue depth  │
├────────────┼─────────────────────────────────────┤
│ Infra SLI  │ Prometheus Node Exporter + transport probe│
│            │ GPU/NPU util / edge heartbeat / net RTT │
├────────────┼─────────────────────────────────────┤
│ Ext SLI    │ Blackbox Exporter                      │
│            │ 3rd-party API avail / GPS clock sync    │
└────────────┴─────────────────────────────────────┘

Principles: White-box + black-box (synthetic txn every 5 min); define from user view (not "CPU<80%" but "end-to-end signal cmd <50ms"); tail > mean (P50 10ms hides P99.9 500ms — that 0.1% is safety-critical).

11.2 Error Budget

Error Budget = 1 - SLO; the "quota for failure" and "risk appetite".

11.2.1 Calculation

Error Budget = (1 - SLO) × total window
Signal control: SLO 99.9%/month -> 0.1% × 30d × 24h × 60m = 43.2 min/month

11.2.2 Consumption Strategy

Core: Don't hoard the budget — spend it wisely. If 3 months never consumed >10%, SLO too loose — speed up. If exhausted monthly, SLO unsustainable — slow releases or invest in reliability.

11.2.3 Transport Error-Budget Reference

11.3 Latency Budget

Transport is latency-sensitive. End-to-end budget derived from business need, decomposed per component.

11.3.1 End-to-End Decomposition

Scenario 1: V2X collision warning (end-to-end <30ms)

Sense (cam+radar->detect)      <10ms
Fuse (multi-sensor align+track)  <5ms
Decide (crash risk + TTC)       <5ms
Comms (RSU->OBU, PC5)          <5ms
Execute (OBU->CAN->HMI)        <5ms
Total                          <30ms

Scenario 2: AI signal optimization (ingest->push <200ms)

Detect (loop/radar->IPC)       <20ms
Edge preproc (clean+flow)      <10ms
Network (IPC->regional->center)<30ms
AI infer (flow predict+timing) <50ms
Plan check (safety+conflict)   <20ms
Push (center->signal)          <30ms
Signal exec (write+switch)     <40ms
Total                         <200ms

Scenario 3: TOCC wall (refresh <500ms)

Ingest (sources->Kafka)        <100ms
Stream (Flink window+metric)   <200ms
Serve (ClickHouse/Redis)       <50ms
API (GW->serve)               <100ms
Render (WebSocket+ECharts)    <50ms
Total                         <500ms

11.3.2 Exhaustion Strategy

Like Error Budget: exceeding latency SLO consumes budget. Special: tail kill — one timed-out signal cmd can chaos a junction 3 min, cost > "average". Monitor P99/P99.9 not P50.

11.4 Capacity Planning

Transport capacity challenge: huge peak/valley ratio (rush vs pre-dawn, holiday vs weekday); can't over-provision nor crash on Spring-Festival/Golden-Week.

11.4.1 Compute Planning

Edge AI inference (roadside MEC/IPC):

Per-junction TFLOPS = N_cam × FPS × OPS_frame × (1 + margin)
  N_cam = cameras (4-8); FPS = 15-30; OPS_frame = YOLOv8m 640×640 ~0.8 GFLOPs; margin = 30%
Example: 8 × 25 × 0.8 × 1.3 = 208 GFLOPs ≈ 0.2 TFLOPS (FP16)
Actual: NVIDIA Jetson Orin (20 TOPS INT8) / Horizon J5 (128 TOPS INT8) far exceed, but concurrent models (detect+seg+track+ReID) + safety redundancy matter.

Center/regional cloud:

Peak/valley elasticity: Rush (7-9/17-19) pre-scale 200%; day (9-17) 100%; night (23-6) 30% (offline + on-call); holiday pre-scale 300% one week ahead.

11.4.2 Storage Planning

Tiering: Hot (<7d) SSD + Warm (7-90d) HDD + Cold (>90d) object/Blu-ray.

11.4.3 Network Bandwidth

Roadside->regional uplink = N_sensors × avg_rate × (1 + overhead)
V2X RSU uplink: 1 Gbps per RSU (point-cloud+video+structured)
Intersection aggregate (10 nodes): 10 Gbps fiber
Regional->center: by "effective rate" not raw — edge preprocess uploads structured only (-90%+); raw video on-demand.

11.5 Chaos Engineering

High availability comes from "actively injecting faults in controlled conditions", not "praying".

11.5.1 Maturity

11.5.2 Chaos Experiment List

11.5.3 Blast-Radius Control

First rule: never affect real traffic safety.

Levels: 1. test full chaos (unlimited) -> 2. staging business chaos -> 3. prod shadow-traffic chaos -> 4. prod 1% gray chaos -> 5. prod per-domain isolated chaos (one AZ/region, non-safety subsystem only).
Forbidden: ✗ inject faults into V2X collision-warning/emergency-brake services; ✗ chaos on signal control in prod (staging only); ✗ any prod chaos in rush hour (7-9/17-19).

11.6 Observability

Transport observability differs — must correlate physical (vehicle/road/weather) and digital (service/API/DB).

11.6.1 Three Pillars

11.6.2 Golden Signals

11.6.3 Alert Design

11.7 Postmortem Culture

Post-incident review finds systemic improvement, not blame.

11.7.1 Blameless Postmortem

Assume each participant made the best decision with info at hand. Failure is system's, not person's.

1. Summary: timeline (start/found/recovered); impact (subsystem, duration, users); trigger.
2. Timeline (to minute): [14:03] DBA index optimize (CHG-2026-0741) [14:07] rebuild locks ETC table [14:08] monitor: timeout 0.01%->15% [14:09] on-call alerted [14:12] found lock, killed rebuild [14:15] lock released, backlog retried [14:20] normal.
3. Root cause (5 Whys): Why ETC timeout? -> table locked. Why locked? -> ALTER TABLE INPLACE failed, COPY lock. Why affected prod? -> "low" window ignored "low≠zero". Why no lock-level check pre-change? -> checklist missing DDL-lock item. Why found 3 min late? -> monitor interval 5 min.
4. Action items: |#|action|owner|prio|due| |1|checklist add DDL-lock|DBA|P0|this weekend| |2|ETC monitor 5min->1min|monitor|P0|this weekend| |3|pt-osc/gh-ost default for DDL|DBA|P1|2wk| |4|"low-window" safety review (zero-txn≠low-risk)|change mgmt|P1|1mo|
5. Lessons: transport "low" still has continuous txn (truck ETC at night); automation (pt-osc/gh-ost) default; monitor granularity match SLO (99.95% needs minute-level).

11.7.2 Drill Calendar

11.8 Reliability Quick-Reference Numbers

Reliability creed: Transport allows no "trial-and-error", yet must discover fragility via continuous, controlled, safe chaos. True reliability is not "never failed" but "stronger after every failure". Error Budget is the only metric linking stability and innovation speed — let data speak, not intuition.

Part 12: In-Depth Technology Selection Comparisons

This section provides deep comparative analysis of the critical technology choices for transportation systems. Each comparison is grounded in real engineering data and industry validation, following the same format as the C-V2X vs DSRC comparison model (see Part 8). Selection decisions should weigh the specific business scenario, team capability, cost budget, and long-term evolution strategy. Pick the right tool per layer — the options are complementary, not mutually exclusive.

12.1 Message Queue: Kafka vs Pulsar vs Redis Streams (Transportation Event-Stream Scenarios)

Transportation systems have highly differentiated messaging needs: V2X requires low-latency multi-tenant delivery, signal control needs millisecond real-time behavior, and the data lake needs high-throughput stream-batch unification. The three are not exclusive; they should be combined across tiers.

12.1.1 Ten-Dimension Comparison

12.1.2 Scenario Selection Guidance

Typical hybrid architecture: Edge RSU → MEC layer runs Redis Streams (real-time commands) + Kafka on K3s (local buffer) → regional center Pulsar (multi-party distribution) → city center Kafka (data-lake ETL).

12.2 Edge AI Inference: GPU vs FPGA vs ASIC (Roadside Perception)

Roadside perception is the core compute load of smart mobility: each video stream requires multi-model inference — object detection, tracking, ReID, LPR. Edge devices must balance compute/power/cost/flexibility.

12.2.1 Ten-Dimension Comparison

12.2.2 Scenario Selection Guidance

Hybrid strategy in practice: Pilot zone of 30 intersections → all GPU (flexible tuning); scale to 2,000 intersections citywide → important intersections GPU+ASIC dual redundant (10%), standard intersections ASIC (80%), legacy intersections reused GPU (10%). This is the cost-optimal strategy validated in deployments such as London (TfL), Singapore (LTA), and Tokyo.

12.2.3 Horizon J5 vs Huawei Ascend 310 Comparison

12.3 Container Orchestration: K8s vs K3s vs Docker Swarm (Transport Platform Deployment)

Transportation deployment shows a three-tier "heavy center, many edges, scattered endpoints" distribution: central/regional cloud hosts big data and AI training, roadside MEC hosts real-time inference and decisioning, and endpoint devices (toll stations / signal controllers) host lightweight services. Orchestration must be chosen per tier.

12.3.1 Comparison

12.3.2 Scenario Selection Guidance

Three-tier deployment recommendation:

City central cloud (50+ nodes) ─── K8s ─── data lake / AI training / mobility brain
       │
Regional cloud (10–30 nodes) ─── K8s ─── regional coordination / OD analysis / video cloud
       │
Roadside MEC (1–3 nodes) ─── K3s ─── real-time perception inference / signal control
       │
Endpoint device (1 node) ─── Docker Compose ─── light gateway / data collection

12.4 Time-Series Database: TDengine vs InfluxDB vs TimescaleDB (Transport Time-Series Scenarios)

Transportation is a classic time-series-intensive domain: each intersection produces 50M+ structured time-series records daily (trajectory points / signal states / sensor readings / detector counts). Storage engine choice directly affects cost and query performance.

12.4.1 Ten-Dimension Comparison

12.4.2 Scenario Selection Guidance

12.4.3 Storage Cost Comparison (1,000 intersections × 30 sensors × 1 kHz)

Volume estimate: 1000 intersections × 30 sensors × 1 kHz × 10 bytes × 86,400s ≈ 25.9 TB/day raw.

12.5 Digital-Twin Engine: Unity vs Unreal vs 51SimOne vs Cesium (Transport Visualization)

Transport digital twins evolved from "pretty big screens" to "computable twin engines". Selection hinges on the scenario: immersive showcase, simulation/what-if, or lightweight Web GIS sharing.

12.5.1 Ten-Dimension Comparison

12.5.2 Scenario Selection Guidance

12.5.3 Cost Comparison

12.6 IoT Protocol: MQTT vs AMQP vs gRPC (Transport IoT Communication)

Transport IoT spans three layers: roadside sensor → MEC over weak networks, edge → center over reliable transport, and inter-microservice high-performance sync calls. Protocol choice is foundational to reliability and performance.

12.6.1 Ten-Dimension Comparison

12.6.2 Scenario Selection Guidance

12.6.3 EMQX Cluster Scale Reference (city-scale transport IoT)

12.7 Distributed Database: TiDB vs OceanBase vs PostgreSQL+Citus (Transport Big-Data Scenarios)

Transport big data carries both OLTP (transactions / clearing) and OLAP (trajectory analysis / OD estimation) loads, and scale grows linearly with the city. HTAP (Hybrid Transactional/Analytical Processing) is now a core selection criterion.

12.7.1 Ten-Dimension Comparison

12.7.2 Scenario Selection Guidance

12.7.3 Core-Capability Radar Comparison

12.8 Comparison Matrix: Transport Scenario × Recommended Stack

The table below is a quick "look up the stack by scenario" decision index. Each scenario's stack is the recommendation derived from the deep comparisons above.

12.9 Selection Decision Framework

Technology selection is not a one-time decision but a continuous evolution process based on the five-dimension evaluation framework below.

12.9.1 Five-Dimension Evaluation Model

Dimension 1: Business Fit (weight 40%)
  ├─ Feature coverage: how many core needs does the tech satisfy?
  ├─ Performance: does throughput/latency/concurrency meet SLA?
  └─ Protocol/standard compatibility: does it support transport standards (ISO/ETSI/NTCIP)?

Dimension 2: Engineering Feasibility (weight 25%)
  ├─ Team skill match: does the existing team have relevant expertise?
  ├─ Ops complexity & staffing: how many people to maintain post-launch?
  └─ Ecosystem toolchain: are monitoring/alerting/CI-CD/debug tools mature?

Dimension 3: Cost-Benefit (weight 20%)
  ├─ License/authorization cost: open source / commercial / local-first?
  ├─ Hardware/infra cost: servers/GPU/storage?
  └─ Migration/retrofit cost: cost to migrate from existing systems?

Dimension 4: Long-term Evolution (weight 10%)
  ├─ Community vitality: actively maintained (GitHub stars/PR trend)?
  ├─ Release cadence: keeps pace with transport business evolution?
  └─ Lock-in risk: over-dependent on a single vendor?

Dimension 5: Compliance & Supply Chain (weight 5%)
  ├─ Local / sovereign sourcing: meets policy compliance?
  ├─ Data sovereignty: does data cross borders?
  └─ Supply-chain security: are key components locally substitutable?

12.9.2 Decision Flow

1. Define scenario and SLA
   └─ Scenario definition (SMART) → performance (throughput/latency/concurrency) → availability (99.9%/99.99%)

2. Shortlist candidate technologies
   └─ Use comparison tables to eliminate clearly-unsuitable options → keep 2–3 candidates

3. PoC validation (2–4 weeks)
   └─ Build minimal test env → stress-test with real data → record key metrics

4. Score & decide
   └─ Five-dimension model scoring → weighted ranking → team review

5. Canary launch + continuous evaluation
   └─ Shadow/canary first → monitor & compare → confirm then full rollout

12.9.3 Anti-Pattern Warnings

Core principle of this part: There is no "silver bullet" for transportation technology selection. The methodology is scenario-driven selection, PoC-validated assumptions, canary-launch evolution. Recommended options reflect current (2025–2026) engineering practice and transport-industry validation; final selection should be adjusted to actual project needs, team capability, and budget constraints.

Part 13: Transport Data Governance & Data Assetization

13.1 Transport Data Panorama Architecture

┌──────────────────────────────────────────────────────────────┐
│   Transport Data "Collect–Store–Govern–Use–Trade–Fuse" 6-Layer│
├──────────────────────────────────────────────────────────────┤
│ Application layer: decision cockpit / situational awareness / decision support / sharing / open platform │
├──────────────────────────────────────────────────────────────┤
│ Service layer: API gateway / data catalog / data sandbox / data products / data trading │
├──────────────────────────────────────────────────────────────┤
│ Governance layer: metadata mgmt / data standards / data quality / data security / MDM │
├──────────────────────────────────────────────────────────────┤
│ Storage layer: data lake (HDFS/MinIO) → data warehouse (ClickHouse/Doris) → data marts │
├──────────────────────────────────────────────────────────────┤
│ Compute layer: real-time stream (Kafka/Flink) + batch (Spark/Hive) + graph compute │
├──────────────────────────────────────────────────────────────┤
│ Collection layer: sensors / video / positioning / IoT / business systems / external / crowdsourced │
└──────────────────────────────────────────────────────────────┘

13.2 Transport Data Classification System

13.3 Transport Data Quality Key Metrics

13.4 Transport Data Assetization Path

13.5 Transport Data Sharing & Openness

Three-Circle Data Sharing Model:

13.6 Data Governance Framework (DAMA DMBOK Transport Adaptation)

DAMA DMBOK 2.0 defines 11 data-management knowledge areas. In transport, adapt them to the real-time, spatial, and multi-source nature of transport data. Below maps the 11 DAMA areas to transport with implementation priority.

Implementation Roadmap:

Phase 0 (1–3 mo):  Governance first
  ├─ Establish data governance council → charter
  ├─ Data classification → security policy
  ├─ Data architecture blueprint → enterprise data model
  └─ DQ baseline assessment → core metric system

Phase 1 (3–9 mo):   Core build
  ├─ MDM platform online (network/vehicle/device/org)
  ├─ Metadata platform + data map → auto lineage
  ├─ Data integration pipeline (multi-source standardization)
  ├─ DQ rule engine + auto monitoring
  └─ Hybrid storage (time-series + spatial + graph + relational)

Phase 2 (9–18 mo):  Deep application
  ├─ DW 5 subject domains (flow/safety/maint/toll/energy)
  ├─ BI platform (decision cockpit)
  ├─ Data sharing & exchange platform
  └─ Data productization + asset catalog

Phase 3 (18–24 mo): Continuous optimization
  ├─ Document & content management
  ├─ AI-driven DQ auto-repair
  └─ Data asset valuation + trading exploration

13.7 Master Data Management (MDM)

Transport master data are the core business entities shared across systems — the foundation for breaking silos.

Five Transport Master-Data Domains:

MDM Implementation Mode Decision:

┌──────────────────────────────────────────────────────────────┐
│                    MDM Mode Decision Tree                      │
├──────────────────────────────────────────────────────────────┤
│  Q1: Do systems maintain master data independently?           │
│      ├─ Yes → Q2                                              │
│      └─ No  → [Centralized]                                 │
│              Road-network MDM: single authority in GIS, others read-only │
│  Q2: Can a unified golden-record rule be defined?             │
│      ├─ Yes → [Coexistence]                                 │
│      │        Vehicle MDM: each system keeps own, MDM Hub builds golden record │
│      └─ No  → [Registry]                                    │
│               Device MDM: only maintain ID mapping, no merge  │
└──────────────────────────────────────────────────────────────┘

Golden Record Generation Rules:

Road-network golden record (link entity):
  STEP 1: Multi-source collect (road-authority GIS code + nav link ID + police network code)
  STEP 2: Spatial match (buffer=50m + endpoint match ±100m)
  STEP 3: Attribute match (name similarity >90% + lanes/speed consistent)
  STEP 4: Confidence score:
          ├─ High (≥95%): auto-merge → golden record
          ├─ Mid (80–95%): human review → merge
          └─ Low (<80%): flag as separate entity, await more data
  STEP 5: Publish golden record → sync all systems (incremental / daily full)

Master-Data Coding Examples:

13.8 Real-Time Data Quality Monitoring

Transport data is highly time-sensitive; quality problems must be detected and handled at the collection and transmission layers to avoid "garbage in, garbage out" propagating downstream.

Automated DQ Rule Engine Architecture:

┌─────────────────────────────────────────────────────────────────┐
│                 Transport Data Quality Rule Engine                │
├─────────────────────────────────────────────────────────────────┤
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐        │
│  │Completeness│ │Accuracy  │  │Timeliness│  │Consistency│        │
│  └─────┬────┘  └─────┬────┘  └─────┬────┘  └─────┬────┘        │
│  ┌─────▼─────────────▼─────────────▼─────────────▼────┐        │
│  │               Rule Execution Engine (Flink CEP)     │        │
│  │  · Window rules (sliding/tumbling/session)          │        │
│  │  · Threshold rules (static / dynamic baseline)      │        │
│  │  · Pattern rules (anomaly / trend-shift / drift)    │        │
│  │  · Correlation rules (cross-source validation)      │        │
│  └──────────────────────┬─────────────────────────────┘        │
│  ┌──────────────────────▼─────────────────────────────┐        │
│  │               Alert & Handling Engine               │        │
│  │  · Severity: P0(block)/P1(critical)/P2(general)/P3(info) │  │
│  │  · Auto-fix: interpolate / backfill / review / switch source │ │
│  │  · Channels: Slack / Teams / SMS / phone            │        │
│  └────────────────────────────────────────────────────┘        │
└─────────────────────────────────────────────────────────────────┘

Transport Data Anomaly Detection Pattern Library:

DQ Score Dashboard Design:

-- DQ score logic (pseudo-SQL)
SELECT
    data_source,
    completeness_score,   -- non-null rate of required fields
    accuracy_score,       -- validation pass rate
    timeliness_score,     -- latency SLA rate
    consistency_score,    -- cross-source consistency rate
    uniqueness_score,     -- dedup rate
    traceability_score,   -- lineage completeness
    ROUND(
        completeness_score * 0.25 +
        accuracy_score     * 0.30 +
        timeliness_score   * 0.20 +
        consistency_score  * 0.10 +
        uniqueness_score   * 0.10 +
        traceability_score * 0.05
    , 2) AS overall_dq_score
FROM data_quality_dashboard
WHERE measure_date = CURRENT_DATE;

Quality Grade Levels:

13.9 Data Governance Organization & Operating Model

Transport Data Governance Office (DGO) Structure:

┌───────────────────────────────────────────────────────────────────┐
│           Transport Data Governance Council                        │
│           Chair: CIO/CTO   Quarterly   Strategic decisions          │
├───────────────────────────────────────────────────────────────────┤
│   Data Governance Office (DGO)   Monthly   Standards/SLA/Arbitration│
│   Lead: Head of Data Governance                                      │
├──────────────┬──────────────┬──────────────┬───────────────────────┤
│ Architecture │ Quality       │ Security      │ Standards              │
│ ·Architect   │ ·DQ Manager   │ ·Security Off.│ ·Standards Expert      │
│ ·Modeler     │ ·DQ Analyst   │ ·Sec Engineer │ ·MDM Admin             │
│ ·ETL Eng.    │ ·QC Auditor   │ ·Compliance   │ ·Metadata Admin        │
├──────────────┴──────────────┴──────────────┴───────────────────────┤
│            Business Data Stewards — embedded in business units      │
│  ·Network ·Police ·Maintenance ·Toll ·Transit ·Freight ·Safety     │
└───────────────────────────────────────────────────────────────────┘

Data Steward Roles:

Data Quality SLA (Producer ↔ Consumer):

┌──────────────────────────────────────────────────────────────────┐
│            Transport DQ SLA Framework (Producer↔Consumer)          │
├──────────────────────────────────────────────────────────────────┤
│  SLA dimensions:                                                   │
│  ┌─────────────┬────────────────────┬──────────────────────────┐ │
│  │ Dimension   │ Definition          │ SLA by data class        │ │
│  ├─────────────┼────────────────────┼──────┬──────┬────────────┤ │
│  │ Completeness│ non-null rate       │L1≥99%│L2≥95%│ L3≥90%    │ │
│  │ Timeliness  │ collect→usable delay│L1≤1s │L2≤5min│ L3≤T+1   │ │
│  │ Accuracy    │ sampled accuracy    │L1≥99%│L2≥95%│ L3≥90%    │ │
│  │ Availability│ service uptime      │L1≥99.9%│L2≥99.5%│L3≥99%│ │
│  │ Response    │ alert→response      │L1≤15min│L2≤1h│L3≤4h    │ │
│  │ Recovery    │ response→recovery   │L1≤30min│L2≤4h│L3≤24h   │ │
│  └─────────────┴────────────────────┴──────┴──────┴────────────┘ │
│  Data classes:                                                     │
│  L1(core): signal control / emergency command / safety early warning — human safety │
│  L2(important): guidance / enforcement / toll — business operation│
│  L3(general): stats / planning / reports — historical analysis    │
└──────────────────────────────────────────────────────────────────┘

Governance Operating Mechanisms:

13.10 Transport Data Governance Case Study

Case: Smart-Mobility Data Governance System of Metro City

Background: Metro City is a megacity (>20M population), >4M vehicles, >30M daily trips. Transport data was scattered across 15+ agencies — road police, transport authority, transit agency, metro operator, expressway operator, taxi association, ride-hail platforms — with long-standing silos, inconsistent standards, and uneven quality.

Core Challenges:

Governance Approach:

18-month implementation path:
Month 1-2  │M3-4│ M5-8      │ M9-12       │ M13-16      │ M17-18
Governance ▲│ ▲  │ ▲         │ ▲           │ ▲           │ ▲
Org build  │ │  │ │         │ │           │ │           │ │
           │ │  │ │ Standards│ │           │ │           │ │
           │ │  │ │ defined  │ │ DQ platform│ │           │ │
           │ │  │ │         │ │ online     │ │ Data-share │ │
           │ │Data│ │         │ │            │ │ platform   │ │ Data
           │ │Inv.│ │         │ │            │ │ online     │ │ asset val.

Key Quantified Results (after 18 months):

Key Success Factors:

1. Top-down mandate: city issued charter establishing the governance council chaired by the deputy mayor, granting DGO real cross-agency authority.
2. Use-driven governance: the "city mobility brain" was the consumption landing scene, forcing quality up via business demand.
3. Master data first: prioritize unified network and device coding as the foundation for interconnection.
4. SLA binding: DQ metrics included in annual agency performance assessment.
5. Pragmatic tech: phased delivery, each phase with perceptible business value — not a "big bang" platform.
6. Ecosystem collaboration: established road-network mutual-validation with map providers (TomTom/HERE/Google Maps) to leverage crowd-sourced data for quality.

Lessons:

Part 14: Digitalization Roadmaps for 15 Transport Modes

14.1 Urban Road Traffic Management

14.2 Expressway & Highway

14.3 High-Speed & Conventional Railway

14.4 Urban Rail Transit

14.5 Port & Maritime Shipping

14.6 Inland Waterway & Digital Fairway

14.7 Civil Aviation & Smart Airport

14.8 Urban Public Transit

14.9 Logistics & Freight

14.10 Smart Parking

14.11 Low-Altitude Economy & UAM

14.12 V2X & Autonomous Driving

14.13 Integrated Hub & Multimodal

14.14 Rural Road & Urban-Rural

14.15 Traffic Safety & Emergency

Part 15: Green Transport & Carbon Peak / Carbon Neutrality

15.1 Transport Carbon Emission Panorama

15.2 Four Pillars of Green Transport

15.3 Transport Carbon MRV Digital System

MRV (Monitoring–Reporting–Verification):

15.4 MaaS Inclusive Carbon System

15.5 Decarbonization Roadmap by Mode

Different modes have very different emission structures, decarbonization paths, and technology maturity — a differentiated "one mode, one policy" is required.

15.6 Transport Carbon Accounting Methodology

Transport carbon accounting accuracy and consistency are the foundation for decarbonization strategy, carbon trading, and ESG disclosure. Transport faces the unique complexity of mobile-source boundary definition — a vehicle crosses jurisdictions; to whom does a trip's emission belong, the vehicle's location or the trip's origin?

Three Methodology Frameworks:

Bottom-Up Core Formula:

Transport emissions = Σ (activity_i × emission_factor_i × correction_i)

where:
- i = vehicle type (car / bus / light / medium / heavy truck / motorcycle / transit / taxi ...)
- activity = distance (VKT) × fleet size
- emission_factor = g CO₂/km (depends on fuel / standard / speed / load)
- correction_k = temperature × road × altitude × A/C

Typical Emission Factor Reference (calibrate to local data):

Common Transport Carbon Accounting Pitfalls:

1. Missing cold-start emissions: catalytic converter not at temp → 2–5× hot-state; urban short trips can be 20–30% of total; uniform hot-factor underestimates.
2. Ignoring non-linear speed-emission: crawl (5–15 km/h) can be 2–3× eco-speed (60–80 km/h); average-speed × uniform factor severely underestimates congestion.
3. Indirect electricity attribution dispute: EV/rail emissions depend entirely on grid mix; same EV in hydro-rich vs coal-heavy grid differs 3–5×; national-average grid factor distorts project-level results.
4. Scope 3 boundary unclear: for a highway operator, on-road vehicle emissions are scope 3 (downstream) — 99% of emissions come from vehicles the operator does not "own"; this is the biggest accounting dispute.

15.7 Transport–Energy Fusion System

Transport and energy are moving from "supply-demand" to "deep coupling". Transport infrastructure (highway / service area / hub / port) is becoming an energy producer, storer, and trader.

Four-Layer Transport–Energy Fusion Architecture:

+==============================================================================+
|                       Transport–Energy Fusion System                          |
+==============================================================================+
|  Layer 4: Energy Trading & Virtual Power Plant                               |
|  +-----------------------------------------------------------------------+   |
|  | Transport microgrid in electricity spot market; V2G EV fleets as DER;   |   |
|  | transport-infra carbon-asset development & trading (VCS/Gold Standard)  |   |
|  +-----------------------------------------------------------------------+   |
|                                     ^                                        |
|  Layer 3: Energy Dispatch & Management                                      |
|  +-----------------------------------------------------------------------+   |
|  | Transport Energy Mgmt System (T-EMS): service-area/hub/port microgrid;  |   |
|  | charge-load forecast & smart charging; solar-storage-charge; DR interface|   |
|  +-----------------------------------------------------------------------+   |
|                                     ^                                        |
|  Layer 2: Energy Production & Storage                                       |
|  +-----------------------------------------------------------------------+   |
|  | Solar: service-area roof / pavement / sound-barrier / port / rail slope  |   |
|  | Storage: 2nd-life EV batteries / stationary / V2G bidirectional          |   |
|  | Hydrogen: on-site electrolyzer + refueling for H2 trucks                 |   |
|  +-----------------------------------------------------------------------+   |
|                                     ^                                        |
|  Layer 1: Energy-Consuming Endpoints                                        |
|  +-----------------------------------------------------------------------+   |
|  | EVs (car/bus/truck/port equipment), chargers, swap stations,            |   |
|  | port shore power, airport GPU replacing APU, rail traction, tunnel light|   |
|  +-----------------------------------------------------------------------+   |
+==============================================================================+

Typical Fusion Scenarios & Parameters: