列車統合管理システム向けGUIソフトウェア基盤 Quintetの開発

一般論文

列車統合管理システム向けGUIソフトウェア基盤 Quintetの開発
伊丹事業所
三菱電機㈱

先端技術総合研究所

ソリューション技術部

更した場合、データの抽出のため中央装置とDUの両方のソフトウェア変更が必要となる課題があった。

列車統合管理システム（Train Control and Monitoring
System）（以下、TCMS）は、列車の状態を監視・制御するシ2.2

ステムである。列車の運転台には表示装置（Display Unit）

集中型制御TCMS

集中型制御のTCMSは、通信帯域が広いEthernet（注2）（以下、DU）が搭載され、乗務員はDUから列車の状態を監（100BASE-TX）を採用し、更なる機能向上のために、分散視・制御する。

型制御のTCMSから、図2のようなシステム構成に見直した。

TCMSは列車の中枢部としての重要性を増しており、従コンセプトは次のとおりである。

来では分散型制御を適用していたが、ネットワーク技術の①集中型制御進展もあり、次世代車両制御システムに向け、さらなる機中央装置に制御を集約することで車両単位制御から列能向上、信頼性向上を図るために集中型制御が適用される車全体制御を実現した。これにより、端末装置はデータようになった。

転送のみ行う伝送装置に置き換えることができる。

この集中型制御のTCMSにDUを適応させるため、三菱②IEC61375（注3）:Train Communication Networkへの準拠

電機㈱先端技術総合研究所と共同でTCMS向けGUI国際標準規格に準拠し、列車内の他システムとの相互（Graphical User Interface）ソフトウェア基盤である接続性の担保を行う。

Quintet（Qt based ui and web integrated framework）③信頼性の向上を開発した。

TCMSに搭載される基板の高密度化、単機能化が行わ

本稿では、Quintetの概要について紹介する。

れた。車両毎の部品点数を削減することにより故障率を下げ、信頼性の向上が期待できる。

２．開発の背景とコンセプト

表示装置

分散型制御TCMS
表示装置
表示

表示

アークネット

中央装置

表示
装置

*1

中央 管理 端末
装置 集約 装置

集約端末装置*1

*1機器
：

機器

端末
集約 装置

端末装置
*1

*1機器

：

機器

機器

：：

機器

機器

機器

伝送装置

伝送
*1 装置

*1

*1機器

中央装置

機器

機器

：

：

：

機器

機器

機器

注 *1 伝送装置は、中央装置の制御情報を機器に転送し、機器からの監視情報を中央装置に転送する。

機器
：

表示装置
*1

伝送装置
*1機器

中央装置

Ethernet
*1

伝送装置
*1

集約

車両情報システム第3課
平野 耕一
プラント計装システム技術G
大崎 雅代

この方式では、データ追加など伝送するデータ構造を変

１．まえがき

2.1

技術第1部

図２．集中型制御方式のシステム構成図

注 *1 端末装置は、機器に制御情報を送信し、機器から監視情報を受信する。

図１．分散型制御方式のシステム構成図

2.3

TCMSにおけるDUの課題

このコンセプトで開発を進めるうえで、集中型制御

分散型制御TCMSは、図1のように車両毎に制御を行うシ

TCMSに搭載するDUには下記の課題解決が必要であった。

ステムであった。先頭車両の中央装置と車両毎に各機器を制御する端末装置から構成される。
伝送方式はアークネット（注1）（10Mbps）であり、ネットワークの通信帯域は狭い。そのため、図1のように端末装置が車両毎に制御を行い、列車としての状態を監視・制御する（注1）アークネットはネットワークの規格の1つである。
（注2）ネットワークの規格の1つである。
（注3）IEC61375は鉄道の車両制御システム規格である。

ために、必要なデータだけを抽出して列車内ネットワークに流す方式を取っている。
67

列車統合管理システム向けGUIソフトウェア基盤 Quintetの開発

上記（1）～（4）の実現のため、Quintetの全体アーキテク（1）分散型から集中型に変更することによる課題

チャを図3のように設計した。図3の各動作（①～⑩）を表1①データの大容量化・通信速度の高速化への対応に示す。詳細は3.1節以降に示す。

分散型制御TCMSのDUは、データに変更が無い場合でも周期的に通信を行っている。データの大容量化・

中央装置

通信速度の高速化に対応するためには必要な時に必要な量のデータを取得することが必要になる。

①伝送ミドルウェア

機器②画面仕様とデータ仕様の独立性向上
分散型制御TCMSではDUは、中央装置が集約するデータのみを参照しており、機器との伝送データ仕様データサーバが変更されても集約データに変更無ければアプリケー

