令和３年度

課題解決型ローカル５Ｇ等の実現に向けた開発実証

ローカル 5G と AI 技術を用いた鉄道駅における車両監視の
高度化

成果報告書

令和 4 年 3 月 25 日

京浜急行電鉄株式会社i

目次
1. 実証概要 .......................................................................................................................... 1
1.1 背景・目的 ................................................................................................................. 1
1.1.1 京浜急行電鉄における列車検査 .................................................................................. 1
1.1.2 令和 2 年度事業のレビュー及び残された課題............................................................. 5
1.1.3 本事業の目的 ............................................................................................................... 8

1.2 実証の概要 ................................................................................................................. 9
1.2.1 実施事項及び実証目標 ................................................................................................. 9
1.2.2 実施体制 ..................................................................................................................... 11

2. 実証環境の構築 .............................................................................................................. 12
2.1 実施環境 ................................................................................................................... 12
2.2 ネットワーク・システム構成 ................................................................................... 14
2.2.1 基地局設置場所 .......................................................................................................... 14
2.2.2 エリアイメージ .......................................................................................................... 17
2.2.3 ネットワーク構成 ...................................................................................................... 18
2.2.4 ローカル 5G 基地局装置 ............................................................................................ 21
2.2.5 ローカル 5G コアネットワーク装置 .......................................................................... 24
2.2.6 その他付随する装置................................................................................................... 25
2.2.7 ローカル 5G 端末 ....................................................................................................... 29
2.2.8 システム構成 ............................................................................................................. 31

2.3 システム機能・性能・要件 ...................................................................................... 41
2.3.1 ローカル 5G ネットワーク ........................................................................................ 41
2.3.2 車両検査の遠隔・自動監視システム ......................................................................... 42

2.4 免許及び各種許認可 ................................................................................................. 74
2.5 その他要件 ............................................................................................................... 75
2.5.1 サイバーセキュリティ対策 ........................................................................................ 75

2.6 実証環境の運用 ........................................................................................................ 78
3. ローカル５Ｇの電波伝搬特性等に関する技術的検討（技術実証） ............................... 79
3.1 実証概要 ................................................................................................................... 79
3.2 実証環境 ................................................................................................................... 80
3.3 実証内容 ................................................................................................................... 86
3.3.1 ローカル 5G の電波伝搬特性等の測定 ...................................................................... 86
3.3.2 電波伝搬モデルの精緻化 ......................................................................................... 117
3.3.3 電波反射板によるエリア構築の柔軟化.................................................................... 143
3.3.4 準同期 TDD の追加パターンの開発 ......................................................................... 143
3.3.5 その他のテーマ ........................................................................................................ 144
3.3.6 技術実証における追加提案 ...................................................................................... 145ii

4. ローカル５Ｇ活用モデルの創出・実装に関する調査検討（課題実証） ...................... 146
4.1 実証概要 ................................................................................................................. 146
4.2 背景となる課題を踏まえた実装シナリオ・実証目標 ............................................. 146
4.3 実証環境 ................................................................................................................. 156
4.4 実証内容 ................................................................................................................. 158
4.4.1 ローカル 5G を用いたソリューションの有効性等に関する検証 ............................ 158
4.4.2 ローカル５Ｇを用いたソリューションの実装性に関する検証 ............................... 262
4.4.3 ローカル 5G の実装に向けた課題の抽出及び解決策の検討.................................... 269
4.4.4 継続利用の見通し・実装計画 .................................................................................. 275

5. 普及啓発活動の実施..................................................................................................... 277
5.1 映像制作への協力 ................................................................................................... 277
5.2 実証視察会の実施 ................................................................................................... 278
5.3 その他普及啓発活動 ............................................................................................... 280
6. 実施体制 ...................................................................................................................... 281
6.1.1 京浜急行電鉄株式会社 ............................................................................................. 281
6.1.2 中央復建コンサルタンツ株式会社 ........................................................................... 281
6.1.3 株式会社 NTT ドコモ ............................................................................................... 282
6.1.4 再委託先及び再々委託先 ......................................................................................... 282

7. スケジュール ............................................................................................................... 284

iii

1. 実証概要
1.1 背景・目的
本実証は、京浜急行電鉄久里浜工場で実施した、令和 2 年度総務省事業「地域課題解決型
ローカル５Ｇ等の実現に向けた開発実証に係る鉄道分野におけるローカル５Ｇ等の技術的条件等に関する調査検討の請負（遠隔・リアルタイムでの列車検査、線路巡視等の実現）」の継続検討として、遠隔・リアルタイムでの列車検査を鉄道駅にて実施し、実装するための課題の洗い出しを目的とした実証である。
取組の背景として、京浜急行電鉄の列車検査業務における課題を整理したうえで、令和 2
年度事業での残された課題を含めた課題整理を踏まえ、今年度事業の目的を示す。

1.1.1 京浜急行電鉄における列車検査
1.1.1.1 列車検査の種類と内容
車両を含む鉄道施設の安全は「検査」によって確保されており、検査による損傷の早期発
見は事故を未然に防止するための基本である。検査は、①短い周期で簡易に行われる「日常検査」、②一定の周期で入念に行われる「定期検査」、③災害発生時などに臨時的に行われる「臨時検査」の 3 つに分類され、検査の周期や内容は、鉄道事業者が法令で定められた範囲
において独自に設定している。
例として、京浜急行電鉄株式会社（以下、「京浜急行電鉄」という。）における列車検査の種類と内容を以下に示す。京浜急行電鉄では、車両に対して「列車検査」、「月検査」、「重要部検査」、「全般検査」、「臨時検査」の 5 種類の検査を実施しており、このうち列車検査が日
常検査、月検査、重要部検査、全般検査が定期検査に分類されている。

1

図 1.1-1

京浜急行電鉄における車両検査の種類（1）検査周期
法令で定められた列車検査の周期（頻度）は 10 日以内であるが、京浜急行電鉄では安全性をより高めるため 6 日に 1 度の頻度で検査しており、保有する約 800 両の列車を 3 つの検車区（久里浜検車区、新町検車区、金沢検車区）にてローテーションしながら検査している。
（2）検査内容
京浜急行電鉄では、人による近接目視によって日常的な列車検査を実施している。列車検
査では保守作業員が車両の床下、車体、台車（車輪、車軸、モーター）、屋根上、客室の装置等に近接し、目視にて外観を確認することによって異常の有無を検査している。

2

（3）検査時間
実際の検査は 1 編成を 5 人体制で検査しており、検査に要する時間は 1 編成あたり概ね30 分程度である。
以上のように、車両の日常検査である「列車検査」では、異常の有無を 1 編成あたり 5 人体制で近接目視によって検査している。車両の異常は事故や輸送障害に直結するため、鉄道事業者は検査周期をできるだけ短くて異常を早期に発見したいものの、現在の保守管理体
制では 6 日に 1 度の頻度での検査が限界であり、ローカル 5G を含む新技術を活用した、さらなる異常の早期発見と安全の向上が期待されている。

図 1.1-2

京浜急行電鉄の列車検査の実施状況

1.1.1.2 列車検査における課題
鉄道事業者は日常的な列車検査によって車両異常の早期発見と安全の確保に努めている
ものの、現在でも車両異常による輸送障害が発生している。列車の運行中に疲労き裂等の異常が発生すると重大事故につながる可能性があり、列車検査が 6 日に 1 度である場合、最大で 5 日間、状態が把握できない可能性がある。

図 1.1-3

列車検査における現状と課題（現場の課題）
3

［疲労き裂による重大インシデント例］

出所）鉄道の輸送トラブルに関する対策のあり方検討会、「鉄道の輸送トラブルに関する対策のあり方検討会とりまとめ」（平成 30 年 7 月 27 日）
https://www.mlit.go.jp/tetudo/tetudo_fr7_000023.html

図 1.1-4

疲労き裂による重大インシデント例

4

1.1.2 令和 2 年度事業のレビュー及び残された課題
1.1.2.1 令和 2 年度事業のレビュー
令和 2 年度事業では、京浜急行電鉄久里浜工場をフィールドとして、鉄道分野へのロー
カル 5G 等の導入を促進し、鉄道インフラの維持・管理における人手不足や熟練作業者不足
等の課題解決に寄与することを目的とした実証を行った。鉄道施設の検査のうち「鉄道車両検査」および「線路巡視業務」にフォーカスし、ローカル 5G 等の電波伝搬特性の解明及び課題解決に資する具体的なアプリケーション（鉄道車両の傷等、線路の障害等を自動検出）を想定した実証を行った。

図 1.1-5

令和 2 年度事業の実施概要

具体的には、4K カメラにて撮影した車両台車及び軌道の高画質画像をローカル 5G 等にて送信し、AI にて異常を検出することによって、台車に発生する疲労き裂等や線路周辺における異常の検出能力を確認した。また、列車検査を実施している鉄道事業者の職員へのヒアリング等を通じて、新技術（ローカル 5G 等＋AI による画像検査）の適用性や導入効果、及び鉄道以外のインフラ点検に対する適用性等を検証した。

5

R2年度、台車のき裂検知では、ダミーのクラックシールについて、クラック幅×４パターン、長さ３パター
ン、貼付け方向２パターンの合計２４パターンで検出した。
各種評価項目（上りスループット、遅延量、検出率、網羅率）の結果を示す。
対象物：ダミークラックシール

手法：対象物の識別
結果：・上りスループット：最大 98.06 Mbps
・End-End遅延量：940 ms （解析込）
課題：
・照度によって検出精度にばらつき
・暴露機材が時折停止（長期安定）・複数インプット映像は未対応★検出精度（速度とクラック進展方向 垂直/水平）
試験情報
走行速度
向き
(km)
5
垂直
5
水平
5 集計
10
垂直
10
水平
10 集計
総計

集計結果
AIが検出した対象数
True_positive

False_positive

14
19
33
4
20
24
57

0
0
0
0
0
0
0

性能評価

AIが検出しなかった対象数
True_negative

False_negative

検出率

網羅率

100%
100%
100%
100%
100%
100%
100%

39%
53%
46%
11%
56%
33%
40%

22
17
39
32
16
48
87

★実装に向けた残課題
・照度に応じた検出精度のばらつき改善→AI映像ソリューションの弱点を解決！

・機材の長期間安定運用を実現→耐候性に優れる機材構成を開発！

・複数インプット映像の解析を実現→包括的な車両監視技術を開発！

R2年度、車軸の異常温度検知では、ダミー温度上昇（カイロ）を利用して、地表面温度との温度差分を作り出して検証した。
図 1.1-6 令和 2 年度の課題実証の結果概要（4K カメラ映像の AI 異常検出）
各種評価項目（上りスループット、遅延量、検出率、網羅率）の結果を示す。
対象物：車軸の温度
手法：車軸識別、温度計算
結果：・上りスループット：最大 98.06 Mbps
・End-End遅延量：940 ms （解析込）
課題：
・複数画角/別センサの異常検知も必要
・データ蓄積/活用基盤の整備
・データ活用手法の運用スキーム★実装に向けた残課題
・センサ画角/種類の多様化

★検出精度
検出対象

AIが検出した対象数

AIが検出しなかった対象数

検出率

網羅率

→より実用的なデータを効率的に取得！

走行速度

閾値

True_positive

False_positive

True_negative

False_negative

5

10

42

0

0

0

100%

100%

・取得データの蓄積/活用基盤を整備→人に依存しないナレッジを構築・運用！

5

30

38

0

4

0

100%

100%

10

10

42

0

0

0

100%

100%

10

30

40

0

2

0

100%

100%

・運用スキームの構築検討→運用方法を事前に定義し、着実に利用！

図 1.1-7

令和 2 年度の課題実証の結果概要（サーマル映像の AI 異常検出）6

1.1.2.2 残された課題
ここでは、令和 2 年度の実証をとおして得られた、実装に向けた課題について述べる。技
術面の課題として、AI の精度向上（照度に応じた検出精度のばらつき改善）、長期安定運用の実現、複数センサによるインプットによる包括的な異常検出（センサフュージョン）などが挙げられる。運用面の課題として、個別技術では、実運用に資するシステムが構築できた
ものの、現場技術者による運用スキームの実用化には至っていない。
当コンソーシアムでは、後者の運用上の課題が特に重要であると認識しており、（列車の運行も含む）オペレーションにおける継ぎ目のない実運用を目指していく必要がある。今年
度事業は、実装に向けた“システムの共存・段階的運用”のフェイズであると考える。

7

1.1.3 本事業の目的
上記の課題認識を踏まえて、今年度は“実装”を念頭に置いた列車検査の高度化の実証を行った。つまり、令和 2 年度の成果である課題解決のためのシステムをブラッシュアップ
し、（令和 2 年度は方向性の検討にとどまっていた）実運用につなげることを目指している。
具体的には、次のような事項を目的とした。
令和 3 年度事業の目的
 実業務の中でのオペレーションを見据え、（検車庫ではなく）鉄道駅での実証を行う
 継続的な運用を見据え、翌年度まで実証を継続する
上記と合わせて、実運用に即したさらなる技術の高度化を図る。
【R3実証～実装運用】
鉄道駅の営業車両を用いた効果検証および運用検証、
長期安定的な実装運用

安全性への効果確認

データに基づく判定

人間主体ナレッジ

5Gクラウド長年の経験に基づく
安全運行オペレーション

実装効果を確認
課題を明確化

AI映像
解析【実装運用での価値向上】
社内運用スキームの高度化、データの活用基盤を用いた
既存スキームとのシナジー創出

図 1.1-8

データ蓄積
活用基盤

データの蓄積・活用

実装に向けた PDCA のイメージ

京浜急行電鉄はローカル 5G を自社専用の高速無線通信網として、以下が可能となることを将来像としている。
 車両の台車や車内、駅ホーム、踏切などの映像を遠隔監視し、鉄道インフラ全体で安全性の向上につなげる。
 運行情報や広告など駅構内および電車内に配信し、お客様の利便性向上につなげる。
将来像の実現に向けて、今年度の実証内容をベースに、さらなる課題の抽出や技術的・人的リソースに関する机上検討を実施するとともに、システムの汎用化等による費用削減、技術向上に向けた開発者との協業を実施した。

8

1.2 実証の概要
1.2.1 実施事項及び実証目標
1.1.3 章で記載した令和 3 年度事業の目的を達成するため、実運用の想定と同じ環境（鉄道駅）にて、ローカル 5G を活用したシステムを構築し、現場のオペレーションへの対応及
び複数デバイスの長期安定運用を見据えた実証を実施した。
京浜急行電鉄羽田空港第 1・第 2 ターミナル駅において、ローカル 5G（周波数：4.8-4.9GHz
帯（100MHz）構成：SA 方式）を構築し、地下駅のホームにおける建物侵入損を考慮した
電波伝搬モデルの精緻化に関する技術実証を実施した。
5G 活用モデルの創出・実装に関する調査検討（課題実証）として、フル HD 映像の AI
解析による車両検査の遠隔・自動監視システムを構築し、上記で構築したローカル 5G を活用した車両台車の遠隔監視の高度化・実装を図る実証を実施した。

図 1.2-1

実証概要イメージシステムを設置した京浜急行電鉄羽田空港第 1・第 2 ターミナル駅の 1 番線には、平日
104 列車、休日 103 列車が発着する。
表 1.2-1 に京浜急行電鉄羽田空港第 1・第 2 ターミナル駅の 1 番線の時刻表を示す。時刻
表のうち、白色は京浜急行電鉄の 8 両編成、橙色は京浜急行電鉄の 6 両編成、灰色は他社
車両が発着すること示している。このように、他社車両も多数入線する環境である。

9

表 1.2-1

京浜急行電鉄羽田空港第 1・第 2 ターミナル駅の 1 番線時刻表

なお、評価・検証項目の具体的な内容に関しては、実業務の中でのオペレーション及び継続的な運用を見据え、コンソーシアム内で協議の上確定した。
10

1.2.2 実施体制
本実証コンソーシアムの実施体制は以下の通りである。
本事業の実証コンソーシアムは、京浜急行電鉄株式会社、中央復建コンサルタンツ株式
会社、株式会社 NTT ドコモの 3 者により構成する。本事業のとりまとめ等を行う代表機関
は、京浜急行電鉄株式会社であり、フィールドの提供、実証全体の管理、実証結果の評価、協議会の主催、報告書作成等を担った。
協力企業を含めた本事業の組織構成を図 1.2-2 に示す。

図 1.2-2実施体制図

11

2. 実証環境の構築
2.1 実施環境
実証実施場所は、東京都大田区羽田空港三丁目 3-4 の 羽田空港第 1・第 2 ターミナル駅（京急空港線）のホーム内線路とした。

図 2.1-1

実証実施場所周辺図

出所）国土地理院のデータを加工し作成

12

羽田空港第 1・第 2 ターミナル駅を本実証場所に選定した理由は以下のとおりである。
 ローカル 5G エリアを利用したシステム検証において、実際の鉄道駅における営業車
両や運航状況下での効果や運用検証が可能であること
 本事業は単年度実証だけでなく、次年度も継続使用することで長期的な実装運用を行うため、継続使用に適していること
 今後多拠点への展開を見据えたユースケースとして適していること

図 2.1-2 羽田空港第 1・第 2 ターミナル駅図
出所）国土地理院のデータを加工し作成

13

2.2 ネットワーク・システム構成
2.2.1 基地局設置場所
無線アンテナと課題実証用は実証場所の羽田空港第 1・第 2 ターミナル駅の島式ホームに設置した。GNSS アンテナは屋外に設置する必要があるため、地上への配線が可能な羽田
空港第 3 ターミナル駅に設置することした。
GNSS アンテナは無線制御部と接続する必要があるため、ローカル 5G のコアネットワ
ーク装置とともに羽田空港第 3 ターミナル駅通信機器室に構築した。図 2.2.1-1 に羽田空港
第 1・第 2 ターミナル駅と羽田空港第 3 ターミナル駅の位置関係を示す。

図 2.2.1-1

羽田空港第 1・第 2 ターミナル駅、羽田空港第 3 ターミナル駅の位置関係

出所）国土地理院のデータを加工し作成

課題実証用機器として、羽田空港第 1・第 2 ターミナル駅の片側の線（1 番線）の車両を片側（ホーム下側）から撮影するフル HD カメラ、照度補完用のライト、端末（ローカル
5G ルータ）を設置した。各機材の設置場所の写真を図 2.2.1-3 に、また各機材の設置状況を図 2.2.1-4 に示す。

14

図 2.2.1-2

羽田空港第 1・第 2 ターミナル駅の全体図

出所）国土地理院のデータを加工し作成

＝カメラ
＝アンテナ
2カメラ

1カメラ

3カメラ

階段

エスカレーター

待合室

エレベーター

エスカレーター
第2旅客ターミナル方面

第1旅客ターミナル方面

終点（列車到着方向）

品川・横浜方面（列車出発方向）

図 2.2.1-3

ホーム下への機材設置場所

15

機器収容箱

照明

アンテナ

照明
カメラ

図 2.2.1-4

ホーム下への機材設置状況

16

2.2.2 エリアイメージ
本実証の基地局位置を起点としたエリアイメージを図 2.2.2-1 に示す。

図 2.2.2-1

エリアイメージ

出所）国土地理院のデータを加工し作成

17

2.2.3 ネットワーク構成
京浜急行電鉄羽田空港第 1・第 2 ターミナル駅に構築したローカル 5G ネットワーク構成
を図 2.2.3-1 に示す。

図 2.2.3-1

ローカル 5G ネットワーク構成図

18

2.2.3.1 ローカル 5G システム構成
本実証では、コアネットワークを含めたローカル 5G システム全てを実証実験敷地内に設置するオンプレミス構成をとった。システム製造ベンダはエリクソン・ジャパン株式会社とし、2022 年 1 月中旬に検証環境構築を完了した。構築したローカル 5G システムの論理構
成を図 2.2.3-2 に示す。

図 2.2.3-2

ローカル 5G システムの論理構成図

19

2.2.3.2 ローカル 5G システムラック構成
19 インチハーフラック内にはローカル 5G コアネットワークシステム及び基地局制御部
及び時刻同期システム（GNSS)を収容した。また小型 19 インチラックには Dot アンテナと接続する IRU（Indoor Radio Unit)を収容した。Dot アンテナは IRU からイーサネットケーブルで接続し IRU から給電する。図 2.2.3-3 にローカル 5G システムのラック収容図を示す。図 2.2.3-4 に羽田空港第 3 ターミナル駅通信機器室の設置状況を示す。

図 2.2.3-3

図 2.2.3-4

ローカル 5G システムのラック収容状況

羽田空港第 3 ターミナル駅通信機器室の設置状況

20

2.2.4 ローカル 5G 基地局装置
本実証において用いたローカル 5G 基地局装置は、コア装置、無線装置、SIM にカテゴリ分けされ、表 2.2.4-1 にそれぞれのカテゴリにおいて使用した機器の製品名及び数量を示す。

Domain
コア装置

無線装置

SIM

表 2.2.4-1 機器一覧
製品名
Network Controller（Dell VEP 4600）
Radio DoT 4479 B79B
IRU 8846
Baseband 6630
Baseband Power Unit （Remote IRU Enclosure）
GNSS Receiver/Antenna
Nano-SIM Card
SIM Card Writer

本実証で使用したローカル 5G 基地局の諸元を表 2.2.4-2 に示す。
表 2.2.4-2 ローカル 5G 基地局システム諸元
項 目
基地局
製造ベンダ
エリクソン・ジャパン株式会社
台数
1台
設置場所（屋内/屋外）
屋内
同期/準同期
同期
DL：UL 比率7:2
周波数帯
4.7GHz 帯
SA/NSASA
同期方式
GNSS
UL 周波数
4.8～4.9GHz
DL 周波数UL 帯域幅99.98MHzDL 帯域幅UL 中心周波数
4849.98MHz
DL 中心周波数
UL 変調方式
QPSK/16QAM/64QAM/256QAM
DL 変調方式
4×4MIMO
MIMO
セルスループット（規格値）
DL：1.5Gbps UL：85Mbps
セクター数
1

21

数量
2台
3台
1台
1台
1台
1式
50 枚
1台

2.2.4.1 Baseband6630
Baseband6630 は、変調前及び変調後の信号処理を行うユニットであり、本体装置部と電源部で構成される。
外観を図 2.3.4-1 及び図 2.3.4-2 に、また、諸元を表 2.3.4-3 に示す。

図 2.2.4-1

図 2.2.4-2

Baseband6630 外観（エリクソン社）

BasebandPowerUnit 外観（エリクソン社）

表 2.2.4-3

Baseband/BasebandPowerUnit 部諸元
2 ポート

×

SFP＋

フロントホール（CPRI ポート） 15 ポート

×

2.5 / 4.9 / 9.8 / 10.1 Gbps

バックホール

1G 又は 10Gbps イーサネット

ラックマウント

19 インチラック

1U サイズ

最大 NR スループット

1Gbps/5Gbps

電源部

入力電圧

AC100V（Baseband Power Unit への入力）

電源部

出力電圧

DC-48V（Baseband 6630 へ入力）

2.2.4.2 IRU8846
5G Sub-6 無線機 Dot4479 と BB6630-5G(4.8GHz)間に挿入し CPRI インターフェースと Dot4479 間インターフェース(LAN ポート)を 8 個有します。又 DC 及び AC 電源両方に対応する。本実証で使用した IRU8846 の外観を図 2.2.4-3 に、また、その諸元を表 2.2.44 に示す。

図 2.2.4-3

IRU8846 外観（エリクソン社）

22

表 2.2.4-4

IRU8846 諸元

Dot 向けポート数8

フロントホール

2CPRI

大きさ

W445mm×D350mm×H67mm

重量

8.6Kg

消費電力

510W(AC)

電源種別

DC-48V
AC100VDot 向け線種

STP(F/FTP)ケーブル

Dot 向け線長制限

100m

SFP＋（2.5/4.9/9.8/10.1Gbps）

2.2.4.3 Dot4479 アンテナ
Dot4479 アンテナは、IRU8846 に最大 8 基まで接続でき、1 つのセルを構成できる。本
実証において使用した Dot アンテナの外観を図 2.2.4-4 に、また、その諸元を表 2.2.4-5 に示す。

図 2.2.4-4
表 2.2.4-5
周波数

小型 RU ユニットの外観
ローカル 5G アンテナの諸元
4.8-4.9Gz（Sub6）
4 送信／4 受信アンテナ本数
送信出力

4×125mW(4×21dBm)

サイズ

1.5L(W200mm*H53mm)

重量

1kg

冷却方式

自然空冷

最大スループット

2Gbps

23

2.2.5 ローカル 5G コアネットワーク装置
本実証において用いたローカル 5G コアネットワークシステムは、SA（Stand Alone）構成に対応した 5G コア（5GC）ソフトウェアを実装した、IA サーバ（Dell 社製 VEP4600）
2 台で構成される。その外観を図 2.2.5-1 に、また、その主な諸元を表 2.2.5-1 に示す

図 2.2.5-1

5G コア装置外観（DELL 社製

表 2.2.5-1
サイズ

VEP4600）

5G コア装置の諸元
W434*D381*H44mm

重量7.43kg

電源100～240 V AC, 50/60 Hz

電源ﾕﾆｯﾄ311W (MAX)

冗長性

active + hot-standby

サーバ機種

DELL/EMC VEP 4600

動作温度

0～+45℃

本実証では設置場所の制限があったため、複数のロケーションに分けて装置を設置した。使用したローカル 5G システム装置の配置図を図 2.2.5-1 に示す。

図 2.2.5-1 ローカル 5G 機器配置図

24

2.2.6 その他付随する装置
2.2.6.1 時刻同期用 GNSS ユニット
時刻同期用 GNSS は、3GPP で定められた 5G システムの時刻整合要件を満たすために、
GNSS より受信する時刻情報を Baseband6630 に配信するシステムであり、GNSS アンテ
ナと GNSS 受信機で構成される。屋内では衛星を補足できないため、屋外の南向き壁面に設置した。GNSS アンテナと接続する GNSS 受信機は、非常に小型な装置のため、機械室のラック内に収容した。
GNSS アンテナ及び GNSS 受信機の外観を図 2.2.6-1 及び図に、諸元を表 2.2.6-1 に示す。

図 2.2.6-1

GNSS Sync Kit (エリクソン社製)※GNSS 受信機の画像は拡大したもの

製品

表 2.2.6-1 GNSS アンテナ,レシーバの諸元
サイズ
周波数帯

重量

GNSS アンテナ

Φ77*74mm

1559Mhzto1610.5MHz

0.3kg

GNSS レシーバ

H30*W36.4*L96

同上

113g

25

図 2.2.6-2

設置された GNSS Sync Kit (エリクソン社製)

26

2.2.6.2 無停電電源ユニット（UPS）
5GC は DELL サーバを使用しているため機器の保護を目的として無停電電源ユニット
UPS を導入した。本実証で使用した無停電電源ユニットの（UPS）の外観を図 2.2.6-3 に、またその諸元を表 2.2.6-2 に示す。

図 2.2.6-3

無停電電源装置（UPSS-15A3-010RM）の外観

表 2.2.6-2

UPS の諸元

運転方式

常時インバータ方式

筐体

ラックマウント方式

最大出力容量(W)1200W

最大出力容量(VA)

1500VA

交流入力

単相 2 線／100V

入力形状

NEMA 5-15P

サイズ

W435*D488*H86mm(2U)

重量

29kg

27

2.2.6.3 JUNIPER NETWORKS EX2300-C（L3SW）
5GC サーバ側で VRRP（冗長化プロトコル）を使用するため、それに対応した製品を選定した。本実証で使用した EX2300-C（L3SW）の外観を図 2.2.6-4 に、またその諸元を表
2.2.6-3 に示す。

図 2.2.6-4 EX2300-C の外観

電力(AC)
10G SFP+対応有無
サイズ
重量
動作時温度範囲

表 2.2.6-3 EX2300-C の諸元
40W
2 ポート
W279×D239×H44(1U)
2.48kg0～40℃

28

2.2.7 ローカル 5G 端末
本実証では、ローカル 5Ｇ端末として Palcom 社製の Raku Plus を 3 台使用した。Raku
Plus の外観を図 2.2 7-1 に、Raku Plus の設置状況を図 2.2.7-2 に、その諸元を表 2.2.7-1に示す。

図 2.2.7-1

Palcom Raku Plus の外観

29

図 2.2.7-2

表 2.2.7-1

Raku Plus の設置状況

RAKU Plus の諸元
物理要件

サイズ

119 x 72 x 23.5 mm

重さ

235g
SIM

SIM card type

Nano SIM
対応周波数

L5G Sub6

n79
Connectivity

USB
USB data rate(理論値)

USB 3.1 Gen2,
10GbpsUSB Connector Type
Ethernet
Data rate

USB-Type C
RJ45
1000BASE-T
Wi-Fi

Wi-Fi 規格

802.11 a/b/g/n/ac/ax

周波数2.4/5.0GHz

最大同時接続数

32
環境条件

動作温度

-10℃ to 45℃

動作湿度

5% to 95%30

2.2.8 システム構成
羽田空港第 1・第 2 ターミナル駅に無線アンテナを置局し、羽田空港第 3 ターミナル駅に、無線制御部とローカル 5G 制御部を設置し、クラウド基盤は NTT ドコモ社が提供するキャリア網内プラットフォームである「ドコモオープンイノベーションクラウド（以下、dOIC）」を使用するネットワークを今回の課題実証システム用として構築した。構築した車両検査の遠隔・自動監視システムの全体イメージを図 2.2.8-1 に、システム構成を図 2.2.82 に、また、システム構築に使用した機器一覧を表 2.2.8-1 に示す。

図 2.2.8-1

車両検査の遠隔・自動監視システムの全体イメージ図31

図 2.2.8-2

車両検査の遠隔・自動監視システム構成

32

表 2.2.8-1
機器等名

車両検査の遠隔・自動監視システム構築に使用した機器及び数量
機能・役割
数量

車両検査用フル HD カメ

ホーム発着時、走行車両の台車状態をフル HD カメラ

ラ

で撮影

Poe インジェクタ

カメラに LAN ケーブルで給電する

ホーム発着時、走行車両の台車状態をフル HD カメラ

照度補完用ライトで撮影する際に、照度の不足を補う
上記カメラ映像を適切な映像フォーマットにエンコー

GPU 搭載ノート PC

ドし、AI 解析基盤へ配信

保守用ノート PC

ローカル 5G 機器及びローカル 5G 端末の保守用 PC

ローカル 5G 端末（ルーローカル 5G を利用し、AI 解析基盤へ広帯域なアップ

タ機材）

ロード通信を行う

防水防塵 BOX

機材の故障を防ぐ
ローカル 5G を利用可能なこと。4.7GHz 帯の 4.8-

ローカル 5G 基地局

4.9GHz（100MHz）のローカル 5Ｇ電波を射出
各システムを構成する IaaS クラウド基盤

クラウド基盤

実証拠点からクラウド基盤外部接続用 DC 間を VPN

VPN ルータ

接続するためのルータ機器

3
3

6
3
1

3
3
1
1
2

現地実証環境からの映像配信を受信し、遠隔監視室と想定する試験室の PC・検査作業員が持つタブレット

映像受配信システム

1

へ映像をストリーミング配信
列車検査用映像 AI 解析

車両台車の状態を AI 解析し、異常等を検出

エンジン

検出座標データの配信、AI 解析結果録画データの配映像配信サーバ

信

AI 結果表示 PC・タブレ

AI 解析結果をリアルタイム表示、解析結果録画の表ット

示・確認するためのクライアント端末

2
1
1~3

▼車両検査用フル HD カメラ
上記の経緯のもと、車両検査用フル HD カメラ 3 台を京浜急行電鉄羽田空港第 1・第 2 ターミナル駅のホーム下に設置した。

図 2.2.8-3

車両検査用フル HD カメラ
33

表 2.2.8-2

スペック・概要（車両検査用フル HD カメラ）

カテゴリー

スペック

メーカー

JVCKENWOOD

型式

VN-U178WPR

カメラ部
撮像素子

1/2.3型裏面照射型CMOSセンサー

有効画素数

約1,240万画素、4072（水平）×3046（垂直）撮像面積

水平6.3mm x 垂直4.7mm

カラー撮像方式

単板原色ローリングシャッター方式

走査方式

プログレッシブスキャン

最低被写体照度

カラー：1.5lx、白黒：0.8lx（50％出力、AGC HIGH、電子シャッター1/60、電子感度アップ2倍）

ホワイトバランス

ATW-WIDE、ATW-NARROW、AWC

AGC

HIGH、MID、OFF

電子シャッターオート：最大・最小シャッター速度を設定、マニュアル：1/30～1/10000、フリッカレス

電子感度アップ

x2、x4、x8、x16、OFF

逆光補正（BLC）

エリア編集、OFF

ワイドダイナミックレンジ

アクティブガンマ方式（HIGH、MID、LOW、OFF）

映像レベル調整

カラー、ブラック、エンハンス

3次元ノイズリダクション

付（HIGH、MID、LOW、OFF）

デイ＆ナイト機能

IRカットフィルター可動式/赤外LED照明（照射距離25m）

画質改善機能コントラスト調整、白とび軽減

音声入出力

各1系統（入力時プラグインパワーマイク対応）

レンズ部
焦点距離（倍率）

4.5～10mm（約2.2倍）

最大口径比

F1.6

包括角度（水平×垂直）

82°×44°（WIDE端）～35°×21°（TELE端）

撮像角度調整パン：±175°、チルト：0°～90°、ローテーション：±95°

フォーカス/ズーム調整

電動（遠隔操作可）

ネットワーク部
インターフェース
通信プロトコルRJ-45、10BASE-T/100BASE-TX
IPv4、IPv6、HTTP、TCP、UDP、FTP、RTP、RTSP、RTCP、SMTP、

標準化プロトコル

DHCP、SNTP、SNMP v1/v2c/v3、ICMP、IGMP、DNS、DDNS、ARP
ONVIF profile S

画像圧縮方式H.264（Main/High profile）/JPEG

画像サイズ

3840×2160、1920×1080、1280×960、1280×720、640×480、640×360、320×240

画像圧縮設定H.264：VBR/CBR（ビットレート設定128Kbps～12Mbps）、JPEG：VFS（クオリティ設定可）

フレームレート

最大30fps（3840×2160）

音声圧縮方式G.711（μ-Law）

音声ファイル再生機能

WAVEファイル（リニアPCM、8kHz、16bit、モノラル）

配信方式

ユニキャスト/マルチキャスト

ビューワー

Webブラウザ（Internet Explorer 11）

接続クライアント数

最大10（エンコーダCHあたり最大8）最大配信ビットレート

ビットレート合計40Mbps未満

ローカル記録機能

H.264（プリ7秒/ポスト60秒、アラーム、連続）、Webブラウザによる再生、ダウンロード可能

FTP映像送出機能

JPEG、640×360、毎秒1枚（ポスト記録60秒、アラーム記録、連続記録）

デジタルPTZ機能

エンコーダ2～4で切出しサイズを指定、エンコーダあたりプリセットポジション×10登録可
OS：Windows 10（64ビット/Pro）/8.1（32/64ビット）/7（SP1）、制御PC仕様CPU：Intel Core i5-3570 3.40GHz以上、
メモリー：4GB以上、HDD空き容量512MB以上、
画面解像度＊：1920×1080ピクセル以上、True Color（4K解像度対応）

総合部
電源

DC12V、DC-48V（PoE：IEEE802.3af）

消費電流/電力

1050mA/12.6W（DC12V）、265mA/12.95W（PoE）

