接続済み NV 課金データ プラットフォーム

ソリューション概要

自動車 OEM、リソース、ユーティリティ プロバイダー、あるいは モビリティー技術スタートアップ であっても、接続済み電気記号（ビルド）の請求には、さまざまな速度で変化し、請求エクスペリエンスのさまざまな部分に負荷がかかるデータを収集する必要があります。

このデータには、次のものが含まれます。

• ステーションのロケーションとコネクタ機能。

• ステーションの可用性とアクティブなセッション。

• 価格。

• 運用イベント。

課金ネットワークが大きくなるにつれて、このデータを一貫性を確保し、ドライバー向けのエクスペリエンスや運用エクスペリエンス全体でアクセスできるようにすることは、信頼できるサービスを提供し、情報に基づいた決定を行うために、ますます重要になります。

このソリューションは、統合運用データレイヤーがMongoDBでこれらのワークロードをどのようにまとめるかを示しています。共有データデータベースは、リアルタイムの課金のエクスペリエンスをサポートし、ステーションとセッションのアクティビティの一貫したビューをオペレーターに提供します。

ソリューションは単一のアプリケーションアーキテクチャ内で以下を管理します。

• ステーションの検出と可用性。

• 予約とアクティブなセッションの課金。

• 運用イベントとテレメトリ。

このアプローチでは、 MongoDBドキュメントモデルを使用してアプリケーションのアクセス パターンに関するデータを整理しますが、地理空間クエリではロケーションを認識する検出をサポートし、条件付きアップデートは正確な可用性を維持するのに役立ち、変更ストリームは運用状態の変更を下流の処理に接続します。運用データを 1 つの柔軟なプラットフォームに統合することで、ネットワーク、データ要件、運用ニーズの増大に対応する接続済み課金アプリケーションを構築できます。

図の 1。 NV 課金のエコエコシステムを提供するデータ プラットフォームの概要

クリックして拡大します

参照アーキテクチャ

このソリューションは、ドライバー エクスペリエンス、課金操作、ステーション シミュレーター、運用データを統合したアプリアーキテクチャを通じて提供します。

図の 2。 ev 課金デモ アーキテクチャ

クリックして拡大します

Next.jsアプリは、2 つのプライマリ エクスペリエンスを提供します。

• ドライバーアプリ: 検出ステーションと課金セッション管理に使用されます。

• 操作コントロール センター:リアルタイムの課金アクティビティと運用データを監視するために使用されます。

アプリは、 Apollo GraphQLで構築された CSMS（Charging State Management System）と双方向で通信します。 CSMS は、課金ワークフローを実行するためのアプリ契約を提供し、アプリのアクションを課金ステージの操作に接続します。また、このアプリはOpenStreetMap を通じてロケーションベースのサービスと統合され、ステーションの検出とロケーションを認識するエクスペリエンスをサポートします。

A Python FastAPI simulator represents charging-station activity and generates session telemetry. MongoDB change streams capture state changes in the charging session for the CSMS-to-simulator workflow. The simulator uses these events to:

• 課金セッションの処理を開始または停止します。

• 課金状態のシミュレートを計算します。

• セッション テレメトリを生成します。

MongoDB は、 アーキテクチャ全体で統合された運用データ プラットフォームを提供します。ドライバーと自動車のコンテキストから、課金インフラストラクチャ、セッション アクティビティ、運用イベント、大容量のテレメトリまで、エンドツーエンドの課金エクスペリエンスに必要なすべてのデータを統合します。

As your solution evolves, MongoDB capabilities such as geospatial queries, time series collections, Atlas Search, and Online Archive support varied data and access patterns.

データモデルアプローチ

データモデルは、NV 課金アプリケーションが実際に機能する方法に従います。ドライバーには課金セッションの完全なビューが必要であり、ステーション検索にはロケーションと可用性が一緒に必要ですが、テレメトリは大容量のストリームとして処理される必要があります。 MongoDBドキュメントモデルを使用すると、特定のアクセス パターンに合わせて各コレクションを形成できます。

このソリューションでは、次のコア コレクションを使用します。

• users および vehicles: ドライバーと自動車の情報を保存する。

• chargingStations および chargingPoints: 追跡ステーションの検出と エビクション（ビルド）の状態を追跡します。

• chargingSessions: 予約、アクティブなセッション、請求履歴を管理します。

• incidents: 運用の問題を追跡します。

• telemetry: 大容量の課金データを保存します。

ドキュメントモデルにより、ソリューションが直感的になり、実装が容易になります。

