ID:45365さん

## 案件概要 EV充電機との連携/情報収集によりユーザーの行動範囲を拡大させるための実証実験プロジェクトでの サーバサイド機能開発を担当。 下記の機能はサーバーサイドアプリケーションの設計/実装/テストを担当したもの。 要件定義や米国本土での利用調査、フィールドテストも行った。 ## 詳細 ### 航続距離計算 EV車両のバッテリー充電状況と走行時抵抗(空気抵抗、転がり抵抗、勾配抵抗)、車両電費 から目的地までの経路のどこまでの走行可能かを算出し、 目的地までの電力が足りない場合は推奨する充電ステーション情報の提供を行う。 経路と勾配の情報はGoogleMaps DirectionsService/ElevationServiceから取得。 Directions APIから返される経路情報の最小単位は **steps** の要素になるが、 このポイントは単なるルート決定上のポイントに過ぎないため、 ここの各ポイントでの高低差から勾配情報を出しても粒度が荒く（しかもまちまち）有意なデータとはならない。 Elevation APIにルート情報を渡してサンプリングした各地点間で勾配を算出することも検討したが、 サンプリング上限が512分割までなので、例えば100kmのルートを指定した場合でも195m毎の分割になり まだ粒度が荒い。 このくらいの粒度があると、例えば入り組んだ路地などがルート上にある場合、実際には右左折して 長い距離を走っているにもかかわらず、2点間の距離が直線距離でしか算出できないため、 実際の走行距離から乖離したデータとなってしまう。 ルートを小さく分割し、分割した区間毎にElevation APIにリクエストして粒度をあげることも考えたが、 リクエスト回数が増大するする可能性があるため、API使用制限を考慮すると使いにくい。 Directions APIのレスポンスの中に、指定したルートを近似した描画用のポリライン(polyline)が エンコードされた形で格納されている。 これをデコードしてLatLngを取り出せばルートに沿った細かい地点データとなり、 有為な勾配データが得られると考えた。 得られた地点データをElevation APIに送り、返された標高データを使用して、各地点間の勾配抵抗を算出した。 ### 充電器混雑状況収集/予測 EV充電器インフラのシステムが提供する全米の充電器情報(OCPI)を定期的に取得し整形する Lambdaワークロードを用意しデータをS3に格納、Athenaにより充電器の使用状況を集計した。 集計情報から各充電器の現在の混雑状況及び予測を提供する。 ２週間程度の実装期間で開発を行わなければならなかった為、AWSのマネージドサービスの利用を検討し、 全米充電器の全定期情報データの保存と集計を実現可能なS3+Glue+Athenaによるアーキテクチャを選択した。 データ量が多くユーザーからのリクエストの度にAthenaへ集計のリクエストを送るとレスポンスに数分を要する為、定期的にAthenaからの集計情報をRDBに保存し、ユーザーへ提供する事にした。 ### 充電器予約 EV充電器インフラのシステムが提供する充電器操作を行うAPI(OCPI)と連携した充電器の予約システム。 充電開始、使用可能時間経過後の自動停止の制御を行う。 OCPIの仕様として充電器へのコマンド送信と充電器からのレスポンスが非同期となる為、充電器からの結果のリクエストを待ち受けるAPIをGoのgoroutineを用いてchannel経由で取得した結果を元にユーザーへのレスポンス内容を決定する事にした。 ### 課金連携 それまで無料での充電を提供していたが、課金フェーズへの移行のため充電の為のチケットや充電器制御などのシステムを一新する事になった。 影響範囲と新規機能の量が大きくなる為、既存の機能とはパッケージ構成を切り離す事にした。 また、要件が不確定な機能が多く後の変更が多くなる事が予想された為、変更容易性が高くなるクリーンアーキテクチャによる実装を行う事にした。 新規事業にもなる為、ドメイン駆動により実装しながら要件を確定させていく開発方針を取った。

## 案件概要 EVのECUとCANバイナリデータをインターネット経由でリアルタイム送受信/サーバで収集し、バッテリーの充放 電制御及びモニタリングを行うシステムの開発 Websocketによる外部システムとのリアルタイム双方向通信用Proxyサーバの開発を担当。 ## 詳細 自社プロダクトであるシステムに他システム関連系が無かったため、顧客のシステムと連携する為のProxyサーバーを開発した。 複数の車両ECUから送信されるストリームデータをリアルタイムかつ並列で送受信する為、WebSocketを用いた。 自社システムとProxy、Proxyと顧客システムそれぞれをWebSocketでリアルタイムにデータ伝送を行い、 車両からのデータ伝送のON/OFFによりシステム間の接続もON/OFF出来るようにgoroutineの並列処理を用いて制御を行った。 また、車両から送信されるCANデータのバイナリデータを特定のフォーマットでファイル化し、バイナリファイルを顧客システムに送信する仕組みも作成した。 これにより、顧客システム側から車両情報を確認しつつ、車両に対してECUへ指示データを送信することでバッテリーの充放電指示等の車両をコントロールする情報も送信可能とした。 システムの作成にあたっては顧客担当者と直接やりとりを行いながら、サーバーサイドの要件定義・設計・実装・テスト・運用までを一貫して担当した。

## 案件概要 車両CAN及びOBDから取得するダイアグデータやカメラからの映像を収集し、リモートからのリアルタイム監視と 解析用バイナリフォーマットファイルへの変換を行う。 ## 詳細 解析用バイナリフォーマット(MDF)の生成及び動画のAVIコンテナ形式への変換を担当。 車両から取得したダイアグデータの特定ビットを抜き出しデータ種別毎に指定のエンディアンでの数値変換後、物理 値計算を行った結果のデータをシグナルとしてMDFフォーマットで格納。 変換にかかる負荷が非常に高く、EC2上に変換サービスを配置すると1リクエストの変換でリソースが占有され、リ クエストを複数並列で変換させると変換時間が倍になるため、各変換毎に専用の環境を用意する必要があった。 Lambdaの採用を検討したが、15分のタイムアウト制限内で変換が終わらないリクエストが想定されたため不採用と した。 ユースケースではリクエスト回数はそれほど多くはなく、複数環境を常に起動させておくとコストが膨大になるた め、AWS Batchを用いてリクエスト毎に専用のECSコンテナインスタンスを起動させ、変換が終わった時点でインス タンスを終了させることで拡張性がありつつPay As You Goなサービスを実現した。 AWSの環境に関してはCloudFormationにより自動プロビジョニングを行い、ECSで実行させるコンテナイメージはGitLab CIでビルド後ECRに自動プッシュし、変更が即時に反映される仕組みを構築した。

利用技術：Go, CAN, WebSocket, PostgreSQL, InfluxDB 担当業務：設計、実装、テスト、運用・保守 ## 案件概要 EVバス及び充電機からのCANデータを収集/監視し、機器のエラーを検知、メール通知を行い、過去のエラー履歴及び現在のエラー状態をモニタリングするシステムの開発 ## 詳細 EVバスと充電器から送信される高粒度のバイナリデータをデータ種別毎に64ビットの各ビットに意味づけを行い常時監視、ビット値の変化を検出して機器のエラーを検知する仕組みを構築。エラー発生時のログと現状の機器のエラー状態を可視化し、ユーザーへはメール通知を行う。 エラーによってはさらに車両情報などを含むバイナリデータから特定の開始/終了ビットからビット列を取り出し物理値変換を行い、エラー情報に付与した。 バイナリデータから特定のビット列を取り出し物理値変換を行う処理にはビットシフト、エンディアン変換、補数の計算等を組み合わせた。