周囲温度－40℃～50℃(PoE時）、－30℃～50℃(DC12V時）、－30℃～40℃（推奨）※起動時は－10℃以上

周囲湿度

10％RH～90％RH（結露なきこと）

防塵防水性能IP66準拠（JIS C 0920）

外形寸法（W×H×D）

101×86×258mm（突起物含まず）

質量約1.2kg34

▼PoE インジェクタ
PoE インジェクタ 3 台を京浜急行電鉄羽田空港第 1・第 2 ターミナル駅のホーム下に設置した。

図 2.2.8-4

表 2.2.8-3

PoE インジェクタ

スペック・概要（PoE インジェクタ）

カテゴリー

スペック

メーカー

APRESIA

型式

APLIJ1GPOEPLUS

仕様概要
Interface

PoE

10BASE-T/100BASE-TX-

10BASE-T/100BASE-TX/1000BASE-T

2

PoE給電ポート数

1

15.4Wフル給電ポート数-

30Wフル給電ポート数

1

給電電力

30.0W

サイズW (mm)80

サイズD (mm)165

サイズH (mm)※

45.5

概算質量

0.6kg以下
最大1W/平均1W(PoE給電なし)

消費電力(AC100V時)
ハードウェア

最大37W/平均34W(PoEフル給電)

動作温度

0～50℃
100～120V±10%

AC電源対応200～240V±10%(50/60Hz)

騒音特性— (FANレス)

FANレス対応○

MTBF(本体のみ)

414年

35

▼照度補完用ライト
ホーム発着時、走行車両の台車状態を車両検査用フル HD カメラで撮影する際に、照度の不足を補うため、カメラの左右に 2 か所、照度保管用ライトを設置した。

図 2.2.8-5
表 2.2.8-4

照度補完用ライト

スペック・概要（照度補完用ライト）

カテゴリー

スペック

メーカー

GOODGOODS

型式

LDJ-100M

仕様概要
消費電力

100W

入力電圧

AC85V～265V

周波数50/60Hz兼用

全光束

約14040lm(光源の値に準ずる)

ランプ効率

140.4lm/W

発光色

昼光色(6000K)

演色性

>Ra80

光源数

LEDチップ×90個

照射角度

40°

ステー調整角度

前後約180°C

使用温度-20°C～45°C

防水等級

IP66（生活防水）

コード

全長約2m

サイズ

W268*H310*D44.5 mm

パッケージサイズ

W307*H357*D97mm

質量約2.8kg材質

アルミニウム合金 ＋ 強化ガラス

36

図 2.2.8-6

車両検査用フル HD カメラ、照度保管用ライトの設置した様子▼GPU 搭載ノート PC
カメラ映像を dOIC 上の映像受配信システムに送信する機能を持つ GPU 搭載ノート PC
を、羽田空港第 3 ターミナル駅内の通信機械室に 3 台設置した。

図 2.2.8-7

GPU 搭載ノート PC37表 2.2.8-5

スペック・概要（GPU 搭載ノート PC）

カテゴリー

スペック

メーカー

ASUS

型式

GA401QM-R9R3060GQ512

仕様概要
カラー

エクリプスグレーOS

Windows 10 Home 64ビット ※1
CPU名：AMD Ryzen™ 9 5900HS プロセッサー

CPU

動作周波数 (標準/最大)：3.0GHz/4.6GHz
キャッシュメモリ：3次キャッシュ 16MB

メモリ容量

標準：16GB ※2
仕様：DDR4-3200
ディスプレイ：14型ワイドTFTカラー液晶
表面仕様：ノングレア
解像度：2,560×1,440ドット (WQHD) (120Hz)

表示機能

タッチパネル：非搭載
グラフィックス機能：NVIDIA® GeForce RTX™ 3060
(NVIDIA® Optimus™ Technology対応)
ビデオメモリ：6GB ※3
外部ディスプレイ出力：最大3,840x2,160ドット ※4

記憶装置

SSD：512GB (PCI Express 3.0 x4接続) ※5
サウンド規格：ハイ・デフィニション・オーディオ準拠

サウンド

スピーカー：クアッドスピーカー内蔵 (1W×2、0.7W×2)
マイク：アレイマイク内蔵

センサー

指紋認証
LAN：-

通信

無線LAN：IEEE802.11a/b/g/n/ac/ax ※6
Bluetooth®機能：Bluetooth® 5.1

入力

キーボード：87キー日本語キーボード (イルミネートキーボード)
ポインティングデバイス：マルチタッチ・タッチパッド
外部ディスプレイ出力：HDMI×1

インターフェース

USBポート：USB3.2 (Type-C/Gen2) ※7 ×1、USB3.2 (Type-C/Gen2) ※8 ×1、USB3.2 (Type-A/Gen1)×2
カードリーダー：オーディオ：マイクロホン/ヘッドホン・コンボジャック×1

電源

ACアダプターまたはリチウムポリマーバッテリー (4セル)

バッテリー駆動時間

約11.3時間 ※9バッテリー充電時間

約1.9時間消費電力

消費電力：最大約180W

電源

エネルギー消費効率：12区分 34.1kWh/年 (68%) ※10サイズ

幅324mm×奥行き222mm×高さ17.9～18.9mm

質量約1.65kg

38▼防水防塵 BOX
京浜急行電鉄羽田空港第 1・第 2 ターミナル駅のホーム下にローカル 5G 端末を設置するにあたり、機材の故障を防ぐために防水防塵 BOX を合計 3 個設置し、防水防塵 BOX 1 つにつき 1 つのローカル 5G 端末を設置した。

図 2.2.8-8
表 2.2.8-6

防水防塵 BOX

スペック・概要（防水防塵 BOX）

カテゴリー

スペック

メーカー

河村電器産業型式

HP 4535-16RP

仕様概要
タテ：450mm
外形寸法

ヨコ：350mm
フカサ：160mm

基板寸法
色彩

タテ：395mm
ヨコ：301mm
ライトグレー（マンセル5GY8.5/0.5近似）

取付基板※ルーバーはベージュ（マンセル5Y7/1近似）
木製基板 12mm/方眼目盛付

材質

ボデー：PC樹脂（GF入り）、 ドア：PC樹脂

函体形式

屋内外兼用 露出形

構造

ルーバー付 換気ファン付（100V）

保護構造

IP55

ドア形式

片扉

重量

3.6kg

▼VPN ルータ
実証拠点からクラウド基盤外部接続用 DC 間を VPN 接続するため、羽田空港第 3 ターミナル駅内の機械室、および外接 DC の 2 か所に VPN ルータを設置した。

図 2.2.8-9

VPN ルータ39

表 2.2.8-7
カテゴリー

スペック

メーカー

YAMAHA

型式

RTX1220

スペック・概要（VPN ルータ）

インターフェース
LANポート3ポート（10BASE-T/100BASE-TX/1000BASE-T, ストレート/クロス自動判別）※LAN1ポートは8ポートL2スイッチ

WANポート

任意のLANポートを利用可能

ISDN Uポート‐

ISDN S/Tポート‐

PRIポート‐LINEポート‐

TELポート‐microSDスロット

1スロット(SDHC対応)

USBポート1ポート（USB 2.0 Type-A, 給電電流:最大500mA, USBメモリ/USBデータ通信端末に対応） (※2)

コンソールポート(設定用)

1ポート(RJ-45, 9,600/19,200/38,400/57,600/115,200 bit/s) (※3)

拡張スロット‐メモリ
Flash ROM

32MB（ファームウェア：2組, コンフィグ：5組/履歴機能あり）

RAM

256MB

性能
内蔵L2スイッチ機能

ポート分離, LAN分割（ポートベースVLAN）, ポートミラーリング, リンクアグリゲーション（冗長化のみ）

閉域網サービス用機能

タグVLAN, IPv6マルチキャスト（MLDv1, MLDv2, MLDプロキシ）

タグVLAN（IEEE 802.1Q）

LANごとに32ID, PPPoE over タグVLAN

PPPoEセッション数40

対応回線およびサービス網 (※1)
対応回線およびサービス網 (※1)

FTTH（光ファイバー）, ADSL, CATV, ATM回線, IP-VPN網, 広域イーサネット網, 携帯電話網, フレッツ・サー
ビス,

IPv6接続形式
IPv6接続形式

ネイティブ, トンネル, デュアルスタック, RAプロキシ, DHCPv6-PD, IPv6 PPPoE

WANプロトコル
WANプロトコル

PPPoE

ルーティングルーティング対象プロトコル

IP, IPv6

IPルーティングプロトコル

RIP, RIP2, OSPF, BGP4(EBGP, IBGP)

IPv6ルーティングプロトコル

RIPng, OSPFv3

経路エントリー数

最大10,000 (※4)

OSPFネイバー数とその経路

30ネイバーの時:経路数8,000 (※4)

BGP4経路数

最大10,000 (※4)

データ圧縮
データ圧縮

IPComp, CCP（Stac LZS）, VJC

スループット
スループット

最大2.0Gbit/s (※5)

IPsecスループット

最大1.5Gbit/s (※6)

VPN対地数VPN対地数（PPTP）

4

VPN対地数（IPsec）

100

VPN対地数（L2TP/IPsec）

100

VPN対地数（L2TPv3）

9

VPN対地数（最大設定可能数）

100 (※7)

VPN機能
IPsec（VPN機能：NATトラバーサル, XAUTH）＋AES128/256, 3DES, DES(暗号機能：ハードウェア処理)+
VPN機能

IKE/IKEv2(メインモード, アグレッシブモード), PPTP（VPN機能）＋RC4（暗号機能）(※8), L2TP/IPsec, L2TPv3, L2TPv3/IPsec, IPIPトンネル, マルチポイントトンネル（サーバー/クライアン

NAT
アドレス変換機能（NATディスクリプター機能）
NATセッション数

NAT, IPマスカレード, 静的NAT, 静的IPマスカレード, DMZホスト機能, PPTPパススルー（複数セッション）(※9), IPsecパススルー（1セッション）, FTP対応, traceroute対応, ping対応, SIP-NAT対応(※10), IPマスカレード変換セッション数制限機能, ポートセービングIPマスカレード
65534

QoS
QoS機能（制御方式）

優先制御, 帯域制御（Dynamic Traffic Control）, Dynamic Class Control, VPN QoS(※11), 帯域検出機能, 負荷通知機能

QoS機能（分類方式）

IPアドレス, プロトコル, ポート番号, ToSフィールド

QoS機能（網側QoS機能との連携）

Diffserv, カラーリング（ToS）, ToS→CoS変換

セキュリティー
認証機能
セキュリティー機能

RADIUS, PAP/CHAP, MS-CHAP/MS-CHAPv2
URLフィルター（内部データベース参照型）, DHCP端末認証機能, Winnyフィルター（Winny Version2 対応）,
Shareフィルター（Share バージョン1.0 EX2対応）, MACアドレスフィルター

ファイアウォール機能

IPアドレス, ポート, プロトコル (Established, TCPフラグ有り), FQDN(IPv4のみ),（IPv4/IPv6静的フィルタリング）

ソース/デスティネーション, LAN側/WAN側のIN/OUTに適用

ファイアウォール機能

基本アプリケーション（TCP, UDP）, 応用アプリケーション（FTP, TFTP, DNS, WWW, SMTP, POP3,（IPv4/IPv6動的フィルタリング）

TELNET）,

動的フィルターセッション数

65534

ファイアウォール機能

LAN側/WAN側のIN/OUTに適用, IPヘッダー, IPオプションヘッダー, ICMP/UDP/TCP/FTPなどのカテゴリで（IDS：IPv4不正アクセス検知）

41種の不正アクセスを検出可能, 不正アクセス検知メール通知機能

ハードウェア
状態表示ランプ

前面：26（POWER, ALARM, STATUS, LAN［LINK×10, SPEED×10］, microSD, USB, DOWNLOAD）, 背面：0

動作環境条件周囲温度0～45℃, 周囲湿度15～80%(結露しないこと)

電源

AC100～240V（50/60Hz）, 電源内蔵, 電源インレット(3極コネクター, C14タイプ), 電源スイッチ

最大消費電力(皮相電力)、最大消費電流、発熱量
14.5W(28VA), 0.28A, 52.2kJ/h
筐体内温度測定

温度計内蔵（コマンドで確認, SNMPによる取得, 閾値設定によるSNMPトラップ, ALARM LEDによる警告）筐体

金属筐体, ファンレス, セキュリティースロット(ケンジントンロック用)

電波障害規格、環境負荷物質管理

VCCIクラスA, RoHS対応

外形寸法

220（W）×42（H）×239（D）mm （ケーブル, 端子類は含まず）

質量(付属品含まず)

1.5kg

40

2.3 システム機能・性能・要件
2.3.1 ローカル 5G ネットワーク
本実証において構築したローカル 5G ネットワークの性能を以下に記載する。

2.3.1.1 同時接続数
同時接続数は Baseband あたりの単位として定義され、RRC connected users として、最大 1000 ユーザが接続可能である。
2.3.1.2 最大スループット
ダウンリンク：1.5Gbps (Single user peak rate, 4 layers, 100MHz BW, 256QAM)
アップリンク： 86Mbps (Single user peak rate, 1 layer, 64QAM)
2.3.1.3 無線局数
IRU = 1 セクタ、最大 6 IRU まで接続可能（1 セクタ ＝ 8 Dots / IRU 構成）である。本実証においては、1 基地局 1 セクタとしてアンテナ 3 台を使用した。
2.3.1.4 品質
エリクソン・ジャパン株式会社では、Ericsson Private 5G の機器において、Business Area
Technologies & New Businesses (BTEB) 、 Dedicated Networks 部 Technology andDevelopment チームにて、製品開発に加え機能仕様確認試験、サービススペック試験を含めた、総合試験を一貫して行っている。この体制により、対象製品の性能、品質を担保し、安定、高品質のサービスを提供している。
また、実証に用いる測定機材については、校正証明書を添付の上、実証試験前に測定系の構築及び事前測定を実施する。

41

2.3.2 車両検査の遠隔・自動監視システム
2.3.2.1 使用した機器及びソフトウェア
本実証における車両検査の遠隔・自動監視システム構築に使用した各種機器及びソフトウェアの機能・性能・要件は表 2.3.2-1 に示すとおりである。

42

表 2.3.2-1

車両検査の遠隔・自動監視システム構築に使用した機材の機能・性能・要件
（1/2）

機器等名

使用機材

機能・性能・要件

車両検査用フルHD カメラ

VN-U178WPR

・4K、FHD の解像度で撮影できる機能を有していること。
・有線で UE と接続できるインターフェースを有していること。
・防塵防水対応であること。
・シャッタースピードを任意に変更可能であること。

車両映像配信用PC

DELL
ALIENWARE
M15 R3 プレミアム・webRTC にエンコード変換可能な性能を有する
GPU ボードを搭載していること。
・19 インチラック内へ収容するために可能な限り
コンパクトなサイズであること。

ローカル 5G 端末（ルータ機材）Compal RAKU Plus・アップロード時最大 1.6Gbps の機能を有している。
・ダウンロード時最大 7.53Gbps の機能を有している。
・有線 LAN(1000BASE-T)を有しており車両検査用フル HD カメラと LAN で接続が可能である。
・Wi-Fi 規格、IEEE802.11a,b,g,n,ac,ax に対応している。

ローカル 5G 基地
局

エリクソン・ジャパン

・ローカル 5G を利用可能なこと。4.7GHz 帯の 4.84.9GHz（100MHz）のローカル 5G 電波を射出

NTT ドコモドコモオープン
イノベーション
クラウド

・必要コンピューティングリソースの提供が可能であること。
・GPU インスタンスが多数準備可能であること。
・ローカル 5G スポットと閉域網接続可能なクラウド基盤であること。
・令和 2 年度実証において構築・動作実績のある基盤であること。

VPN ルータ・VPN 機能を有すること。
・VPN スループットが 100Mbps 以上確保できること。
・GigabitEthernet 対応のポートを具備していること。

クラウド基盤

VPN ルータ43表 2.3.2-1

車両検査の遠隔・自動監視システム構築に使用した機材の機能・性能・要件
（2/2）

機器等名

映像受配信システ
ム

列車検査用映像
AI 解析エンジン

映像配信サーバ

AI 結果表示 PC・
タブレット

使用機材

機能・性能・要件

時 雨 堂 WebRTCSFU Sora

・GPU 搭載ノート PC へ搭載する WebRTC クラ
イアントから AI 解析システムへ映像送信可能である。
・映像を WebRTC SFU サーバ経由で配信元に代わってストリーミング配信が可能である。
・多地点からの要求に対し、WebRTC SFU サーバ経由で配信元に代わって配信が可能なシステム構成である。
・一般的な配信において高ビットレートでの配信
時、映像の解像度が引き下げられてしまう場合があるが、株式会社時雨堂が提供する WebRTC
SFU sora は、クライアントに対し上限値を引き上げるように通知することで解像度を担保した
映像配信が可能である。

・高精度映像異常
検出エンジン
・NVIDIA Quadro
P5000*8・フル HD 映像を AI 解析し、異常箇所を特定した
座標情報をリアルタイムに出力することで検出
座標データ配信を行う。
・AI 解析結果映像をクラウド上の録画ストレージへ保存することで、後からでも映像再生可能とする。

Web サーバ・リアルタイム映像と AI 解析した結果の異常位置を示すバウンディングボックス等を合成可能な状態でクライアントに配信することで、低遅延で配信可能である。
・また、AI 解析した結果の異常位置を示すバウン
ディングボックス等のデータは、映像配信サーバに MQTT ブローカーを配置してクライアントに配信することで、高頻度で配信可能である。
・映像配信サーバに録画映像のデータベースおよび Web サーバを配置し、Web サーバから AI 解析結果をファイル形式で配信することで映像配信可能である。

・ノート PC・タブレット・Chrome ブラウザが動作可能な端末であり、http
アクセスにより Web サーバへ接続することで配信要求と解析結果の表示が可能である。
・高性能グラフィック処理基盤を搭載していること。
・有線 LAN を有しており、ルータ機材と LAN で接続可能であること。

44

2.3.2.2 車両検査用フル HD カメラ選定に至る経緯及び同カメラに関する機能・性能・要件
本実証において、京浜急行電鉄羽田空港第 1・第 2 ターミナル駅の線路内に入線する列車の台車部分をカメラで撮影する構成となっている。
京浜急行電鉄羽田空港第 1・第 2 ターミナル駅の線路内への設置にあたり、長期安定運用に耐え、建築限界を超えないカメラが必要となる。建築限界とは、線路の周辺に物体を設置する場合、安全のために線路から定められた範囲内には物体を設置してはいけないというものである。
また、速度のある対象物体を撮影するためには、シャッタースピードを上げて画像のブレを少なくする必要があった。一方で、シャッタースピードを上げると映像が暗くなるという現象が起きるため、ライトで照度を補う必要がある。
事前に机上及び実地検証を実施した上で、必要とされる機能・性能・要件に適合する機器を選定した。
（1）カメラ
車両検査用フル HD カメラの選定について、実装を踏まえ比較的安価に購入可能なこと、駅に設置するため防水防塵対応であることなどを前提に選定を行った。下記の 3 機種を候補として選定し、比較検証を行うことにより VN-U178WPR を使用することとした。
表 2.3.2-2
カメラ（型番）

メーカ

車両検査用フル HD カメラ候補の比較
利点

欠点

総評

VN-U178WPR

JVC

・即納可
・防水防塵対応

筐体の奥行きが大きく、設置時に建築限界を超える可能性〇
防水防塵対応、即納可のため

P3248-LVE

Axis

・ドーム型のため筐体の奥行きが小さく、設置
時の建築限界に左右されない・防水防塵対応

納期 3 か月・撮影
画像が魚眼レンズのような映り方×
納期 3 か月で検証
時期に間に合わ
ないため

α7sⅢ

SONY

・シャッタースピ
ードなど、パラ
メータを柔軟に調節可

・納期未定
・防水防塵非対応

×防水防塵非対応、
納期未定のため

夜間の終車後に羽田空港第 1・第 2 ターミナル駅

1 番線の線路内に立ち入り、カメラの設置に関する建築限界の確認を実施した。図面での確認は困難なことから、現地にてカメラを設置する場所の確認と併せて、設置するカメラ筐体の大きさが建築限界に干渉しないかどうかを確認した。

45

図 2.3.2-1

カメラ設置に関する建築限界確認の結果

羽田空港第 1・第 2 ターミナル駅

1 番線の線路内で確認した結果、筐体の大きさから建築限界との干渉が懸念された VN-U178WPR でも問題なく設置可能なことが確認できたた
め、VN-U178WPR を使用することとした。

46

（2）車両検査用フル HD 映像撮影のためのパラメータ決定のための事前検証
どの程度シャッタースピードを上げ、どの程度の明るさのライトが必要となるか、実際に入線する速度で走行する列車を撮影し検証することが望ましいが、暗い環境において時速30km 程度で列車を走行させ撮影可能な環境がなかったため、日没後に、NTT ドコモの柏の葉テストフィールドで自動車を走行させ、撮影することで検証を行った。

図 2.3.2-2

シャッタースピードの比較

図 2.3.2-2 の左側がシャッタースピードを 1/1000 に設定した時の画像、右側が 1/4000 に設定した時の画像である。1/1000 の時はタイヤのホイールがぶれているが、1/4000 ではタ
イヤのホイールや、その周辺も比較的はっきりと映っていた。この結果により、シャッター
スピードは 1/4000 とした。
またこの時、カメラからタイヤまで 1m、撮影対象の中心で照度は 2200lx 程度 であったが、タイヤのホイール周辺部分は暗く映っており、電車の台車に置き換えたときにき裂を検出するためには照度が不足する恐れがある。
この結果を踏まえ、机上検討も行った結果、ライトの照度は 10,000lm 以上必要であることがわかった。

47

（3）ライト
柏の葉のテストコースにおける事前検証及び机上検討の結果から、ライトに必要な要件は下記のとおりであることが判明した。
 設置場所となる羽田空港第 1・第 2 ターミナル駅は定期的に夜間停電が起こるため、
物理スイッチで点灯させる必要がなく、通電させることで点灯すること。
 10,000lm 以上あること。
 屋外設置可能なものであること。
下記の 2 機種を候補として選定し、比較検証を行うことにより LDJ-100M を使用することとした。
比較対象の LD-F60W は、全光束が約 10200lm で必要と想定した光量を満たしているが、検証を実施したところ、照射角度が 120 度と広いため、光量が分散され撮影対象範囲が暗く写ることがわかった。一方で LDJ-100M は全光束が約 14040lm、照射角度が 40 度で、検証にて撮影対象範囲の光量が十分であることが確認された。

ライト型番
GoodGoods
LD-F60W
GoodGoods
LDJ-100M

表 2.3.2-3 照度補完のためのライト候補の比較
メーカ
特徴
グッド・グッズ
全光束 約 10200lm
照射角度 120 度
防水等級 IP66
グッド・グッズ
全光束 約 14040lm
照射角度 40 度
防水等級 IP66

図 2.3.2-3

LDJ-100M の検証風景（事前検証における撮影条件）
 4K15fps、FHD20fps。共に 4000 分の 1 シャッタースピード 光量としては画角中心部で 14,000 ルクス
 カメラ～被写体の距離：1300mm

48

総評
× 照射角度が広く、撮影対象範
囲が暗い。
〇 屋外設置可能。照射角度が広く、撮影対象範囲の光量十分。

一方で、図 2.3.2-3 のように、フリッカーが生じることが判明したが、AI 解析に影響があるかを確認し、選定することとした。
後述する令和 2 年度京浜急行電鉄久里浜工場における教師データ撮影時の映像を用いて、フリッカーが生じることで AI 解析に影響があるかを検証した結果、AI 解析に大きな影響がないことが確認されたため、LDJ-100M を選定することとした。

49

2.3.2.3 車両検査の遠隔・自動監視システムに関する機能・性能・要件（1）システム要件
車両検査の遠隔・自動監視システム（以降、2.3.2.3 項では本システムと記載する）を構
築するにあたり、運用コスト並びに既存業務への組み込み、言わば本システムと人による業
務とのマッチングを考慮した実運用に資するシステム要件を京浜急行電鉄との協議に基づき定義し、システムを検討・構築した。
運用コストを考慮したサーバスペックの選定
本システムはドコモオープンイノベーションクラウド「dOIC」（2.3.2.4 項に詳細記載）
上に構築した。システム運用における dOIC のイニシャルコスト及びランニングコストを長期利用を前提に鑑みて、利用するクラウド基盤やサーバスペックを選定した。dOIC の機
能及び性能に関しては後述 2.3.2.4 にて詳細を記載する。

運用に資するシステム処理時間の定義
羽田空港第 1・第 2 ターミナル駅（以降、2.3.2.3 項では京急羽田 1T2T 駅と記載する）1番線ホームにて、運行中の列車車両の異常を検出する今回の実証環境においては、車両の入線完了～出線完了および出線完了～入線完了までの時間枠でシステムの処理を終えなければ処理が積み上がってしまい、システムが異常情報をアウトプットするまでの処理遅延が次々と蓄積されることとなる。そのため京急羽田 1T2T 駅 1 番線の運行スケジュールに則り、車両の入線～出線、および出線～入線までの、AI 解析の対象とならない時間の最短である 2 分間で、映像伝送、AI 解析、録画映像の配信処理などを含むシステム処理を完了させる必要がある。このため、時刻表上の列車発着時刻から本システムで車両の異常情報をア
ウトプットする（ユーザが確認可能な状態とする）までのシステム処理時間の目安を 2 分
以内として設計した。なお、サーバ処理遅延の蓄積を回避することを目標としたため、ユー
ザが監視画面で映像を閲覧する下り通信の時間は 2 分間には含まない。
本実証では長期利用を前提にしたシステム設計であることから、イニシャルコストおよびランニングコストを抑えるため、サーバスペックを抑えた設計としたが、机上計算では録画映像を配信する処理のために約 1 分間、AI 解析処理等に、約 1 分間要することが判明した。このため、ローカル 5G により短時間で安定した映像伝送を行えることを前提に、録画映像の配信処理、および AI 解析処理を短縮する工夫により、システム処理時間 2 分間を達成できるような設計を行った。AI 解析処理における工夫及び検討内容は後述 2.3.2.3(5)にて記載する。
ユーザの検出結果の確認手段は UI 画面（Web ページ）とし、AI 解析結果は異常種別及び箇所をバウンディングボックス表示し、録画映像に重畳させて表示した。リアルタイム映像に重畳させることも検討したが、机上計算において AI 解析処理等に約 1 分間要することが判明したことにより、その間カメラからの映像を AI 解析処理等が完了するまでディレイさせておく必要がある。しかしディレイする仕組みは映像を受信および配信する WebRTC
50

サーバにて実現可能だが WebRTC の制約として最大 40 秒しかディレイさせることができないことが判明したため、録画映像への重畳に至った。
（2）全体構成図
京急羽田 1T2T 駅 1 番線ホーム下に固定設置された 3 台のフル HD カメラにより撮影した、入線/出線の走行車両台車のフル HD 映像をもとに、台車き裂等の異常をリアルタイム
で AI 解析し、検出結果の座標データを配信した。UI コンテンツを内包する映像配信サーバ（Web サーバ）にて、取得した映像上に時刻同期した検出座標データを重畳させ、バウ
ンディングボックスとして表示させた。
カメラ映像より車両の入線/出線及び車両の停止を判定するロジックを設け、車両の映っていない時間帯や車両停止時は台車異常検出の AI 解析処理を稼働させないこととした。
実証フィールド・拠点と本システムを図示した全体構成図を以下に記載する。

図 2.3.2-4

全体構成図

51

（3）ネットワーク構成図
実証フィールド・拠点と本システムを図示したネットワーク構成図を以下に記載する。

図 2.3.2-5

ネットワーク構成図52

（4）駅からのカメラ映像を受配信する機能
リアルタイム映像の配信
京急羽田 1T2T 駅 1 番線ホームに設置した 3 台のカメラ（ネットワークカメラ）のリア
ルタイム映像を L5G 通信により、それぞれ羽田空港第 3 ターミナル駅に配置した GPU 搭
載ノート PC へ送信する。各 GPU 搭載ノート PC にて「WebRTC Native Client Momo」
を用いて、映像にタイムスタンプを付与しクラウド側の WebRTC インスタンスに送信する。
WebRTC インスタンス上の「WebRTC SFU Sora」を用いて、受信したリアルタイム映像の配信を行う。2.3.2.3.(6)にて後述するが、映像を閲覧する UI 機能によりブラウザ経由
で WebRTC インスタンスが配信するリアルタイム映像を閲覧する。

図 2.3.2-6

リアルタイム映像配信イメージ

53

録画映像の配信
WebRTC インスタンスにて受信したリアルタイム映像を特定時間で分割して録画共有イ
ンスタンスに録画ファイルとして保存する。録画ファイルの生成が完了したタイミングで
Web サーバインスタンスにファイルを取り込み、並行して実行する AI 解析処理の結果情報（検出対象物、異常検出箇所を示す矩形座標情報）と録画ファイルを紐づける。2.3.2.3.(6)にて後述するが、映像を閲覧する UI 機能によりブラウザ経由で AI 解析結果付きの録画映像にアクセスする。

図 2.3.2-7

録画映像配信イメージ

録画は京急羽田 1T2T 駅 1 番線の列車運行スケジュールに則り算出した各列車の入線時
刻と出線時刻を起点として、それぞれ前後 55 秒（計 1 分 50 秒）の長さとした。
運行スケジュールに則した録画開始/終了スケジュールをシステム側でセットしておき、それに沿って録画処理を実行させた。
ここで、配信するカメラ映像の品質やデータアップロード速度、それに付随する検討背景について以下に記載する。
項目
映像品質

データアップロード
速度

表 2.3.2-4 配信する映像品質と検討背景
実測・実施内容
検討背景
運行中の列車車両に対して撮影及び解析
FullHD 30FPS（L5G 通信区間）を行うに当たり、設置カメラと車両との間隔が 50cm 程度かつ入線時は 30～
40km/h の速度で過ぎ去る車両の台車部を捉えるためには、フレーム間の抜け漏れを防ぐためにフレームレートの高さを確保し、画質は FullHD とした。
上記の「映像品質」項目で記載の FullHD
36Mbps（FullHD 12Mbps × 3） 30FPS のデータ伝送に必要な帯域は約5436Mbps となった。今後、列車を両側面から監視することや、カメラ設置制限のあるホームの場合にカメラ台数を増やしてカバーして工夫する等、総じてカメラ
台数の少なさに起因する異常検出漏れを防ぐためのカメラ設置数の増大及び必要性の見込みは十分に考えられる。その場合、本システムへのインプットデータが増大することから、システム要件であった「システム処理時間 2 分以内」の達成を想定した場合に、アップロード帯域不足によるネットワークのボトルネックが発生する可能性を避けるため L5G に用いた帯域確保は必要となる。

（カメラ-クラウド）

録画ファイル時間

1 回分の録画ファイルの長さは 1 分 50 秒

55

録画ファイルは列車運行スケジュールから算出した入線時刻、出線時刻を起点として、それぞれの前後 55 秒（計 1 分 50秒）の長さとした。これは列車運行の入線/出線の時刻を実測した結果、多少の時刻誤差を許容可能な間隔、かつ録画処理の終了から録画ファイルを UI 機能にて確認可能な状態にするまでのリードタイ
ムを考慮した上で「システム処理時間 2分以内」を満たすことができる設定値である。

（5）映像を AI 解析する機能
全体概要図
AI 解析機能の全体概要図を以下に記載する。

図 2.3.2-8

AI 解析機能56

全体概要図

車両有無の判定
流れてくる映像から「列車が走行している状態」を判定し、結果を返却するアルゴリズムを導入した。
当初、列車走行状態を加味せずに、受診映像を全て AI 解析したところ、AI 解析処理は追いつかず、処理遅延が蓄積し、「システム処理時間 2 分以内」という要件を満たすことができなかった。検討を重ね、"入線時"・"出線時"のみを判定・解析を可能にする本判定アルゴ
リズムを開発・導入することで、限られたリソースを有効に活用し、最終的にはシステムの処理遅延時間の要件を達成した。
本判定アルゴリズムの概要を以下に記載する。

図 2.3.2-9

判定アルゴリズムの概要（1/2）

57図 2.3.2-10

図 2.3.2-11

判定アルゴリズムの概要（2/2）

判定アルゴリズムの処理内容（参考）58車両異常の検出
列車走行状態の判定結果に基づき後続の処理が「画像保存処理」「AI 解析処理処理」のいずれかに振り分けられる。
「画像保存処理」とは、WebRTC インスタンスから受信する映像（画像）・タイムスタンプを画像として保存する処理である。電車が"入線中"もしくは"出線中"の際に、本処理が起動する。
「AI 解析処理」とは、AI エンジン内に保存された画像を解析・UI 側へ結果を返却する処理のことである。車両の入線後・出線後に、本処理へと切り替わり、マシンリソースを AI 解析に集中させて解析が行われる。
AI モデルの概要を以下に記載する。

図 2.3.2-12

AI モデルの概要

59

図 2.3.2-13

AI モデル・ロジック概要（ブレーキパッド摩耗）

図 2.3.2-14

AI モデル・ロジック概要（ハンドル開閉）60

（6）車両状況を監視する機能
車両状況や AI 検出結果の監視・確認する機能として UI 画面（Web ページ）を実装した。
UI 機能の活用イメージを以下に記載する。

図 2.3.2-15 UI 機能利用イメージ
UI 画面へのアクセス経路として Internet 経由があるため、セキュリティ観点より Basic
認証によりアクセスを制限している。

図 2.3.2-16

Basic 認証時のダイアログイメージ

61

映像の閲覧
UI 画面の機能として 3 種類実装した。
 車両監視（ライブ映像）画面
 車両監視（録画映像）画面
 メニューバー
各画面の相関関係を図示した画面遷移図を以下に記載する。

図 2.3.2-17

画面遷移図a）車両監視（ライブ映像）画面
駅に設置したカメラからのリアルタイム映像を閲覧する。
画面イメージを以下に記載する。

図 2.3.2-18

車両監視（ライブ映像）画面イメージ▼異常検出お知らせ機能
AI が異常を検出した際、画面右上に対象のカメラと異常検出した日時情報について音を鳴らしポップアップ表示する。×ボタンでお知らせの表示を消した後は、次に異常検出なし
から異常検出ありに変化した際にお知らせ表示する。異常検出情報受信時にすでにお知らせが表示されている場合は、今受信した最新の情報で表示しなおす。
62

▼全画面表示機能
全画面表示ボタンをクリック or タッチされた場合は、映像の全画面表示を行う。映像の全画面表示後に全画面表示解除ボタンをクリック or タッチすると、元の位置、サイズに戻る。

b）車両監視（録画映像）画面
AI 解析結果付きの録画映像を閲覧する。
画面イメージを以下に記載する。

図 2.3.2-19

車両監視（録画映像）画面イメージ▼異常検出お知らせ機能
AI が異常を検出した際、画面右上に対象のカメラと異常検出した日時情報について音を鳴らしポップアップ表示する。×ボタンでお知らせの表示を消した後は、次に異常検出なし
から異常検出ありに変化した際にお知らせ表示する。異常検出情報受信時にすでにお知らせが表示されている場合は、今受信した最新の情報で表示しなおす。
▼全画面表示機能
全画面表示ボタンをクリック or タッチされた場合は、映像の全画面表示を行う。映像の全画面表示後に全画面表示解除ボタンをクリック or タッチすると、元の位置、サイズに戻る。
▼映像再生位置制御
シークバーにてユーザ操作で録画映像の再生位置の制御を行う。シークバーやコマ送り
ボタンを操作すると画面上に表示している全ての映像の再生位置が移動する。
▼コマ送り再生機能
コマ送り進む or 戻るボタンがクリック or タッチされた時、現在のカメラ 1 号機の再生位置を取得する。映像は 20fps であり、1 フレームの間隔は 50ms である。

63

▼永久保存機能
車両監視(録画映像)画面から永久に保存したい録画ファイルについて、永久保存設定可能
なチェックボックス表示を行う。※サーバ上の録画ファイルは、サーバリソース確保の観点から、一定期間で過去ファイルを自動削除することとした。ただ、後日見返したい、何度もチェックする必要がある等ユーザの判断により永久的に保存したい録画ファイルについて
本機能により、自動削除対象から外すことができる。
▼AI 検出一覧機能
各カメラ映像における異常検出情報の件数表示を行う。ユーザは AI 検出一覧タブをクリック or タッチすることで異常検出した再生位置のリストを表示させることができる。

c）メニューバー
車両監視（ライブ映像）画面と車両監視（録画映像）画面の切り替えを行うメニューバー。

図 2.3.2-20

メニューバー イメージ

▼録画映像検索機能
メニューにて、録画映像を検索するフォームを表示する。
録画映像の日時を検索する検索フォームについて、日時の範囲(下限～上限の入力)を指定できる表示をする。
初期表示については、下限：当日の 00:00、上限：当日の現在時刻
検索ボタンを押下された際、下限、上限のうち１つでも入力されていれば、検索する。また、下限、上限ともに入力されていなければ、全件検索する。

64

日時を検索してください
ライブ映像＋録画映像検索年/月/日- -：- -～
年/月/日

クリックorタッチ- -：- -

検索

図 2.3.2-21

録画映像検索フォームイメージ

検索結果のリンクテキストの表示色によって、動画を以下の通りカテゴライズする。
赤色：AI 検出し、異常ありの録画映像
緑色：AI 検出し、異常なしの録画映像
青色：AI 検出していない録画映像

図 2.3.2-22

検索結果のリンクテキストの表示色イメージ▼録画映像検索結果保持機能
メニューにて、録画映像検索結果表示をページ遷移しても遷移前の検索結果の表示を保
持する。

65

車両異常情報の通知
前述 2.3.2.3.(6).1)にて、車両監視（ライブ映像）画面及び車両監視（録画映像）画面の記載にもあった通り、AI 解析の結果、異常検出した場合、異常情報を画面上にポップアップ
表示で通知する。どのカメラ映像で異常検出したかをユーザに通知する。

図 2.3.2-23

異常通知ポップアップの表示イメージ異常検出時刻も表示され、リンクを押下すると該当時点の録画映像へジャンプする
但し、異常通知のタイミングはリアルタイム AI 解析が異常検出したタイミングのため、録画映像の作成→完了より先行して通知されるケースが多く
通知後すぐに時刻リンクを押下した場合、ジャンプ先の録画映像が未だ作成されていないことが想定される。その際は以下のようなポップアップが表示される。

図 2.3.2-24

異常通知ポップアップの表示イメージ 2

66

（7）AI モデル構築における教師データの取得について
車両運行中である実環境（商用駅）での教師データ取得は困難であったことから、可能な限り実環境を模した状況下で車両工場にてデータ取得を行った。実施内容について以下に示す。

久里浜工場での教師データ撮影
4 両編成の列車の台車にシールに印刷した疑似き裂を張り付けて、久里浜工場内の屋外の線路を往復させて撮影した。この時取得した教師データの種類は、疑似き裂については幅 4
種類（0.1mm，0.2mm，1.0mm，2.0mm）、長さ 3 種類（20mm，60mm，80mm）、向き
2 種類（水平方向、垂直方向）の合計 24 種類、ハンドルについては向き 3 種類（0 度、45
度、90 度）を取得した。ブレーキパッドについては、撮影用に走行可能な営業車両を使用したため、意図的に厚みのあるものやすり減っているものを指定するということは行っていない。速度については時速 5km、10km でそれぞれ往復走行させて撮影した。なお、4 両編成の列車にき裂を取り付け可能な位置は限られているため、疑似き裂のシールを貼り替えて走行させることで全パターンの疑似き裂の取得を実施した。
カメラ、およびライトの設置については、車両を走行させる線路の横 1 か所に図 2.3.2-5のように設置した。カメラの設置位置については、羽田空港第 1・第 2 ターミナル駅のホーム下に実際に設置するときと同様の高さ・対象物との距離となるように設置した。

図 2.3.2-25

カメラ設置の様子

67このとき、シールに疑似き裂を印刷し切り取ったものを列車の台車に張り付けて疑似き裂としたが、昨年度の実証に比べて照度補完のために光量の強いライトを使用したため、シール部分が反射して光ってしまう現象が確認された。実際にき裂が発生した場合にカメラに写るき裂の見え方と異なり、シールに印刷した疑似き裂で AI 学習すると、実際のき裂を検出できない AI になってしまう恐れがあった。
このため、疑似き裂の取り付け方法を変更し、油性黒ペンで疑似き裂を台車に書き込むことにし、より実際のき裂に近い形で AI 学習ができるように対策した。これにより、油性黒ペンで疑似き裂を書きこんだ状態での教師データの撮影が追加で必要となり、新町検車区での教師データ撮影を改めて実施した。

新町検車区での教師データ撮影
新町検車区の屋内で点検中の 4 両編成の列車の台車に油性黒ペンで疑似き裂を書き込み、列車の横を荷物運搬用の台車に乗せたカメラを移動させ、疑似的に列車が走行していると模した映像を撮影した。新町検車区での撮影時には点検スケジュールの関係で列車の走行が困難であったため、このように列車が停止した状態でカメラを動かすことで撮影を行った。
この時取得した教師データの種類は、疑似き裂については久里浜工場と同様に幅 4 種類
（0.1mm，0.2mm，1.0mm，2.0mm）、長さ 3 種類（20mm，60mm，80mm）、向き 2 種類（水平方向、垂直方向）の合計 24 種類、ハンドルについては点検中により安全のために操作せず、すべて正常な水平方向で撮影した。ブレーキパッドについては、点検スケジュー
ル上撮影に使用可能な営業車両を使用したため、意図的に厚みのあるものやすり減っているものを指定するということは行っていない。速度については検車区内を安全に移動できる可能な範囲での速度で、荷物運搬用の台車に乗せたカメラを移動させた。なお、4 両編成の列車に疑似き裂を取り付け可能な位置は限られているため、一度書き込んだ油性黒ペンの線をアルコールで除去し、再度書き込むことで全パターンの疑似き裂の取得を実施した。
カメラ、およびライトの設置については、点検中の列車の横に図 2.3.2-6 のように設置した。カメラの設置位置については、羽田空港第 1・第 2 ターミナル駅のホーム下に実際に設置するときと同様の高さ・対象物との距離となるように設置した。
油性黒ペンは太さごとに種類を分け、図に示す 4 種類の油性黒ペンを使用した。書き込
む際には 20mm，60mm，80mm の長さに切り取った台紙に沿って、図のように書き込んだ。

68

図 2.3.2-26

カメラ設置の様子

0.1mm

0.2mm

1mm

2mm

図 2.3.2-27

図 2.3.2-28

使用した油性黒ペンと台紙

油性黒ペンで台車に書き込む様子（水平方向、垂直方向）

69図 2.3.2-29

油性黒ペンで書き込んだ疑似き裂（水平方向、垂直方向）

70

2.3.2.4 クラウド（dOIC）に関する機能・性能・要件
ドコモオープンイノベーションクラウド（dOIC）は、株式会社 NTT ドコモが運用する
IaaS 基盤で、 仮想マシン、仮想ネットワークなどを提供する。NTT ドコモ網との直結および東西 4 拠点配置により MEC（Multi-access Edge Computing）の特徴を持つクラウドである。NTT ドコモの技術アセットを活用し、ソリューション構築が可能である。

図 2.3.2-30 ドコモオープンイノベーションクラウド（dOIC）概要
ドコモオープンイノベーションクラウドのクラウド基盤は「OpenStack」と「VMware」から構成され、下記 6 拠点から利用する基盤を選択可能である。

図 2.3.2-31

dOIC 提供の各基盤の利用可能拠点「Compute O」と「Compute V」で提供する GPU 仕様が以下のように異なる。

71

図 2.3.2-32

dOIC で提供される「Compute O」「Compute V」の仕様

72

本実証で導入した各インスタンスの機能性能を表 2.3.2-12 に示す。
表 2.3.2-5
インスタンス名

インスタンス機能性能

用途

CPU

GPU

メモリ

Disk

[GB]

[GB]

OS

WebRTC

映像の受配信サーバ

8vCPU

-

32

50 Ubuntu18.04

録画共有

録画映像の保存サーバ

16vCPU-64

4,800 Ubuntu18.04

WebサーバUI提供サーバ

8vCPU

-

32

2,400 Ubuntu18.04

VPN

メンテナンス時のVPN接続サーバ

1vCPU

-

4

10 Ubuntu18.04

Proxy/NTP

インターネット接続時のproxy、及びNTPサーバ

1vCPU

-

4

10 Ubuntu18.04

AI(車両１)

AI解析サーバ

Xeon Silver 4114 × 2

Quadro P5000 × 8

512

960 Ubuntu18.04

AI(車両２)

AI解析サーバ

Xeon Silver 4114 × 2

Quadro P5000 × 8

512

960 Ubuntu18.04

各インスタンスの要件を表 2.3.2-13 に示す。
表 2.3.2-6

インスタンス要件

インスタンス名

用途

WebRTC

FHD20fpsの映像を、３セッション同時に受配信可能なスペックを有すること

録画共有

始発から終電までのサイクルの中で、計算上で1週間以上の録画データを保存可能な容量を有すること

WebサーバWebUIを構築可能なスペックを有すること

VPN

VPNサーバを構築可能なスペックを有すること

Proxy/NTP

Proxy、及びNTPサーバを構築可能なスペックを有することAI(車両１)

計算上、３セッションのFHD20fpsストリーミング映像を受信可能なスペックを有し、AI解析のAI(車両２)

処理時間のKPI達成が可能なスペックを有すること732.4 免許及び各種許認可
実証においては、本実証実験の運用者であり実証コンソーシアムメンバーである京浜急
行電鉄株式会社が免許人となった。その免許人から委託を受けたエクシオグループ株式会
社が、コンソーシアムメンバーである株式会社 NTT ドコモの支援を受けて、ローカル 5G（商用局）免許の申請を行った。各関係者の主な役割を表 2.4-1 に示す。
表 2.4-1
関係者
土地又は建物の運用者
免許人
免許申請及び干渉調整
免許申請支援
無線従事者

各関係者の主な役割
社名

京浜急行電鉄株式会社
京浜急行電鉄株式会社
エクシオグループ株式会社
株式会社ＮＴＴドコモ
エクシオグループ株式会社

備考
コンソーシアムメンバー
コンソーシアムメンバー
免許人より委任
コンソーシアムメンバー
免許人より専任

2021 年 11 月 16 日、総務省関東総合通信局から免許を受けた。

74

2.5 その他要件
2.5.1 サイバーセキュリティ対策
本実証で利用する装置はエリクソン・ジャパンが開発供給しているものであり、特定高度
情報通信技術活用システムの開発供給及び導入の促進に関する法律（令和 2 年法律第 37 号）に基づく開発供給計画認定を受けた実績を有する事業者が開発供給した機器でないため、装置構成および各装置の製造ベンダを図 2.5.1-1 に示す。また、サプライチェーンリスク対応を含むサイバーセキュリティ対策については、機器提供元ベンダのエリクソン・ジャパンによる対策状況を表 2.5.1-1 に示す。

図 2.5.1-1

装置構成及び各装置の製造ベンダ

75

表 2.5.1-1

エリクソン・ジャパンのサイバーセキュリティ対策
Local5G 装置
サイバーセキュリティ対策について
システム観点での施策

OS カーネルとユーザスペースの堅牢化

メモリ管理を行い、ランダム化、スタックス
マッシング保護、実行不可能なヒープとスタ
ックを対処
OS を最小限に抑え、不要なサービスとコン
ポーネントを削除

プロセスの分離システム設計において、なるべくプロセス間の関連性をなくしており、分離して動作

暗号化と鍵管理

すべての通信は暗号化されています。データの機密性、整合性、信頼性を確保し、キーを安全に管理するためのセキュリティプラクテ
ィスを適用

認証によるアクセス管理

ノードへのアクセスおけるユーザ認証が可能であり、RBAC(ロールベースのアドミッションコントロール)が実装され、潜在的な攻撃のリスクを軽減し、セキュリティを強化します。ユーザは、権限に準拠したアクティビ
ティのみを実行できます。

ログの記録

操作ログ、セキュリティログや監査証跡ログを記録しており、全ての操作履歴及びセキュ
リティイベントをログファイルとして記録しております。ログファイルがサイズ制限を超えた場合、ログは FTPES サーバの SFTP に
手動または自動で転送され、バルクデータとして送信するよう設定可能

脆弱性試験

製品のリリースに際し、システムの堅牢性が適切に強化されているかどうかを評価するた
めに、サードパーティの商用ツールを使用して脆弱性と侵入試験を実施し、システムの脆弱性を検出、対策

セキュリティのライフサイクルスキーム実装

エリクソンでは PSIRT (Product Security
Incident Response Team)という組織を立ち上げており、2006 年より FIRST (Forum of
Incident Response and Security Team)の一員として活動しております。PSIRT にて収集したグローバルでのセキュリティ情報に基づき、弊社 local5G 製品の定期リリースにおいて脆弱性の対処及びセキュリティ対策の改
善及び強化を行っております。

76データ、及びトラフィック観点での施策
3GPP で定義されたセキュリティ施策に準拠
すべての無線リソース制御シグナリングは、UE とコア装置の間で 128 ビットの AES および EEA2 128 暗号を使用し、エンドツーエンドの通信ルートにおいて保護されます。ユーザ/データプレーンは、128 ビット AES を使用して UE と eNodeB の間で暗号化されます。
UE と無線ベースバンド間のユーザプレーンとデータプレーンは、128 ビット AES を使用して暗号化されます。
登録された UE はそれぞれ独自の暗号鍵により NW 接続において認証されます。
システム間の通信には、SSH、SSL / TLS、SFTP、SNMPv3 などの安全なプロトコルが使用されます。
ユーザ証明書やクレデンシャル（パスワードなど）などのユーザ関連データは、ストレージ
内とシステムコンポーネント間の転送中の両方で暗号的に保護されます。パスワードは、端末画面への表示、印刷物、ログレコードなど、どのメディアにもプレーンテキストとして表示されることはありません。

ローカル 5G コア装置と dOIC（クラウド）間は VPN 接続する回線を使用し、閉域網でクラウドまで接続することにより、セキュリティを担保する。また、なお、京浜急行電鉄の監視拠点からはインターネット接続でクラウドに接続するが、VPN 接続により、クラウド
接続のセキュアな接続を担保している。

77

2.6 実証環境の運用
本実証においてはローカル 5G 主装置を含めネットワーク機器や IoT デバイス等の分析用機器を多く導入する必要があることから、機器の操作性や保守面での事前の検討が必要となる。対応策としては、導入時にエリクソン・ジャパンのエンジニアによる現地 OJT にて操作方法のレクチャーを受けるとともに、マニュアルを整備して運用に支障のないように配慮した。
機器の保守面に関しては、不具合発生時はＮＴＴドコモが故障の対応を実施した。またローカル 5G 機器ベンダであるエリクソン・ジャパンとは平日 9-18 時での保守契約を締結することで保守体制を強化した。

78

3. ローカル５Ｇの電波伝搬特性等に関する技術的検討（技術実証）
3.1 実証概要
鉄道インフラ分野における課題実証では、“令和 2 年度「地域課題解決型ローカル 5G 等の実現に向けた開発実証に係るインフラ分野におけるローカル 5G 等の技術的条件及び利活用に関する調査検討の請負」における「遠隔・リアルタイムでの列車検査、線路巡視等の実現」において構築した車両検査の遠隔・自動監視システムに関する実用性（技術面・運用面）の向上・評価” を目的としており、実証環境としては、実際に運用されている鉄道駅（羽田空港第 1・第 2 ターミナル駅 1 番線）の屋内ホーム・線路を活用する。技術実証としても、課題実証で実施するユースケースを前提とし、仕様書で規定されている“a.ローカル
5G の電波伝搬特性等の測定”“b.Ⅰ.電波伝搬モデルの精緻化”について検討を行う。その際、今回得られた知見が、他の似たような環境（鉄道駅の屋内ホーム・線路）においても適用できるよう、“遮へい、反射環境における電波伝搬特性”及び“屋内環境におけるエリア
展開の在り方”を意識しながら検討を進めていくこととする。
また、電波伝搬特性の解析においては、ITU や 3GPP における 5G 検討で用いられているパラメータ等を活用して検討を行う。
表 3-1

技術実証の概要項目
技術実証の該当（〇、×）
周波数帯

実施環境
屋内外

周辺環境

4.7GHz 帯〇

28GHz 帯×キャリア 5G の周波数帯

×

屋内

〇

屋外

×

半屋内

×

都市部

×

郊外

〇

開放地

×

その他

×

テーマ別

I. 電 波 伝 搬 モ デ ル のK の精緻化

×実証

精緻化

S の精緻化×

R の精緻化〇その他の精緻化

×

実施の有無

×

III.準同期 TDD の追TDD2 の検討

×

加パターンの開発

TDD3 の検討

×

TDD2、3 以外のパターンの検討×

追加パターンを具備した実機での検証

×

実施の有無

×

II.電波反射板によるエリア構築の柔軟化

IV.その他のテーマ

79

3.2 実証環境
東京都大田区羽田空港の京浜急行電鉄、羽田空港第 1・第 2 ターミナル駅のホーム下に置局される 4.7GHz 帯（4.8‐4.9GHz）のローカル 5G 基地局 1 局を用いて実証試験を行う。
なお、ホーム下から広範囲のエリアをカバーするため、1 つの基地局を分岐させ、3 つのアンテナを張り出してエリア形成を行う。
図 3.2-1 に羽田空港第 1・第 2 ターミナル駅における技術実証試験フィールド（図中、赤枠内）および基地局のアンテナ設置状況を示す。

図 3.2-1

技術実証フィールド

課題実証では、鉄道車体の駆動部をカメラ、センサ等を用いて遠隔監視を行う事から基地局が設置される場所が、ホームより低い場所に置局される。図 3.2-2 の様に、技術実証を行う駅屋内エリアでは、鉄道車両及び、ホームの床面など、遮へいまたは反射による電波伝搬
特性への影響が考えられるため、留意が必要である。

80

図 3.2-2

遮へい物・反射物の状況 （羽田空港第 1・第 2 ターミナル駅）

81

実証時は、駅利用者への影響を除外する事と、線路上の測定等を実施する為、営業時間外での測定を実施しており、実証時の環境を図 3.2-3(a)～(c)で示す。

図 3.2-3(a)実証時における羽田空港第 1・第 2 ターミナル駅 基地局アンテナ設置状況

図 3.2-3(b)

実証時における羽田空港第 1・第 2 ターミナル駅 線路上測定状況82

図 3.2-3(c)

実証時における羽田空港第 1・第 2 ターミナル駅 ホーム上測定状況

各種データの実測に使用する測定機器を表 3.2-1 に示す。
表 3.2-1

実測に使用する測定機器

測定機器名

測定項目

備考

Anritsu
エリアテスタ ML8780A1

SS-RSRP
SS-RSRQ

図 3.2-3

測定用 PC

伝送スループット

図 3.2-4

iPerf2
Packet Capture (Wireshark3)
Garmin eTrex30xJ4

遅延時間

設定値：表 3.2-2

GPS 座標（屋外測定用）

図 3.2-5https://dl.cdn-anritsu.com/ja-jp/test-measurement/files/ProductIntroductions/Product-Introduction/ml8780a-81a-jl11400.pdf
2 https://iperf.fr/
3 https://www.wireshark.org/
4 https://buy.garmin.com/en-US/US/p/518048/pn/010-01508-10#specs
183図 3.2-3

Anritsu エリアテスタの外観

図 3.2-4

測定用 PC(iPerf,Wireshark)

図 3.2-5 Garmin eTrex30xJ の外観

84

本実証を通して、エリアテスタの主な設定値は表 3.2-2 を用いることとする。
表 3.2-2 エリアテスタ設定値
項目

設定値

測定周波数

4827.36MHz

帯域幅100MHz

測定項目

測定周期

SS-RSRP
SS-RSRQ
SS-SINR0.3[s]

アンテナパターンオムニ

測定においては、多数の測定点における測定を効率的に実施するため、図 3.2-6 に示すような測定補助用の治具を作成して測定を実施する。

図 3.2-6 実測に用いる測定補助用治具85

3.3 実証内容
3.3.1 ローカル 5G の電波伝搬特性等の測定
鉄道インフラ分野における課題実証では、“令和２年度「地域課題解決型ローカル 5G 等の実現に向けた開発実証に係るインフラ分野におけるローカル 5G 等の技術的条件及び利活用に関する調査検討の請負」における「遠隔・リアルタイムでの列車検査、線路巡視等の実現」において構築した車両検査の遠隔・自動監視システムに関する実用性（技術面・運用面）の向上・評価” を目的としており、実証環境としては、実際に運用されている鉄道駅（羽田空港第 1・第 2 ターミナル駅 2 番線）の屋内ホーム・線路を活用する。
課題実証において提案するローカル 5G を用いたユースケースで要求される性能を表
3.3.1.1-1 に示す。
課題実証では、上り回線において、映像、センサデータを送信する為、ローカル 5G 性能としては、上り回線の伝送スループットが重要となる。従って、技術実証においても、上り回線のスループットが表 3.3.1.1-1 に示す 60Mbps を満たすことを実証目標とする。
その際、エリア形成の観点とユーザへのサービス提供の観点から評価を行う。
それらの評価結果から、類似の環境（鉄道駅の屋内ホーム・線路）においてローカル 5G
サービスを提供する場合に適用可能なエリア形成やサービス提供品質の知見を取り纏めることも実証目標とする。また、得られた知見については、総務省が策定しているローカル 5G
ガイドラインにおいて、モデルケースとして記載することで、ローカル 5G の利活用に生かされることを想定している。
本項で取得する測定データについては、後述する技術実証項目において評価を行う際に活用する。
表 3.3.1.1-1
項目

課題実証で要求される所要性能
下り(DL)
上り(UL)

通信速度

60Mbps60Mbps

遅延時間

400ms 以下

400msec 以下

利用条件

サイネージ表示 4 台、常時接続

同時通信カメラ 4 台、常時接続（将来的なユースケースを想定）

86

3.3.1.1 実証目標
実証環境におけるローカル 5G の性能評価として、エリア形成の検証と、ユーザへのサー
ビス提供品質の評価を行う。
まず、エリア形成の検証は、「電波法関係審査基準（平成 13 年総務省訓令第 67 号）が規定するエリア算出法」（以下、「エリア算出法」という。）に基づく、カバーエリア及び調整対象区域のエリア端閾値を基準に、実証環境において実測した下り受信電力値及びそこから導く伝搬ロス特性により行う。
次に、ユーザへのサービス提供品質は、カバーエリア端における伝送スループット、遅延
時間が、表 3.3.1-1 にて示している課題実証側での所要性能を達成できているか評価する。
これらの評価・検証を通じて、ローカル 5G 性能向上のための課題抽出と解決策等についても考察を行う。
表 3.3.1.1-1 に、評価項目と測定項目との関係を示す。
表 3.3.1.1-1 技術実証試験における評価項目と測定項目との関係
評価・検証項目

評価項目の概要

主な測定項目エリア算出法に基づく、カバーエリア及び調整対エリア形成の検証

象区域のエリア端において実測する下り受信電

下り受信電力

力値とエリア端閾値の比較。

（SS-RSRP）

測定地点における伝搬ロスと、いくつかの電波伝搬モデルとの比較。
サービス提供品質の評価

カバーエリア端における、伝送スループットと遅延時間が、課題実証で要求される基準を満たしているか評価。

87

伝送スループット
遅延時間

3.3.1.2 評価・検証項目（1）測定方法
測定については、仕様書の規定に従い、エリア算出法に基づく基地局ごとのカバーエリア
及び調整対象区域（図 3.3.1.2-1）において行うこととし、以下の考え方で実施する。

図 3.3.1.2-1 エリア算出法に基づくカバーエリア及び調整対象区域図

88

測定地点の考え方
屋内、屋外の測定地点に置いて下記考え方に基づき測定地点を選定する。
測定地点番号は技術実証を通して同じであり連番となっていないことに注意されたい。
※なお、各測定地点において障害物等により測定困難な地点については、測定地点をずらす等の調整を行う。
 ホーム及び、線路上の測定地点
図面内において、仕様書上の 20 点以上の測定地点及び、分岐されたアンテナを考慮して、ホーム及び、線路上の測定地点を選定する。
なお、この時、ホーム天井面についても遮へい対象として留意を行う事から、階上の施設
エリアにおいても、測定可能となるエリアを考慮して選定を実施する。
階上の施設エリアは、立ち入り可能となるエリアが限られており、測定員の安全性確保の観点も含め、該当エリアの測定点の粒度は、粗くなる。
測定地点の状況を、図 3.3.1.2-2 に示す。

図 3.3.1.2-2

駅ホーム及び、線路上の測定地点（B3F）

 階上の施設エリアの測定地点
地下駅である事からホーム下に設置した基地局装置からの電界が、地上方向への漏れ出しを考慮して、階上の施設エリアにおいても測定を実施する。
なお、駅ホーム及び、線路上の測定地点でも記載した階上の施設エリアは、立ち入り可能となるエリアが限られている事から、立ち入りが可能となるエリアにおいて、網羅的に測定地点の選定を行った。
測定地点の状況を、図 3.3.1.2-3 に示す。

図 3.3.1.2-3

駅ホーム及び、線路上の測定地点（B2F）
89

測定項目
 下り受信電力
一般的に５ＧNR のエリア指標として用いられている SS-RSRP (Synchronization
Signal-Reference Signal Received Power)及び SS-RSRQ (Synchronization SignalReference Signal Received Quality)、SS-SINR (Synchronization Signal-Signal toInterference Reti)について実測する。
SS-RSRP は、1 リソースエレメント当たりの SSS (Secondary Synchronization
Signal)の受信電力であり、基地局からの電波の受信レベルを評価する基本的なパラメータである。SS-RSRQ は、受信品質を評価するパラメータであり、近隣基地局の干渉が増大すれば RSRQ が小さくなる。SS-SINR も RSRQ 同様に受信品質を評価するパラメータであり、RSRQ は分母に RSSI、つまり全体帯域の電力を用いるが、SINR では RS と同じリソースブロックの帯域内に存在する干渉電力を分母とする。干渉電力
は、同じ帯域内の隣接セルからの信号に加えて雑音成分や、CP(Cyclic Prefic)時間を超えて遅延したマルチパスとなり、その干渉電力が増大すれば SINR が小さくなる。
 伝送スループット及び遅延時間
伝送スループットについては、アップリンク（以下、UL）/ダウンリンク（以下、DL）を、端末側に接続したクライアント PC と基地局側コアネットワークに接続したサーバ PC との区間において測定する。遅延時間についても同じ区間において実測する。

測定手法と実測模様
各種データは、上記の考え方に基づき選定した測定地点に測定員が赴き、表 3.2-1 に示す測定器及び表 3.2-2 に示す設定値を用いて実測する。また、実証環境における電波伝搬環境をより詳細に分析するため、各測定地点においては測定員の目視により見通し環境もしくは見通し外環境であるかを併せて記録する。ただし、建物の構造や障害物の存在等により立ち入りが難しい場所については測定地点をずらすなどで対応する。
SS-RSRP 及び SS-RSRQ は、エリアテスタを用いて、1000 サンプル/地点のログ取得を実施する。
なお、受信電力の測定においては、定在波の影響を避けるため、1 つの測定点において、10λ(λは波長)の範囲で測定位置を動かしながら測定を実施する。
伝送スループットや遅延時間の測定については、図 3.3.1.3-4 に示す通り UE と CN の
End To End で測定を行うが、期待する測定値とは異なる結果や、そもそも測定値が取得できない等の場合を考慮し、無線装置と 5G Core 装置の中間である場所に「パケットキャプ
チャ装置」(光信号分岐用装置（TAP）含む)を接続し、問題発生時の切り分けとして無線伝送部分の測定を行う。

90

図 3.3.1.3-4 伝送性能測定区間

913.3.1.3 評価・検証方法
ローカル 5G の電波伝搬特性等の測定に関しては下記に記載する流れで評価・検証を進めていくこととする。

（1）実証環境におけるエリア形成の検証
エリア形成の検証としては、エリア算出法に基づく、カバーエリア及び調整対象区域のエリア端閾値を基準に、実証環境において実測した下り受信電力値及びそこから導く伝搬ロ
ス特性により行う。
具体的には、実証環境におけるカバーエリア及び調整対象区域をエリア算出法により作図する（エリア算出法によるエリア図）。その後、それぞれのエリア端における実際の下り受信電力値とエリア端閾値との比較を行う。下り受信電力値とエリア端閾値が異なっている場合は、カバーエリア及び調整対象区域のエリア端閾値が実測される地点と基地局との距離の確認を行うことにより実測値による推定エリア図を作成する。最後に、エリア算出法
によるエリア図と実測値による推定エリア図の差分を評価する。
加えて、20 か所の測定地点において実測した下り受信電力値と測定地点～基地局間距離から算出した伝搬ロス特性を、携帯電話システムの設計等に用いられている電波伝搬モデ
ルと比較することで、実証環境における 4.7GHz 帯（4.8~4.9GHz）の電波伝搬特性の評価を行う。

（2）実証環境におけるユーザへのサービス提供品質の評価
ユーザへのサービス提供品質の評価として、カバーエリア端における伝送スループット、
遅延時間について、下り受信電力値との関係性で評価し、表 3.3.1.3-1 にて示している課題
実証側での所要性能を達成できているか評価する。
表 3.3.1.3-1
項目

課題実証で要求される所要性能（再掲）
下り(DL)
上り(UL)

通信速度

60Mbps60Mbps

遅延時間

400ms 以下

400msec 以下

利用条件

サイネージ表示 4 台、常時接続

同時通信カメラ 4 台、常時接続（将来的なユースケースを想定）

92

3.3.1.4 実証結果及び考察（1）下り受信電力、受信品質測定結果
実証環境における下り受信電力及び受信品質の測定地点は、3.3.1.2 章にて示しており、駅ホーム及び線路上において 49 地点、階上の施設エリアにおいて 53 地点で測定を実施した。なお、実証環境においては、基地局アンテナが配置されている 1 番線と、その反対側となる 2 番線のどちらかに車両が停車している環境となる。そのため、測定は 1 番線、2 番線
どちらかに車両が停車している環境においてそれぞれ実施している。
実測結果を図 3.3.1.4-1～2 及び、表 3.3.1.4-1～2 に示す。表中の基地局からの 3D 距離は、今回基地局アンテナを 3 基張り出しているため、各測定地点から最も近いアンテナまでの距離を記載している。

図 3.3.1.4-1(a)駅ホーム及び線路上の SS-RSRP 測定結果（B3F）

図 3.3.1.4-1(b)駅ホーム及び線路上の SS-RSRQ 測定結果（B3F）

93

図 3.3.1.4-1(c)駅ホーム及び線路上の SS-SINR 測定結果（B3F）

94

表 3.3.1.4-1(a) 駅ホーム及び線路上を対象とした SS-RSRP、RSRQ、SINR 測定結果
SS-RSRP (dBm)

測定点 ID

車両 1 番線
1-115.292-112.423-104.684-106.665-99.696-105.047-98.318-101.879-90.4710-94.63

11-101.3612-95.3113-96.5814-102.1715-93.8116-104.7517-96.3418-96.3919-100.0120-99.5221-106.4822-102.4323-108.7524-112.7725-121.9026-120.7527-117.7028-121.8729-128.5730-125.6131-131.6332-124.76

SS-RSRQ (dB)

車両 2 番線-93.06SS-SINR (dB)

車両 1 番線

車両 2 番線

車両 1 番線

車両 2 番線-12.88-10.35

7.76

20.75

-10.90-83.82-10.77

10.62-10.20-10.32-78.69-12.92-10.39-10.92-10.26-10.10-10.97-9.61-10.26-10.12-10.26-10.83-10.42-10.55-10.55-11.45-10.91-10.30

-9.85

-9.59

-13.72-10.97-12.41-10.79-17.95-10.25-19.34-14.98

95

20.06

20.11

19.28

18.46

20.61

15.85

20.21

14.44

18.82

1.60

18.92

6.34

19.44

1.80
-10.69-15.13-111.50

19.01

2.84

-13.32-108.04

20.08

10.05

-12.71-97.21

19.80

16.19

-11.41-97.95

20.77

18.79

-11.04-97.28

17.43

20.29

-10.14-86.37

20.65

15.97

-10.52-78.44

20.53

17.32

-11.12-85.44

20.42

19.34

-10.42-79.58

16.20

19.99

-11.14-81.93

20.82

17.13

-10.68-77.65

17.88
15.92

-10.69-78.51

20.89

14.76

-10.97-82.34

16.58

-5.74

14.24

-2.19
-10.90

-7.59
-2.06

11.39

33

-108.50-91.66-11.25-10.07

13.78

19.45

34

-79.62-10.6021.71

35-73.37-10.5521.84

36-78.41-11.1721.22

37-66.93-10.4921.28

38-68.76-10.7021.41

39-67.03-10.3621.84

40-69.38-10.2921.13

41-71.18-10.2521.32

42-62.27-10.8922.05

43-69.81-10.1822.29

44-81.54-11.2820.65

45-86.02-10.9020.57

46-90.84-10.9919.82

47-88.88-10.4220.95

48-92.86-10.5618.43

49-93.27-10.8319.34

96

図 3.3.1.4-2(a)階上の施設エリアの SS-RSRP 測定結果（B2F）

図 3.3.1.4-2(b)階上の施設エリアの SS-RSRQ 測定結果（B2F）

図 3.3.1.4-2(c)階上の施設エリアの SS-SINR 測定結果（B2F）

97

表 3.3.1.4-2(a)
測定点 ID

階上の施設エリアを対象とした SS-RSRP、RSRQ、SINR 測定結果
SS-RSRP (dBm)

車両 1 番線

車両 2 番線

SS-RSRQ (dB)
車両 1 番線

車両 2 番線

SS-SINR (dB)
車両 1 番線

50-112.56-10.6010.61

51-122.82-13.730.71

52-134.06-21.60-9.48-132.63-20.31-8.55

車両 2 番線

53
54
55-115.05-11.478.55

56-128.24-109.26-17.01-11.03

-5.03

12.98

57

-130.23-113.56-18.40-12.09

-6.64

9.11

58

-133.86-111.69-21.78-11.62

-9.47

11.27

59

-122.35-102.40-13.30-12.40

0.78

17.44

60

-124.61-14.63-1.41

61-124.03-14.25-0.55

62-116.99-11.825.84

63-114.83-11.508.08

64-125.21-15.71-2.73

65-124.21-14.70-0.89

66-124.53-14.13-1.07

67-124.37-14.32-0.95

68-132.01-20.70-8.40

69-127.52-16.30-4.17-135.64-23.65-10.6577-131.86-20.08-8.30

78-129.95-18.59-6.76

79-125.94-14.96-2.56

80-120.22-12.39

2.79

70
71
72
73
74
75
76

81

-130.61-111.02-19.4598-10.76

-7.47

10.89

82

-112.21-10.3010.13

83-118.64-11.974.60

84-115.01-99.29-11.38-10.69

7.97

18.34

85

-125.86-109.87-15.30-11.29

-2.47

12.60

86

-133.42-113.75-21.41-11.65

-9.25

8.75

87

-129.46-111.73-18.22-11.03

-6.15

10.92

88

-125.66-115.26-14.94-10.72

-2.22

7.78

89

-126.81-16.48-3.92

90-130.04-18.71-6.64

91-121.22-12.861.68

92-118.40-12.214.77

93-120.39-13.122.56

94-122.57-13.88-0.19

95-120.44-12.492.44

96-124.94-15.03-1.72

97-126.41-15.94-3.05

98-125.78-15.04-2.37

99-128.92-17.32-5.49

100-126.37-16.06-3.49

101-130.04-18.39-6.64

102-132.75-21.30-8.93

99

（2）伝送スループット、RTT 測定結果
実証環境における伝送スループット及び RTT 測定については図 3.3.1.4-3 に示す課題
実証エリア周辺にて実施している。実測の結果を図 3.3.1.4-4 及び、表 3.3.1.4-3 に示す。

図 3.3.1.4-3 伝送スループット、RTT 測定範囲

図 3.3.1.4-4（a）伝送スループット（UL）測定結果

図 3.3.1.4-4（b）伝送スループット（DL）測定結果

100

図 3.3.1.4-4（c）伝送遅延（RTT）測定結果

101

表 3.3.1.4-3 伝送スループット、RTT 測定結果
DL T-Put (Mbps)

測定点 ID

車両 1 番線
3

150.53

4

136.537

165.538

154.0311

169.1712

161.9715

163.6316

152.8719

163.9720

154.70

23

66.28

24

55.43

27

18.85

28

5.76

31
33

車両 2 番線

UL T-put (Mbps)
車両 1 番線

車両 2 番線

車両 1 番線

車両 2 番線

8.25

29.26

35.63

32.33

162.73

3.95
164.37

22.19

32.63
50.28

10.63
165.9326.25

167.53

15.20

56.70

14.00

58.13

0.49

67.34

0.00

12.19

29.50

38.67

46.17

15.10

52.00

32.77

33.10

31.83

57.57
1.47

5.14

30.93

38.03

0.00

169.63

31.60

28.77

0.45
165.43

28.80

32.50

9.99
161.87

32.33

31.73

10.00
171.67

59.13
35.63

20.48

112.76142.40

RTT (ms)

33.21

33.73
33.10

30.37

35

148.27

61.46

31.13

37

160.03

64.32

32.93

39

167.33

81.62

30.90

41

164.97

62.65

29.77

43

163.63

78.59

45.23

45

172.47

67.05

31.67

47

166.17

48.07

29.33

49

167.60

35.25

32.57

102

（3）実証環境における電波伝搬特性の評価
今回の実証環境である羽田空港第 1・第 2 ターミナル駅は、地下駅である事からソリュー
ションを展開する上では、自己土地としてサービスエリアの構築が容易であるといえる。しかしながら、地下駅においては、階上の施設が別事業者の運用が為されることも想定され、3.2 章で示した通り、駅天井の遮へいによる階上方向への電波漏洩が別事業者へ与える影響を考慮する必要がある。
このような環境においても、ローカル 5G を運用するには、階上への電波漏洩による干渉を抑えつつ、自己土地内で必要十分なサービスエリアを確保するサイトエンジニアリングが求められる。その為、まずは実証環境における 4.8GHz 帯の電波伝搬特性の評価を行う。
3.3.1.4 章（1）にて示した下り受信電力の実測データ（SS-RSRP）を用いて、地下駅の環境における 4.8GHz 帯の電波伝搬特性を考察する。
具体的には、実測した下り受信電力値から伝搬ロスを算出し、それらの距離特性を求める。
さらに、携帯電話システムの設計等に用いられている、いくつかの電波伝搬モデルから求められる伝搬ロスとの比較を行うことで、地下駅等の環境における 4.8GHz 帯の電波伝搬特性の評価を行う。
ここで、実測値との比較に用いる伝搬式を表 3.3.1.4-4 に示す。

電波伝搬式

表 3.3.1.4-4 実測値との比較に用いた電波伝搬式
概要

自由空間伝搬開放地に適用。周波数範囲、伝搬距離、送受信機の高さなどの適用制限はない。
4𝜋𝑑
4𝜋𝑓𝑑
4𝜋𝐿 = 20 log () = 20 log () = 20 log 𝑓 + 20 log 𝑑 + 20 log ( )𝜆𝑐𝑐= 20 log 𝑓 + 20 log 𝑑 + 32.4 [dB]f: 周波数[MHz]、d: 距離[km]、c: 3.0×108[m/s]

ローカル 5G 審査基準

電波法関係審査基準（平成 13 年総務省訓令第 67 号）
令和 2 年 12 月 18 日制定

3GPP モデルITU-R P.1411 ベースの伝搬式。環境により基地局、移動局高が規定されている。
RuralMacro:基地局 10～150m、移動局 1～10m
UrbanMacro:基地局 25m、移動局 1.5～22.5m
UrbanMicro:基地局 10m、移動局 1.5～22.5m
InH Office(LOS):直線距離 1～100m
InH Office(NLOS):直線距離 1～86m
InH ShoppingMall:直線距離 1～150m

駅ホーム下に置局した基地局と、駅ホーム及び、線路上について、実測した下り受信電力
データから算出した電波伝搬特性を図 3.3.1.4-10 に示す。
図中、●は LOS データ、×は NLOS のデータを示している（LOS か NLOS は、測定地点から基地局アンテナが目視できるかで判断している。）
実測値と比較した伝搬式は、自由空間伝搬と、ローカル 5G 審査基準で用いられている伝搬式（奥村・秦式）である。結果からは、以下のことがわかる。
103

 今回、環境では一番線のホームの下に、オムニ指向性のアンテナを地下駅の水平方向に設置している。この場合、「アンテナ設置の開口部に近い 1 番線」に車両がある環境では、LOS 環境となる測定点が得られず、且つ、アンテナ直近に遮へいとなる鉄
道車両が設置されたことになる。結果、NLOS 環境では、奥村・秦式（市街地）モデ
ルのカーブ傾向よりも低い結果となった事が確認できる。
 一方、「アンテナ設置の開口部と反対側となる 2 番線」に車両がある場合、LOS 環境となる 1 番の線路上は、自由空間損失モデルのカーブ傾向に近い事が出来る。また、ホーム上の地下 3 階(B3F)の NLOS 環境では、奥村・秦式（開放地）のカーブ傾向に近いが、ホーム階上地下 2 階(B2F)の NLOS 環境では、奥村・秦式（市街地）モデルのカーブ傾向よりも低い結果となった事が確認できる。
これらの結果から、鉄道等の駅ホーム下に設置した今回環境については、線路上で見通しが取れる場合は、自由空間損失モデルで概ね推定が出来るものと考えられる。
一方、同環境におけるホーム上については、アンテナ設置を行った側に車両がある場合
は、奥村・秦式（市街地）モデルよりも低い傾向として、車両が無い場合は、奥村・秦式（開放地）モデルで、概ね推定が出来るものと考えられる。

図 3.3.1.4-10(a) 地下駅ホーム下設置基地局からの伝搬ロスの距離特性（1 番線車両あり）

104

図 3.3.1.4-10(a) 地下駅ホーム下設置基地局からの伝搬ロスの距離特性（2 番線車両あり）

105

（4）実証環境におけるローカル 5G 性能評価
実際の鉄道等地下鉄の環境において、ローカル 5G の性能が想定通りに実現できているかを、実測した SS-RSRP、SS-RSRQ、伝送スループット、ラウンドトリップタイムにより評価する。
ローカル 5G の性能評価は、3.3.1.3 章に示す評価方法に基づきエリア形成の観点と、ユーザへのサービス提供品質の観点から実施した。前者については、基地局からの受信レベ
ルを用いて、設計通りのエリアが構築できているか否か、できていない場合はどのような原因で想定され、対策としてどのような方策が取りえるのかを考察する。後者については、ローカル 5G ネットワーク上に構築されるアプリケーションやシステムのパフォーマンス
に直接的な影響を与えると考えられる、伝送スループットとラウンドトリップタイムの実測結果を用いて考察する。

実証環境におけるローカル 5G エリア形成について
ローカル 5G 性能評価の前提となる、実証環境のターゲットエリア（サービスを提供したいエリア）を図 3.3.1.4-11 に示す。実証環境においては、図中に示す線路上をターゲットエ
リアとするため、ホーム下にオムニ指向性のアンテナを 3 つ設置している。

図 3.3.1.4-11 地下鉄線路上のターゲットエリア
ここでは、下り受信レベル（SS-RSRP）の測定結果からエリア形成の観点での評価を行う。
図 3.3.1.4-12~13 に実証を行うホーム、線路上（B3F）のエリア形成状況を示す。図中、赤線は 4.6-4.9GHz 帯におけるローカル 5G 審査基準で定められている“カバーエリア端レベル（100MHz 幅の場合：-84.6dBm）”を前提に実測値から評価した想定カバーエリア端である。一方、青線は、同様に審査基準で定められている“調整区域端レベル（100MHz 幅の場合：-91.0dBm）”を前提に実測値から評価した想定調整区域端である。なお、本実証に用いる基地局装置の下り受信レベル（SS-RSRP）の測定帯域は 30kHz であるため、上述したエリア端閾値を 100MHz から、30kHz へ帯域換算した以下の値を用いている。
カバーエリア端レベル（SS-RSRP 帯域換算）：-119.8dBm

調整区域端レベル（SS-RSRP 帯域換算） ：-126.2dBm
結果からは、以下のことがわかる。
 鉄道駅ホーム下にアンテナ設置を行った今回環境では、アンテナ設置を行った側に車両がある場合、アンテナ設置位置に対して離れたホーム上に、カバーエリア端が形成
106

されている事が確認できる。車両が無い場合については、今回環境では、ホーム上は、カバーエリア内に収まる結果となる事が確認できる。
 SS-RSRP によるカバーエリア端として確認できた測定ポイント付近で、SS-RSRQの劣化を確認しており、相関性があると考えられる。
 SS-SINR においては付近に干渉影響となる無線局は存在していない環境となる。そのため、SINR における"IN"は、環境雑音または CP（Cyclic Prefix）時間を超えて遅延したマルチパスが支配的と考えられるが、屋内に設置した基地局と屋内各測定地点の距離から CP 時間を超えて遅延波が観測されることは考えにくく、"IN"に影響を与える要因は環境雑音が支配的と想定する。加えて、RSRP 同様に減衰傾向が見えることから、SINR が低い地点に置いては"S"となる主波及び CP 時間内の遅延波のレベルが減衰しているためと考えられる。

図 3.3.1.4-12 受信レベル SS-RSRP から評価した想定カバーエリア（B3F）

図 3.3.1.4-13(a) 受信品質 SS-RSRQ から評価した想定カバーエリア（B3F）

107

図 3.3.1.4-13(b) 受信品質 SS-SINR から評価した想定カバーエリア（B3F）
図 3.3.1.4-14~15 にホーム、線路上の階上となる（B2F）を示す。なお、本階層は実証対
象区域ではないが、実証エリア（B3F）から階上（B2F）への電波漏洩観点でエリア形成を評価する。図中、赤線は 4.6-4.9GHz 帯におけるローカル 5G 審査基準で定められている“カバーエリア端レベル（100MHz 幅の場合：-84.6dBm）”を前提に実測値から評価した想定カ
バーエリア端である。一方、青線は、同様に審査基準で定められている“調整区域端レベル（100MHz 幅の場合：-91.0dBm）”を前提に実測値から評価した想定調整区域端である。なお、本実証に用いる基地局装置の下り受信レベル（SS-RSRP）の測定帯域は 30kHz である
ため、上述したエリア端閾値を 100MHz から、30kHz へ帯域換算した以下の値を用いている。
カバーエリア端レベル（SS-RSRP 帯域換算）：-119.8dBm

調整区域端レベル（SS-RSRP 帯域換算）：-126.2dBm

結果からは、以下のことがわかる。
 鉄道駅ホーム下にアンテナ設置を行った今回環境の線路上の階上となる(B2F)では、アンテナ設置を行った側に車両がある場合、基地局の直上エリアと、階段及び、エレベータ付近による開口部で、電波の漏れ出しが発生している事が分かる。車両が無い
場合においては、この傾向が強く確認する事が出来る。
 基地局の直上となる場所で、電波の漏れ出しを確認しているが、B3F の実証フィール
ドの該当部付近において、天井にエアダクトが設置されている事を確認しており、その分の遮へい損失が低くなったと考えられる。
 SS-RSRQ の状況についても、上記の電波の漏れ出し傾向が良く表れる傾向が確認できる。
これらの結果より、鉄道等における地下駅の環境においては、ターゲットエリアの受信電力を維持したまま、天井面における開口部となる、エアダクト、エレベータ、階段等の駅内
開口部によって発生する電波漏洩を防ぐ事が課題であると考える。
すなわち、階上方向の開口部付近での漏洩電力が観測されている事から、本実証で使用したオムニ指向性のアンテナではなく、セクタ指向性のアンテナ等を用いて、バックローブを漏洩電力が強く出てしまう方向に向ける等の置局設計が望ましいと考えられる。

108

図 3.3.1.4-14 受信レベル SS-RSRP から評価した想定カバーエリア（B2F）

図 3.3.1.4-15(a) 受信品質 SS-RSRQ から評価した想定カバーエリア（B2F）

図 3.3.1.4-15(b) 受信品質 SS-SINR から評価した想定カバーエリア（B2F）

実証環境におけるローカル 5G サービス提供品質
ここでは、伝送スループット、ラウンドトリップタイムの測定結果から、ユーザへのサー
ビス提供品質の観点で評価を行う。
109

図 3.3.1.4-16-18 は、図 3.3.1.4-11 のターゲットエリア内において実測した伝送スループット(DL/UL)とラウンドトリップタイムを地図上に記載したものである。また、図 3.3.1.4.19
はターゲットエリア内における下り受信電力（SS-RSRP）と伝送スループット、ラウンド
トリップタイムとの関係をそれぞれにおいてグラフ化したものである。
UL スループットは、ターゲットエリア内に車両が無い場合において、概ね
70Mbps 以上となる事を確認出来ている。ターゲットエリア内に車両が有る場合においては、測定が出来ていないが、ホーム床面の遮へい影響を受ける、ホーム上において車両有無によって、20Mbps 以上の劣化が見えている事から、車両あり時のターゲットエリアにおいても、同様の劣化が発生するものと考えられる。
 DL スループットについては、ターゲットエリア内に車両が無い場合において、概ね、175Mbps 以上となる事が確認できる。ターゲットエリア内に車両が有る場合においては、UL スループットと同様に測定が出来ていないが、車両有無によるホーム上のスループット差分が、図 3.3.1.4-12 に示した、SS-RSRP が劣化する場合を除き、低い傾向にある事が確認できる。これは、DL 通信については各ビームにおいて直行性を持っており、誤りが少なくなることから、スループット劣化が抑えられたものと考えられる。
 ラウンドトリップタイムについては、車両の配置状況に影響せず、概ね 50ms 程度となる事が見えているが、UL と DL のスループットについては、電界エリアが良好となるにつれて、良好な結果が得られており、ターゲットエリアにおいて良好な電界の確保が必要である事が分かる。
 設定した目標値に対して、ターゲットエリアに車両が無い場合において、目標品質をクリアする事が確認できたが、ターゲットエリアに車両が有る場合においては、測定を行う事が出来ず、確認は取れていない。考察上の推定では、UL スループットにおいて、目標となる 60Mbps を下回る可能性があると考えられる。


図 3.3.1.4-16 伝送スループット（UL）測定結果

110

図 3.3.1.4-17 伝送スループット（DL）測定結果

図 3.3.1.4-18 RTT 測定結果111

図 3.3.1.4-19(a) 伝送スループットと SS-RSRP の関係（1 番線車両あり）

図 3.3.1.4-19(b) 伝送スループットと SS-RSRP の関係（2 番線車両あり）
3.3.1 章に示しているように、鉄道インフラにおけるユースケースを想定した場合、表
3.3.1 に示す所要性能、特に上り回線の伝送スループットが重要となる。課題実証においては、UL 伝送スループットの目標値として 60Mbps としており、技術実証においても、この目標値を基に評価を行う。
112

表 3.3.1

項目
通信速度
遅延時間
利用条件

課題実証で要求される所要性能（再掲）
下り(DL)
上り(UL)
60Mbps60Mbps
400ms 以下
400msec 以下
サイネージ表示 4 台、常時接続
同時通信カメラ 4 台、常時接続（将来的なユースケースを想定）

図 3.3.1.4-20 は、ターゲットエリア内における伝送スループット、RTT の測定結果を累積確率分布としてグラフ化したものである。
 今回環境において、見通しが取れる LOS 環境の方が、伝送スループット（UL/DL）
及び、ラウンドトリップタイムの何れにおいても良好な結果があり、よりスループッ
ト速度、低遅延を求めるのであれば、アンテナ設置位置に対して、見通しが取れるエリアにターゲットとなるソリューションを構築した方が良い事が確認できる。
 UL スループットと DL スループットの累積確率分布として、NLOS 環境では、UL
スループットのばらつきが低く、DL スループットではバラつきが大きい。これは、受信品質によって、変調精度を変えて信号強度を変える処理テーブルが DL の方が多い事が要因と考えられる。
 今回目標とした UL スループット目標は、60Mbps であり、LOS 環境でも、50%を下回る結果となっており、NLOS 環境では達成が厳しい事が確認できる。今回環境は、
ホーム下にアンテナが設置されており、ターゲットエリアもホームより低いエリアであった事が要因と考えられる。
 一方で、DL スループット目標の 60Mbps は、NLOS 環境でも 20%未満であり概ね良好な結果を確認できたと考えられる。ラウンドトリップタイム目標は 400ms であり、目標を達成している事を確認する事が出来たと考えられる。
これらの結果から、今回環境における実証フィールド全体で十分な所要性能を得る為には、カバーエリア閾値以上の電力を確保する事はもちろん、アンテナ設置位置に対して、ソ
リューションを実施するエリアに対し見通しを考慮した設計が必要となる。

113

図 3.3.1.4-20(a) ターゲットエリア周辺における UL 伝送スループット累積分布

図 3.3.1.4-20(b) ターゲットエリア周辺における DL 伝送スループット累積分布114

図 3.3.1.4-20(c) ターゲットエリア周辺における RTT 累積分布115

（5）技術的課題の解決方策
今回の実証では、鉄道等における地下駅環境において、基地局から、オムニ指向性のアン
テナを 3 つに分岐する形でホーム下にローカル 5G の構築を行った。その結果、実測値から得られた伝搬特性は線路上で見通しが取れる場合は、自由空間損失モデルで、見通しが取れない場合は、奥村・秦式（市街地）モデルよりも低い傾向として、概ね推定が出来るものと考えられる。同環境におけるホーム上については、アンテナ設置を行った側に車両がある場
合は、奥村・秦式（市街地）モデルよりも低い傾向として、車両が無い場合は、奥村・秦式（開放地）モデルで、概ね推定が出来るものと考えられる。ホーム下にアンテナを設置した
事により、設置した側に車両があると、車両による遮へい影響が発生した事が要因と考えられる。
また、ホーム上においては車両への出入りに伴う人流が発生する事が想定され、ホーム上に移動局を置局するような場合においては、その分の損失マージンを見込む必要があると考えられる。本実証においては、人流による損失について詳細な検討を実施できていないが、その影響は否定できない為、ホーム上でのエリア設計が必要とされる場合、高所にアンテナを設置し、吹き降ろす様な形で設計を行う事が望ましいと考えられる。

116

3.3.2 電波伝搬モデルの精緻化
3.3.2.1 実証の目的・目標（1）背景となる技術的課題と実証目的背景として、今回課題実証では、“遠隔・リアルタイムでの列車検査、線路巡視等の実現」
において構築した車両検査の遠隔・自動監視システムに関する実用性（技術面・運用面）の向上・評価” を目的としており、図 3.3.2.1-1 に示すカメラ等を設置する線路内のエリアをカバーするため、ローカル５G 基地局 1 局を活用して実証を行っている。なお、ホーム下から広範囲のエリアをカバーするため、1 つのローカル 5G 基地局から 3 つのアンテナを張り出してエリア化されており、こちらを活用して実証を行っている。
本実証環境においてローカル 5G 基地局のアンテナは、ホーム下への置局となる。そのため、本実証においては図 3.3.2.1-2 に示すような同じホーム内において、他のローカル 5G
もしくはキャリア 5G 局が運用されるケースを想定し、ホーム下側からの電波がホーム床面（コンクリート）を通過して、ホーム上側へどれだけ漏洩するかに着目し、平面ではなく立体的な干渉調整を行うためのエリア算出法への精緻化について実施を行う事を目的とする。

図 3.3.2.1-1

羽田空港第 1・第 2 ターミナル駅内実証エリア

117

図 3.3.2.1-2

立体的な干渉調整イメージ

118

（2）実証目標
はじめに、3.3.2 章においては柔軟なローカル 5G システムの設計・構築に資する検討
として、仕様書要件5で規定されているエリア算出法に含まれるいくつかのパラメータ（表3.3.2.1-1）を対象とし、その値を精緻化することが求められる。
本検討において得られる精緻化したパラメータ値により、ローカル 5G 運用エリアに合わせてエリア算出法を適正化する等の制度改正につながることを目標としている。また、得られた知見については、総務省が策定しているローカル 5G ガイドラインにおいて、モデルケースとして記載することで、ローカル 5G の利活用に生かされることを想定している。
今回の実証環境においては、4.7GHz 帯の屋内局を活用するため精緻化の対象パラメータは表 3.3.2.1-1 から“R”とする。なお、“R”は建物内に基地局を配置する際に建物侵入損
失の値に応じて修正するパラメータである。また、本実証環境においては(1)で記載している通り、ホーム下側への置局になる為、建物侵入損 R をホームの遮へいと置き換えた場合、地下ホーム以外で同様な環境を構築する際のモデルケースを示すにあたって適切なパラメータであると考える。
表.3.3.2.1-1 精緻化の対象パラメータと精緻化の方向性、実証環境の要件

5

令和 3 年課題解決型ローカル 5G 等の実現に向けた開発実証（令和 3 年 6 月）P34 表 2

より引用
119

3.3.2.2 実証仮説
今回精緻化の対象とするパラメータ“R”については、4.7GHz 帯のローカル 5G 技術的条件等を検討した情報通信審議会報告書6において、建物侵入損として詳しく記載されている（表 3.3.2.2-1 参照）。建物侵入損は、建物の外壁の材質によって想定される値が変化する
ことが示されており、一般的な建物外壁（Traditional）では、50%の期待値において
R=16.2dB となっている。また、4.7GHz 帯のローカル 5G 審査基準においては、R＝16.2dBが規定値として定められてもいる。
本実証においては、ホーム下側にローカル 5G 局を置局するため、同じホーム内において、他のローカル 5G 局もしくはキャリア 5G 局が運用されるケースを想定し、ホームの遮へい損失を考慮した立体的なカバーエリア及び調整対象区域の作成も併せて行う為、ホームにおける遮へい損失も同様に建物侵入損と見込んで検討を進めることとする。今回、技術実証を行う場所は鉄道駅の地下ホームであり、ホームの材質はコンクリートと想定されるため、“R”値は、一般的なコンクリート壁面と想定し、Traditional における期待値 5%（=4.2dB）～期待値 50%（=16.2dB）の間にあるものと仮定する。

建物の種別※
Traditional
Thermallyefficient

表 3.3.2.2-1 4.7GHz 帯における建物侵入損
建物侵入損の期待値
5%
4.2dB

10%
6.0dB

20%
8.8dB

50%
16.2dB

13.3dB

16.6dB

21.0dB

31.4dB※Thermally-efficient：金属化ガラス（断熱効果を高めるために使用する建築用の紫外線を遮断するガラス）、金属ホイルを裏打ちしたパネルを用いた建物。
Traditional：上記以外の建物
なお、エリア算出法では、表 3.3.2.2-2 に示すように、送受信間距離 dxy が 40m 以下の場合には、計算対象地域の環境に応じて、建物侵入損に対して考慮する補正値“R”の選択が必要である。本実証環境においては、ホームはコンクリートで構築されているものと仮定しており、R 値は一般的な建物侵入損失の期待値 50%である 16.2dB とする。
表 3.3.2.2-2 電波関係審査基準の電波伝搬式における補正項選択肢（dxy が 40m 以下の場合）
補正項

定義

選択肢
16.2[dB]

R

建物侵入損に対して考慮する補正項

実際の建物侵入損が明確な場合は明示の上、建物に応じた値を適用する。
本実証環境においては 16.2[dB]とする。

上記仮説に基づき、パラメータ“R”の値を修正したカバーエリア及び調整対象区域を図6

情報通信審議会情報通信技術分科会新世代モバイル通信システム委員会報告（令和 2 年

7 月 14 日）P123 表 4.2.1.2-1 より引用
120

3.3.2.2-1 に実線で示す。本実証に用いる無線機器はオムニパターンのアンテナを用いるため、水平/垂直面共に全ての方位で一律のアンテナ利得で補正をかける関係上、エリア図はカバーエリア、調整区域共に真円となる。なお、それぞれにエリア端までの距離は基地局アンテナからカバーエリアで 159m、調整区域で 241m となる。そのため、図 3.3.2.2-1(a)に示すように地下の壁面より先は土壌となり、それ以上の電波漏洩はないと仮定すると、閾値
＞壁面までの距離となることから、それぞれのエリア端は内壁までと推定する。

図 3.3.2.2-1(a) 仮説パラメータ R（=16.2dB）を用いて算出した
カバーエリアおよび調整対象区域（水平面）
つぎに、立体的な垂直面におけるエリア図作成手法として、図 3.3.2.2-1(b)に示す通り基地局アンテナが設置されるホーム下から、上階への損失として考慮すべき壁面（フロア）を、
ホームと地下 2 階フロア、地下 1 階フロアとする。なお、それぞれの壁面（フロア）の損失は仮説値である 16.2dB をそれぞれ考慮する。上記考えに基づく地下 2 階におけるエリア算
出では、ホーム（=16.2dB）＋地下 2 階フロア（=16.2dB）＝32.4dB の損失を R 値として見込むこととなり、基地局アンテナからのカバーエリア端は 63m、調整区域端は 88m となる。また、地下 1 階におけるエリア算出では、ホーム（=16.2dB）＋地下 2 階フロア（=16.2dB）＋地下 1 階フロア（16.2dB）＝48.6dB の損失を R 値として見込むこととなり、基地局アンテナからのカバーエリア端は 12m、調整対象区域は 25m となる。その場合、基地局からのカバーエリア端までの距離は地下 1 階フロア高よりも小さい値となるため、カバーエリア
端は地下 1 階フロア高までとなる。また、基地局からの調整区域端までの距離は地下 1 階
フロア高よりも大きい値となるため、地下 1 階のフロア高を超えたエリア図となる。

121

図 3.3.2.2-1(b) 仮説パラメータ R（=16.2dB）を用いて算出した
カバーエリアおよび調整対象区域（1 アンテナあたりの垂直面）

122

3.3.2.3 評価・検証項目
精緻化の対象パラメータ“R”について、仮設と実測結果から得られる知見の両方を用いて評価・検証を行い、実証環境における適切な R 値を導く。
また、この評価・検証において、実証環境におけるローカル 5G の電波伝搬モデルの精緻化に関する技術的課題を整理するとともに、それら課題の解決方策等についても考察を行う。
3.3.2.4 評価・検証方法（1）測定方法
測定については、以下の考え方で実施する。測定機器に関しては技術実証全体を通して同じであり 3.2 章にて記載している。

測定エリアの考え方
エリア算出法と比較を行うための下り受信電力値の実測は、設置した 3 つのアンテナ毎の R=16.2dB という仮説に基づくカバーエリアおよび調整対象区域において実施する。
各エリアは置局点に対し全方位で作図する必要があるため、精緻化後のエリア算出式の評価としては、ある一方向だけではなく、できるだけ全方位での実測を実施が望ましい。
そのため、図 3.3.2.4-1 の実測エリア内において置局点となるエリアおよび、階上のエリ
アにおいて、比較可能な測定点を選出して測定を実施し、地下駅及び階上の測定点で比較が可能となる様にする（図中赤●）。なお、観測された下り受信電力値が、エリア算出法により導出されるカバーエリア端、調整対象区域端の閾値と異なる場合はそれぞれの閾値が観測される範囲まで測定エリアを広げることとする。
ただし、建物の構造や障害物の存在等により立ち入りが難しい場所については測定地点をずらすなどで対応する。

123

図 3.3.2.4-1(a) エリア算出法に基づく測定地点

測定項目
一般的に 5GNR のエリア指標として用いられている SS-RSRP (Synchronization
Signal-Reference Signal Received Power)及び SS-RSRQ (Synchronization SignalReference Signal Received Quality)について実測する。
加えて、R 値に影響を与える実証環境のデータとして下記に示す情報を記録する。
 壁面の材質/厚さ/面積率
 対象の壁面と送信/受信点の位置関係測定手法と実測模様
各種データは、上記の考え方に基づき選定した測定地点に測定員が赴き、表 3.2-1 に示す測定器及び表 3.2-2 に示す設定値を用いて実測する。また、実証環境における電波伝搬
環境をより詳細に分析するため、各測定地点においては測定員の目視により見通し環境もしくは見通し外環境であるかを併せて記録する。ただし、建物の構造や障害物の存在等により立ち入りが難しい場所については測定地点をずらすなどで対応する。
SS-RSRP 及び SS-RSRQ は、エリアテスタを用いて、1000 サンプル/地点のログ取得を実施する。
なお、受信電力の測定においては、定在波の影響を避けるため、1 つの測定点において、10λ(λ は波長)の範囲で測定位置を動かしながら測定を実施する。
測定においては、歩行しながらの測定を効率的に実施するため、図 3.2-6 に示すような測定補助用の治具を作成して測定を実施する

124

（2）評価・検証方法
電波伝搬モデルの精緻化については 3.3.1 章、3.3.2 章で実測した各種データを用いて下記に記載する流れで評価・検証を進めていくこととする。

1）仮説 R 値に基づくカバーエリアおよび調整対象区域図の作成
実証環境内に設置する１つの基地局について、仮説 R 値に基づくカバーエリアおよび調
整対象区域の図を作成する。詳細は 3.3.2.2 章の実証仮説を参照されたい。

2）実測値から推定されるカバーエリア及び調整対象区域図の作成
1)で作成した仮説に基づくエリア図との比較を行う為、実測した各種データを図面上にプロットし、カバーエリア及び、調整対象区域の閾値から実測値による推定エリア図を作成する。