⑥②⑤
共有メモリ

④
DUアプリケーションションへの影響は無い。
しかし、集中型制御TCMSではDUは、全ての装置データ収集部③と伝送を行うため、伝送データ仕様変更の影響を大きデータ収集定義く受ける。そのため、画面仕様とデータ仕様の独立性

View
Controllerを向上させ、データ仕様変更の影響を小さくすることが必要になる。

⑦⑩キャッシュ（2）分散型制御TCMSから継続する課題⑧①多様化する併結パターンへの対応
分散型制御TCMSでは、システムの動作をシンプル

Model

⑨

図３．Quintetの全体アーキテクチャにするために、分割・併結パターンの組合せを限定して表１．Quintetの動作いた。しかし、車両の効率的な運用を実現するため、編成の分割・併結パターンは多様化する傾向にある。併No

動作結パターンの組合せ数が多い場合でも容易に対応出来①ることが必要になる。

中央装置と機器が発信するデータを伝送ミドルウェアが受信する。

②

伝送ミドルウェアが受信したデータを共有メモリに格納する。

③

データ収集定義から画面が必要としているデータを参照する。

④

データサーバにデータを要求する。（3.2節を参照）⑤

共有メモリから要求されたデータを検索する。

⑥

データ収集部に要求したデータを配信する。

⑦

受信したデータをキャッシュに保存する。

⑧

画面表示に適した形にデータを加工する。

⑨

画面に表示するデータをModelに格納する。

⑩

画面にModelの内容を表示する（3.1節を参照）②複数のプラットフォームへの対応
DUのアプリケーションは、組込機器に搭載する場合や、乗務員の教育のためPC上に搭載する場合があり、案件ごとにWindowsやLinuxなど様々な環境下で動作することが必要になる。
これらの課題を解決し、システムに適したソフトウェア構成に見直すため、集中型制御のTCMS向けGUIソフトウェ

3.1

ア基盤であるQuintetの開発に至った。

画面仕様とデータ仕様の独立性向上

分散型制御TCMSのDUアプリケーションは、画面仕様

３．Quintetの概要とデータ仕様の結合度が高く、データ仕様の変更は画面表分散型制御におけるDUの課題解決のため、Quintetは次と表示処理を分離する設計とし、画面仕様が決まった段階示にも影響を与える。そのため、Quintetは、データ収集部の方針で開発を進めた。

で画面の描画部品（後述のView部品とModel部品）の製作を可能とした。

（1）画面仕様とデータ仕様の独立性が強いアーキテクチャ

GUIの各機能の役割を明確化するデザインパターンの1つを構築するにMVC（Model View Controller）パターンがある。

（2）使用するデータだけを抽出することでデータの大容量

QuintetはMVCパターンを派生させViewとControllerを化に対応する（3）組合せ数の多い併結パターンに対応する統合した、図4に示すModel/Viewアーキテクチャを採用し（4）複数のプラットフォームに対応するた。テーブル構造でデータを保持するModelとそれを元に描画処理を行うViewに機能分割し、図3のように、データ68

列車統合管理システム向けGUIソフトウェア基盤 Quintetの開発

収集部をModelから分離することで、画面仕様とデータ仕を必要な時に参照する図6の仕組みを導入し、データ量増加様の独立性向上を実現した。に対応した。
分散型制御TCMSでは、DUは中央装置から受けた集約データに対して応答を返していた。集中型制御TCMSでは、View

DUは主体的にデータを要求し必要なデータを受ける。

View部品

分散型制御TCMS

集中型制御TCMS

機器

機器

Controller
画面表示

伝送

Model

伝送装置

端末装置
集約 転送

Model部品

データサーバ

中央装置
集約図４．Model/Viewアーキテクチャ

応答

DUアプリ
ケーション

Viewは複数のView部品群、Modelは複数のModel部品群から構成される。View部品は、ボタンや表・図形など画要求

応答

DUアプリ
ケーション

集中型制御TCMSでは分散型制御TCMSに比べてデータは集約されないが、DUアプリケーションは画面表示に必要なデータだけをデータサーバから受け取る。

面上に表示される部品を示す。Controllerは、画面表示への入力処理であり、このアーキテクチャではViewに統合している。Model部品は、行が状態を表し、列が車両を表す、図６．データ量増加への対応図5のような仮想テーブルを持つ。
View部品は、Model部品に設定された内容に基づき、図データサーバへの要求は、データ収集部がデータ収集定5に示すように画面表示を行う。Model部品が更新されるた義の内容に基づいて行う（表1 No③）。データ収集定義には、びにView部品にその結果が反映される。
（表1 No⑩）