例、chargingSessionsコレクションは拡張参照パターンを使用してセッション履歴データをまとめています。基礎となるデータベースとステーションへの参照に加えて、セッションは関連する詳細の小さなスナップショットを保存します。

{
  "status": "COMPLETED",
  "stationSnapshot": {
    "name": "Downtown Mall Charging",
    "addressShort": "Main St 10, Zurich",
    "chargingPointLabel": "Bay 1"
  },
  "vehicleSnapshot": {
    "make": "BMW",
    "model": "i3"
  },
  "charging": {
    "energyDeliveredKwh": 52.4
  },
  "pricingSnapshot": {
    "currency": "EUR",
    "priceCentsPerKwh": 55
  },
  "cost": {
    "totalCents": 2882
  }
}

ドライバーがセッション履歴を表示する場合、アプリは複数のコレクションに結合せずに単一のドキュメントからこの情報を取得します。スナップショットは、基礎となるステーションや自動車のデータが後で変更された場合でも、履歴セッションのコンテキストも保持します。

The same principle simplifies station discovery. The chargingStations collection stores its location as GeoJSON, enabling MongoDB geospatial queries to find stations near a driver's location. It also maintains computed availability counts and a bounded projection of charging-point capabilities, so common map and search queries can be answered directly from the station document.

{
  "name": "Downtown Mall Charging",
  "location": {
    "type": "Point",
    "coordinates": [8.5417, 47.3769]
  },
  "availability": {
    "availableNowPoints": 7
  },
  "chargingPoints": [
    {
      "connectors": [
        { "type": "CCS", "power": 150 },
        { "type": "TYPE2", "power": 22 }
      ]
    }
  ]
}

頻繁に変更される操作状態は、別の chargingPointsコレクションに保持され、請求ポイントのステータスが変化するたびにステーション ドキュメントが更新されません。これにより、テレメトリ容量が大きくなるにつれてモデルの効率が維持されます。

Telemetry has a different access pattern: it is high-volume, time-based, and continuously growing. The solution keeps telemetry separate and uses a MongoDB time series collection with a TTL index to automatically enforce retention policies. For longer-lived data, MongoDB Online Archive moves older data to lower-cost storage, providing a native way to manage the data lifecycle without building separate archival workflows.

{
  "timestamp": "2026-02-12T08:11:58Z",
  "meta": {
    "stationId": "65c8f2e2d2f4c3a9b3b9b001",
    "chargingPointId": "65c8f2e2d2f4c3a9b3b9b101",
    "stationCode": "station-001",
    "chargingPointCode": "cp_station-001_01"
  },
  "messageType": "SESSION_SAMPLE",
  "ok": true,
  "powerKw": 120,
  "energyKwhDelta": 0.4,
  "voltageV": 400,
  "currentA": 300,
  "temperatureC": 31.2
}

これらのパターンにより、実装はアプリケーションの実際のワークフローに焦点を当て、各データ型を独立して増やすおよび展開できるようにします。その結果、柔軟性を失うことなくアプリの複雑さを軽減する実用的なドキュメントモデルが作成されます。

ソリューションのビルド

ソリューションをローカルで実行するには、次の手順を実行します。

完全なセットアップ手順、ローカル開発オプション、環境変数、および追加のコマンドについては、 GitHubリポジトリ を参照してください。

キーポイント

• NV 課金データと操作を統合: ドライバー エクスペリエンス、課金インフラストラクチャ、運用データ、テレメトリを単一の運用データプラットフォームに統合し、可視性を向上させ、アーキテクチャを簡素化します。

• 開発と展開を簡素化: MongoDB の柔軟なドキュメントモデルとスキーマパターンを使用して、要件の変化に応じて課金ワークフローを構築、調整します。

• 可用性と増やすための構築 :リアルタイムデータ、イベント駆動型処理、およびネイティブMongoDB機能を組み合わせて、インフラストラクチャとデータ量の増加に伴う応答性の高い課金をサポートします。

• AIで操作を拡張 : AI支援サポートと運用決定ワークフローの基盤として、接続されたステーション、セッション、インシデント、テレメトリのコンテキストを使用します。

作成者

• Rami Pinto、MongoDB

• Humza Akhtar、MongoDB

• MongoDB、 MongoDB

詳細

• オートメーションデータの相互運用性におけるギャップを埋め込む

• LeafyCharge NV でのノードの GitHub リポジトリ

• EnBW はMongoDBを配置して、料金を平均してネットワーク ゼロにします

• Node はAWS & でMongoDB Atlasを活用しています。 GCP はコアデータベースとして、ビルド ステーション マネジメントのグローバル マーケットを構築するためのコア データベースとして使用されています