3）仮説に基づくエリア算出法と、実測値から推定されるエリア図との比較
仮説 R 値に基づくエリア図の妥当性を評価するため、①、②で作図したエリア図の比較を行う。また、カバーエリア及び調整対象区域のエリア端が異なる箇所においてはその差分値を取り纏める。

4）実測値から建物侵入損失を算出
R 値の精緻化のもう 1 つのアプローチとして、地下駅及び、階上エリアで実測した下り
受信電力値から建物侵入損失を算出する。なお、建物侵入損失とは、厳密には、建物近傍路上における受信レベルと建物中央部における受信レベルとの差を意味するが7、今回はエリア設計上ホーム上側への漏洩電力を対象としているため、ホーム下側の受信レベルとホーム上側の受信レベルの差分を建物侵入損として検証する（図 3.3.2.4-3）。
R＝地下駅階上エリア参照点の電界強度 – 地下駅ホームエリア測定点の電界強度
なお、安全上、ホーム下側での測定は困難であるため、アンテナ設置位置がホーム直下であることを考慮し、アンテナ設置位置の直上の測定地点を対象とし、測定地点方向における基地局からの空中線電力と観測される受信電力レベルの差から、ホームの遮へい損失を求めることとした。
また、今回の実証環境のみに有効な結論ではなく、他の環境でも有効な汎用的/一般的な成果を得るため、ホームの材質や、それに伴う面積率などを記録し、汎用的に利用可能な
R 値の精緻化を実施する。