パケット名称及びデータ名称を割り付ける。名称を定義す3.2

るため、データの位置やサイズなどデータ構造には依存しデータ大容量化への対応ない。そのため、受信するデータ量が増加してもアプリケーションは使用するデータのみを扱うことができる。

分散型制御TCMSのDUアプリケーションは、データに変更が無い場合でも周期的に通信を行っており、通信帯域を効率的に使用していなかった。Quintetはデータ大容量化

DUアプリケーションは、データ収集定義に記載されたに対応するため、イベント駆動で通信を行う仕組みを導入

データをもとに、収集対象のデータを一意に特定可能なIDした。

（数値）に変換し、そのIDをデータサーバに要求する（表1

イベント駆動型プログラムにおけるデザインパターンの1No④）。データサーバは、共有メモリ上からDUが要求するつに出版/購読型モデルがある。出版/購読型モデルは送信IDのデータを取得し（表1 No⑤）、DUアプリケーションに者（出版側）が受信者（購読側）を想定せずにメッセージを送配信する（表1 No⑥）。データサーバへの要求は周期配信・るモデルである。出版側のシステムと購読側のシステムは、イベント配信・周期+イベント配信のいずれかを選択可能とそれぞれ相手の状態によらず動作可能である。

した。

Quintetはアプリケーションと伝送ミドルウェアの間に出版/購読型モデルのデータサーバを設け、必要なデータのみ

図５．View部品とModel部品の関係

69

列車統合管理システム向けGUIソフトウェア基盤 Quintetの開発

Quintetでは、出版/購読型モデルのデータサーバ導入に集中型制御TCMSにおいてDUは、列車構成情報を中央よりイベント駆動でデータ更新及び画面描画を行えるよう装置と同様に取得可能である。列車構成情報は、TTDPにした。具体的には、Model部品のデータが更新された時（Train Topology Discovery Protocol）による編成認識処にView部品を更新している。これにより、DUアプリケー

理により決定される。TTDPは、隣接する車両が存在するションは、画面表示に必要な情報を変化があった時のみデーか車両のトポロジーを調べることで併結状態を認識するプ

タサーバから取得可能とした。また、頻繁に変化するデーロトコルであり、決定した列車構成情報はTCMSネットワー

タの場合は周期的に配信した方が通信帯域を効率的に使用でク内の各装置に通知される。DUアプリケーションは、このきる場合もある。そのため、分散型制御のDUが行っていた列車構成情報から車両数及び車両の並びを認識する。

機能と同様に周期的にデータを取得することも可能とした。

Quintetでは、View部品とModel部品は仮想テーブルの1列効率的なデータ取得を行うことで、データ取得までの時を1車両として取り扱っているため、編成数の増減は図8の間を短縮し、分散型制御TCMSに比べて画面描画を高速にように仮想テーブルの列を増減させることで対応可能とした。

行えるようになった。

収

３．３多様な併結パターンへの適応
多様な併結パターンへの適応
3.3

集列車は運用中の任意のタイミングで併結・分割を行う。

ため、車両数の動的な変化に適応することは客先の大タ

きなニーズの１つである。システムにより編成認識方法がは異なるため、Quintetは併結パターンの組合せ数が多をい場合にも対応可能とした。とした。

1編成目①全編成のデータを要求

列車は、運用中の任意のタイミングで併結・分割を行うた

DUアプリ
ケーション

め、車両数の動的な変化に適応することは客先の大きなニーズの1つである。システムにより編成認識方法は異なるため、②1編成目のデータを配信

データ
サーバ

⑤2編成目のデータを配信

Quintetは併結パターンの組合せ数が多い場合にも対応可能④2編成目のデータを配信

2編成目

た

データサーバはDUアプ
リケーションからの要求もデータサーバからの要
求も同様に扱う能す③2編成目のデータを要求

データサーバ

要シ

周

図7．分散型制御TCMSにおける編成認識
図７．分散型制御TCMSにおける編成認識

図９．データサーバの多段購読

分散型制御TCMSにおいてDUは、図7のように併結パ

また、Quintetでは、データサーバへの問合せは現在の車ターンをあらかじめ全て定義していた。DUは、列車構成情両数分だけ行う。例えば6両編成の場合、1車両目から6車報を中央装置からしか得られず、中央装置からはデータを両目までのデータを収集対象とする。

ータを集約するために併結パターンの番号だけを得てため、組合せに無いパターンを追加するには中央装置とDUされ、図9のようにサーバ間で購読/配信を中継する多段購えいる。そのため、組合せに無いパターンを追加するにはの双方に改修が必要になる。