7

進士「無線通信の電波伝搬」（P.241、1993 年）
125図 3.3.2.4-3①

実測値からの R 値算出手法

対象パラメータの精緻化

仮説に基づき設定した対象パラメータ“R”の値について、③の結果から得られる①、②エリア図の差分、④から得られる建物侵入損失の値を活用し、対象パラメータ“R”の値について精緻化を行う。
精緻化を行った対象パラメータ“R”を用いて、再度カバーエリア及び調整対象区域
図を作成し、図 3.3.2.4-2 に示す実測値から推定されるエリア図との比較を行うことでその妥当性を評価する。
5）精緻化パラメータの妥当性評価
仮説に基づき設定した対象パラメータ“R”の値について、3)の結果から得られる 1)、2)
エリア図の差分、4)から得られる建物侵入損失の値、5)から得られる建物占有面積率の値を活用し、対象パラメータ“R”の値について精緻化を行う。
精緻化を行った対象パラメータ“R”を用いて、再度カバーエリア及び調整対象区域図を作成し、実測値から推定されるエリア図との比較を行うことでその妥当性を評価する。

126

3.3.2.5 実証結果及び考察
実証環境における測定結果の取りまとめは、3.3.1.4（1）で取り纏めており、本章においてもそのデータを活用する。

（1）仮説 R 値に基づくカバーエリア及び調整対象区域図
図 3.3.2.2-1 にて、実証環境内に設置するそれぞれの基地局について、仮説 R 値に基づく
カバーエリアおよび調整対象区域の図を示す。
詳細は 3.3.2.2 章の実証仮説を参照されたい。

図 3.3.2.2-1(a) 仮説パラメータ R（=16.2dB）を用いて算出した
カバーエリアおよび調整対象区域（水平面）
（再掲）

127

図 3.3.2.2-1(b) 仮説パラメータ R（=16.2dB）を用いて算出した
カバーエリアおよび調整対象区域（1 アンテナあたりの垂直面）（再掲）

128

（2）実測値から推定されるカバーエリア及び調整対象区域図
図 3.3.2.5-2(a)～(b)に実測値から推定されるカバーエリア及び調整対象区域図を示す。併せて、図 3.3.2.5-3(a)~(c)には、測定時の周辺環境を示す。なお、エリア図の推定においては、定点による測定結果のみでは詳細な推定が困難であるため、実証環境周辺において立ち入り可能な場所を面的に測定した結果も参考にしつつ評価を実施している。
図中、赤線は 4.6-4.9GHz 帯におけるローカル 5G 審査基準で定められている“カバーエリア端レベル（100MHz 幅の場合：-84.6dBm）”を前提に実測値から評価した想定カバーエ
リア端である。一方、青線は、同様に審査基準で定められている“調整区域端レベル（100MHz
幅の場合：-91.0dBm）”を前提に実測値から評価した想定調整区域端である。なお、本実証に用いる基地局装置の下り受信レベル（SS-RSRP）の測定帯域は 30kHz であるため、上述したエリア端閾値を 100MHz から、30kHz へ帯域換算した以下の値を用いている。
カバーエリア端レベル（SS-RSRP 帯域換算）：-119.8dBm

調整区域端レベル（SS-RSRP 帯域換算）：-126.2dBm

結果からは、地下駅ホームエリアにおいては、アンテナを設置した 1 番線側に車両が配置される場合は、アンテナ設置位置から離れた測定点 ID25 以降において、調整対象区域が発生する事が判明した。これは、ホーム下にオムニ指向性アンテナを設置しているが、直近に車両がいる事による遮へい損失が発生したと考えられる。
一方で、地下駅階上エリアにおいては、地下駅からの出入り口となる階段の方向に沿って、強い漏洩電力が観測された。こちらは地下駅エリアでアンテナを設置しない 2 番線側に車両が配置された場合において強く観測されており、ホーム下にアンテナを設置した場合における車両位置によって、遮へい損失の差分が出たものと考えられる。
また、図 3.3.2.5-2(b)において、階上においてもアンテナ設置位置の直上でカバーエリア
閾値以上となる電力値を観測している。これは、図 3.3.2.5-2(b)に黄色塗りでマスキングした箇所においてエアダクト及び階段等の開口部が存在しており、天井面の遮へい損失に差分が出たものと考えられる。

図 3.3.2.5-2(a) 実測値から推定した
カバーエリアおよび調整対象区域：地下駅ホームエリア
129

図 3.3.2.5-2(b) 実測値から推定した
カバーエリアおよび調整対象区域：地下駅階上エリア

図 3.3.2.5-3(a) 地下駅における階層構造

図 3.3.2.5-3(b) 地下駅から階上に向かう階段の方向

130

図 3.3.2.5-3(c) 地下駅から階上に向かうエレベータの状況

131

（3）仮説に基づくエリア図と実測値から推定されるエリア図との比較
3.3.2.5 章（1）にて仮説値から算出したエリア図と、3.3.2.5 章（2）にて実測値から推定したエリア図の比較を行い、仮説値の妥当性を評価する。
図 3.3.2.5-4(a)~(b)に仮説値におけるエリア図と実測値から推定したエリア図を示す。
結果から、地下駅ホームエリアにおいては、ホーム床面による遮へい損失があったとしても、ホーム下に設置したアンテナ側に車両が配置されていない場合において、地下駅ホーム
エリア全体にカバーエリアが広がっている事が分かる。ホーム下に設置したアンテナ側に車両が配置される場合においては、駅ホームエリアのアンテナ設置点から離れた階段裏のエリアでカバーエリア端が見られ、調整対象区域となるエリアが見受けられる。これは、アンテナ開口部側に車両が配置される事により、車両による遮へい損失が増えたことが要因と考えられる。

図 3.3.2.5-4(a) 仮説値エリア図と実測値推定エリア図との比較（水平面）
ホーム階上エリアにおいては、垂直方向における測定地点数が少ないことから、電波漏洩観点でワーストケースとなる、アンテナ直上において、エリア算出法との比較を行う。図3.3.2.5-3(b)に示す、ホーム上の測定点 7 においては仮説値としてホームの損失（=16.2dB）を見込んだエリア算出法の受信電力値（＝-81dBm）と、実測値（＝-83dBm）の差分としては 2dB 程度となり、ホームによる損失 R 値は、概ね仮説通りの値となっていることが確認できる。一方で、階上の地下 2 階におけるアンテナ直上の測定点 55 においては仮説値としてホーム＋地下 2 階フロアの損失（＝32.4dB）を見込んだエリア算出法受信電力値（＝99dBm）と、実測値（＝-113dBm）の差分としては 14dB と大きく、地下 2 階フロアの損
失 R 値は、仮説値よりも 14dB 程度大きい値と考えられる。
これらの結果から、地下駅のホーム下に設置されたアンテナに対して、車両の有無に依らずに設計を行う為には。ホーム上のエリアと地下駅階上エリアの両面にてそれぞれの損失 R値を考慮する必要があると考えられる。その為、次節に示す実測値を用いた建物進入損失の132

導出においては、構造が異なるホーム床面とホーム天井面のそれぞれにおいて、その値を算出する。

図 3.3.2.5-4(b) 仮説値エリア図と実測値との比較（垂直面）

133

（4）実測値を用いた建物侵入損失の算出
R 値の精緻化のもう 1 つのアプローチとして、建物内/外で実測した下り受信電力値から建物侵入損失を算出する。なお、建物侵入損失とは、厳密には、建物近傍路上における受信レベルと建物中央部における受信レベルとの差を意味するが、今回はエリア設計上建物外への漏洩電力を対象としているため、それぞれの基地局アンテナから、直線上となる建物内
壁と建物外壁の電界強度差分を建物侵入損として検証する（図 3.3.2.4-3）。
R＝建物外参照点の電界強度 – 建物内部測定点の電界強度
また、純粋な壁面損失を算出するため、基地局から建物外参照点と建物内部測定点間の距離に応じた自由空間損失(FSPL)の差分を減算し補正するものとする。
なお、今回の実証環境のみに有効な結論ではなく、他の環境でも有効な汎用的/一般的な成果を得るため、壁面の材質や、それに伴う面積率などを記録し、汎用的に利用可能な R 値の精緻化を実施する。

図 3.3.2.4-3

実測値からの R 値算出手法（再掲）

図 3.3.2.5-5 及び表 3.3.2.5-1 に、実証環境における壁面損失算出対象の測定地点及び算出結果を示す。図中の黒矢印で結ばれる屋内測定点と屋外参照点において、壁面損失の導出を行う。なお、屋内測定点と屋外参照点の比較においては前述した手法により自由空間損失を補正しているが、その他損失は周辺環境要因にて異なり、建物外壁から遠方の屋外参照点は
その他損失の影響が支配的になる。そのため、自由空間損失以外が含まれると判断した屋外
参照点は精緻化対象から外している。
なお、図 3.3.2.5-5(a)に示す壁面 1（ホーム床面）については、屋内測定点に相当するホーム下での測定が困難であり、実測できていない。そのため、基地局から屋外参照点までの距離から自由空間損失を算出し、ホーム上の実測値から算出される伝搬損失と比較を行う
ことで、ホーム床面における損失 R 値を算出することとした。

134

図 3.3.2.5-5(a) 壁面 1（ホーム床面）精緻化対象測定地点135

表 3.3.2.5-1(a) 壁面 1（ホーム床面）精緻化結果
測定点 ID

基地局からの 3D 距離

自由空間損失実測値伝搬損失

（m）

(dB)

(dB)

R 値 (dB)

1

30.05

75.71

89.26

13.54

3

20.77

72.51

80.02

7.51

5

11.43

67.32

74.89

7.57

7

6.24

62.06

78.54

16.47

9

8.87

65.11

74.71

9.60

11

6.92

62.96

73.85

10.89

13

14.11

69.14

78.13

8.98

15

7.50

63.66

75.78

12.12

17

8.18

64.42

81.64

17.22

19

16.79

70.66

74.64

3.99

21

26.06

74.48

82.57

8.10

23

36.74

77.46

93.48

16.02

25

46.03

79.42

94.15

14.74

27

56.03

81.12

93.41

12.29

29

66.02

82.55

104.24

21.69

31

74.72

83.63

107.70

24.07

33

6.82

62.83

87.86

25.03

図 3.3.2.5-5(b) 壁面 2（ホーム天井面）精緻化対象測定地点136

表 3.3.2.5-1(b) 壁面 2（ホーム天井面）精緻化結果
比較対象
屋内 ID

屋外 ID

実測平均値 SS-RSRP (dBm)

自由空間

電界強度差分

屋内測定点

損失差分 (dB)

(dB)

屋外参照点

R 値 (dB)

1

57-94.59-114.85

1.64

20.26

18.62

3

57

-84.27-114.85

1.57

30.57

29.00

3

69

-84.27-128.24

0.50

43.97

43.47

11

74

-78.16-136.40

4.76

58.24

53.48

13

74

-82.84-136.40

1.43

53.56

52.14

17

77

-86.29-132.67

3.90

46.38

42.48

19

78

-78.97-130.86

0.26

51.89

51.63

21

78

-87.22-130.86

3.56

43.64

40.08

表 3.3.2.5-2 に表 3.3.2.5-1 にて算出した R の精緻化値と対象壁面の材質/厚さ/面積率を示す。なお、精緻化値については壁面ごとに算出した R 値の平均値を記載している。図 3.3.2.56 にフロアごとの測定状況を示す。
結果からは、以下のことがわかる。
壁面 1 においては、仮説値よりも精緻化値が 3dB 程度小さい値となる。これは、本実証
環境の様な閉空間では反射波が多く、マルチパスの影響により測定地点では強い受信電力が観測され、実測値における伝搬損失が小さく算出されている。そのため、比較対象としている自由空間損失は基地局からの一つの直接パスでしかないため、その考慮差分が影響していると考えられる。
壁面 2 においては、仮説値よりも精緻化値が 25dB 程度大きい値となる。これは、仮説値で用いている R 値は窓ガラス等の開口部が存在する壁面における損失であり、今回の実証
環境の様な地下鉄駅構内におけるフロアは開口部がほとんど存在せず、厚さも 5cm 程度と堅牢であるため、その環境差分が影響していると考えられる。
表 3.3.2.5-2 4.7GHz 帯における実証環境 R 値
周波数

建物4.7GHz

代表値
壁面 1

材質

厚さ

面積率

仮説値

精緻化値

R(dB)

R [dB]
16.2

コンクリート

100mm

100%

16.2

13.5

コンクリート

500mm

100%

16.2

41.4

コンクリートで構成された、地下鉄駅の
ホーム床面
壁面 2
コンクリートで構成された、地下鉄駅の
天井面

137

図 3.3.2.5-6(a)ホーム下 アンテナ設置位置の状況

図 3.3.2.5-6(b) 壁面 1：ホーム床面参照点の状況

138

図 3.3.2.5-6(c) 壁面 2：ホーム階上の参照点の状況

139

（5）精緻化パラメータの妥当性評価
3.3.2.5 章(4)及び、3.3.2.5 章(5)にて精緻化を行った対象パラメータ“R”を用いて、再度カバーエリア及び調整対象区域図を作成し、実測値から推定されるエリア図との比較を行うことでその妥当性を評価する。なお、今回精緻化対象としている、壁面はホーム床面及び地下 2 階フロアとなるため、垂直面におけるエリア図と実測値の比較を行い、その妥当性を評価する。
図 3.3.2.5-7 に精緻化後のパラメータを用いて算出したカバーエリア及び調整対象区域図を示す。図中破線は 3.3.2.2 章で示す仮説値 R（16.2dB）におけるエリア図であり、実線は
壁面ごとに表 3.3.2.5-2 に示す精緻化値 R を考慮したエリア図である。垂直面におけるエリア図の作成手法については 3.3.2.2 章実証仮説を参照されたい。
結果から、精緻化値 R に基づくエリア図では、地下 2 階における損失 R 値が 41.4dB と仮説値よりも大きくなることで、地下 1 階フロアにおいても地下 2 階フロアよりも床面が厚くなることを考慮すると、同等に損失 R 値としては大きくなると考えられる。そのため、
地下 1 階への電波漏洩は無いものとすると、エリア図としてはカバーエリア及び調整対象
区域が地下 2 階に収まる結果となった。

図 3.3.2.5-7(a) 精緻化パラメータを用いたカバーエリア及び調整対象区域図（垂直面）
図 3.3.2.5-8 に精緻化後のパラメータを用いて算出したカバーエリア及び調整対象区域図と実測値から推定したカバーエリア及び調整対象区域図との比較結果を示す。
結果から、図 3.3.2.5-8 に示す、ホーム上の測定点 7 においては精緻化値であるホームの損失（=13.5dB）を見込んだエリア算出法の受信電力値（＝-78dBm）と、実測値（＝-83dBm）
140の差分としては 5dB 程度となり、階上の地下 2 階におけるアンテナ直上の測定点 55 においては精緻化値である地下 2 階フロアの損失（＝41.4dB）を見込んだエリア算出法受信電力値（＝-108dBm）と、実測値（＝-113dBm）の差分としては 5dB となる。これらの差分として、精緻化値の算出では複数の測定地点における損失差分の平均値を用いており、一部
エアダクト等による開口部や車両配置等による反射影響などの特異的な環境差分が含まれていたためと考えられる。
これらの結果から、地下鉄駅における階層的なエリア図は、そのフロア毎の損失 R 値を見込むことで、概ね推定できることが確認できると考えられる。また、精緻化値から推定されるエリア図は地下 2 階で収まることから、地上への調整対象区域レベルでの電波漏洩はほぼないと考えられる。そのため、本実証環境の様な地下鉄にエリア構築を実施する場合は地上における干渉調整は不要であると想定されるが、同フロアもしくは階上において他の無線局が運用される場合は、間に存在する階層によってその調整可否が決まるものと考えられる。

図 3.3.2.5-8 精緻化エリア図と実測値推定エリア図との比較（垂直面）

141

（6）技術的課題の解決方策
今回の実証では、地下駅環境に置局したローカル 5G 基地局 1 局に対し、ホーム下に 3 つのオムニ指向性のアンテナを張り出した環境を活用し、地下駅環境におけるエリア算出法
パラメータ R 値の精緻化を実施した。その結果精緻化値から推定されるエリア図は地下 2階で収まることから、地上への調整対象区域レベルでの電波漏洩はほぼないと考えられる。
そのため、本実証環境の様な地下鉄にエリア構築を実施する場合は地上における干渉調整は不要であると想定されるが、同フロアもしくは階上において他の無線局が運用される場
合は、間に存在する階層によってその調整可否が決まるものと考えられる。
これらの結果から、自己土地となる地下駅ホームエリア以外への電波漏洩の観点では、前述した通り、地下駅ホームエリアの開口部となるエアダクト、エレベータ、階段等が存在す
る箇所は精緻化値よりも強い傾向となる。その場合、他者土地にて他のローカル 5G システ
ムが運用される場合は、互いに干渉調整が必要となる事から、サービスエリア内のカバレッ
ジを十分にとりつつ、出来る限り調整対象区域を抑える置局設計が求められる。
本実証では、オムニ指向性のアンテナをホーム下に配置したが、階上に向かう開口部にて電波漏洩が強く出ているため、オムニ指向性アンテナを用いる場合は、できるだけ開口部から離れた場所での置局が望ましいと考えられる。
また、セクタ指向性のアンテナを用いて、天井面方向もしくは、他のローカル 5G システ
ムが運用される方向は、バックローブとなるような置局設計も有効であると考えられる。

142

3.3.3 電波反射板によるエリア構築の柔軟化「本テーマには取り組まない」

3.3.3.1 実証の目的・目標（1）背景となる技術的課題と実証目的「本テーマには取り組まない」（2）実証目標「本テーマには取り組まない」

3.3.3.2 実証仮説
「本テーマには取り組まない」

3.3.3.3 評価・検証項目「本テーマには取り組まない」

3.3.3.4 評価・検証方法「本テーマには取り組まない」

3.3.3.5 実証結果及び考察「本テーマには取り組まない」

3.3.4 準同期 TDD の追加パターンの開発「本テーマには取り組まない」

3.3.4.1 実証の目的・目標（1）背景となる技術的課題と実証目的「本テーマには取り組まない」

143

（2）実証目標「本テーマには取り組まない」

3.3.4.2 実証仮説
「本テーマには取り組まない」

3.3.4.3 評価・検証項目「本テーマには取り組まない」

3.3.4.4 評価・検証方法「本テーマには取り組まない」

3.3.4.5 実証結果及び考察「本テーマには取り組まない」
3.3.5 その他のテーマ「本テーマには取り組まない」

3.3.5.1 実証の目的・目標（1）背景となる技術的課題と実証目的「本テーマには取り組まない」（2）実証目標「本テーマには取り組まない」

3.3.5.2 実証仮説
「本テーマには取り組まない」

144

3.3.5.3 評価・検証項目「本テーマには取り組まない」

3.3.5.4 評価・検証方法「本テーマには取り組まない」

3.3.5.5 実証結果及び考察「本テーマには取り組まない」

3.3.6 技術実証における追加提案「本テーマには取り組まない」

3.3.6.1 協力内容
「本テーマには取り組まない」

3.3.6.2 評価・検証項目「本テーマには取り組まない」

3.3.6.3 評価・検証方法「本テーマには取り組まない」

3.3.6.4 実証結果及び考察「本テーマには取り組まない」

145

4. ローカル５Ｇ活用モデルの創出・実装に関する調査検討（課題実証）
4.1 実証概要
1.2 章で記載したとおり、京浜急行電鉄羽田空港第 1・第 2 ターミナル駅に構築したロー
カル 5G を活用し、フル HD 映像の AI 解析による車両検査の遠隔・自動監視システムを構築し、現場のオペレーションへの対応及び複数デバイスの長期安定運用を見据えて、車両台車の遠隔監視の高度化・実装を図る実証を実施した。

4.2 背景となる課題を踏まえた実装シナリオ・実証目標
1.1 章で記載したとおり、「令和 2 年度

地域課題解決型ローカル 5G 等の実現に向けた開発実証に係るインフラ分野におけるローカル 5G 等の技術的条件及び利活用に関する調査検討の請負（遠隔・リアルタイムでの列車検査、線路巡視等の実現）」の実証事業では、
京浜急行電鉄久里浜工場で実装可能な車両検査の遠隔・自動監視技術を生み出した。具体的には、京浜急行電鉄久里浜工場に入車・出車する車両台車の 4K カメラ映像の AI 解析により、微細なき裂を検出すると共に、ヒューマンエラーを抑止する目的で、ハンドルの開きやブレーキパッドのすり減りを検出し、1 秒未満で現地の運用担当者に伝送することに成功している。（図 4.2-1 参照）

図 4.2-1

令和 2 年度の車両検査の遠隔・自動監視システム実証の振り返り（再掲）146今年度は鉄道駅での実装に向けて、サーバやカメラなどの機材のコストを抑えつつ、スピードのある車両の監視ができることや、短い間隔で列車が発着する合間に処理遅延を蓄積することなく AI 解析処理を行う必要がある。処理遅延を蓄積させないためには、列車がホームに入線後に停止する時間、もしくは出線後、次の列車が入線するまでの時間は最短で 2分間であることが時刻表からわかっており、その間に AI 解析を含むサーバ処理を完了させることが必須となる。
表 4.2-1

京浜急行電鉄羽田空港第 1・第 2 ターミナル駅の 1 番線時刻表（再掲）147上記の前提をふまえ、実装に向けて図 4.2-2 のイシューツリーに示す令和 2 年度の課題を解決するための検討を行うとともに、本実証における運用担当者の意見等を収集し、今後の実装について検討した。

図 4.2-2

実証背景（令和 2 年度の残課題）

図 4.2-3~図 4.2-5 のイシューツリーに示すように実装に向けた課題が残り、それらの解決に向けた対策を検討する必要があることが判明した。
環境要因に関する分析を図 4.2-3 に、必要な対策に関する検討を表 4.2-2 に示す。

図 4.2-3

環境要因に関するイシューツリー
148

表 4.2-2 環境要因での機能低下防止に必要な対策に関する検討
発生要因
必要な対策に関する検討
検出対象物【車速変化対応 0-120km/h】
・時速 10km までは撮影可能だったが、10km 時点で垂直方向のき裂検
出精度は低下した。
・実装時を想定すると、より高速移動する車両の映像撮影・解析が必要となる可能性がある。（Ⅰ）
【設置位置対応（対象まで 50cm 以下）】
・昨年度は設置位制約がなく、撮影対象まで約 2m での検証を実施した。
・実装を想定すると、駅ホーム下空間というより撮影対象の近傍への設
置（50cm 以下）が必要となる。このとき、事前の施工性の確認が必要である。（Ⅱ）・また、カメラの画角に収まる範囲がかなり限定されるため、より広角のレンズ導入など検討が必要である。 （Ⅲ）
周辺環境【天候・時間帯による照度変化への対応】
・天候や時間帯によって日照状況が変化し、カメラ機材の撮影性能に影響を及ぼし AI 検出性能が低下した。
・実装時を想定すると、より暗い環境での映像撮影・解析が必要となり、照度の補完が必要となる。 （Ⅳ）

149

長期安定性に関するイシューツリーを図 4.2-4 に、必要な対策に関する検討を表 4.2-3 に示す。

図 4.2-4長期安定性に関するイシューツリー

150

表 4.2-3 システムの長期安定を確保するために必要な対策に関する検討（1/2）
発生場所
必要な対策に関する検討
映像撮影機材【現地の防水防塵対策】
・昨年度は比較的乾燥した広い環境に汎用カメラを設置することができた
ため、異常は発生しなかった。
・駅のホーム下に設置される実装時を想定すると、より湿気が多く、かつ車両に近いため金属粉も舞いやすいと想定される、防水防塵対応済みの機材の選択が必要である。
車 両 映 像 配 信 【現地の防水防塵対策】
用デバイス
・昨年度は映像配信用デバイスとしてシングルボードコンピュータを、比較的乾燥した広い環境で使用していたが、一度金属粉によるコンピュータのインターフェース故障（接触不良）が発生し、機材交換対応を行った。
・駅のホーム下に映像配信用デバイスが設置される実装時を想定すると、駅のホーム下は、より湿気が多く、かつ車両に近いため金属粉も舞いやすいと想定されるため、映像配信用デバイスが GPU 搭載ノート PC であれ、
シングルボードコンピュータであれ、より入念な防水防塵対策が必要である。
【熱暴走対策】
・昨年度は、運用時に機材が発熱し熱暴走の恐れがあったため、アルミ板・
空冷ファンを用いて事前の予防策を講じた。結果として、映像配信用デバイスとしてのシングルボードコンピュータの熱暴走は発生しなかった。
・駅のホーム下に映像配信用デバイスが設置される実装時を想定すると、設置位置の制約が大きいため、大がかりな冷却対策を講じることができないため、映像配信用デバイスが GPU 搭載ノート PC であれ、シングル
ボードコンピュータであれ、小型で冷却効率の高い構成を検討する必要があるとともに、発熱による影響がある機材の設置位置を工夫することで熱対策を講じる必要がある。
5G ルータ【現地の防水防塵対策】
・昨年度は比較的乾燥した広い環境にであったため、異常は発生しなかった。
・実装時を想定すると、より湿気が多く、かつ車両に近いため金属粉も舞いやすいと想定される。そのため、5G ルータの防水防塵対策が必要である。
【熱暴走対策】
・昨年度は、運用時に機材が発熱し熱暴走の恐れがあったため、アルミ板・
空冷ファンを用いて事前の予防策を講じた。しかし、遠隔監視中に 5G ルータの電源が落ちてしまうことが度々あった。（電源が落ちた時点で充電自体は十分であり、筐体から機材の発熱を確認したため、熱暴走によるものと判断した。）
・実装時を想定すると、設置位置の制約が大きいため、大がかりな冷却対策を講じることができないため、小型で冷却効率の高い構成を検討する必要
がある。

151

表 4.2-3 システムの長期安定を確保するために必要な対策に関する検討（2/2）
発生場所
必要な対策に関する検討
映 像 伝 送 シ ス 【故障頻度と故障時間の短縮】
テム・昨年度は、映像伝送システムの処理ができず、フリーズやダウンすることがあった。
・実装時を想定すると、より安定性の高い映像伝送システムを構築する検討を行う必要がある。具体的には、エラーハンドリング（エラーを吐いても継続処理しつつトラブルシュートを検討）や効果的なロギング設定を行
い、運用時の故障回数低減、故障時間短縮化を実現する必要がある。
AI 解析エンジ 【故障頻度と故障時間の短縮】
ン
・昨年度は、AI 解析エンジンが運用中にダウンすることはなかったが、時折、エラーが発生時に人の手でシステムを停止する必要があったり、シス
テムの主系統・予備系統を切り替える際やエラーハンドリングに時間を要したりすることがあった。
・実装時を想定すると、エラーハンドリング（エラーを吐いても継続処理しつつトラブルシュートを検討）や効果的なロギング設定を行い、運用時の故障回数低減、故障時間短縮化を実現する必要がある。

152

必要性能のための機能追加に関するイシューツリーを図 4.2-5 に、必要な対策に関する検討を表 4.2-4 に示す。

図 4.2-5

必要性能のための機能追加に関するイシューツリー
153

表 4.2-4
発生要因
映像撮影機材

必要性能のための機能追加に必要な対策に関する検討（1/2）
必要な対策に関する検討【対象の速度、照度への対応】環境要因課題（Ⅲ）、（Ⅳ）と共通
・駅のホーム下に設置され、入線・停止・出線する車両を撮影するという実装を想定すると、車両の速度によってカメラの画角に収まる範囲
がかなり限定されるため、より広角のレンズ導入など検討が必要である。
・駅のホーム下に設置される実装時を想定すると、より暗い環境での映像撮影・解析が必要となり、照度の補完が必要となる。
車両映像配信用デ 【無線リソースの効率活用に向けた追加処理】
バイス
・昨年度は、映像配信用デバイスとしてシングルボードコンピュータを使い、カメラ機材が撮影する映像を圧縮してストリーミング伝送し、問題なく伝送することができていた。
・実装時を想定すると、車両の速度対応のため複数のカメラを設置し、複数系（3 系）から同時にアップロードする必要がある。このとき、無線リソースの帯域がひっ迫することが想定されるため、無線帯域の効率活用に向けた前処理が必要となる。
・複数台のフル HD カメラで撮影された映像をリアルタイムで適切な映像フォーマット（H.264）へリアルタイムに近しい高速度でのコーデッ
ク変換し、WebRTC で AI 解析基盤へ配信可能な GPU を実装した GPU
搭載ノート PC での追加処理が必要になる。
・カメラを複数台設置することから、1 台のカメラが捉えるべき車両を限定でき、中～低速域の車両が撮影できれば良くなり、フレームレート（fps）を下げることにより、対象車両を撮り逃すことなく捉えられるパラメータで構築する。
5G アンテナ、ルー 【無線リソースの効率活用に向けた設置】
タ・昨年度は設置位置の制約がなく、5G 基地局のアンテナ直下に端末を設置できたため、クラウド環境との通信スループットは最大で約90Mbps となった。1 系統の 4K 映像を通すには十分なスループットであり、検証するうえで重大な課題とはならなかった。
映像伝送システム【複数インプットの処理】
・昨年度は、4K 映像は 1 系統のみのインプットであった。このときは、
WebRTC により問題なく伝送することができた。
・実装時を想定すると、複数の機材からフル HD 映像をインプットし、同時並行的に伝送しなければならず、追加開発と検証が必要となる。
【複数拠点へのアウトプット処理】
・昨年度は 1 拠点の遠隔監視 PC への伝送を行った。このときは、
WebRTC により問題なく伝送することができた。
・実装時を想定すると、複数拠点で同時並行的に映像を確認し、実運用の対応にシームレスにつなげることが必要である。そのため、複数拠点からアウトプット映像の確認ができるよう追加開発と検証が必要と
なる。

154

表 4.2-4
発生要因
AI 解析エンジン

必要性能のための機能追加に必要な対策に関する検討（2/2）
必要な対策に関する検討【複数インプットの処理】
・昨年度は、4K 映像は 1 系統のみのインプットであり、これをクラウド
インスタンス上の複数 GPU に分散して処理を行った。このときは問題なく処理を遂行することができた。
・実装時を想定すると、複数のフル HD 映像インプットを同時並行的に、インスタンス上の複数 GPU を用いて処理することが必要で、n:n の複雑な処理が求められる。そのため、これを実現する機能の追加開発と検証が必要となる。
【解析フレームの最適化調整】
・昨年度は、4K 映像は 1 系統のみのインプットであり、これをクラウド
インスタンス上の複数 GPU に分散して処理を行った。このときは問題なく処理を遂行することができた。
・実装時を想定すると、複数のフル HD 映像インプットを同時並行的に、インスタンス上の複数 GPU を用いて処理することが必要で、n:n の複雑な処理が求められる。そのため、これを実現する機能の追加開発と検証が必要となる。

ノート PC（汎用品）【ブラウザ投影の UI 構築】
・昨年度は 4K 映像インプットについては、1 系統のみの処理を行い、それに適した UI を構築した。
このときは、
WebRTC により問題なく Web
サーバに伝送し、適切な表示ができていた。
・実装時を想定すると、複数の機材からフル HD 映像をインプットし、Web サーバが複数のインプット映像を同時並行的に受け取った上で表示しなければならない。これに適した表示 UI と合わせて、追加開発と検証が必要となる。

タブレット
（汎用品）

同上

今年度の実証においては、列車検査の遠隔・自動監視システムの実装のための環境要因、
長期安定性、性能面の観点での課題分析・解決を行うことを目指しており、実装を見据えた場合、利用者の理解という環境要因の観点を盛り込みつつ、かつ目指す成果に影響が出ない
実現可能な構成を取ることが必要である。

155

4.3 実証環境
実証環境に関する模式図を下記に示す。

図 4.3-1

実証環境概要156

第 2.2.8 章でも記載したとおり、ローカル 5G 活用モデルの創出・実装に関する調査検討（課題実証）のための、車両検査の遠隔・自動監視システムを構築した。その全体イメージを図 4.3-2 に、システム構成を図 4.3-3 に示す。

図 4.3-2

車両検査の遠隔・自動監視システムの全体イメージ図

図 4.3-3

車両検査の遠隔・自動監視システム構成

157

4.4 実証内容
4.4.1 ローカル 5G を用いたソリューションの有効性等に関する検証
4.4.1.1 効果検証
（1）評価・検証項目
通信性能
通信性能に関する評価・検証項目を表 4.4.1.1-1 に示す。今年度は複数のカメラからのイ
ンプット及び複数拠点でのアウトプットに関する通信性能の効果検証をアジャイル的に実施した。システム構築を進めるなかで、システムを設置する現場環境の確認を実施し、実運用を見据えた機材選定や長期安定性を考慮した機材設置場所の見直しなどを踏まえ、シス
テム構成変更に伴い検証項目の見直しも行った。
表 4.4.1.1-1
対象機能

No.
1

通信性能に関する評価・検証項目
評価項目
評価項目の詳細ローカル 5G の通信機

システム End-End 間及び各区間

・上りスループット

能

の通信性能

(TCP,UDP)
・下りスループット・実証フィールド ～ ローカル
・ローカル 5G 基地局 ～ 専用線(TCP,UDP)
・遅延量(VPN 網) ～ クラウドサーバ

・ドロップ数/率

5G 基地局(dOIC)
・開発拠点～ Internet ～ クラウドサーバ(dOIC)
2システム End-End 区間におけるネットワーク基本性能（実証フィールド ～ dOIC
開発環境）

・映像インプットから
画面表示までの～End2End の遅延量
・スループット
・測定間隔
・解像度
・フレーム
・各リソース量158

UI・映像伝送システム
UI・映像伝送システムでは、録画映像に AI 解析エンジンから取得した映像と時刻同期した検出座標データを映像上に重畳させ、バウンディングボックスとして表示させた。
UI・映像伝送システムに関する評価・検証項目を表 4.4.1.1-2 に示す。今年度は複数のカ
メラからのインプット及び複数拠点でのアウトプットに関する UI・映像伝送システムの効果検証をアジャイル的に実施した。実装を見据えたシステム構成としたため、サーバのコストを抑えたことで映像解析に 1 分程度かかることが机上検討で判明した。ライブ映像に AI
解析結果の矩形を表示させるためにはライブ映像に AI 処理時間の分だけ遅延処理を行う必要があるが、使用したソフトウェアの制約で遅延処理の上限を超えており、ライブ映像に AI
解析結果の矩形を表示させることが困難となった。検査から検査までの間に台車の異常が発生するケースは極まれであり、リアルタイムで映像確認を行う監視員を常駐させることは非効率である。このため、実運用の際には異常通知を発出する機能を付加し、異常を確認する運用を想定するという結論に至り、AI 解析結果は録画映像に表示させることで設計し、評価項目の見直しも行った。
羽田空港第 1・第 2 ターミナル駅 1 番線ホームにて、運行中の列車車両の異常を検出する
今回の実証環境においては、車両の入線完了～出線完了および出線完了～入線完了までの時間枠でシステムの処理を終えなければ処理が積み上がってしまい、システムが異常情報をアウトプットするまでの処理遅延が次々と蓄積されることとなる。そのため羽田空港第1・第 2 ターミナル駅 1 番線の運行スケジュールに則り、車両の入線～出線、および出線～
入線までの、AI 解析の対象とならない時間の最短である 2 分間で映像伝送、AI 解析などを含むシステム処理を完了させる必要がある。このため、時刻表上の列車の発着時刻から本シ
ステムで車両の異常情報をアウトプットする（ユーザが確認可能な状態とする）までのシス
テム処理時間の目安を 2 分以内とした。なお、サーバ処理遅延の蓄積を回避することを目標としたため、ユーザが監視画面で映像を閲覧する下り通信の時間は 2 分間には含まない。

No1

表 4.4.1.1-2 UI・映像伝送システムに関する評価・検証項目
対象機能
評価項目
評価対象
映像伝送

伝送・表示性能（遅延等） 単一拠点の遠隔監視席における映像の視認性

2

3

複数拠点の遠隔監視席における映像の視認性

AI 解 析

AI 解析結果との連携性能

単一拠点の遠隔監視席における AI 解析結果の結果表示（時刻同期等）視認性

4

複数拠点の遠隔監視席における AI 解析結果の
視認性

5

実用可能

利用者の体感

複数拠点の遠隔監視席における映像の視認性

性
6

複数拠点の遠隔監視席における AI 解析結果の
視認性

159

160

AI 解析エンジン
AI システム事前検証において AI の学習及び教師データの取得を行うとともに、実証期
間中には、羽田空港第 1・第 2 ターミナル駅 1 番線に固定設置されたフル HD カメラで撮影した車両台車の状態のフル HD 映像をリアルタイムで AI 解析して、台車のき裂等の異常を検出した。
AI 解析エンジンについては、構成面（パフォーマンス）と検出性能面についてアジャイ
ル的に検証した。AI 推論処理の精度の評価にあたり、昨年度は疑似き裂として透明なシー
ルに細い線を印刷したものを使用したが、長期間にわたり車両が走行するうちに剥がれ落ちる恐れがあった。このため、評価の方法について京浜急行電鉄車両部とディスカッション
し、油性黒ペンで台車に線を描くことで疑似き裂とすることにした。
また、ディスカッションを通して、全体で約 800 両ある京浜急行電鉄の車両のうち、疑似き裂を記入した車両が、羽田空港第 1・第 2 ターミナル駅にいつ入線するかを事前に把握することは、運用上困難であるという制約が判明した。このため、疑似き裂を記入する車両
を羽田空港第 1・第 2 ターミナル駅に入線する 6 両編成の列車に限定し、6 両編成列車 39
編成のうち 24 編成に記入することで、疑似き裂を記入した車両が入線する確率を高めることとした。
AI 構成面に関する評価・検証項目を表 4.4.1.1-3 に示す。今年度は複数のインプット映像の処理に関する AI 解析エンジンの効果検証を実施した。
表 4.4.1.1-3
No
1

AI 構成面に関する評価・検証項目
評価項目

対象機能

計算リソースに応じた AI 解析速度

理論的に処理可能なフレーム数確認（机上検討）

2

複数インプット映像の処理

同時並行処理における処理フレーム数確
認（実測値の統計評価）

続いて、AI 検出機能面に関する評価・検証項目を表 4.4.1.1-4 に示す。
表 4.4.1.1-4
No

AI 検出機能面に関する評価・検証項目

対象機能

評価項目

1

AI 推論処理の速度

処理時間

2

AI 推論処理の精度

検出精度

3

AI 推論処理の精度

検出限界速度4

その他

その他：解析対象の汚れや周辺環境の影響

5

実用性（定性評価）

利用者体感等

その他（現場環境）
161

その他（現場環境）
その他（現場環境）に関する評価・検証項目を表 4.4.1.1-5 に示す。今年度は AI 検出性能の環境適応性やカメラ機材等の長期安定性に関する効果検証をアジャイル的に実施した。
今年度実証は検車区ではなく実際の駅で検証を行うため、駅のホーム下に設置した機材に直接触れて調整するハードルが高いことを受け、照度の比較検証については夜間に線路に立ち入りが可能な環境を作り実施するなどの工夫が必要となった。

No
1

2

3

表 4.4.1.1-5 その他（現場環境）に関する評価・検証項目
対象機能
評価項目
評価内容
環境適応性

照度変化に

現場に設置した照明機材を調整し、異なる照度環境（照度）ともなう AIを構築した上で、照度の違いが取得映像の品質や AI

検出性能

解析性能に及ぼす影響を評価し、改善する。

環境適応性

対象物の色

対象物（車両台車等）の色合い変化に応じた AI 検出

（対象物の

合い変化に

性能を評価し、改善する。特に検出精度が低くなる

色合い）ともなう AI

色合いなどが見られる場合は、要因分析と重点的な検出性能追加学習を行い、改善を試みる。

カメラ機材

現場に設置したカメラ機材の連続稼働時間を評価すの連続稼働る。機材停止を確認した時点で切り分けを行い、時間

PDCA を通じて停止要因を改善し、再度検証を実施

長期安定性

する。
4

長期安定性

GPU 搭載ノ現場に設置した GPU 搭載ノート PC の連続稼働時間

ート PC の連を評価する。機材停止を確認した時点で切り分けを続稼働時間行い、PDCA を通じて停止要因を改善し、再度検証を実施する。

5長期安定性

5G ルータの現場に設置した 5G ルータの連続稼働時間を評価す

連続稼働時る。機材停止を確認した時点で切り分けを行い、間PDCA を通じて停止要因を改善し、再度検証を実施
する。

162

（2）評価・検証方法
通信性能a）ローカル 5G 区間の通信性能実証フィールド～ ローカル 5G 基地局の区間において、通信プロトコル TCP 及び UDPを使った上りスループット値および下りスループット値、遅延量を計測し、本実証環境におけるネットワーク該当区間の通信性能を定量評価した。現時点では映像のアップロードでUDP 通信を使用しているが、将来的に TCP 通信が必要なユースケースを想定し、通信ス
ペックを確認するため今回の検証内で測定を行った。

図 4.4.1.1-1

End-End 区間の通信性能試験◯測定区間（L5GUE 配下）ホーム下 試験 PC〜ローカル 5G 基地局◯測定項目：
1：上り方向スループット計測(TCP、UDP)※iperf2：下り方向スループット計測(TCP、UDP)※iperf▼パラメータ：bandwidth 800Mb、MTU：1460B、送信時間 60s、表示インターバル 1s、開始 8s を計測除外

計測値：bandwidth 、jitter、lost/total パケ

ット数、 ※3 回の計測、またその平均
3：レイテンシ（RTT）※ping▼パラメータ：(フラグメントしない値)、送信時間 60s、表示インターバル 1s、
計測値：min/avg/max/stddev※3 回の計測、またその平均b）専用線区間の通信性能
専用線区間（ローカル 5G 基地局 ～ 専用線 (VPN 網) ～ クラウドサーバ(dOIC)）において、通信プロトコル TCP 及び UDP を使った上りスループット値および下りスループッ
ト値、遅延量を計測し、本実証環境におけるネットワーク該当区間の通信性能を定量評価した。現時点では映像のアップロードで UDP 通信を使用しているが、将来的に TCP 通信が必要なユースケースを想定し、通信スペックを確認するため今回の検証内で測定を行った。

163

図 4.4.1.1-2

専用線区間の通信性能試験◯測定区間（羽田空港第 3 ターミナル駅通信機器室 ラック内）試験 PC〜VPN プライオ経由〜dOIC
WebRTC インスタンス◯測定項目：
1：上り方向スループット計測(TCP、UDP)※iperf2：下り方向スループット計測(TCP、UDP)※iperf▼パラメータ：bandwidth 800Mb、MTU：1460B、送信時間 60s、表示インターバル 1s、開始 8s を計測除外

計測値：bandwidth 、jitter、lost/total パケット数、 ※3 回の計測、またその平均
3：レイテンシ（RTT）※ping▼パラメータ：(フラグメントしない値)、送信時間 60s、表示インターバル 1s、計
測値：min/avg/max/stddev※3 回の計測、またその平均c）クライアント～dOIC 区間の通信性能
監視拠点クライアント～dOIC 区間において、通信プロトコル TCP 及び UDP を使った
上りスループット値および下りスループット値、遅延量を計測し、実際にユーザが映像確認を実施する監視拠点における通信性能を定量評価した。なお、本実証では実装に向けて、多拠点で場所の制約なく映像を確認できることを前提とし、固定 IP アドレスを割り振り接続元の制限をかけたモバイル端末によるインターネット接続を使用した。このため、通信性能を評価した区間はインターネットの区間を含むものである。映像の再生に UDP,それ以外の操作には TCP を使用しているため、それぞれの項目を測定した。

図 4.4.1.1-3

クライアント～dOIC 区間の通信性能試験
164

◯測定区間（監視拠点を想定）試験 PC〜インターネット経由〜dOIC Web サーバ インスタンス◯測定項目：
1：上り方向スループット計測(TCP、UDP) ※iperf
2：下り方向スループット計測(TCP、UDP) ※iperf▼パラメータ：bandwidth 800Mb、MTU：1460B、送信時間 60s、表示インターバ
ル 1s、開始 8s を計測除外

計測値：bandwidth 、jitter、lost/total パケット数、※3 回の計測、またその平均
3：レイテンシ（RTT）※ping▼パラメータ：(フラグメントしない値)、送信時間 60s、表示インターバル 1s、計測
値：min/avg/max/stddev ※3 回の計測、またその平均d）End-End 通信遅延確認
実証フィールド～ ローカル 5G 基地局 ～ 専用線 (VPN 網) ～ クラウドサーバ(dOIC)の End—End 区間において、ストリーミング配信する際の遅延時間を計測した。

図 4.4.1.1-4

End-End 区間でストリーミング配信する際の遅延確認◯測定区間（監視拠点を想定）GPU-PC(momo)〜VPN プライオ経由〜dOIC Web サーバ インス
タンス〜Web サーバインスタンス〜監視拠点 PC◯測定項目：WebRTC 設定確認（フル HD カメラ時 送信パラメータ：12Mbps）、フレーム数：（20fps）
1：End-End 遅延時間計測：デジタル時計（msec 表示）と伝送後表示モニタを同時撮
影し、遅延量を確認
2：内容ア：ノート PC 上の Chrome WebRTC デバッグ（解像度、再生中フレーム数、
受信フレーム数、デコードフレーム数、ドロップフレーム数）
3：内容イ：コンピュータのリソース確認：Xavier NX（Momo）、WebRTC インスタンス（Sora）、受信ノート PC（Chrome 動作機）、CPU、MEM、GPU のリソース
165

推移
なお、長期安定性の観点から onvif 対応・防水防塵対応のネットワークカメラを使用し、かつメンテナンスの容易さの観点からホーム下でではなく、羽田空港第 3 ターミナル駅の通信機器室内で onvif→WebRTC の変換を行なった。

図 4.4.1.1-5

End-End 区間でストリーミング配信する際の遅延確認の様子

UI・映像伝送システム
UI・映像伝送システムの評価・検証方法を表 4.4.1.1-6 に示す。ここでは、利用者のオペ
レーション観点で重要性の高いシステム機能について、具体的には、対象となる機能の特性に応じて、遅延量や解析結果の表示性能などを定量的に評価した。また、利用者の体感とオ
ペレーション観点での実用性について、具体的には、視認性、使いやすさ、操作性、表示速
度体感等について京浜急行電鉄の技術者等へのアンケートを通じて評価した。

166

表 4.4.1.1-6 UI・映像伝送システムの評価・検証方法
No

対象機能

評価項目

評価対象

1

映像伝送

伝送・表示性

単一拠点の遠隔遠隔監視室における監視画面への能（遅延等）

監視席における

映像等の表示に関して

映像の視認性・表示性能を確認（遅延等）

評価方法

・UI 機能の動作確認について検証する。
2

複数拠点の遠隔遠隔監視室における監視画面への監視席における

映像等の表示に関して、拠点数の映像の視認性増加にともなう・表示性能を確認（遅延等）
・UI 機能の動作確認について検証する。

3

AI 解 析

AI 解 析 結 果

単一拠点の遠隔遠隔監視室における監視画面への結果表示との連携性能監視席における

映像等の表示に関して、（時刻同期

AI 解析結果の視・検出結果に応じた分類表示等）

認性について検証する。

複数拠点の遠隔遠隔監視室における監視画面への監視席における

映像等の表示に関して、拠点数のAI 解析結果の視増加にともなう

認性・検出結果に応じた分類表示

4について検証する。
5

実用可能
性

利用者の体感

複数拠点の遠隔

京浜急行電鉄の技術者による監視

監視席における

作業デモを実施し、拠点数の増加

映像の視認性にともなう・映像伝送遅延等の体感
・UI 画面の映像表示レイアウト
・UI 画面の映像確認に関する操作性
・実装への期待感
・実装への懸念点

6

複数拠点の遠隔

京浜急行電鉄の技術者による監視

監視席における

作業デモを実施し、AI 解析結果の視・AI 解析結果の表示内容

認性・実装への期待感
・実装への懸念点

167

①遠隔監視室における監視画面への映像等の表示に関する表示性能（遅延等）
遠隔監視室における監視画面への映像等の表示に関して表示性能（遅延等）を確認した。

図 4.4.1.1-6

遠隔監視室内監視画面への映像等の表示に関する表示性能（遅延等）確認◯測定区間
Web サーバインスタンス～試験 PC（Chrome ブラウザ）◯測定項目：
１．試験 PC 上のブラウザから該当 URL へアクセスした時に、UI が表示されるまでの時間を計る。
２．UI 上で該当リンクをクリックしてから、画面が遷移するまでの時間を計る。
３．上記１及び２を１台の PC、複数台の PC でそれぞれ実施する。
②遠隔監視室における監視画面への映像等の表示に関する UI 機能の動作確認
遠隔監視室における監視画面への映像等の表示に関して表示性能を確認（遅延等）した。

図 4.4.1.1-7

遠隔監視室内監視画面への映像等の表示に関する表示性能（機能）確認168

表 4.4.1.1-7

表示性能に関する確認内容

機能名
画面 UI

確認内容
車両監視を選択する機能および録画映像を一覧表示し選択できる－異常検出お知らせ 異常検出された際、画面右上に対象のカメラと日時がポップアップ
機能
表示される－映像全画面表示機
映像を全画面表示できる
能－録画映像検索機能 メニューにて、録画映像を検索するフォームが表示される－録画映像再生位置
シークバーにてユーザ操作で録画映像の再生位置の制御を行える
制御機能－永久保存機能

UI から永久に保存したい録画映像やその関連データを設定できる－AI 検出一覧機能

表示している録画映像について異常検出情報の件数表示と再生リストを表示できる

リアルタイム映像配
リアルタイム映像が配信される
信機能
録画映像選択機能

ブラウザから録画映像を検索できる

録画映像再生機能

録画映像を配信して AI 解析結果の異常検出が合成できている

異常検出データ保存
AI 解析結果の異常検出を保存できている機能
録画映像取り込み機
録画映像の情報を異常検出情報に紐づけ、Web サーバに取り込める
能◯測定区間
Web サーバインスタンス～試験 PC（Chrome ブラウザ）◯測定項目：
1．試験 PC 上のブラウザから該当 URL へアクセスし、各機能の動作確認を行う。
2．上記を 1 台の PC、複数台の PC でそれぞれ実施する。

169

③遠隔監視室における監視画面での AI 解析結果の視認性の確認
遠隔監視室における監視画面での AI 解析結果の視認性を確認した。

図 4.4.1.1-8

図 4.4.1.1-9

遠隔監視室内監視画面での AI 解析結果の視認性確認

遠隔監視室内監視画面での AI 解析結果の視認性確認イメージ◯測定区間
Web サーバインスタンス～試験 PC（Chrome ブラウザ）◯測定項目：
1．試験 PC 上のブラウザから該当 URL へアクセスし、AI 検出結果に応じた分類表示について表示確認を行う。
2．上記を 1 台の PC、複数台の PC でそれぞれ実施する。

170

AI 解析エンジン
AI 構成面に関する評価・検証方法を表 4.4.1.1-8 に示す。ここでは、クラウド上の AI 解析エンジンにおいて、実際のオペレーションに則した性能要件を付加し、処理性能（パフォーマンス）を評価した。

No
1

対象機能

表 4.4.1.1-8 AI 構成面に関する評価・検証方法
評価項目
評価方法

計算リソースに理論的に処理可能なクラウド上の AI 解析エンジンにおい

応じた AI 解析速

フレーム数確認て、複数の映像インプットを同時並行度（机上検討）

的に処理するため、内部アーキテクチ
ャを考慮した上で、・クラウド上計算リソースの配分計画
・映像のインプット数に応じた処理可能フレーム数について机上検討する。

2

複数インプット

同時並行処理におけクラウド上の AI 解析エンジンにおい

映像の処理

る処理フレーム数確て、実際のオペレーションに則した数

認（実測値の統計評の映像インプットを同時並行的に処理価）するにあたり、クラウド上の計算リソースの制約に基づき・クラウド上のリソース稼働率
・解析可能なフレーム数（統計処理）について、実測値を用いて理論値との比較検証を行う。

171

AI 検出性能面に関する評価・検証方法を表 4.4.1.1-9 に示す。ここでは、クラウド上の AI
解析エンジンにおいて、実際の取得映像を解析する際の機能要件を評価した。具体的には処理時間、検出精度、検出限界速度（AI が解析可能な映像品質を実現できる車両速度）、その他の環境要因による検出精度等への影響を確認した。

No
1

評価項目

表 4.4.1.1-9 AI 検出性能面に関する評価・検証方法
評価方法

処理時間

一定のクラウド上の計算リソースおよび処理フレーム数の前提に基づき、AI 処理時間および End-End 区間での遅延時間を計測・評価する。

2

検出精度

検出対象物（台車き裂、ハンドル開閉、ブレーキパッド摩耗等）に応じて、検出率（試行ごとの適合率）および網羅率（試行ごとの再現率）を計測・評価する。

3

検出限界速度

検出対象物（台車き裂、ハンドル開閉、ブレーキパッド摩耗等）に応じて、どの程度の速度で移動する対象を検出可能か、
計測・評価する。

4

その他

必要に応じて環境要因を評価する。具体的には解析実行時の照度、対象物の汚れ具合等を記録し、評価する。

5

実用可能性

利用者の体感とオペレーション観点での実用性について、京浜急行電鉄の技術者へのアンケートを通じて評価する。

a）AI 推論処理の速度（処理時間）①車両１編成当たりの AI 解析にかかる処理時間

図 4.4.1.1-10 AI 処理時間確認イメージ（車両１編成当たりの AI 解析にかかる処理時間）172◯実施内容：カメラ①～③の映像を並行して解析する中で、カメラ①において車両がホームへ入線
しカメラに写り込んだ時間を AI エンジンへのインプット開始時間とし、車両が停車した
時間をインプット終了時間とした。インプット終了時間後、該当期間中の映像解析が完了するまでの時間を計測した。
◯測定項目：
1：カメラ①における車両の入線時間（カメラに先頭車両が映り込んだ時間）
2：カメラ①における車両が停車した時間
3：車両停車時の最後のインプット画像が AI エンジンにより解析処理が完了した時間②1 日における車両の始発から終電まで通して AI 解析を行った場合の処理時間

図 4.4.1.1-11 AI 処理時間確認イメージ（1 日における車両の始発から終電まで通して AI 解析を行った場合の処理時間）◯実施内容：
始発電車がホームへ入選しカメラ①に写り込んだ時間を AI エンジンへのインプット開
始時間とし、終電がホームから出発しカメラ①の画角から消えた時間をインプット終了
時間とした。インプット終了時間後、該当期間中の映像解析が完了するまでの時間を計測した。これにより、処理遅延が蓄積されているかどうか、蓄積される場合はどの程度蓄積されるのかを評価した。
（①車両１編成当たりの AI 解析にかかる処理時間と比較して、②1 日における車両の始発から終電まで通して AI 解析を行った場合の処理時間が大きくなっている場合は、処理遅延が蓄積されたものとして評価する。）◯測定項目：
1：カメラ①における始発車両の入線時間（カメラに先頭車両が映り込んだ時間）
2：カメラ①における終電車両が出発した時間（カメラの画角から車両が消えた時間）
3：終電出発の最後のインプット画像が AI エンジンにより解析処理が完了した時間

173b）AI 推論処理の精度（検出精度）
検出対象物（台車き裂、ハンドル開閉、ブレーキパッド摩耗等）ごとに、Precision（適合率）及び Recall（再現率）を以下のように評価した。
・Precision（適合率）：システムが検出した結果のうち、本当に正しかったものの割合を、
人が解析映像を確認の上、評価する。（表 4.4.1.1-10 における D／(B＋D)）
・Recall（再現率）：結果として検出されるべきもののうち、システムが正しく認識できたものの割合を人が解析映像を確認の上、評価する。（表 4.4.1.1-10 における D／(C＋D)）
表 4.4.1.1-10

検出結果の分類

AI検出

正
実 常
際
の
状 異
態
常

検出なし

検出あり

A

B
(誤検出)

C
(検出漏れ)

D(正常に検出)図 4.4.1.1-12

AI 検出性能確認イメージ〇台車き裂
幅：0.1mm、0.2mm、1.0mm、2.0mm、4.0mm、6.0mm
長さ：20mm、60mm、80mm
方向：縦横
油性黒ペンで擬似き裂のそれぞれのパターンを実証場所に入線する車両の台車に描き、擬似き裂の AI 検出ができるか確認した。なお、疑似き裂の記入は京浜急行電鉄車両部にて実施した。
174

図 4.4.1.1-13

擬似き裂を描く台車

175

図 4.4.1.1-14

横方向の擬似き裂

図 4.4.1.1-15

縦方向の擬似き裂

図 4.4.1.1-16

台車に描く擬似き裂パターン
176

図 4.4.1.1-17

台車に疑似き裂を記入する様子

図 4.4.1.1-18

記入した疑似き裂の例

177

〇ハンドル開閉
京浜急行電鉄羽田空港第 1・第 2 ターミナル駅では、安全面の観点で検証のためにハンドルを意図的に開閉させて走行させることが不可能であったため、正しい位置（閉まっている）であることを AI 検出できるか確認した。ハンドル開閉について AI で異常を検出できるかどうかの確認として、京急久里浜工場でハンドルを意図的に開閉させて列車を走行させて撮影した映像を使用し、評価を行った。
〇ブレーキパッド
擦り減った割合の適合率ではなく、異常（取り替え要）と AI 検出されたブレーキパッドに対して実際に取り替えが必要なほど擦り減っているかを目視確認した。

c）AI 推論処理の精度（検出限界速度）
検出対象物（台車き裂、ハンドル開閉、ブレーキパッド摩耗等）に応じて、どの程度の速度で移動する対象を検出可能か、計測・評価した。

d）その他（解析対象の汚れや周辺環境の影響）
必要に応じて環境要因、具体的には解析実行時の照度、対象物の汚れ具合の解析に対する影響を評価した。

図 4.4.1.1-19

環境要因による AI 解析影響評価イメージe）実用性に関する定性評価（利用者体感等）
利用者の体感とオペレーション観点での実用性について、京浜急行電鉄の技術者へのアンケートを通じて評価した。

178

その他（現場環境）
その他（現場環境）に関する評価・検証方法を表 4.4.1.1-11 に示す。ここでは、現場機材の運用にあたり、鉄道駅における監視システムの必要十分な環境への適応性、および長期安
定性について評価・検証した。

No

表 4.4.1.1-11 その他（現場環境）に関する評価・検証方法
対象機能
評価項目
評価方法

1

環境適応性（照度）

照度変化にともなう AI 検出
性能

現場に設置した照明機材を調整し、異なる照度環境を構築した上で、照度の違いが取得映像の品質や AI 解析性能に及ぼす影響を評価し、改善する。

2