読機能によりデータを収集する。

さ

中央装置とDUの双方に改修が必要になる。

か導分散型制御TCMSにおいてDUは図7のように併結パターンをあらかじめ全て定義していた。DUは列車構成情報を中央装置からしか得られず、中央装置からはデ集約するために併結パターンの番号だけを得ている。その併結構成の車両の場合、データサーバは編成ごとに配置プた集中型制御TCMSにおいてDUは列車構成情報を中に央装置と同様に取得可能である。列車構成情報は

帯TTDP(Train Topology Discovery Protocol)による編成認型識処理により決定される。TTDPは隣接する車両が存在タするか車両のトポロジーを調べることで併結状態を認識するプロトコルであり、決定した列車構成情報はTCMSのネットワーク内の各装置に通知される。DUアプリケーシをョンはこの列車構成情報から車両数及び車両の並びを認識する。
QuintetではView部品とModel部品は仮想テーブルの図８．集中型制御TCMSにおける編成認識1列を1車両として取り扱っているため、編成数の増減は図8のように仮想テーブルの列を増減させることで対応可能とした。

70

列車統合管理システム向けGUIソフトウェア基盤 Quintetの開発

DUアプリケーションは、併結構成の場合も単編成と同様とで、列車運用中の車両数変化にも対応可能となった。に、自編成のデータサーバに対してデータの購読要求を行そのため、組合せ数の多い併結パターンの場合でもアプう。データサーバは要求されたデータが他編成にある場合、リケーションは容易に対応可能になった。

他編成のデータサーバからデータを取得してDUアプリケーションに返す。この時、データサーバはアプリケーション（4）マルチプラットフォーム化の実現

からの要求も他編成のデータサーバからの要求も同等に扱

Quintetは、Qtを使用することによりマルチプラットうため、DUアプリケーションはデータがどの編成のデータフォームアプリケーションの開発が可能になり、案件ごサーバにあるかを意識する必要はない。とに要求されるプラットフォームが変更されても対応可能になった。

例えば、図8のように6両編成+8両編成の場合、DUアプ
リケーションは自編成のデータサーバには14両分のデータを要求する。自編成内で集められないデータは他編成に中５．むすび継し、自編成のデータサーバを介して、14両分すべてのデータを収集可能である。

3.4

本稿で紹介したGUIソフトウェア基盤のQuintetを適用することで、集中型制御システム構成に適した開発を進めマルチプラットフォーム化ることができるようになった。
今後も新規案件へのQuintet適用が見込まれており、競争Quintetの開発にはQtを採用した。Qtはそれぞれのプ力強化のため、更なる改善策を進めていく。

ラットフォーム向けにビルドすることにより、同じソース最後に、本開発にあたり技術的な助言をはじめとして、コードで同じ機能を動作させるという特徴がある。

さまざまな面でサポートいただいた関係者の方々に深く感

Quintetは、Qtを使用することによりマルチプラット謝申し上げる。

フォームアプリケーションの開発を可能にした。
このため、組込機器に搭載するLinux上で動作するソフトウェアを、乗務員の教育用のソフトウェアとしてWindows上で動作させることも可能である。

４．開発の成果
Quintetは、2016年から開発を行い、2017年9月時点で海外5案件に適用され、次のような成果があった。
（1）画面表示性能の向上
Quintetは、データサーバの導入により大容量化したデータから必要なデータのみを抽出し、イベント駆動型の処理とした。分散型制御システムに比べてデータを取得するまでの応答時間が1/10に改善され、画面描画が高執筆者紹介速化された。

平野耕一

ヒラノコウイチ2007年入社。主に列車モニタリング車（2）伝送フォーマットへの依存度の低減

上システムのソフトウェア開発に従事。

データ収集部と表示処理を分離し、MVCパターンの採現在、伊丹事業所技術第1部車両情報シ用により表示処理をModel/Viewの構造に見直したため、ステム第3課。

DUアプリケーションは伝送フォーマットへの依存度を低減できた。

大崎

伝送フォーマットが未決定の段階でも表示処理は単独

雅代

オオサキ

マサヨ

19 91年三菱 電 機 入社 。大 規模ソフトで動作確認が可能になった。

ウェアの開 発 効 率化の 研 究 開 発 に従事。現在、先端技術総合研究所ソリュー（3）組合せ数の多い併結パターンに対応

ション技術部プラント計装システム技術

Quintetでは、Model/Viewアーキテクチャとデータグループ。

サーバを導入し、列車構成情報の取得方式を変更したこ
71