環境適応性（対 対象物の色合い変化にとも象物の色合い） なう AI 検出性能

対象物（車両台車等）の色合い変化に応じた AI 検出性能を評価し、改善する。特に検出精度が低くなる色合いなどが見られる場合は、要因分析と重点的な追加学習を行い、改善を試みる。

3

長期安定性

カメラ機材の連続稼働時間

現場に設置したカメラ機材の連続稼働時間を評価する。機材停止を確認した時点で切り分けを行い、PDCA を通じて停止要因を改善し、再度検証を実
施する。

4

長期安定性

GPU 搭載ノート PC の連続稼働時間

現場に設置した GPU 搭載ノート PCの連続稼働時間を評価する。機材停止を確認した時点で切り分けを行い、PDCA を通じて停止要因を改善し、再度検証を実施する。

5

長期安定性

5G ルータの連続稼働時間

現場に設置した 5G ルータの連続稼働時間を評価する。機材停止を確認した時点で切り分けを行い、PDCA を通じて停止要因を改善し、再度検証を実施
する。

179

（3）実証結果及び考察
通信性能a）ローカル 5G 区間の通信性能測定結果を表 4.4.1.1-12 に示す。なお、各測定における測定対象外の項目はグレーで塗りつぶしている。
表 4.4.1.1-12
試験項目
1−1

測定端末#1

測定端末#2

試験

TCP

iperf 100M

UDP

ローカル5G区間の通信性能

L5GUE配下
ノートPC

ローカル 5G の通信性能評価

プロトコル 試験区分 パケットサイズ送信時間

第3ターミナル
L3SW配下
ノートPC

TCP

iperf 200M

UDP

ping

スループット 試験回数

上り
上り
上り

1420
1420
1420

60 60 60 -

下り
下り
下り

1420
1420
1420

60 60 60 -

上り
上り
上り

1420
1420
1420

60
60
60

100
100
100

下り
下り
下り

1420
1420
1420

60
60
60

100
100
100

上り
上り
上り

1420
1420
1420

60 60 60 -

下り
下り
下り

1420
1420
1420

60 60 60 -

上り
上り
上り

1420
1420
1420

60
60
60

200
200
200

下り
下り
下り

1420
1420
1420

60
60
60

200
200
200

1420
1420
1420

60 60 60 -ICMPbandwidthjitter

1
80.90 -2
81.40 -3
81.30 -※avg
81.2 -1
100.00 -2
100.00 -3
100.00 -※avg
100.0 -1
82.40
2
82.20
3
81.90
※avg
82.17
1
100.002
100.003
100.00※avg
100.00181.30 -2
81.80 -3
81.80 -※avg
81.6 -1
200.00 -2
200.00 -3
200.00 -※avg
200.0 -1
81.90
2
81.70
3
81.80
※avg
81.80
1
139.002
139.003
139.00※avg
139.00
1 --2 --3 --※avg ---

0.10
0.11
0.09
0.10
0.14
0.14
0.08
0.12

0.21
0.12
0.20
0.18
0.06
0.04
0.16
0.09

lost/total min/

avg/

max/

-------------------------------------------------------------------------------------------------0.00 -0.00 -0.00 -0.00 -0.20 -0.20 -0.20 -0.20 ---------0.59 -0.59 -0.59 -0.59 -0.00 -0.00 -0.00 -0.00 --10.00319.44315.71115.052333

31.59633.43632.78832.6067mdev/--------------------------------55.532 7.40504
44.276 5.70458
42.745 5.49294
47.5177 6.20085▼上り方向：
TCP の場合、送信パケットを 100Mbps、200Mbps に設定すると、3 回の測定結果の平均
でスループットがそれぞれ 81.2Mbps、81.6Mbps となった。また、UDP の場合、送信パケ
ットを 100Mbps、200Mbps に設定すると、3 回の測定結果の平均でスループットがそれぞれ 82.17Mbps、81.8Mbps となった。
▼下り方向：
TCP の場合、送信パケットを 100Mbps、200Mbps に設定すると、3 回の測定結果の平均
でスループットがそれぞれ 100.0Mbps、200.0Mbps となった。また、UDP の場合、送信パ
ケットを 100Mbps、200Mbps に設定すると、3 回の測定結果の平均でスループットがそれ
ぞれ 100.0Mbps、139.0Mbps となった。
以上の結果より、本課題解決システムの上り通信の目標値である 60Mbps、および下り通信の目標値である 60Mbps で送信するために十分な帯域を確保できていることが分かる。

180b）専用線区間の通信性能測定結果を表 4.4.1.1-13 に示す。なお、各測定における測定対象外の項目はグレーで塗りつぶしている。
表 4.4.1.1-13
No.

試験項目

測定端末#1 測定端末#2

試験

プロトコル 試験区分

60 60 60 -

下り

1420
1420
1420

60 60 60 -

上り

1420
1420
1420

60
60
60

100
100
100

下り

1420
1420
1420

60
60
60

100
100
100

上り

1420
1420
1420

60 60 60 -

下り

1420
1420
1420

60 60 60 -

上り

1420
1420
1420

60
60
60

200
200
200

下り

1420
1420
1420

60
60
60

200
200
200

1420
1420
1420

60 60 60 -

UDP

dOIC
WebRTC
インスタンスTCP

iperf 200M

UDP

ping

ICMP

送信時間 スループット
試験回数
(sec)
(Mbps)

1420
1420
1420

iperf 100M

第3ターミナル
L3SW配下
ノートPC

パケット
サイズ

上り
TCP

専用線区
1−2 間の通信性能

専用線区間の通信性能評価
bandwidth1
92.13 -2
90.10 -3
90.10 -※avg
90.8 -1
122.04 -2
120.91 -3
120.91 -※avg
121.3 -1
99.92
2
101.673
99.91※avg
100.50
1
87.39
2
87.01
3
87.31
※avg
87.23
1
90.05 -2
86.01 -3
89.83 -※avg
88.6 -1
119.67 -2 117.99333 -3
112.64 -※avg
116.8 -1
186.752
185.153
185.82※avg
185.911
144.352
144.873
144.83※avg
144.68
1 --2 --3 --※avg ---

min/
avg/
max/
mdev/
lost/total
Microsec Microsec Microsec Microsec
パケット数
onds
onds
onds
onds
----------------------------------------0.02
0.00 ----0.02
0.00 ----0.02
0.00 ----0.02
0.00 ----0.01
0.13 ----0.02
0.13 ----0.02
0.13 ----0.02
0.13 --------------------------------------------0.03
0.07 ----0.03
0.07 ----0.03
0.07 ----0.03
0.07 ----0.01
0.28 ----0.01
0.28 ----0.01
0.28 ----0.01
0.28 -----12
12
14 --12
12
14 --12
12
14 --1212
14 --jitter▼上り方向：
TCP の場合、送信パケットを 100Mbps、200Mbps に設定すると、3 回の測定結果の平均
でスループットがそれぞれ 90.80Mbps、88.6Mbps となった。また、UDP の場合、送信パ
ケットを 100Mbps、200Mbps に設定すると、3 回の測定結果の平均でスループットがそれ
ぞれ 100.50Mbps、185.91Mbps となった。
▼下り方向：
TCP の場合、送信パケットを 100Mbps、200Mbps に設定すると、3 回の測定結果の平均
でスループットがそれぞれ 121.30Mbps、116.80Mbps となった。また、UDP の場合、送信パケットを 100Mbps、200Mbps に設定すると、3 回の測定結果の平均でスループットがそれぞれ 87.23Mbps、114.68Mbps となった。
以上の結果より、本課題解決システムの上り通信の目標値である 60Mbps、および下り通信の目標値である 60Mbps で送信するために十分な帯域を確保できていることが分かる。

181c）クライアント～dOIC 区間の通信性能測定結果を表 4.4.1.1-14 に示す。なお、各測定における測定対象外の項目はグレーで塗りつぶしている。
表 4.4.1.1-14
No.

試験項目

測定端末#1 測定端末#2

試験

クライアント～dOIC 区間の通信性能評価

プロトコル 試験区分

1420
1420
1420

60 60 60 -

下り

1420
1420
1420

60 60 60 -

上り

1420
1420
1420

60
60
60

100
100
100

下り

1420
1420
1420

60
60
60

100
100
100

上り

1420
1420
1420

60 60 60 -

下り

1420
1420
1420

60 60 60 -

上り

1420
1420
1420

60
60
60

200
200
200

下り

1420
1420
1420

60
60
60

200
200
200

1420
1420
1420

60 60 60 -iperf 100M

UDP

TCP

iperf 200M

UDP

ping

送信時間 スループット
試験回数
(sec)
(Mbps)

上り
TCP

監視拠点
クライアント京急本社
dOIC
1−3 ～dOIC区 監視クライアン WebRTC
間の通信
トPC
インスタンス
性能

パケット
サイズ

ICMP

bandwidth

1
2
3
※avg
1
2
3
※avg
1
2
3
※avg
1
2
3
※avg
1
2
3
※avg
1
2
3
※avg
1
2
3
※avg
1
2
3
※avg
1 -2 -3 -※avg --9.9 -12.6 -12.6 -11.7 -6.4 -3.7 -6.2 -5.4 -9.4
6.5
12.2
9.4
15.7
15.8
16.5
16.0
16.5 -15.8 -14.5 -15.6 -6.6 -6.2 -5.8 -6.2 -16.4
13.9
17.8
16.0
27.7
28.2
27.2
27.7
-----

min/
avg/
max/
mdev/
lost/total
Microsec Microsec Microsec Microsec
パケット数
onds
onds
onds
onds
----------------------------------------2.0
0.9 ----2.4
0.9 ----0.7
0.9 ----1.7
0.9 ----1.6
0.8 ----1.6
0.8 ----0.3
0.8 ----1.2
0.8 --------------------------------------------4.4
0.9 ----1.0
0.9 ----1.2
0.9 ----2.2
0.9 ----0.4
0.9 ----0.3
0.9 ----0.4
0.9 ----0.4
0.9 -----43
61
204 --45
73
285 --46
63
209 --44.7
65.7
232.7 --

jitter▼上り方向：
TCP の場合、送信パケットを 100Mbps、200Mbps に設定すると、3 回の測定結果の平均
でスループットがそれぞれ 11.7Mbps、15.6Mbps となった。また、UDP の場合、送信パケ
ットを 100Mbps、200Mbps に設定すると、3 回の測定結果の平均でスループットがそれぞれ 9.4Mbps、16.0Mbps となった。
▼下り方向：
TCP の場合、送信パケットを 100Mbps、200Mbps に設定すると、3 回の測定結果の平均
でスループットがそれぞれ 5.4Mbps、6.2Mbps となった。また、UDP の場合、送信パケッ
トを 100Mbps、200Mbps に設定すると、3 回の測定結果の平均でスループットがそれぞれ16.0Mbps、27.7Mbps となった。
本実証で開発した監視画面では、フル HD の映像を 3 つ閲覧するため、通信品質としては 36Mbps 以上あることが望ましいが、結果から目標値は達成できていないことがわかる。
今回構築したシステムでは、監視拠点の通信回線として、構築期間の短縮のためモバイル
ルータを用いたインターネット回線を使用した。なお、セキュリティ強化のため、モバイル
ルータに固定 IP アドレスを付与し、その固定 IP アドレスからの通信のみ可能となるように設計した。このため、インターネット回線であることや、モバイル回線を使用することによる通信品質の揺らぎや時間帯による混雑具合の影響なども含まれた結果である。また、本通信性能試験を実施した、監視拠点の京浜急行電鉄の本社会議室内は LTE エリアであった。
5G などの高速・大容量通信が可能な環境で閲覧することで、監視拠点の通信性能の改善は見込まれるものと結論づけた。
182d）End-End 通信遅延確認
測定結果を表 4.4.1.1-15 に示す。なお、各測定における測定対象外の項目はグレーで塗りつぶしている。
表 4.4.1.1-15
試験項目

試験区分

1回目 30分間

End-End
通信遅延確認

2回目 30分間

3回目 30分間

試験回数

対象端末

5分後

3T機械室 GPU-PC (momo)dOIC WebRTCインスタンス
SH52A配下 GPUPC※avg
3T機械室 GPU-PC (momo)
10分後 dOIC WebRTCインスタンス
SH52A配下 GPUPC※avg
3T機械室 GPU-PC (momo)
30分後 dOIC WebRTCインスタンス
SH52A配下 GPUPC※avg
3T機械室 GPU-PC (momo)
5分後 dOIC WebRTCインスタンス
SH52A配下 GPUPC※avg
3T機械室 GPU-PC (momo)
10分後 dOIC WebRTCインスタンス
SH52A配下 GPUPC※avg
3T機械室 GPU-PC (momo)
30分後 dOIC WebRTCインスタンス
SH52A配下 GPUPC※avg
3T機械室 GPU-PC (momo)
5分後 dOIC WebRTCインスタンス
SH52A配下 GPUPC※avg
3T機械室 GPU-PC (momo)
10分後 dOIC WebRTCインスタンス
SH52A配下 GPUPC※avg
3T機械室 GPU-PC (momo)
30分後 dOIC WebRTCインスタンス
SH52A配下 GPUPC※avg

End-End 通信遅延確認評価
CPU%
3.00
3.70
4.00
3.57
3.00
3.30
7.00
4.43
3.00
3.60
4.00
3.53
3.00
3.00
4.00
3.33
3.00
3.40
4.00
3.47
3.00
2.80
3.00
2.93
3.00
2.30
3.00
2.77
3.00
2.90
3.00
2.97
3.00
4.00
4.00
3.67

MEM%
22.00
0.02
16.00
12.67
22.00
0.02
17.00
13.01
22.00
0.02
17.00
13.01
22.00
0.02
17.00
13.01
22.00
0.02
18.00
13.34
22.00
0.02
17.00
13.01
22.00
0.02
17.00
13.01
22.00
0.02
17.00
13.01
22.00
0.02
17.00
13.01

GPU%

解像度

19.00 --13.00 1920×1080
16.00 -18.00 --14.00 1920×1080
16.00 -18.00 --13.00 1920×1080
15.50 -18.00 --13.00 1920×1080
15.50 -18.00 --12.00 1920×1080
15.00 -16.00 --12.00 1920×1080
14.00 -16.00 --12.00 1920×1080
14.00 -16.00 --12.00 1920×1080
14.00 -18.00 --12.00 1920×1080
15.00 --

備考
ドロップ 遅延時間・量 ※映像劣
フレーム数のチェック 化、かくつきの有無など--------20.00 5889.00 5880.00
6.00 0:00:01.41------------20.24 11899.00 11729.00
148.00 0:00:02.41------------21.08 35889.00 35634.00
253.00 0:00:02.50------------19.90 5918.00 5915.00
12.00 0:00:02.55------------17.87 11916.00 11892.00
24.00 0:00:02.58------------21.26 35938.00 35644.00
291.00 0:00:02.69------------20.00 5896.00 5862.00
31.00 0:00:02.64------------19.74 11895.00 11856.00
37.00 0:00:02.75------------19.08 35894.00 35701.00
192.00 0:00:03.35
-----

フレーム数
----------------------------

受信
フレーム数

デコード
フレーム数

測定時はホーム下 3 か所に設置したカメラのうち 1 つのカメラで映像伝送し、使用しな
い 2 台のカメラは通信を切断した状態で実施した。映像伝送のパラメータはフル HD 、
12Mbps、20fps で伝送した。結果として、遅延量は 1.41s~3.35s となった。
本課題実証システムでは、長期安定性の観点で onvif 対応・防水防塵対応のネットワーク
カメラを使用したため、onvif から WebRTC への変換が必要な構成となった。この変換のために遅延が発生することは机上検討でも把握しており、実運用上の観点で、長期安定性を優先して遅延が発生することは、運用上の業務フローに大きく影響しないことをコンソー
シアム内で協議の上、ネットワークカメラを使用した。事前検証において、onvif から
WebRTC への変換により数秒の遅延が生じることを確認しており、測定で確認された遅延と一致するため、試験結果にみられる遅延は onvif から WebRTC への変換により生じた遅延であると結論づけた。
以上のことから、onvif から WebRTC への変換により生じた遅延以外は生じていないものとみなすことができ、列車走行後 2 分以内にユーザが映像を閲覧できるという目標値に対して大きな影響を及ぼさないことから、目標値を達成したと結論付けた。

183

UI・映像伝送システムa）UI・映像伝送システムの評価結果
UI・映像伝送システムの評価結果を表 4.4.1.1-16 に示す。
時刻表上の列車発着時刻からユーザが解析結果を確認可能な状態にするまでの時間を 2分内という目標に対して、サーバ処理は時刻表上の列車発着時刻から平均 111 秒で完了し、ユーザがサーバにアクセスすれば映像を閲覧できる状態になっていることを確認し、シス
テム処理時間の KPI は達成したことを確認した。一方で、実際の監視拠点となる、京浜急
行電鉄本社内では映像閲覧までに平均 17 秒程度要しており、かつ試行によって大きくばらつきがあることから、列車の発着から 2 分以内にユーザが監視画面で映像を閲覧できることは確認できなかった。
映像閲覧の下り通信はインターネットを利用しているため、通信環境の影響を受け、画面
表示、画面遷移に時間を要した結果となった。本実証では実装に向けて、多拠点で場所の制
約なく映像を確認できることを前提とし、固定 IP アドレスを割り振り接続元の制限をかけたモバイル端末によるインターネット接続を使用した。このため、通信性能を評価した区間
はインターネットの区間を含むものであり、インターネット接続による通信品質の揺らぎや時間帯による混雑具合の影響など受けたものと結論づけた。
表 4.4.1.1-16

UI・映像伝送システムの評価結果
確認結果

機能名

単一拠点

確認内容

複数拠点

試験結果

表示/遷移時間拠点①

拠点②

表示/遷移時間

表示/遷移時間

画面UI

車両監視を選択する機能および録画映像を一覧表示し選択できる－異常検知お知らせ機能

異常検知された際、画面右上に対象のカメラと日時がポップアップ表示される○

40sec以下

15sec以下

20sec以下－映像全画面表示機能

映像を全画面表示できる○

1sec以下

1sec以下

1sec以下－録画映像検索機能

メニューにて、録画映像を検索するフォームが表示される○

1sec以下

1sec以下

1sec以下－録画映像再生位置制御機能

シークバーにてユーザー操作で録画映像の再生位置の制御を行える○-－永久保存機能UIから永久に保存したい録画映像やその関連データを設定できる○

1sec以下

1sec以下

1sec以下－AI検出一覧機能

表示している録画映像について異常検知情報の件数表示と再生リストを
表示できる

○

1sec以下

1sec以下

1sec以下

画面遷移

各画面間を設計通り遷移できる－ライブ画面 → 録画画面

ライブ画面にてメニューから録画画面へ遷移できる○

20sec以下

30sec以下

1sec以下－録画画面 → ライブ画面

録画画面にてメニューからライブ画面へ遷移できる○

1sec以下2sec以下

1sec以下リアルタイム映像配信機能

リアルタイム映像が配信される○

録画映像選択機能

ブラウザから録画映像を検索できる○

録画映像再生機能

録画映像を配信してAI解析結果の異常検知が合成できている○

AI解析結果の異常検知を保存できている○

録画映像の情報を異常検知情報に紐づけ、webサーバに取り込める○

異常検知データ保存機能
録画映像取り込み機能

184

検索対象10分間 検索対象10分間→1sec以下→1sec以下
検索対象1時間 検索対象1時間→1sec以下→1sec以下
検索対象3時間 検索対象3時間→5sec以下→5sec以下
検索対象12時間 検索対象12時間→25sec以下→25sec以下
検索対象24時間 検索対象24時間→1.5min以下→1.5min以下

各評価項目の画面を図 4.4.1.1-20～図 4.4.1.1-28 に示す。なお、画面内の対象となる機能の箇所に橙色の枠で示した。

図 4.4.1.1-20

異常検出お知らせ機能185

図 4.4.1.1-21

全画面表示機能（上：全画面表示前、下：全画面表示後）

186

図 4.4.1.1-22

録画映像検索機能・録画映像選択機能（上：検索時、下：検索結果）

187

図 4.4.1.1-23

録画映像再生位置制御機能（上：操作前、下：操作後）

188

図 4.4.1.1-24

永久保存機能（上：操作前、下：操作後）

189

図 4.4.1.1-25

AI 検出一覧機能（上：操作前、下：操作後）190

図 4.4.1.1-26

リアルタイム映像配信機能（上：接続時、下：一定時間経過後）

191

図 4.4.1.1-27

図 4.4.1.1-28

録画映像再生機能

異常検出データ保存機能・録画映像取り込み機能

192b）UI・映像伝送システムの利用者の体感
京浜急行電鉄の車両部に UI・映像伝送システムのデモンストレーション、および操作を体験していただき、アンケートと対面によるヒアリングを実施した。なお、アンケートは代表して 2 名に記入いただいた。アンケートの結果を図 4.4.1.1-26~図 4.4.1.1-27 に示す。
①ユーザインターフェースの利便性
提示する情報の配置や表示の仕方について、実運用の観点で改善すべき点のコメントをいただいた。具体的には、接続したときのトップ画面には、ライブ映像とともに直近の検出結果を表示させておき、時間で検索をかけなくても検出結果を常時表示させておくことや、
異常検出お知らせ機能（ポップアップ通知）をより強調させて表示させるなどが挙げられた。
また、リアルタイム性については、実装を見据えた第一歩としては、現状のシステムの約 2分後に検出結果の映像が確認できる仕様（録画映像選択機能、およびライブ画面→録画画面の画面遷移に該当）で問題ないが、将来的な実運用の際には異常を検出次第、すぐに映像・画像とともに通知し確認できるようにしてほしい、という意見を得た。
ユーザインターフェース上で提示する情報の種類としては、運用に必要な情報をある程度網羅できているが、提示の仕方やリアルタイム性に課題があることが浮き彫りになった。
全体を通して、利用することを前提にした具体的な改善案等の意見を得ることができたことから、実装に向けたより詳細な検討のステップを踏むことができていると考えられる。
②使用した機材について
監視用端末としてノートパソコンで映像を確認していただき、表示される映像の品質については鮮明に見ることができている、というポジティブな意見を得ることができた。昨年
度と比較してスピードのある車両を撮影するため、シャッタースピードを大きくしたこと
で照度補完のためにライトを設置したが、照度についても問題なく十分な明るさを確保できているという意見も得られた。一方で、現状では監視用端末のノートパソコンで映像を確認しているが、将来的には大画面に投影し、複数人で画像を確認する場面も想定されるという意見もあり、その場合にはより高画質な映像が必要となる可能性がある。
また、本システムでは車号の特定をシステム的に行うことができないが、実運用時には異常があった台車はどの編成のどの台車部分なのか、までシステムで特定されるとスムーズな運用が可能となるという意見を得られた。車号の特定には、列車側にビーコンなどの機材を設置する、カメラで列車の正面に記入されている番号を撮影する等、複数の案が考えられるが、各鉄道会社で導入可能な汎用的なシステムとするためには各社の異なる車体の仕様にも対応できるような仕組みが必要となり、詳細な検討が必要となる。
③5G - AI 監視システムの機能と導入可能性について
デモンストレーションで確認いただいた AI 検出結果の画面については、検出ができているという意見を得られた。一方で、塗装のひび割れなど疑似き裂ではないものをき裂として検出する場合があることが確認されており、き裂の AI 判定をどのように学習させるか、精度の向上と追加学習が課題として浮き彫りになった。

193

④ローカル 5G の機能と導入可能性について
ローカル 5G の通信自体は問題ないが、周辺機器や処理環境、および映像閲覧環境の通信
環境の影響で映像がスムーズに確認できず、課題があるという意見を得た。デモンストレー
ションでは通信環境により画面表示に時間がかかる（録画映像選択機能、およびライブ画面→録画画面の画面遷移に該当）など、操作の体感に大きな影響を与えた。実運用の際には、下り通信においても 5G を使用できる環境での映像閲覧が望ましい。
表 4.4.1.1-17

アンケート結果

アンケート項目【1.UIの利便性について】
Q1 Web画面のレイアウト・見た目はいかがでしたか？
A1：1(悪い)：録画映像一覧及び検出結果を常時表示すべき。
A2：2(やや悪い)：ライブ映像より、録画映像を表示した一覧をトップ画面に表示してほしい。
AI解析によって異常があったものが、トップ画面で分かるようにしてほしい。
（せっかく録画映像を色分けしているのにもったいないと考えます。）
Q2 実業務を想定すると、Web画面上どのような機能が良かったと思いましたか？
A1：①ライブ映像 ②ポップアップ
A2：①トップ画面と一覧追加
Q3 実業務を考えると、Web画面上において、どのような追加機能が必要だと思いましたか？
A1：①リアルタイム性 ②強調
A2：①疑似き裂の画面をすぐ表示する ②疑似き裂画面の拡大化 ③ポップアップから映像確認できる機能【2.使用した機材について】
Q1 高精細カメラについて、実運用を想定したときに十分な映像品質だと感じましたか？
A1：5(良い)：ライブ映像をノートパソコンで確認する範囲では問題なし。
A2：2(やや悪い)：現状のAI解析精度との関係が不明なのでなんともいえない。
ただし、録画映像を拡大するという観点でいえば、もう少し高性能カメラで良いかと考える。
Q2 照度の補完のためにライトを使用したが、実運用を想定したときに十分な性能だと感じましたか？
A1：5(良い)：問題なし。
A2：3(普通)：台車を検知するには明るいと考える。
ただし、電車を運転している運転手の目にどう映るか、眩しくないか、確認しなくてはならないと考える。
Q3 検出対象物について、今回は台車亀裂（初期）、ハンドルの開閉、ブレーキパッドの摩耗を選定しましたが、実業務を想定したときの、各対象物の異常検出の必要性について教えて下さい。
A1：台車の亀裂：5(良い) ハンドルの開閉：5(良い) ブレーキパッドの摩耗：5(良い)A2：台車の亀裂：2(やや悪い) ハンドルの開閉：4(やや良い) ブレーキパッドの摩耗：3(普通)Q4 検出対象物について、実業務を想定して上記の3種類以外の検出対象物を選ぶとしたら、何を対象に選びますか？
A1：①屋根上（理由：運用上外的な損傷を受ける部分であるため。） ②車体全体（理由：同上）
A2：①車号（理由：どの車両か紐づけしてほしい。）【3.5G-AI監視システムの機能と導入可能性について】
Q1 AI検知により、異常箇所を見分けやすいと感じましたか？
A1：5(良い)：対象物に対しては問題なし。
A2：3(普通)：まだ精度が確認できないため、現状なんともいえないが、画面を確認した限り、検知ができていた。
Q2 AI検知により、将来的に実業務の効率化やより一層の安全性向上に貢献できると感じますか？
A1：3(普通)：安全性向上できるが、実務向上は望めないため。
A2：2(やや悪い)：塗装剥がれを検知しているため、追加学習が必要と考える。
Q3 AI検知システムを導入するにあたり、実業務を想定した課題を教えて下さい。3つ以内でお答え下さい。
A1：正確性の向上
A2：クラックの判断をどのように学習させるか。
【4.ローカル5Gの機能と導入の可能性について】
Q1 将来的に鉄道事業（車両部門）におけるローカル5Gの導入可能性（領域・用途）と課題について、ご意見下さい。
A1：５G通信自体は問題ない様子であるが、周辺機器や処理環境に必要な設置に課題が多くあると感じている。
A2：3(普通)：L5Gの通信速度は速いと考えられるが、カメラの性能と社内の通信速度の影響によりスムーズに映像が確認できなかった。
※回答は５段階数値 １：悪い ～ ５：良い にて評価を入力

194

AI 解析エンジンa）AI 構成面における評価結果
AI 構成面における評価結果を表 4.4.1.1-18 及び図 4.4.1.1-29 に示す。
表 4.4.1.1-18

AI 構成面における評価結果

図 4.4.1.1-29

AI 処理時間の分布
195

AI 構成面での評価として、机上での見積もり解析速度と実績値を比較した。その結果、見積もりに対して検出対象時間が想定より短くなっており、机上検討の 41 秒よりも実際の処理時間は 25 秒と短くなったこと以外は机上検討に沿った内容の解析速度が出ていた。
なお、今回はカメラ 3 台でシステムを構築したが、将来的にカメラの台数を増やした場
合の AI 処理時間を評価した。試験結果に基づいて、カメラ 6 台をインプットの映像数とした場合の AI 処理時間を机上計算により確認した。その結果、AI 処理時間は 50 秒となり、
カメラ 3 台の場合と同等の処理時間に収めるためには、AI 処理を並列で行う GPU の数を
現状の 16 から 32 に増やす必要があることが確認された。

b）AI 処理時間の評価結果
処理時間の評価結果を表 4.4.1.1-19~表 4.4.1.1-20 に示す。
表 4.4.1.1-19

表 4.4.1.1-20

車両１編成当たりの AI 解析にかかる処理時間

1 日における車両の始発から終電まで通して AI 解析を行った場合の処理時間

車両 1 編成あたりの AI 解析にかかった処理時間と、1 日における車両の始発から終電までを通してＡＩ解析を行った場合の処理時間を測定した。その結果、いずれの測定においても車両が出線後 30 秒以内に AI 解析が完了しており、処理遅延の蓄積は生じていないことが見受けられた。処理遅延の蓄積を生じさせないためには、システム設計上、処理時間の全体で 2 分以内にする必要があったが、列車有無判定アルゴリズム・システムの導入により、走行する列車がカメラに写っている間だけを AI 解析の対象とすることができたことで、処理遅延の蓄積が生じないシステムを実現することができた。

196c）AI 検出精度・検出限界速度の評価結果
疑似き裂を記入した 24 編成の列車について、10 日間かけて羽田空港第 1 第 2 ターミナ
ル駅に入線する映像を 1 回ずつ評価した。
ただし、H（幅 1mm、長さ 60mm の 2 編成のうち 1 編成）、P（幅 6mm、長さ 20mm）、W（幅 2mm、長さ 60mm の 2 編成のうち 1 編成）については評価した 10 日間で 1 度も入線せず、評価の対象外とした。
評価の対象とした編成数は 22 編成、車両数は 132 両である。AI 検出性能評価としては、設置したカメラ 3 台にそれぞれ映った疑似き裂、ブレーキパッド、ハンドルのうち、映像の乱れ等により AI 解析不可能な画像を除いたものを有効サンプルとして評価を行った。有効
サンプル数としては、疑似き裂は 1,109 個、ブレーキパッドは 690 個、ハンドルは 320 個である。
①疑似き裂の検出性能評価
 疑似き裂の属性観点で評価
まず、疑似き裂の属性に着目し解析を行った。
疑似き裂の方向、疑似き裂の幅に着目し、適合率・再現率を評価した。
幅 4.0mm, 6.0mm では、長さ 20mm，60mm，80mm のいずれの場合でもおおよそ検出できている。
幅 2mm では、長さ 60mm は適合率 100%、再現率 100％でおおよそ検出、長さ 80mmは適合率 99.06%、再現率 82.03％でおおよそ検出ができており、幅 1mm では、長さ 80mmで適合率 100%、再現率 55.65％でおおよそ検出ができている。幅 0.1mm では全体で適合率 96.67%、再現率 15.10％であった。幅 0.2mm では全体で適合率 100%、再現率 14.06％であった。疑似き裂幅 0.1mm，0.2mm では、1mm 以上のより太い幅の疑似き裂に比べて検出がよりできていないが、昨年度の結果と比較すると幅 0.1mm、長さ 20mm でも検出ができていることから、システムの性能として向上しているといえる。
性能が向上した要因として、昨年度と比較し、列車の台車部分とカメラの距離が近くなったことから、映像がより鮮明になったことが考えられる。また、昨年度は照度に関して日照条件の影響を受けやすい環境であったが、今回は地下駅かつ照度補完のためにライトを設置したため、照度が一定かつ十分な明るさが確保された環境を構築できたことから、再現率が向上したものと考えられる。

197

図 4.4.1.1-30

疑似き裂方向・疑似き裂幅観点での評価結果

表 4.4.1.1-21

疑似き裂方向・疑似き裂幅観点での評価結果

198

図 4.4.1.1-31

疑似き裂方向・疑似き裂長さ観点での評価結果

表 4.4.1.1-22

疑似き裂方向・疑似き裂長さ観点での評価結果

199

表 4.4.1.1-23

車両速度（0-10km/h）・疑似き裂幅・疑似き裂長さ観点での評価結果

表 4.4.1.1-24

車両速度（10-20km/h）・疑似き裂幅・疑似き裂長さ観点での評価結果

200

表 4.4.1.1-25

車両速度（20-30km/h）・疑似き裂幅・疑似き裂長さ観点での評価結果

表 4.4.1.1-26

車両速度（30-km/h）・疑似き裂幅・疑似き裂長さ観点での評価結果

201

表 4.4.1.1-27 昨年度の模擬き裂の検出率・網羅率の一覧（令和 2 年度 成果報告書報告書より引用）

202 列車速度観点での評価
列車の速度については、目安として実測に基づきカメラと列車の台車の組み合わせごとに表 4.4.1.1-28 のように整理した。なお、表のうちカメラの撮影範囲外の車両はグレーで示している。
表 4.4.1.1-28

速度対応表

全体として、横方向よりも縦方向において、再現率が低い傾向が見られた。車両速度 010km/h のとき、縦方向は 50.25%、横方向は 58.38%であった。車両速度 10-20km/h のとき、縦方向は 55.00%、横方向は 72.50%であった。車両速度 20-30km/h のとき、縦方向は35.87%、横方向は 48.19%であった。車両速度 30km/h 以上のとき、縦方向は 35.96%、横方向は 51.75%であった。これは昨年度の結果と同様の傾向であり、映像を確認したところ
縦方向の疑似き裂のほうが目視確認が難しい傾向があるように見受けられた。

図 4.4.1.1-32

車両速度・疑似き裂方向観点での評価結果
203

表 4.4.1.1-29

車両速度・疑似き裂方向観点での評価結果

疑似き裂の幅に着目すると、30km/h 以上のときに幅 0.1mm の疑似き裂は 36 サンプルに対して 5.56%検出されており、AI システム性能としては 30km/h の場合に幅 0.1mm 相
当の疑似き裂を検出可能なことを確認した。そのほか、車両速度が 30km/h 以上の場合に、
幅 0.2mm 相当の疑似き裂の再現率は 11.11%、幅 1.0mm 相当の疑似き裂の再現率は 29.55%であった。幅 2.0mm 相当の疑似き裂の再現率は 65.00%、幅 4.0mm 相当の疑似き裂の再現率は 83.33%、幅 6.0mm 相当の疑似き裂の再現率は 75.00%と 7 割近くの検出性能となっており、速度のある対象物でも検出可能であることがいえる。
事前検証により、時速 30km で走行する乗用車を撮影して、画像が鮮明に写るシャッタースピードを調節し、さらに照度補完のためにライトを設置したことで、速度のある対象物
でも画像のぶれやぼやけを軽減し、検出性能を向上させることができたと考えられる。

図 4.4.1.1-33

車両速度・疑似き裂幅観点での評価結果

204

表 4.4.1.1-30

車両速度・疑似き裂幅観点での評価結果

疑似き裂の長さに着目すると、全体として長さ 60mm、80mm では速度による検出性能の大きな差はないように見受けられた。長さ 20mm になると大きく検出性能が下がり、その中でも車両速度が大きくなるにつれて検出性能が下がる傾向にあることがわかった。
長さ 20mm の疑似き裂の画像を目視で確認したところ、目視でも記入されている個所の特定が難しいものが見受けられた。本実証では、一度疑似き裂を車両の台車に記入した後は再度記入しなかったため、日が経つにつれて雨風にさらされ、短い疑似き裂は汚れが上書きされる、もしくは記入した油性黒ペンの線が薄くなることが想定される。本検証で解析の対象とした車両は、疑似き裂を記入してから 1 週間～2 週間経過したものであり、長さ 20mmの疑似き裂は汚れが上書きされた、もしくは線が薄くなったものが多く含まれていたと考
えられる。

205

図 4.4.1.1-34

車両速度・疑似き裂長さ観点での評価結果

表 4.4.1.1-31

車両速度・疑似き裂長さ観点での評価結果検出した疑似き裂の例を図 4.4.1.1-35～図 4.4.1.1-47 に示す。図に示すように、台車の汚れ具合はさまざまであり、台車ごとに色が異なっている。このように色が異なる台車に記入された疑似き裂でも検出できていることがわかる。AI 学習の教師データにも、羽田空港第1・第 2 ターミナル駅 1 番線で実際に撮影した映像を使用したことで、様々な汚れ具合の台車のデータが含まれた。これにより、台車の色の違いにも対応した AI 検出性能を持つシス
テムを構築することができた。

206

図 4.4.1.1-35

AI が検出した疑似き裂例（幅 0.1mm、長さ 20mm、車両速度 010km/h）

図 4.4.1.1-36

AI が検出した疑似き裂例（幅 0.1mm、長さ 60mm、車両速度 0-10km/h）

207図 4.4.1.1-37

AI が検出した疑似き裂例（幅 0.1mm、長さ 60mm、車両速度 1020km/h）

図 4.4.1.1-38

AI が検出した疑似き裂例（幅 0.1mm、長さ 60mm、車両速度 2030km/h）

208図 4.4.1.1-39

AI が検出した疑似き裂例（幅 0.1mm、長さ 80mm、車両速度 0-10km/h）

図 4.4.1.1-40

AI が検出した疑似き裂例（幅 0.1mm、長さ 80mm、車両速度 1020km/h）

209図 4.4.1.1-41

図 4.4.1.1-42

AI が検出した疑似き裂例（幅 0.1mm、長さ 80mm、車両速度 2030km/h）

AI が検出した疑似き裂例（幅 0.1mm、長さ 60mm、車両速度 30km/h 以
上）210

図 4.4.1.1-43

AI が検出した疑似き裂例（幅 0.1mm、長さ 80mm、車両速度 30km/h 以
上）

図 4.4.1.1-44

AI が検出した疑似き裂例（幅 2.0mm、長さ 20mm、車両速度 0-10km/h）

211図 4.4.1.1-45

AI が検出した疑似き裂例（幅 2.0mm、長さ 20mm、車両速度 1020km/h）

図 4.4.1.1-46

AI が検出した疑似き裂例（幅 2.0mm、長さ 20mm、車両速度 2030km/h）

212図 4.4.1.1-47
上）AI が検出した疑似き裂例（幅 2.0mm、長さ 20mm、車両速度 30km/h 以②ブレーキパッドの検出性能評価
ブレーキパッドの検出性能について、おおよそ検出できているものの、車両速度が大きくなるについて、再現率が下がる傾向が見られた。検出しなかったブレーキパッドのうち、チューブのようなものがブレーキパッドに重なって映っていることで、検出がしなかったものがあった。このような台車は教師データには存在しなかったため、今後追加学習を繰り返すことで性能が向上すると考えられる。

図 4.4.1.1-48

ブレーキパッドの検出性能評価結果

213

表 4.4.1.1-32

図 4.4.1.1-49

ブレーキパッドの検出性能評価結果

チューブのようなものが重なるブレーキパッドの例

ブレーキパッドの残存割合について、AI で検出された値の妥当性について評価した。
京浜急行電鉄では 10 日を超えない期間ごと（2022 年 3 月現在，6 日回帰）で列車検査を実施し、列車検査の際にブレーキパッド（制輪子）の残存割合を目視にて確認を行っている。
ブレーキパッドの残存割合は、残厚表示線からの厚さを目視に確認、交換を行っている。

214

図 4.4.1.1-50

図 4.4.1.1-51

ブレーキパッドの一例

ブレーキパッドの残圧表示線と外側・内側までの距離

215

AI により検出されたブレーキパッドの残存割合は、全体の厚みに対する残存する厚みを
パーセンテージで表したものになっている。その妥当性について、実際の点検時における目視確認方法を参考に、カメラで撮影された映像の中から残厚表示線が目視で判別できる画像を使用し、残厚表示線からブレーキパッドの外側までの距離と、残厚表示線からブレーキ
パッドの内側までの距離を目視により測定し、残存するブレーキパッドのおおよその厚み、および残存割合を算出した。その結果、おおよそ誤差が 5%未満に収まっていることを確認
し、AI によるブレーキパッドの残存割合の検出性能は妥当であると結論づけた。
表 4.4.1.1-33

ブレーキパッドの残存割合検出の性能評価結果

サンプルNo.

画像から目視で算出した残存割合

AI検出による残存割合

1

55%

53%

2

67%

69%

3

91%

89%

4

100%

96%

図 4.4.1.1-52

サンプル No.1 の検出結果

216

図 4.4.1.1-53

サンプル No.2 の検出結果

図 4.4.1.1-54

サンプル No.3 の検出結果

217

図 4.4.1.1-55

サンプル No.4 の検出結果

218

ブレーキパッドが検出されても、厚みが検出されなかった場合も見受けられた。ブレーキ
パッドの厚み検出は、まず車軸を検出し、その車軸の中心からブレーキパッドの外側までの距離により厚みを算出している。そのため、車軸がカメラの画角から見切れたために、厚みが検出されていないと考えられる。厚み検出の計算ロジックを見直すことで、車軸がカメラからある程度見切れていても厚み検出ができるように改善することは可能であると考えられる。

図 4.4.1.1-56

ブレーキパッドの厚みが検出されなかった例

219

③ハンドルの検出性能評価
ハンドルについては、おおよそ検出できていることを確認した。最大速度 20km/h までは適合率、再現率 100%で検出した。速度が 20km/h 以上になると、数件検出ができない場合が見受けられた。現状のシステムではハンドルを 100％検出可能なのは最大速度 20km/h が限界であると考えられる。なお、羽田空港第 1・第 2 ターミナル駅に入線する列車のハンド
ルはすべて正常である前提であることから、久里浜検車区で撮影したハンドルの向きを正常である水平から変更し異常な状態を模した映像を用いて、ハンドルの異常状態の検出性能を確認した。その結果、異常と検出されたことを確認し、さらに検出の漏れはないことを確認した。

図 4.4.1.1-57

ハンドルの検出性能評価結果

表 4.4.1.1-34

ハンドルの検出性能評価結果

220

図 4.4.1.1-58

図 4.4.1.1-59

ハンドル検出結果の例

ハンドル異常検出結果の例

221

④追加学習後の AI 検出精度の評価結果
カメラを羽田空港第 1・第 2 ターミナル駅の 1 番線に設置し、疑似き裂を記入した車両が入線するようになってからの約 25 日間においてカメラで撮影された、疑似き裂を記入した車両が発着する映像を AI の追加学習に使用し、再度 AI 検出精度について評価を行った。
その結果、疑似き裂、ブレーキパッド、ハンドルの検出性能が向上したことが確認された。
まず疑似き裂について、追加学習前はあまり検出ができていなかった幅 0.1mm、0.2mmの疑似き裂について、追加学習後は検出性能が向上したことが確認された。幅 0.1mm については、追加学習前後で適合率が 96.67%から 99.07%に、再現率が 15.10%から 55.21%に向上した。幅 0.2mm については、追加学習前後で再現率が 14.06%から 41.67%に向上した。疑似き裂の長さに着目すると、追加学習前はあまり検出ができていなかった長さ 20mmの疑似き裂について追加学習前後で再現率が 21.88%から 69.42%に向上した。
一方で、幅 0.2mm の適合率については、追加学習前後で 100%から 97.56%に減少したことが確認された。追加学習後のモデルでは、検出性能が向上したために、疑似き裂に似たものに対して反応しやすくなったものと考えられる。

図 4.4.1.1-60

車両速度観点の追加学習前後の AI 検出性能比較

表 4.4.1.1-35

車両速度観点の追加学習前後の AI 検出性能比較

222

図 4.4.1.1-61

疑似き裂幅観点の追加学習前後の AI 検出性能比較

表 4.4.1.1-36

疑似き裂幅観点の追加学習前後の AI 検出性能比較

図 4.4.1.1-62

疑似き裂長さ観点の追加学習前後の AI 検出性能比較

223

表 4.4.1.1-37

図 4.4.1.1-63

疑似き裂長さ観点の追加学習前後の AI 検出性能比較

疑似き裂方向・幅観点の追加学習前後の AI 検出性能比較

224

表 4.4.1.1-38

疑似き裂方向・幅観点の追加学習前後の AI 検出性能比較

図 4.4.1.1-64

疑似き裂方向・長さ観点の追加学習前後の AI 検出性能比較

225

表 4.4.1.1-39

表 4.4.1.1-40

疑似き裂方向・長さ観点の追加学習前後の AI 検出性能比較

車両速度（0-10km/h）・疑似き裂幅・長さ観点の追加学習前後の AI 検出性
能比較

226

表 4.4.1.1-41

車両速度（10-20km/h）
・疑似き裂幅・長さ観点の追加学習前後の AI 検出
性能比較

227

表 4.4.1.1-42

車両速度（20-30km/h）
・疑似き裂幅・長さ観点の追加学習前後の AI 検出
性能比較

228

表 4.4.1.1-43

車両速度（30km/h 以上）・疑似き裂幅・長さ観点の追加学習前後の AI 検
出性能比較

図 4.4.1.1-65

追加学習後のき裂誤検出の例

229

ブレーキパッドの AI 検出性能についても、追加学習により AI 検出性能が向上したことが確認できた。例えば、車両速度 30km/h 以上のときに、追加学習前後で再現率が 83.33%
から 92.08%に向上した。また、追加学習前は検出ができていなかった、ブレーキパッドにチューブのようなものが重なっている場合にも、追加学習により検出できるようになったことを確認した。

図 4.4.1.1-66

ブレーキパッドの追加学習前後の AI 検出性能比較

表 4.4.1.1-44

ブレーキパッドの追加学習前後の AI 検出性能比較

230

図 4.4.1.1-67

チューブのようなものが重なるブレーキパッドの例①（追加学習前）

図 4.4.1.1-68

チューブのようなものが重なるブレーキパッドの例①（追加学習後）

231

図 4.4.1.1-69

チューブのようなものが重なるブレーキパッドの例②（追加学習前）

図 4.4.1.1-70

チューブのようなものが重なるブレーキパッドの例②（追加学習後）

232ハンドルの AI 検出性能についても、追加学習により AI 検出性能が向上したことが確認できた。例えば、車両速度 30km/h 以上のときに、追加学習前後で再現率が 99.1%から 100%に向上した。

図 4.4.1.1-71

ハンドルの追加学習前後の AI 検出性能比較

表 4.4.1.1-45

ハンドルの追加学習前後の AI 検出性能比較

233

⑤京浜急行電鉄 8 両編成車両、他社車両のブレーキパッド、ハンドルの AI 検出結果
京浜急行電鉄の 8 両編成の車両について、ブレーキパッド、ハンドルの検出性能を確認した。評価には追加学習したモデルを使用した。評価対象は 8 両編成車両の 3 編成、各 1 往復ずつ走行する、合計 6 回走行分の映像とした。
ブレーキパッドについては、6 両編成の評価結果と同様に、車両速度が大きくなるにつれて再現率が減少する傾向が見られた。適合率、再現率ともに、6 両編成の追加学習後の検出
性能評価結果と比較して大きな差異は見られなかった。以上の結果から、京浜急行電鉄の 8両編成の車両に対しても、ブレーキパッドを検出可能であると結論付けた。
ハンドルについては、おおよそ 6 両編成の追加学習後の検出性能評価結果と同等に検出ができており、適合率、再現率ともに、6 両編成の追加学習後の検出性能評価結果と比較して大きな差異は見られなかったことから、京浜急行電鉄の 8 両編成の車両に対しても、ハンドルを検出可能であると結論付けた。一部、誤検出されている箇所が見られ、誤検出された要因について、以下の 2 点が画像の分析により確認された。
 AI の学習に使用した 6 両編成車両と形状が異なること。
 ハンドルの形状に似た汚れが台車部分に見られたこと。
車両の台車部分の形状は型式により異なる形状となっており、学習データの対象とした 6両編成の 24 編成の列車には含まれていなかったり、データの数が少なかったりした形状の台車については検出性能が下がる可能性がある。今回の学習データの対象としなかった台車も含めて追加学習を行うことで、適合率の向上は可能であると考えられる。

図 4.4.1.1-72

京浜急行電鉄 8 両編成車両ブレーキパッドの検出性能評価結果234

表 4.4.1.1-46

京浜急行電鉄 8 両編成車両ブレーキパッドの検出性能評価結果

図 4.4.1.1-73

京浜急行電鉄 8 両編成車両ブレーキパッドの検出結果の例

図 4.4.1.1-74

京浜急行電鉄 8 両編成車両ハンドルの検出性能評価結果

235

表 4.4.1.1-47

京浜急行電鉄 8 両編成車両ハンドルの検出性能評価結果

図 4.4.1.1-75

京浜急行電鉄 8 両編成車両ハンドルの検出結果の例

図 4.4.1.1-76

京浜急行電鉄 8 両編成車両ハンドルの誤検出の例①（左：京急 8 両編成、右：京急）236

図 4.4.1.1-77

京浜急行電鉄 8 両編成車両ハンドルの誤検出の例②（ハンドルの形状に似た汚れ）

羽田空港第 1・第 2 ターミナル駅

1 番線に入線する他鉄道会社の車両について、ブレー

キパッド、ハンドルの検出性能を確認した。評価には追加学習したモデルを使用した。評価
対象は 8 両編成車両の 3 編成、各 1 往復ずつ走行する、合計 6 回走行分の映像とした。
ブレーキパッドについては、適合率・再現率ともに 80％以上の結果となっており、一定の検出性能が確認された。京浜急行電鉄 6 両編成車両と比較して、再現率が低く検出できていないサンプルが見られたが、追加学習に他社車両のデータを含むことで再現率は向上可能であると考えられる。
ハンドルについては、再現率については 100％となっており、他社車両であってもハンド
ルを検出可能であるとみられる。適合率については 100％に達しておらず、画像を分析した
ところ、京浜急行電鉄の車両には見られないパーツがハンドルとして検出されていた。ブレーキパッドと同様に、追加学習に他社車両のデータを含むことで再現率は向上可能であると考えられる。
羽田空港第 1・第 2 ターミナル駅には、相互直通運行している異なる鉄道会社 4 社の車両が入線しており、他社の車両においても一定の検出性能が確認され、追加学習により検出性能の向上が見込めることから、本システムは汎用性があるシステムであると結論づけた。

237

図 4.4.1.1-78

他社車両ブレーキパッドの検出性能評価結果

表 4.4.1.1-48

他社車両ブレーキパッドの検出性能評価結果

図 4.4.1.1-79

他社車両ブレーキパッドの検出結果の例
238

図 4.4.1.1-80

他社車両ハンドルの検出性能評価結果

表 4.4.1.1-49

他社車両ハンドルの検出性能評価結果

図 4.4.1.1-81

他社車両ハンドルの検出結果の例
239

図 4.4.1.1-82

他社車両ハンドルの誤検出の例

240d）その他の評価結果
適合率と再現率が低かった疑似き裂について、要因を分析した。
・誤検出について
今回の実証において、疑似き裂として油性黒ペンで台車部分に書き込みを行った箇所以
外にも、き裂として検出された箇所が見受けられた。誤検出されたき裂の例を図 4.4.1.1-83に示す。

図 4.4.1.1-83

き裂の誤検出の例
241

き裂が誤検出された箇所の画像を確認したところ、汚れや塗装のひび割れをき裂として検出している可能性があることがわかった。
昨年度はこのように疑似き裂でない箇所をき裂として誤検出することは生じていなかった。昨年度は疑似き裂としてシールに線を印刷し台車に貼り付けて検証を行ったが、その際シールの反射を含めて AI 学習をさせたことで、シールの反射があるものをき裂として一部検出していた可能性が考えられる。今年度の実証では、シールの反射を考慮し油性黒ペンで疑似き裂を記入したことにより、シールの反射等ではなく、き裂の形状を認識して検出することができていると考えられる。誤検出された箇所の汚れや塗装のひび割れは、疑似き裂として記入したものと、画像上で見る限り人の目で見ても類似しており、学習させた疑似き裂に類似したものを検出することができる AI であると考えることができる。
一方で、誤検出を減らすためには AI の追加学習が必要となるが、そのためには長期間にわたりデータを収集し、京浜急行電鉄の技術者の目線で画像を確認し、異常である・異常ではない、の判断を行う等、膨大な時間と作業量が必要となる。AI の追加学習については今後の課題とし、継続運用の中で協議のうえ対応を検討する。
・目視確認が不可能
対象の疑似き裂が目視困難であり、検出ができない場合が見受けられた。詳細については
4)その他（現場環境）内の環境適応性（対象物の色合い）の項で述べる。
・映像の乱れ撮影された映像のうち、映像が乱れたことにより解析不可能となった場合があった。このような乱れは切り分けを行った結果、カメラ起因により発生していることがわかった。

e）実用可能性の評価結果
利用者の体感とオペレーション観点での実用性について、京浜急行電鉄の車両部へのアンケートを通じて評価した。デモンストレーションで確認した AI 検出結果の画面について
は、検出ができているという意見を得られた。一方で、塗装のひび割れなど疑似き裂ではな
いものをき裂として検出する場合があることが確認されており、き裂の AI 判定をどのように学習させるか、精度の向上と追加学習が課題として浮き彫りになった。

242

その他（現場環境）
a）環境適応性（照度）照度変化にともなう AI 検出性能の評価結果
夜間に疑似き裂を記入した 4 両編成の車両を時速 5km/h で走行させ、ライトが 1 灯のときと 2 灯のときで検出性能の差を評価した。なお、疑似き裂は 80mm の長さのものを対象とした。
表 4.4.1.1-50
ライト数
1
2

合計/AIが検出した
32
41

環境適応性（照度）の評価結果
合計/AIが検出しなかった
0
0

サンプル数
40
47

適合率
100.0%
100.0%

再現率
80.0%
87.0%

ライト 1 灯のときは網羅率が 80.0%であるのに対し、ライト 2 灯のときは 87.0％となっていることから、ライト数が多く明るい環境であるほうがより多くの疑似き裂を検出できているといえる。

b）対象物の色合い変化にともなう AI 検出性能の評価結果
疑似き裂を記入した箇所のうち、AI が検出しなかった箇所について、カメラで撮影した映像（図 4.4.1.1-84）を確認したところ疑似き裂を目視確認が困難であり、かつ疑似き裂を記入した直後の画像（図 4.4.1.1-85）でも疑似き裂の目視確認が困難な箇所があった。

図 4.4.1.1-84

カメラで撮影した画像（AI が検出しなかった箇所）

243

図 4.4.1.1-85

疑似き裂を記入した直後の画像（AI が検出しなかった箇所）

今回、疑似き裂として油性黒ペンで台車に線を記入したが、台車の色と油性黒ペンの色がほぼ同色であり、目視確認ができないほど背景色と同化しており AI で検出されなかったものと考えられる。疑似き裂を油性黒ペンで記入したことにより検出されなかったものと考えることもでき、より実際のき裂に近しいものでき裂を再現し、検証を行う必要があることが示唆された。

c）長期安定性（カメラ機材の連続稼働時間）の評価結果
実証実験開始日から安定して動作していることを確認した。

d）長期安定性（GPU 搭載ノート PC の連続稼働時間）の評価結果
実証実験開始日から安定して動作していることを確認した。

244e）長期安定性（5G ルータの連続稼働時間）の評価結果
実証期間中、3 台使用している 5G ルータのうち、2 台は通信断が各 1 回ずつ発生した。
1 台は実証実験開始日から安定して動作していることを確認した。
事前にメーカに確認した動作実績では、ビデオストリームを流した状態で 120 時間連続
稼働、および 3 週間連続で ping 疎通試験を実施した動作実績を確認した。一方で本実証の設置環境はメーカで動作実績のない、防水防塵 BOX に入れて使用し、24 時間 365 日電源が入った状態で稼働し、ホーム下のため現地に人が立ち入り定期的に電源 ON/OFF や再起動を行うことができない環境であった。このため、事前確認では確認しえなかった事象が発生したものと考えられる。5G ルータは OS を搭載した機器であり、定期的に電源を OFF したり再起動したりすることが一般的に必要であるが、5G ルータを選定した当時、5G 基地
局装置と接続し動作実績のある機種を選定したが、該当機種には遠隔から再起動をしたり、定期的に再起動をしたりする機能が備わっていなかった。5G 基地局装置と接続動作実績のある端末はこれから増えていく見込みであることから、将来的には遠隔再起動や定期的な再起動の機能が備わった機種を選定することが望ましい。

245

効果検証のまとめ
 通信性能カメラ～クラウドの上り通信は、目標値である 60Mbps を達成しており、十分な性能があるといえる。一方でクラウド～監視用端末の下り通信は、本実証ではコスト、構築期間、
セキュリティの関係で、固定 IP アドレスにより接続元制限をかけた、モバイル回線によるインターネット接続を使用したため、3 つの映像を閲覧するためには不十分な性能であった。
実運用の際には、下り通信においても 5G を使用できる環境での映像閲覧が望ましい。
本実証におけるローカル 5G アンテナの設置場所である駅ホーム下は、柱や既存設備など
電波伝搬の観点での障害物が多いほか、列車がホームに停車する間は列車も障害物になる
ため、回折しやすい Sub6 帯を採用した。一方で、将来的には費用対効果の観点からもユー
スケースを拡大し、車内や駅ホーム上の安全監視、車内や駅ホーム上および駅構内への運行
情報の配信や広告の掲示などでの利用を検討する見込みである。実現のためには、Sub6 では伝送容量が足りなくなることが想定されるため、エリア観点の課題を払拭することができれば、ミリ波は有効であると考えられる。
 UI 性能
通信環境により画面表示に時間がかかるなど、操作の体感に大きな影響を与えた。上記と同様に、実運用の際には、下り通信においても 5G を使用できる環境での映像閲覧が望ましい。実運用を考慮すると、画面表示の機能には改善の余地が見受けられた。画面上で提示する情報の順位を決め、分かりやすい表示が必要である。全体を通して、京浜急行電鉄車両部から、利用することを前提にした具体的な改善案等の意見を得ることができたことから、実装に向けたより詳細な検討のステップを踏むことができていると考えられる。
 AI 検出性能
昨年度よりも速いスピードでの検出が実現できたことから、システム性能を向上することができたといえる。昨年度と比較し、列車の台車部分とカメラの距離が近くなり映像がよ
り鮮明になったこと、ライトを設置したため、照度が一定かつ十分な明るさが確保された環境を構築できたことから、再現率が向上したものと考えられる。長期間実証を行ったことにより、AI 学習に使用する教師データをより多く収集できたことで、追加学習により検出性能を向上できることを確認した。また、羽田空港第 1・第 2 ターミナル駅に相互接続している異なる 4 社の車両についても一定の検出性能を確認したことから、本システムは汎用性があると評価した。
一方で、実運用を踏まえると、AI 検出精度、リアルタイム性の 2 点が課題として浮き彫りになった。実運用の際にはき裂が走っている危険な状態の車両はすぐにでも停止し点検することが求められるため、カメラで異常を検出したらすぐに通知とともに対象の画像を確認できることが望ましい。AI 検出精度の向上のためには追加学習が必須となるが、そのためには長期間にわたりデータを収集し、京浜急行電鉄の技術者の目線で画像を確認し、異常である・異常ではない、の判断を行う等、膨大な時間と作業量が必要となる。リアルタイ
ム性の向上のためには処理時間の短縮が必須であり、クラウドリソースの向上が必要となるが、長期運用を前提とするとコストが大きくなるため、クラウドリソースの低価格化が求
められる。
246

247

4.4.1.2 機能検証
（1）評価・検証項目
実証におけるローカル 5G を用いたソリューションのシステムを構成する伝送メディア、
映像取得、映像蓄積、映像解析、映像配信、結果表示の各ジャンルにおいて、それぞれ以下の項目に関して機能検証を実施した。

伝送メディア
伝送メディアとして、「キャリア 5G」
「ローカル 5G」
「Wi-Fi」「光ケーブル」を評価・検証の対象とした。
映像取得
映像取得機材として、「8K カメラ」「4K カメラ」「フル HD カメラ」「ハイスピードカメ
ラ」「サーマルカメラ」を評価・検証の対象とした。
映像蓄積
映像蓄積用に使う基盤サービスとして、「dOIC」「AWS」「Azure」を評価・検証の対象とした。
映像解析
映像解析手法として、「単純画像解析」「ディープラーニング」「人の目」を評価・検証の対象とした。
映像配信
映像配信規格として、「WebRTC」「HLS」「RTSP」を評価・検証の対象とし、また、コーデック規格として「H.264」「VP8」「VP9」を評価・検証の対象とした。
結果表示
UI 設計（デバイス）として、「PC」「タブレット」「スマートフォン」評価・検証の対象とし、また、UI 設計（媒体）として「ブラウザ」「アプリ」「専用デバイス」を評価・検証の対象とした。

248

（2）評価・検証方法
実証におけるローカル 5G を用いたソリューションのシステムを構成する伝送メディア、
映像取得、映像蓄積、映像解析、映像配信、結果表示の各ジャンルにおいて、それぞれ以下の方法を使って機能検証を実施した。
伝送メディア
伝送メディアとして、「キャリア 5G」
「ローカル 5G」
「Wi-Fi」「光ケーブル」を対象とし、それぞれの「性能・スペック」、「拡張性」、「運用保守性」、「コスト・汎用性」の点からそれぞれを検証し、5 段階評価して、総合的な機能評価を行った。

映像取得
映像取得機材として、「8K カメラ」「4K カメラ」「フル HD カメラ」「ハイスピードカメ
ラ」「サーマルカメラ」を対象とし、それぞれの「性能・スペック」、「拡張性」、「運用保守性」、「コスト・汎用性」の点からそれぞれを検証し、5 段階評価して、総合的な機能評価を
行った。
映像蓄積
映像蓄積用に使う基盤サービスとして、「dOIC」「AWS」「Azure」を対象とし、それぞれの「性能・スペック」、「拡張性」、「運用保守性」、「コスト・汎用性」の点からそれぞれを検証し、5 段階評価して、総合的な機能評価を行った。
映像解析
映像解析手法として、「単純画像解析」「ディープラーニング」「人の目」を対象とし、それぞれの「性能・スペック」、「拡張性」、「運用保守性」、「コスト・汎用性」の点からそれぞれを検証し、5 段階評価して、総合的な機能評価を行った。
映像配信
映像配信規格として、「WebRTC」「HLS」「RTSP」を対象とし、また、コーデック規格
として「H.264」「VP8」「VP9」を対象とし、それぞれの「性能・スペック」、「拡張性」、「運
用保守性」、「コスト・汎用性」の点からそれぞれを検証し、5 段階評価して、総合的な機能評価を行った。
結果表示
UI 設計（デバイス）として、「PC」「タブレット」「スマートフォン」を対象とし、また、UI 設計（媒体）として「ブラウザ」「アプリ」「専用デバイス」を対象とし、それぞれの「性能・スペック」、「拡張性」、「運用保守性」、「コスト・汎用性」の点からそれぞれを検証し、5 段階評価して、総合的な機能評価を行った。
249

（3）実証結果及び考察
本実証におけるローカル 5G を用いたソリューションのシステムを構成する各ジャンル（伝送メディア、映像取得、映像蓄積、映像解析、映像配信、結果表示 ）の機能の評価・検証結果を以下に記載する。

伝送メディア以下の表に示すように、①伝送メディアでは「ローカル 5G」を利用することが適切であると結論付けた。
表 4.4.1.2-1 伝送メディアのジャンル別機能の評価・検証結果
伝 送 メ デ ィ 性能・ 拡 張 運 用 コ ス 評点
コメント
ア
スペッ 性
保 守 ト・汎ク
性用性
キャリア 5G
3
2
5
4
14 5G のエリアがキャリア次第となってしまい使用場所には制約がある。下り通信としては優位性があるが、他の利用者による通信速度低下などの影響などは受けやすいといえる。
ローカル 5G
4
4
5
2
15 アンテナの設置場所などを含め、利用用途にあわせた柔軟なエリア
設計が可能となる。コストが高い
ことが難点ではあるが、ほかの利用者による通信速度の低下などの影響を受けないなどの観点でも優位性がある。
光ケーブル
4
3
3
4
14 物理的な制約がなくケーブルの敷設に問題がないようであれば、上り、下りともに帯域は良好である
が、保守性に関しては他メディアに比べて劣る。
総 合 的 な 評 実証フィールドとなる羽田空港第 1 駅・第 2 ターミナル駅構内は地下 2 階部
価分ということもありキャリア 5G のエリア外であった。また、駅構内の工事状
況等に応じ、システムの設置場所を柔軟に変更可能であることから、伝送メ
ディアとしてはローカル 5G が適していたともいえる。
ただ、前述のとおりローカル 5G のコアネットワーク装置群は、GNSS アン
テナを屋外に設置する必要があり、地上への配線が可能な隣駅となる羽田空
港第 3 ターミナル駅に設置することになった。こちらについては、1 駅分の距離をおいてもローカル 5G 基地局と屋内無線装置、無線アンテナを離して設置することができるなど、設置環境の制約に応じた柔軟な機器設置ができたことは設計、構築段階においても特に有用であった。

250

映像取得
以下の表に示すように、②映像取得では「フル HD カメラ」を利用することが適切であると結論付けた。

映像取得

8K カメラ

4K カメラ

フル HD
カメラ

サーマル
カメラ

総合的な
評価

表 4.4.1.2-2 映像取得のジャンル別機能の評価・検証結果
性拡 張 運 用 コ ス 評点
コメント
能 ・ 性
保 守 ト ・
ス ペ
性
汎 用
ック
性
映像品質が極めて高い。帯域次第
5
2
2
1
10
でフレーム数が減少。エンコード・でコード技術が開発中で、クラウド上に実装不可。
映像品質が高い。エンコード・デコ
4
3
3
3
13
ードの汎用技術を利用可能。クラウド上に実装可能。屋外設置可能な防水・防塵対応機種が限定される。フレーム数は機材次第で増減。
映像品質が中程度。エンコード・デ
3
4
5
4
16
コードの汎用技術を利用可能。ク
ラウド上に実装可能。屋外設置可
能な防水・防塵対応機種が比較的多い。フレーム数は機材次第で増減。
映像品質は低いが温度情報を取得
3
2
2
2
9
可能。フレーム数が少ない。屋外設
置可能な防水・防塵対応かつ、移動体を撮影可能なスペックを有する機種が市場に存在しない。
今回の実証では、カメラの設置場所が地下駅のホーム下であり、汚れや湿度等の影響を受けることが想定され、長期安定性を考慮すると屋外設置可能な防水・防塵対応の機種を選定することが必須と考えた。防水・防塵対応でストリーミ
ング映像配信可能、かつ開発可能な拡張性の高い機種は限定され、4K/フル HDの両方に対応した機種を選定した。ただし、選定した機種では 4K 映像のフレ
ーム数は 15fps が上限であり、フル HD 映像では 30fps が上限であるなど、フレーム数は機材のスペック次第で増減する。今回の実証では速度のある対象物を撮影することが前提となっており、フレーム数が多いことが望ましいことから、選定した機種のうちフル HD 映像を採用した。

251

映像蓄積
以下の表に示すように、③映像蓄積用基盤サービスでは「dOIC」を利用することが適切であると結論付けた。
表 4.4.1.2-3 映像蓄積のジャンル別機能の評価・検証結果
映像蓄積
性能・ 拡 張 運 用 コ ス 評点
コメント
スペッ 性
保守 ト ・
ク
性
汎 用
性
dOIC
5
3
4
3
15
本実証では昨年度課題解決型実証システム環境の構成を踏襲することで社会実装実現性の向上を目指すこともあり昨年度同様
dOIC を選定とした。ただし、基盤としての性能比較の面では、拡張性などについては他社パブリッククラウドには劣る。
AWS
4
4
4
3
15
dOIC・AWS との遅延比較では、
AWS ではインターネット経由での基盤接続構成をとる場合には遅延に対する対策の検討が必要である。例えば、KDDI(au)5G を
利 用 す る 場 合 は 、 AWS
Wavelength という低遅延接続可能な MEC が活用可能である
ため遅延に関する問題は改善されることが考えられる。
Azure
3
4
4
4
14 パブリッククラウドサービスとしては活用しやすい機能と構成が用意されている。しかし、5Gを利用して低遅延性を求める場
合については、現時点で、5G 環
境と閉域接続する構成がない。
このため低遅延性については、
dOIC/AWS と比較すると見劣りする。
総 合 的 な 評 本課題実証では「4K 映像をクラウドでリアルタイム AI 解析し、利用を価想定するロケーションでリアルタイム活用すること」を前提で評価した。
本実証では、伝送を行う無線 NW 環境としてローカル 5G 環境を活用することとし、映像伝送基盤については、昨年度の課題実証システム構成を踏襲しドコモオープンイノベーションクラウド（以降、dOIC）を用いて昨年度に引き続き社会実装性を高めることに主眼を置くこととした。他基盤については、KDDI(au)5G を利用する場合は、AWS Wavelength が、遅延観点では優れ た 構 成 と な る こ と が 考 え ら れ る 。 Azure に つ い て は 、 現 時 点 で
dOIC,AWS Wavelength と同等な低遅延接続構成が存在しないようであ
る。
252

映像解析
以下の表に示すように、④映像解析では「ディープラーニング」を利用することが適切であると結論付けた。

映像解析

単純画像
解析

ディープ
ラーニン
グ
人の目

総合的な
評価

表 4.4.1.2-4 映像解析のジャンル別機能の評価・検証結果
性 能 ・ 拡 張 運 用 コ ス 評点
コメント
スペッ 性
保守 ト ・
ク
性
汎 用
性
2
2
4
5
13
精度が低く移動体にも活用可能、
特定物体の検出のみで拡張性が少ない。シンプルで、保守性とコスト面では高評価である。
5
4
4
4
17
精度が高く移動体にも活用可能、判断材料を学習させ同様物体の検出要否を判断可能。保守性が高く低コストに運用可能である。
3
5
3
2
13
精度が高いが移動体の 検出が困
難、経験的に幅広い判断軸をもつが、維持する人件費や稼働時間の制約が発生する。
車両検査の遠隔・自動監視システムの構築にあたっては、移動体に対する検出を複数同時かつ高精度に実施する必要がある。このとき、単純画像解析では精度が上がらず、人の目では運用コストが莫大になってしまう。そのため、ディープラーニングの AI エンジンを導入し、同様の映像を常時解析し続け、異常状態を検出した時のみ、専門の技術者が確認した上で、対処するのが理
想である。

253

映像配信
以下の表に示すように、④映像配信では「WebRTC」を利用することが適切であると結論付けた。
表 4.4.1.2-5 映像配信（映像配信規格）のジャンル別機能の評価・検証結果
映像配信 性能・ 拡 張 運 用 コ ス 評点
コメント
（ 映 像 配 スペッ 性
保 守 ト ・
信規格） ク
性
汎 用
性
WebRTC
55
4
3
17
4K30fps で映像伝送と配信が可能であり、拡張性として同時接続数を柔軟に増やせ、多拠点配信が可
能な商用パッケージが存在する製品のため、問題発生時はベンダへ問い合わせ可能であり、運用・保守性に優れている。ただし、製品のため年間ライセンス費用が発生す
る。
HLS
3
4
3
4
14
4K30fps で映像を配信可能ではあるが、他の方式と比較した場合に遅延量が大きく、リアルタイム性に欠けるものである。拡張性・汎用性は HTTP 利用端末であれば映像の受信が可能である。
RTSP
5
3
3
4
15
4K30fps で映像を低遅延で配信可
能であるが、同時接続数の拡張性
は WebRTC に劣る。また、商用パッケージが少なく、オープンソースソフトウェア(OSS)が選択肢となってしまう。OSS では実装・
テスト・運用の問題発生時において、提供団体・コミュニティへ問
い合わせとなるため、解決が長期化する懸念が残る。
総 合 的 な 本実証において車両の映像をより速やかに AI エンジンへ伝送し、異常の検評価
出を行う必要があることを前提として評価した場合に、WebRTC は低ビットレート・低遅延での映像伝送が可能で、かつ複数拠点への配信機能に優れていることから、運用と保守性に優れていると判断した。
HLS は拡張・汎用性はあるものの遅延量が大きいことから不採用とした。
RTSP は低遅延なものの商用パッケージとしての扱いが少なく、OSS が選択肢となるため、問題発生時の対応解決方法を考慮し不採用とした。

254

表 4.4.1.2-6 映像配信（コーデック）のジャンル別機能の評価・検証結果
映像配信 性拡 張 運 用 コ ス 評点
コメント
（コーデ 能 ・ 性
保 守 ト ・
ック）
ス ペ
性
汎 用
ック
性
H.264
5
5
5
3
18
従来方式である MPEG-2 などの 2倍以上の圧縮効率を実現可能である。HDTV クラスの高ビットレート用途に至るまでの幅広く利用されることを想定されている。
VP8
2
3
2
5
12
ロイヤリティフリーとして発表されたコーデック。ビットレートハ
ンドリングに優れており比較的低めのビットレートでも性能を発揮
するが、エンコードが遅いうえ、同等の品質を持つ H.264 が広く普及していることと、後継の VP9があるため VP8 を選択するメリットがあまり無い。
VP9
4
2
3
5
14
VP8 の後継としてロイヤリティフ
リーで発表されたコーデックである。動画の圧縮率が最も高い上、低ビットレートでも高い画質が実現できているが、甲圧縮することから VP8 よりも CPU の使用率が20～30%ほど上がってしまうた
め、ハード面のコストにデメリッ
トが発生する恐れがある。
総合的な 汎用性を考えた場合に一般的な防犯カメラ仕様に多く適用されている H.264
評価
コーデックが適切と考えた。性能面についても VP8、VP9 と今回実証内容で必要な条件においては大きな差も無いことから、H.264 を採用することとし
た。

255

結果表示
以下の表に示すように、⑥結果表示では「PC」を利用することが適切であると結論付けた。
表 4.4.1.2-7 結果表示（デバイス）のジャンル別機能の評価・検証結果
結果
性能
拡 張 運 用 コ ス 評点
コメント
表示
・
性
保 守 ト ・
(デバイ ス ペ
性
汎 用
ス)
ック
性
PC
5
5
3
2
15
フル HD 映像の画質を低下せず再生可
能、かつ複数映像を同時に再生可能な
GPU メモリ等、リソースの選択肢が最も柔軟なデバイスである。AI で解析された結果を画面上から確認する際の視認性も十分であり、遠隔点検には最も適したデバイスであると考えられる。
ただし、持ち運びには難がある。デス
クトップ型であれば常時給電が必要なため据え置きが前提となる。バッテリーを搭載したノート型であっても、高性能なものになれば消費電力も高くなり、バッテリー運転時間は比較的短くなってしまうケースもある。
4
2
4
3
13
タ ブ レ
持ち運びが容易な上、画面も比較的大ット
きなものが多く、現場で AI 解析結果
映像と現物を比較するなど幅広い利用ケースが考えられる。PC ほどの高スペックは期待できないが、それを十分カバーできるほどの機動性がメリットで
ある。
2
1
2
5
10
ス マ ー
小型で持ち運びに優れており、導入コ
ト フ ォ
ストも比較的安くなる。一方で、リソンースも低く異常検出箇所を確認するた
めには画面も小さいため、フル HD 映
像で伝送するメリットが低いと考えられる。今回の実証においては複数のカメラの映像を同時に配信するため、再生するためのスペックや画面の大きさの点で不十分であると考えられる。
業務用としても導入率が上昇している
ため、AI 異常検出時の通知の受け取りや、一次確認など運用面での工夫によりその機能を十分に発揮できると考えられる。
総 合 的 今回の検証においては、フル HD 映像を高画質のまま、かつ複数の映像を同時にな評価
配信・再生することを前提としているため、性能が最も優れる PC を選定した。
今後の導入時のオペレーションを考えた場合には、詳細な検出結果映像の確認には PC を用い、AI 異常検出時の通知の受け取りや、対象の検出結果画像を一次確認するために、可搬性に優れたタブレットやスマートフォンを用いる等、デバイス
によって役割分担することで、デバイスの機能を発揮する形で運用することが望
ましいと考えられる。
256

4.4.1.3 運用検証
（1）評価・検証項目
実際の鉄道駅でローカル 5G 活用モデル（5G と AI を活用した列車検査の遠隔化・自動化システム）の運用を試行する本実証では、今後継ぎ目なく実運用していく際の解決すべき課題を運用面から明確化し、解決していく必要がある。このため、運用検証として、実証結果を踏まえたローカル 5G 活用モデルの運用面における課題抽出・解決策の検討を実施。
課題解決に向けたシステムが具備すべき要件と考える、①一般性・汎用性、②拡張可能性、③経済性の観点から運用検証を実施した。
① 一般性・汎用性
課題解決システムが、広く他事業者でも適用できる一般性、汎用性を有する（すなわち、高い横展開の可能性を有する）。ここには、危険を伴わずにシステムを運用できる「安全性」、
システムが遅延なく使い心地よく運用できる UI の「利便性」、システムそのものの「持続可能性」を含むものとする。
② 拡張可能性
課題解決システムが、対象とする事業により変化させることができる、事業規模の変化に応じてシステムを拡張できるスケーラビリティを有する。
③ 経済性
課題解決システムが、イニシャル・ランニングコストに見合う、財政面の効果（必要な人
員、時間、経費など）をもたらすという経済性を有する。特に、土木インフラ等と比較して一定程度短期間でのコスト削減効果を求められる民間の鉄道経営の観点にも留意する。
評価・検証は、京浜急行電鉄の現場技術者（車両部門）へのヒアリング結果にもとづき評価した。実証実験の事前・事中・事後など多段階にて現場技術者にヒアリングを実施し、“継ぎ目のない実運用”を念頭に置いた現行のオペレーションにおける運用の課題を整理し、オ
ペレーションの改善等への寄与度を検証した。
【ヒアリング項目】➢➢➢➢

従来の検査に課題解決システムの機能を追加するオペレーションの運用可能性
具体的な運用スキーム（人員配置や現場作業）の想定
実際の運用スキームを想定した際の懸念事項
過去に遡って画像を確認できるメリット、考えられる活用方法

257

1）実運用に関する作業
課題解決システムの運用方法のうち「（各駅における）状態監視による日常定点観測」に着目し、実運用に関する作業項目を抽出したうえで評価した。
実運用に関する作業項目は以下のとおりである。

課題解決システムの管理

異常検知

異常検知のアラートの認知

異常検知の
画像確認
異常がない場合（検知エラー）

異常がある場合

異常が疑われる場合異常検知の目視確認異常がある場合異常がない場合（検知エラー）

運行取り止め＋
最寄りの検車場に入庫

運行継続

事後の振り返り図 4.4.1.3-1

作業項目の検討（実運用）258

2）運用スキームの持続性等に関するシステムのメンテナンス作業
課題解決システムの運用方法のうち「（各駅における）列車の状態監視による日常定点観測」に着目し、運用スキームの持続性等に関するシステムのメンテナンス作業項目を抽出したうえで評価した。
通常時のメンテナンスに関する作業項目は以下のとおりである。
表 4.4.1.3-1 作業項目の検討（通常時のメンテナンス）
分類
項目
対応者
5G エリアの保守
システム運用サービス提供者
クラウド環境の保守
機器の点検
振動（映像のぶれ）
現場における運用
サービス提供者
機器の清掃
カメラレンズの汚れ
また、現場における運用のうち、「振動（映像のぶれ）」および「カメラレンズの汚れ」が検出の正確さにどの程度影響を与えるか検証し、振動の許容範囲および清掃の必要な間隔を確認した。

259

（2）実証結果及び考察
ローカル 5G 活用モデルの運用検証の結果を表 4.4.1.3-2 に示す。
本実証は、継続運用を見据えて実際の鉄道駅にて営業車両を対象に実施するもので、令和 2 年度とは異なり、運用作業は京浜急行電鉄における実オペレーションを踏まえ、評価・検証することを基本とした。
結果として、課題は大きく人的負担（費用）の増加、オペレーションにおける改善の必要性の 2 つが挙げられる。解決策として、以下のとおり考えられる。
【人的負担（費用）の増加】
・作業内容のマニュアルを作成し、日常業務の一環とすること
・可能な限りシステム面で作業を補助し、対応者の負担を軽減すること【オペレーションの改善の必要性】
・導入時の影響を抑制するようなオペレーションを検討すること・検討したオペレーションを踏まえて、システムを構築すること
なお、導入にあたっては、上記の課題に対する解決策で負担の軽減や影響の抑制を図るものの、将来の効果発現に向けて順応するための期間が必要となると考える。
表 4.4.1.3-2
分類

運用作業
課題解決システムの

対応者

対応場所

車両部

管理

－
（
１
）
実
運
用
に
関
す
る
作
業

運用検証の結果（1/2）

課題と対応策

評価の観点

課題

対応策

①一般性・汎用性②拡張可能性③経済性

 問題なく運用は可能であると想 マニュアル化により日常業務の システムの管理に特別な技

 観測点の追加などのシステム

 本作業の人的負担（費用）は定されるものの、システムの起一環とすることで、人的負担軽術を必要としないため、事拡張は本作業の負荷を大きく動、運用、停止などの管理（保減を図る

業者を問わず運用可能するものではなく拡張可能性

守は分類（2））を実施する際の

純増となる

は高い

 また、相互乗り入れを実施し人的負担が必要となるている他社の車両についても追加の AI 学習の実施により対応が可能
異常検出のアラートの
認知

車両部

事務所（本

 問題なく運用は可能であると想 人的リソースの割り当てだけで 特別な技術を必要としない

 観測点の追加や他社の車両の社、各検車区定されるものの、アラートを適なく、異常検出のアラートを然ため、事業者を問わず運用対応などのシステム拡張によ等）

時認知する体制が必要るべき担当者に伝達するシステ

可能

りアラート件数の増加が想定

ムの構築が必要 伝達するシステムとしては以下が考えられる 関係者（複数）に画像付きのメールを送付

 監視用 PC のそばに回転灯を設置し、異常検出時に点灯259されるものの、運用上は拡張可能性が高い 大きな費用増は伴わない

表 4.4.1.3-2

分類

運用作業
異 常 検出 のアラ ー ト

対応者
車両部

の画像確認

運用検証の結果（2/2）

課題と対応策

対応場所

評価の観点

課題

対応策

事務所（本

 アラートは人の目で確認すること

 複数の技術者で判断することが望社、各検車区が必須であり、遠隔監視によるフましいため、スマートフォンやタ（運行の条件により異なる対応などのシステム拡張によ等）

ル HD 画像は有効であると考えブレットから監視システムにアクものの、鉄道会社の運行管り必要な「判断」の増加が想 現場に即したマニュアルを作られる。一方、アラートを“真セスできることが必要

理体制で対応可能）

定されるものの、運用上は拡成する費用が発生するもの

張可能性が高いの、本運用による安全性の向の”異常と「判断」する技術者が必要①一般性・汎用性

 現場技術者の判断を伴う

 また、複数人の意見が異なったと②拡張可能性③経済性

 観測点の追加や他社の車両の 本作業の人的負担（費用）は

 他社車両については「判断」

きの判断についてマニュアルの作成が必要となるのポイントをあらかじめ共有 画像だけでなく、音の遠隔観測の純増となる

上は極めて大きな経済的効果を有すると考えるする必要があるものの、運用情報があるとさらなる判断の高精上の問題はない度化に資するため、センサフュー
ジョンを推進する
異常検出のアラートの

車両部

駅

目視確認
（１）

 画像から異常を「判断」すること

 監視用システムおよび画像付き

 現場技術者の判断を伴う（運 他社車両については対象車両が難しい場合、駅係員等により目メールに車両の両端部の画像を行の条件により異なるものを把握する方法が異なる可能

視にて確認が必要となる

掲載することで、運行番号からの、鉄道会社の運行管理体制

対象車両を把握することができで対応可能）

 その際、迅速に対象車両の情報を実運用伝えることが必要

に関す

る

増となる

があるため、調整が必要である

 他社車両は「判断」のポイントを事前に共有する必要がある （「運行取りやめ＋最寄りの検車る作業

 本作業の人的負担（費用）は純

ものの、運用上の問題はない場に入庫」にも共通）
運行取りやめ＋

車両部→

事務所（本

 “真の”異常（疑いを含む）と判 異常の度合い別の対応パターンを

 オペレーション自体は特別 他事業者への展開（拡張）を

 現場に即したマニュアルを作

最寄りの検車場に入庫

運転指令

社、各検車

断されれば、運行取り止め＋最寄

マニュアル化することで、円滑なな技術を必要としないた

考えたとき、対応パターンの成する費用が発生するもの

室区等）

りの検車場に入庫の対応が必要運用に資する（対応のマニュアル

め、事業者を問わず運用可

ルールが事業者によって異なの、本運用による安全性の向化は必須と考える）

能

るため、システムの拡張性の上は極めて大きな経済的効果

観点からの評価はできないを有すると考える

 その場合、乗客を降ろしたうえで異常の度合いによって駅で停車／
運行に支障のない場所に移動する／検車区に移動するなどの対応が必要となる
事後の振り返り車両部・

 アラートを受けた不具合への対応

 記録された振り返り画像により確

 システムは一般的に活用可 他事業者への展開（拡張）を（事実確認）

運転指令を事後検証し、オペレーションや認する（※振り返り画像の確認シ能（事後検証には現場技術

考えたとき、対応パターンの判断基準の継続的なブラッシュア

ステムを構築済み）

者による評価が必要）。一

ルールが事業者によって異な般的に事業者ごとのオペレるため、システムの拡張性のーション改善に資する観点からの評価はできない室－ップを図る必要がある

の 続 （
メ 性 ２
ン 等 ）
テ に 運
ナ 関 用
ン す ス
ス る キ
作 シ ー
業 ス ム
テ の
ム 持

機器の管理

サービス

駅（設置箇

（点検・清掃）提供者所）

ローカル 5G エリアの

サービス

駅（設置箇

保守

提供者

所）

クラウド環境の保守

サービス

駅（設置箇

提供者

所）

 サービス提供者の対応事項と想定

 現場とサービス提供者の役割分

 現場作業員が実施する作業

 サービス提供者によるパッケ

担・連携のスキームを明確化し、の枠組みは一般性、汎用性のージ化により他事業者への拡問題が発生した場合に速やかに対ある内容である。

張性がある

応できる仕組み（バックアップ体制含む）を構築する必要がある

260

 本作業の人的負担（費用）は純増となる

 サービス提供者の収益モデルに依存する

また、振動およびカメラレンズの汚れの検出率への影響検証を企画したものの、実証期間
中は振動およびカメラレンズの汚れの影響による検出率の低下はみられなかった。これは実証に使用したカメラが防塵・防水に優れた機種であったことが理由として考えられる。
一方、長期間の実装にあたっては、メンテナンスの視点での検討を実施する必要がある。

261

4.4.2 ローカル５Ｇを用いたソリューションの実装性に関する検証
今年度の実証は、実際の鉄道駅（羽田空港第 1・第 2 ターミナル駅構内）にて実施するもので、京急久里浜工場で実施した令和 2 年度より、実装に近づいているといえる。
具体的には、「実装イメージに近い環境下での試験運用」を念頭に置き、令和 2 年度事業
では車両基地で実施していた異常検出を、鉄道駅で実施することで“運行中の”車両を検査することで日々鉄道駅を通過する車両すべてを常時観測できる仕組みを構築した点である。
また、本事業では、カメラを複数台設置し、検出精度を維持しながら一部の台車の異常を検出することが可能なシステムを構築した。

図 4.4.2-1

令和 2 年度実証と令和 3 年度実証の比較

ローカル 5G を用いたソリューションの実装性については、前述の運用検証結果に基づき、抽出された課題に対する解決策の有無／解決策が実行可否を踏まえて、京浜急行電鉄での PDCA による意思決定を行うことで、実装を目指すものである。

262

【R3実証～実装運用】
鉄道駅の営業車両を用いた効果検証および運用検証、
長期安定的な実装運用

安全性への効果確認

データに基づく判定

人間主体ナレッジ

5Gクラウド長年の経験に基づく
安全運行オペレーション

実装効果を確認
課題を明確化

AI映像
解析【実装運用での価値向上】
社内運用スキームの高度化、データの活用基盤を用いた
既存スキームとのシナジー創出

図 4.4.2-2

データの蓄積・活用

実装に向けた PDCA のイメージ

263

データ蓄積
活用基盤

4.4.2.1 ローカル 5G 活用モデルの構築・検証（1）京浜急行電鉄におけるシステムの実装イメージ
京浜急行電鉄におけるシステム実装イメージを示す。

図 4.4.2-3

京浜急行電鉄におけるシステム実装イメージ項目

実装イメージ想定される具体的な主体

京浜急行電鉄株式会社

対象となるシステム実証で用いたシステムを前提に、機材の長期運用観点および
AI 検出精度の改善を行うために、鉄道事業者とシステム開発
者で協力し継続運用する

詳細の前提条件

羽田空港第 1・第 2 ターミナル駅で実証システムを継続運用
する

標準モデル

実証システムをベースに、京浜急行内での運用方法や処理手順については継続して検討

体制・事業スキームのモデル

継続運用における免許人・ネットワーク・システム構築・運用等の役割分担の在り方については、システム開発者と協力し、今後調整を図る

導入効果

安全性の向上

課題と対応策

■運用課題
・AI 検出精度の見極め、追加機能の検討、システムの設置場
所に関する検証 等■システム課題
・UI の改善、データの蓄積方法（大量・膨大なデータの効率的な保存や管理） 等→現業部門との意見交換により改善を図る

264

（2）実証から見えてきた実装に向けての課題
実証から以下の課題が見えてきたことから（詳細は 4.4.3 で記述）、実装モデルの更新の必要性について、今後検討を行う。
項目

見えてきた課題

システムの運用場
所に関する課題

・乗客のプライバシーへの配慮
・AI の検出精度の確保に関する課題
・異常検出時の対応を踏まえた
課題

システム全体の機能に関する課題

・様々なセンサを用いた異常検出による機能向上
・異常箇所の迅速な把握のための追加情報の取得

265

実装モデルへの影響(更新後の姿)以下について今後検討○営業線内とするか営業線外（車両基地の入出庫線など）とするか○駅とするか駅以外とするか○地下空間とするか地上の空間とするか
以下について今後検討
・センサフュージョンのあり方
・列車識別のための追加情報として取得する情報

4.4.2.2 普及展開方策の検討（1）プラットフォームの構築
システムのプラットフォーム化について
新型コロナの影響により、鉄道事業者の収益状況は悪化しており、その状況においてシス
テムに対する投資を行うためには、投資に見合った効果が求められる。
また、システムの開発や維持管理に向けて、それぞれの事業者が単独で取組むことは 1 社
最適化の面では優れているが、費用負担の面では必ずしも優れているとは言えない面もある。鉄道事業者における共通のニーズを踏まえ、複数の事業者が共用できるようなシステムのプラットフォーム化を図ることも有用と考えられる。

図 4.4.2-6

プラットフォームのイメージ

出所）総務省「Beyond 5G 推進戦略－6G へのロードマップ－」266

鉄道事業者の共通ニーズの把握
上記プラットフォーム化を意識しながら、普及展開方策として、京浜急行電鉄以外の鉄道事業者での実装を念頭に置き、以下の事業者に対してヒアリングを実施するとともに、各社のニーズから共通ニーズの抽出を実施した。
■各事業者へのヒアリングの視点①鉄道 DX に係るニーズ②本実証システムの発展形のイメージ③横展開を可能とする取り組み方策
表 4.4.2-1

鉄道事業者の鉄道 DX に係るニーズ等
鉄道 DX に係るニーズ等
西日本鉄道
・鉄道 DX は喫緊の課題である。
・メンテナンスの省力化に向けて、車両に設置された各種センサにより車両の状態を逐次モニタリングする「状態監視システム」の運用について、実証試験を行っている。
・扉の開閉に係る検査に時間がかかっている。何秒以内で閉まるか映像で自動確認できると良い。
・今年度実証を行っている車両監視 AI システムについては、目視検査
を AI に置き換えることによる検査の迅速化・省力化、作業者の負担軽減、目視では確認できない異常の発見による故障の未然防止などの期待がある。
京阪電鉄
・京急システムの発展形として、一部を列車検査に代替していくという考え方については、精度が高くなれば可能性は考えられる。
・装置関係のカバーの確認は検査時だけでなく故障時にも開いてしまうことがあるため、そのようなチェックができるのは有用である。
・映像の活用という点では、鋼索線の車掌無人化や列車映像の送信、
運転状況記録装置等データの取得（CBM への活用）なども期待できる。
南海電鉄
・鉄道 DX について、推進をする必要性はあるが、5G の活用によって何ができるかについては勉強中である。
・IT 技術を活用した課題解決しては、ドローンによる目視困難箇所の点検や AI と高感度カメラによる踏切部の状況把握の迅速化などの取り組みを行っている。
・営業列車及び機器による車両・設備点検実現（CBM の実現）に向けた要素技術について調査・研究を行っている。
東急電鉄
・労働人口・熟練技術者の減少や収益の悪化等の課題に対して、高効率な鉄道オペレーションや人が行う作業の機械への置き換えなどの実現に向け、省人化の一環として、「線路巡視業務の高度化」、「車両ドア閉扉判断の高度化」について実証を行っている。
・他の事業者も含めた共通ニーズでもあると考えられることから、普及展開の可能性についても検証を行っている予定である。
※鉄道 DX：AI や IoT を活用して、鉄道の業務プロセスの変革（省力化・コスト削減）や旅客サービスの変革（省人化新たな価値の創造など）を目指すもの。
鉄道事業者

267

各鉄道事業者ともに、鉄道 DX への取り組みを進めており、AI や無線技術などの技術活用による効率化・省人化は共通ニーズであることを改めて確認した。
本実証のシステムである車両の検査の効率化についても、複数社がニーズを有しており
プラットフォーム化による横展開の可能性は十分に考えられる。そのためにも、4.4.2.1 で示した、本実証で明らかになった課題等について、関係する鉄道事業者の意見を反映させな
がら解決を図っていく取り組みが必要である。
課題解決システムとしては、上記のような共通課題を背景として、検査対象部品や検査対
象項目といったシステムの機能の汎用化だけではなく、判断・意思決定スキームそのものを共通化する“運用方法の汎用化”が横展開には極めて重要であると考える。そのためには、各社の検査スキーム全体にわたる効率化を念頭に、複数事業者での段取りや評価方法などの共通部分の洗い出しといった一歩踏み込んだ連携が必要であろう。
（2）横展開を可能とするサービス検討・提供スキーム（案） 鉄道事業者ごとのシステム開発ではなく、基本システムと個別カスタマイズを可能とするサービス提供の体制を構築することが必要
 サービス提供者は、5G インフラの構築及び 5G インフラを活用したサービスを一括して提供する。
 鉄道事業者は、サービス提供に対して、サービスの利用に対する対価を支払う。
 鉄道事業者の共通ニーズを踏まえた基礎的なシステム構築までは、各鉄道事業者の積極的な投資が難しいと考えられる。よって、横展開の実現に至る間には、支援制度（5G を活用した鉄道事業の安全性の向上や効率化に資する技術開発に対する助成等）を活用しながら、複数の事業者による共同開発を行う体制を構築するなどの検討体制を構築することが他鉄道事業者における横展開にあたって効果的と考えられる。

図 4.4.2-5

横展開を可能とするサービス検討・提供スキーム（案）268

4.4.3 ローカル 5G の実装に向けた課題の抽出及び解決策の検討
4.4.3.1 実装に向けた課題について
1）システムの運用場所に関する課題
今年度は、実運用を想定して京急羽田空港第 1・第 2 ターミナル駅で実証を行い、18 日間の連続運用にて、経時的な変化も確認することができた。
その中で、現実的な課題として、以下に示す課題も見えてきた。
a）乗客のプライバシーへの配慮
昨年度の実証の結果を踏まえ、AI の検出精度向上のために、照度を確保するためのライ
トをプラットホーム下に設置した。ライトの設置により、AI の検出精度の向上効果は確認できたが、ライトがかなり明るいこと、また駅に設置されたホームドアは透明な部分があり、乗客に向く側にライトを設置すると、ホーム上の乗客にとってかなり眩しいだけでなく、プラットホームの高さより低い位置からライトを照らすことによるプライバシーへの配慮の問題も生じることが明らかになった。このため、実証では乗客に向かない側のライト（プラットホームの下に設置）のみ設置し、乗客に向く側のライトは設置できなかった。結果的に台車の片側側面のみを確認することとした。

図 4.4.2-4

ホームドアの透明部分より確認できるライトの明かり269

図 4.4.2-5 ホーム下に設置されたライト（乗客に向かない側（プラットホーム下）のみに設置）b）設備設置に関する安全性の確保
今年度の実証では、カメラやライト、機器カバーなどの諸設備を駅のプラットホーム下に設置した。これらの設備は、列車への接触を回避するために「乗降場に対する建築限界」の外に設置することが基本となるが、プラットホームの下は狭隘な空間であり、設置空間には制約が生じるため、その空間の制約も踏まえつつシステム上望ましい位置に設置する必要がある。また、営業線での運用となることから、運用中に機器の落下等が生じないよう、列車運行の安全性確保に十分に配慮した確実な設置が必要である。
c）AI の検出精度の確保に関する課題
今年度の実証では、台車とカメラとの距離が短くなったことや照度を確保できたことで、昨年度に比べると AI の検出精度は高まり、今年度のシステムは、実装への第一歩となった。
一方で、現時点のカメラの性能等を考慮すると、列車速度は 20km/h 以下が望ましい状況
であり、この速度以下で長編成の車両のすべての台車を確認するためには複数台のカメラの設置が必須となる（列車の駅への進入速度は 40km/h 程度であり、駅の最も起点方に１台カメラを設置するだけでは、すべての台車を 20km/h で撮影することができない。20km/h
以下の速度ですべての台車を撮影するためには、複数のカメラが必要となる）。必要なカメ
ラの台数の増加は、システムのコスト増やメンテナンス費用の増につながる。
この課題を解決する方法としては、○高速の通過に対する撮影に耐えるハイスピードカメラの採用など、システムを構成する機材の高性能化で対応する方法
270

○低速で撮影可能な場所（車両基地の入出庫線など）に設置する方法などが考えられる。システムの高性能化はコストに影響するため、現時点での技術レベルを前提に、低コストで実現可能な現実的な方法を模索する必要がある。
また、本実証では大きな課題とはならなかったが、長期的な運用を考えた場合、ホコリ等の付着が検出精度に影響を与えることも想定されるため、定期的なメンテナンスは必須である。AI の検出精度を維持するための周辺環境及びメンテナンスの容易さを考えた場合、地下空間への設置や駅への設置が最適であるかについても検証が必要と考えられる。
d）異常検出時の対応を踏まえた課題
システムが異常を検出した（アラートが出た）場合、①係員による当該画像の確認
該当車両の運行中止の判断→③乗客の降車等の対応→②などの対応が必要となるが、駅での折返しの時間の中で、システム及び係員による一連の確認・判断を迅速に実施できるかどうかは、今後の課題の一つと考えられる。上記①→②の間には乗務している係員や検車係員等による目視確認などの作業が必要になる場合も考えられ、様々なパターンに対応しなければならない。システムの大きな目的である「安全の上乗せ」を確実に実行するためには、現時点での AI による検出の限界も踏まえれば、「当初はある程度の誤検出を許容しながら、データの蓄積により精度を高めていく」運用が現実的と考えられる。
このような考え方の運用を営業線内のオペレーションとして組み込んでいくことについては、具体的な実施体制も含めてさらに深化が必要と考えられる。
なお、アラートの有無の把握にあたって、係員が常にシステムのモニターを監視している
状態は要員増となることから、現実的ではない。アラートが出た場合、関係する検車区員全員のスマートフォンに配信し、その場で異常を検知した画像を確認できるなど、要員増とならず、かつ迅速な対応が可能となるように、使いやすいシステムへの機能向上を図るとともに、それに応じた体制の検討を行うことが必要である。
今年度の実証では、異常を検知した後の様々なパターンに対する具体的な対応については再現できていない。今年度の実証において見えてきた上記の課題を考慮すると、実装さらには横展開に向けて、システムの運用場所として、○営業線内とするか営業線外（車両基地の入出庫線など）とするか○駅とするか駅以外とするか○地下空間とするか地上の空間とするかなどについて、より現実的なシミュレーションによる検討も必要と考えられる。
2）システム全体の機能に関する課題
a）様々なセンサを用いた異常検出による機能向上
今年度の実証では、「安全の上乗せ」として、台車き裂の発見に着目して検出精度の向上を図っているが、昨年度の実証ではその他に「温度」に着目したサーマルカメラによる車軸温度上昇の検出も行っている。
目視だけでは判別できない情報を、センサにより取得可能であれば、部分的には「目視以上」の検出が可能となり、異常の早期発見に効果的である。昨年度の実証では、車軸の温度271

差については精度良く検出が可能な結果であった。
また、車両の異常は、走行時には運転士の五感により検出している部分もあり、温度だけ
でなく、例えば「音」に着目して異常を検出するなどの方法も考えられる。
なお、本実証では地上側へのカメラ設置による検知を行ったが、車両側に振動検知等のセンサを設置し、データを蓄積して適切なタイミングで地上側と交信することで、車両の状態をモニタリングするなど、車両側への端末の設置も考えられる。
将来的な車両メンテナンス業務の効率化を見据えた場合には、このようなセンサフュー
ジョンによって、人間の五感による検出を機械に置き換えることの可能性についてさらに検討を深める必要がある。

b）異常箇所の迅速な把握のための追加情報の取得
今年度の実証では、プラットホームの下にカメラを設置し、カメラと台車との距離が昨年
度の実証よりも近くなった。これにより、検出精度の向上が図られる効果が確認できた。一
方、昨年度の実証では、台車とともに車両番号も撮影し、車両と台車の紐付けができていたが、今年度の実証では、カメラと台車との距離の関係で車両番号の撮影が困難であった。どの台車で異常が発生しているかを迅速に把握するためには、車両もしくは編成の情報を同時に取得する必要がある。異常箇所の正しい情報を素早く係員等に伝えることができれば、迅速に対応が可能となる。
この方法としては、別途側面の車両番号を撮影する方法や、車両の正面からの情報を前後で取得する方法などが考え、具体的な情報の取得方法について検討が必要である。

3）費用面に関する課題
本システムを採用すれば、日々の状態確認が可能となり、安全性の向上につながることがわかった。一方、現状の車両点検・補修業務は廃止・軽減されないため、新たなシステムの導入・運用費用（人件費等）は純増となる。
この解決策として、作業内容のマニュアルを作成し日常業務の一環とすることや、可能な限りシステム面で作業を補助し、対応者の負担を軽減することが考えられる。
また、本システムの汎用性を高めることで需要が増加すれば、システムの価格が下がることが期待される。そこで、他の鉄道事業者への連携と横展開を検討する。

272

4.4.3.2 実装に向けた課題の抽出（1）運用課題
今回実証においては、台車のき裂が AI で検出可能であることを確認できたものの、色合いの違いや列車速度による横ぶれなどによる再現率の低下や照度の確保・カメラ性能が課
題として残っている。
上記を踏まえ、運用面の課題として以下を設定した。
・安全の上乗せとしての AI の検出精度の見極め→実運用と現時点での AI の検出精度を踏まえた、実用時の AI の精度の見極め。（閾
値を厳しくしすぎると検出漏れが増え、緩くすると誤検出が増える）
・検出内容、列車検査体系の見直し→現在の列車検査では、目視の検査以外に動作確認なども含まれていることから、列車検査の一部代替を行う場合には目視検査項目以外の項目をいつどのように実施するかなどの対応が必要となる。
（AI による検出については、本実証による検出精度等の確認）※本実証では、現時点での AI の性能等を踏まえ「安全の上乗せ」のシステムという位置づけで検討を行ったが、将来的には「安全の上乗せ」の役割だけでなく、「撮影された車両の画像を係員が確認することによる検査の可能性（現場での係員の労働環境の改善など）」や、「画像＋AI による、現在係員が実施している検査の一部の代替の可能性」などを視野に入れ、省力化・コスト削減といった鉄道 DX の実現につながるシステムへの機能向上や、業務体制等の見直し検討が必要である。
・メンテナンス（対策）業務との関係の整理→部品交換等の対策の流れなど

・追加機能の検討→目視では発見が難しいものの、画像では確認可能な機能（温度など）などの追加による機能向上（センサフュージョン）
・システムの設置場所に関する検証→現実的なシミュレーションによるシステムの設置場所に関する検討○営業線内とするか営業線外（車両基地の入出庫線など）とするか○駅とするか駅以外とするか○地下空間とするか地上の空間とするか

273

（2）システム課題
今回実証においては、限定された期間・条件・試行回数の下で実施されたものであり、実装段階では実証とは異なる運用体制を構築したうえで多様なシーンに対応していくことが必要と考えられる。
加えて、状態監視を想定した場合、記録動画が非常に多くなり、これらを効率的・効果的に参照できることが必要となる。
上記を踏まえ、システム課題として以下を設定した。
・機器の設置場所、機器のメンテナンス・検出精度の維持方法（定期的なカメラの清掃など）などの検討・ソフトウェアの開発（UI の検討、事業者にニーズに合わせたカスタマイズなど）
・データの蓄積方法（大量・膨大なデータの効率的な保存や管理）
・導入規模

274

4.4.4 継続利用の見通し・実装計画
今年度は、実運用を想定して羽田空港第 1・第 2 ターミナル駅で実証を行い、現実的な課題が見えた。実装を見据えたシステムを構築するため、実運用環境での AI 検出性能の向を目指したが、
車両速度最大 30km/h 以上で幅 0.1mm 相当の疑似き裂検出率 5.6%、幅 0.1mm～6.0mm 相当の全疑似き裂で平均 47%の検出率、追加学習で車両速度最大 30km/h 以上で
幅 0.1mm 相当の疑似き裂検出率 5.6%が 55.6%、全体の検出率 47%が 74%となり令和 2 年度の実証実験よりも向上したが、実運用させるためには更なる検出率の向上が必要だと判明した。
さらにお客様のプライバシーへの配慮、システムを最適に稼働させるための設置場所の改良等が実装には欠かせないものと判明した。
なお、本システムの導入にあたっては、コスト低減に向けた各鉄道事業者との連携・横展開の検討も不可欠であると認識した。
今年度の実証において判明した課題について、令和 4 年度は、今回構築した実証システ
ムのモニタリングを 1 年間目途に継続し、教師データの収集および台車のキズ検知 AI の追加学習を行う。その後、前述および 4.4.3 に記載した課題および解決策の検証を以下のステップを経て実施し、実運用できるシステムを構築し実装を目指す。

ステップ 1

課題および検証項目

解決策および検証内容

高精細カメラ撮影によ

今年度の実証実験を 1 年間目途に継続して行い，追る車両台車部分の AI

加学習により全疑似き裂で平均 90%以上の検出が可解析による異常検出率能となるよう，AI 検出性能の向上を目指す。

向上のため、本年度構

具体的には、異常として検出されたデータの確認を築した実証システムの行い、通常点検業務の担当者による画像データの確認

モニタリング継続

および必要に応じて実際の車両を目視確認すること
で、検出されたデータが真に異常であるかを人の目で判別する。これにより誤検出されたデータ、および真に異常として検出されたデータを蓄積し、追加学習を行う。
なお、異常検出率の向上には、高速の通過に対する撮影に耐えられるハイスピードカメラの採用など、システムを構成する機材の高性能化も検討できるため、導入コストの検証もあわせて検討する。
また、長期的な運用を考えた場合、ホコリ等の付着が検出精度に影響を与えることも想定されるため、定期的なメンテナンス費用も検証する。

ステップ 2本システムの導入にあ本システムは、安全性の向上につながるものであ

たって、コスト軽減にり、各鉄道事業者において有効な検査システムになる向けた各鉄道事業者とと考えられるが、コストを軽減しシステムを実装に導の連携を検討くために、各鉄道事業者との会合を開催して情報を発信する。その中で検査システムに関する共通ニーズを洗い出し、利用可能なシステムを見据えた継続検討を行い，汎用性を高め、横展開を目指す。

ステップ 3

お客様のプライバシー

高精細カメラによる車両台車の撮影は、ホームより275

保護や列車の進入速度

下側で現状ではお客様の視界に入る位置になり、お客に対応するための最適様のプライバシーに影響を与えてしまう。また、カメな設置環境の構築を検ラ等の設置にあたっては、既存の鉄道設備に配慮して討いるため、最適な場所に設置できておらず、今後は数回にわたり移設しなければならないことが想定されるため、カメラ・ライトおよび各センサ等が最適に設置できる場所を構築するよう検討する。

ステップ 4ローカル 5G 基地局お今年度の実証では、お客様のプライバシーに影響をよび高精細カメラ等の与えないように、羽田空港第 1・第 2 ターミナル駅の追加設置駅の検討

ホーム下片側（山側）のみの設置となったため、反対側（海側）の確認を行うカメラ・ライトおよび各セン
サ等が設置できる駅を検討する。
また、当該駅においてローカル 5G 基地局の設置も検討する。

ステップ 5

各課題に対しての解決策をもとに検証を行い実運用できる実装システムの構築を検討

ステップ 4 までの実施内容を基に，実装できる異常
検知システムの構築をめざした検証を実施する。
羽田空港第 1・第 2 ターミナル駅での実証と並行しステップ 4 で選定した駅へカメラ・ライト等の各機材を設置し異常検知システムの検証内容を検討する。
システムからのアラート等を確認するソフトウェ
アについてもユーザーインターフェース改善等を含めて検証内容を検討する。

上記内容については、今年度の実証で残された課題や新たに発生した課題であり、その解決策の内容検討は、上記のとおり段階的に検討を行っていくため、現時点で検証および実証時期の計画は未定である。
また、コストについても現時点では実証内容が明確ではないため、投資内容の試算はできていないが、今後実証内容等の検討を進めながらコストについても検証していく。
今年度の実証では、車両台車の異常検知を高精細カメラ映像による目視の補完に注力したが、最終段階では、走行中の異音や高熱による異常検知も重要であり、異音を検知する集音マイク、高熱を検知するサーマルカメラ等を組合せた「異常検知システム」として実装を目指す。
なお、ローカル 5G を幅広く活用するため今回の異常検知システム（車両監視）にとどまらず、車内や駅ホーム、踏切道等の安全監視、車内や駅への運行情報の配信によるお客様の利便性向上、車内や駅広告による広告収入等にもつなげ、効率的な利用を目指す。

276

5. 普及啓発活動の実施
仕様書に記載されている普及啓発活動について、以下のとおり実施した。
5.1 映像制作への協力
実証コンソーシアムの取組成果に係る動画を作成にあたって、映像制作に必要な実証事
業の映像素材の提供や関係者へのインタビューの撮影等に協力した。
撮影内容については表のとおりである。
表 5.1-1
撮影内容

撮影内容

1

駅・ホーム・列車の走る風景

2

ホームのカメラ3

カメラが車両を撮影する様子

4

AI により車両検査が行われている様子

5

AI による車両検査を監視する様子

6

担当者による実証についてのコメント

277

5.2 実証視察会の実施
ローカル 5G 等の導入に関心のある企業や、地方公共団体、関係省庁等に対する周知啓発の一環として、オンラインでの実証視察会を主催した。

日時
実施形態
場所

表 5.2-1 開催概要（1/2）
2022/02/24（木） 9:30~10:30
オンライン
Teams
（コンソーシアムメンバーは京浜急行電鉄金沢検車区にて配信）参加者

総務省
関東総合通信局
九州総合通信局
四国総合通信局
信越総合通信局
中国総合通信局
東北総合通信局(株)国際電気通信基礎技術研究所(株)スリーダブリュー
住友商事(株)(株)日立システムズ
アイコム(株)(株)ベイ・コミュニケーションズ
富士通(株)
KDDI エンジニアリング
シャープ(株)東芝インフラシステムズ(株)日鉄ソリューションズ(株)(株)日立国際電気
電制コムテック(株)日本電気通信システム(株)富士通ネットワークソリューションズ(株)パナソニックシステムソリューションズジャパン(株)日本電気(株)日本無線(株)
JRC
モビリティ(株)三菱総研
フロンティアインターナショナル
評価委員
専門会合委員

278

資料

プログラ
ム

表 5.2-1 開催概要（2/2）
・No13：ローカル 5G と AI 技術を用いた鉄道駅における車両監視の高度化 視察会資料
・説明用動画1．資料説明2．映像上映3．質疑応答279

5.3 その他普及啓発活動
実証成果その他の普及啓発活動として、プレスリリース、インタビュー対応、技術展への出展（イベントへの参加）、学会への報告等のアウトリーチその取り組み内容及び実施結果を以下に示す。

報告月

表 5.3-1
取り組み内容1

11 月度

日本工業出版「検査技術」

2

1 月度

日本鉄道電気技術協会「鉄道と電気技術」 2022 年 3 月刊行

その他普及啓発活動
備考280

2022 年 2 月刊行

6. 実施体制
体制及び役割
本事業は、京浜急行電鉄株式会社、中央復建コンサルタンツ株式会社、株式会社 NTT ドコモの 3 者により実証コンソーシアムを構成して実施した。本事業のとりまとめ等を行う
代表機関は、京浜急行電鉄株式会社であり、フィールドの提供、実証全体の管理、実証結果の評価、協議会の主催、報告書作成等を担った。
協力企業を含めた本事業の組織構成を図 6.1-1 に示す。課題実証の要素技術ごとに高度な知見を有する専門業者を擁し、円滑な事業遂行を目指した。

図 6.1.-1

実施体制図

6.1.1 京浜急行電鉄株式会社
※本店住所
※代表者名

〒220-8625 神奈川県横浜市西区高島 1 丁目 2 番 8 号
取締役社長 原田 一之「日常の列車検査の高頻度及び検査精度の向上による鉄道運行の更なる安全性向上」、「自然災害後等の運行再開時の巡視作業の高効率化及び巡視作業員の安全性向上」の課題を有する鉄道事業者で、本調査検討事業における鉄道分野の実証フィールドを提供。

6.1.2 中央復建コンサルタンツ株式会社
本社住所：〒533-0033 大阪市東淀川区東中島 4 丁目 11 番 10 号
代表者名：代表取締役社長 兼塚 卓也
国内外の道路・橋梁・鉄道などの社会インフラの計画や設計、三次元化技術、社会インフ
ラマネジメント、まちづくりコーディネートなどの総合的な分野で豊富な知見と実績を有する総合建設コンサルタント。

281

6.1.3 株式会社 NTT ドコモ※本店住所：〒100-6150 東京都千代田区永田町 2 丁目 11 番 1 号山王パークタワー
代表者名：代表取締役社長

井伊 基之

キャリア 5G サービスを提供中であるとともに、ローカル 5G 等の通信と映像の AI 解析を統合した課題解決システムを使った実証、ローカル 5G の性能評価等の実証を実施可
能な通信事業者。

6.1.4 再委託先及び再々委託先
6.1.4.1 再委託先
（1）中央復建コンサルタンツ株式会社※本社住所：〒533-0033 大阪市東淀川区東中島 4 丁目 11 番 10 号
※代表者名：代表取締役社長 兼塚 卓也※再委託の業務範囲：
鉄道分野における課題解決システムの運用支援、実証実験の実施支援、運用スキームの検討支援、実装・横展開に関する協議会の運営、報告書作成
支援（2）株式会社 NTT ドコモ※本店住所：〒100-6150 東京都千代田区永田町 2 丁目 11 番 1 号 山王パークタワー※代表者名：代表取締役社長 井伊 基之※再委託の業務範囲：
鉄道インフラ分野における課題解決システムの構築及び課題解決システ
ム実証実施、技術実証におけるローカル 5G システム（基地局及び移動局）
環境構築支援、技術実証の実施
6.1.4.2 再々委託先（1）ドコモ・テクノロジ株式会社
東京都港区赤坂一丁目 8 番 1 号 赤坂インターシティ AIR
26 階※代表者名：代表取締役社長 中村 寛
※再々委託範囲：
電波伝搬試験、干渉検討、試験結果取りまとめ※本店住所：〒107-0052（2）エクシオグループ株式会社※本店住所：〒150-0002 東京都渋谷区渋谷 3 丁目 29 番 20 号
※代表者名：代表取締役社長 舩橋 哲也※再々委託範囲：
282

IaaS・映像配信、UI 構築・検証支援（3）エリクソン・ジャパン株式会社※本店住所：〒105-0021 東京都港区東新橋 2-3-17 MOMENTO SHIODOME※代表者名：代表取締役社長

野崎哲※再々委託範囲：
ローカル 5G 基地局設定等

283

図 7-1

284

課題実証

技術実証

実証環境の構築

大区分

事前検討

実証スケジュール

実装シナリオの見直し

実証シナリオ再検討▲報告書1次 ▲報告書2次

ドキュメン
ト作成

▲報告書1次 ▲報告書2次▲報告書1次 ▲報告書2次

実 装 ス キ ー ム 再 検 討 （ リ バ イ ズ ） ▲報告書1次 ▲報告書2次▲実証開始 ドキュメント作成▲報告書1次 ▲報告書2次

報告資料作成14日 21日 28日

▲実
証終

電波測定

報告資料作成報告資料作成3月
14日 21日 28日 7日

机上計算・ドキュメント作成

本番運用

本番運用

▲電波発射

ク ラ ウ ド 内 NW連 携 作 業

施工▲クラウド内詳細設計▲実証環境構築▲クラウド環境払い出し▲免許交付

実装スキーム整理 現用スキームとの擦り合わせ検討

▲再
委託
契約
クラ
ウド
構
築・

京浜急行電鉄の主管部署へのヒアリング

▲免
許申
請

2月
10日 17日 24日 31日 7日

実装に向けた課題抽出及び解決策の検討

事業者干渉
調整

1月
12月
15日 22日 29日 6日 13日 20日 27日 3日

実装性検証

設計
確定

10月 11月
25日 1日 8日

証証
検検
前前
事事
のム
性テ
定ス
AIシ
現地設置機材の長期安

備考

有効性検証

テーマ別実証

電波伝搬特性等の測定

システム構築クラウド環境・ネット
ワーク構築

ローカル５Ｇ基地局構築

小区分

7. スケジュール
実証のスケジュールは以下のとおりである。