2013年11月3日に航空自衛隊入間基地(埼玉県)で、毎年恒例の航空祭があった。筆者は人混みに恐れをなして行かなかったのだが、なんでも過去最大の32万人が集まったそうである。そのため、輸送の主役となった西武池袋線ではダイヤの乱れが発生したというからタダゴトではない。

乗客の多寡は意外と影響する

そこで、ちょっと算数をやってみよう。

電車1両に、ちょっと詰め込んで200名を乗せると仮定する。そして10両編成だから1編成で2,000名。32万人を輸送するには、延べ160編成の電車が必要になる計算だ。

その総数はともかく、1編成に2,000名が乗ると、どれぐらいの重さになるか。一人60kgと概算すると、120トンである! (もっと重い人もいれば軽い人もいるだろうし、航空祭だから重たいカメラ機材を持ち込んでいる人が多いのではないか…… なんていう突っ込みは、とりあえず無視する)

形式によって差があるので一概にはいえないが、一般的な通勤型電車の自重は25~40トンぐらいだ。そこに、1両につき200名が乗れば12トン増えることになる。つまり30~50%ぐらいの重量増加になる。

これが加減速性能に影響しないはずがない。空車のときと比較すれば、満員で重くなったときの方が加速が悪くなるし、ブレーキの効きも悪くなるだろう。当然、運転士はそのことを頭に入れて運転するわけだが、車両の側で支援できることもいろいろある。

ブレーキには応荷重装置

そのひとつが、通勤型車両では定番となっている応荷重装置だ。機能は読んで字のごとくで、荷重(つまり混雑率)の状況に応じてブレーキ性能をコントロールするものである。目的は、荷重に関係なく同じ減速度を発揮させることにあり、そのため、荷重が大きいときにはブレーキをきつめにかける。

荷重の多寡は、空気バネの内圧を使って把握する方法が一般的だ。ブレーキ力の制御は、そのデータに基づいて発する電気信号を利用するので、電気指令式ブレーキの方が対応しやすい。機械的に同じ仕組みを作り込もうとすると、かなり面倒だろう。もっとも、当節の通勤型電車はたいてい、電気指令式ブレーキを使っているから、その点での問題はない。

というわけで、混雑しているときでも空車のときでも同じ減速度を得られるようにする仕組みは、ずいぶん前から一般的になっている。これで、少なくともブレーキをかける場面では、混雑度がダイヤに影響する事態を抑制できる。

加速力はコントロールしなくていいの?

では、加速の方はどうか? 重くなれば加速力に響くのは当然のことなのだが、問題は、荷重に応じて加速力を加減する操作をどう実現するか、である。

電気指令式の登場が比較的早かったブレーキの分野と異なり、加速力を制御する制御装置の方は、機械的な機構を用いるケースが多かった。それでは、混雑率に応じて加速力を細かくコントロールするのは難しい。

おまけに、乗車率はハコによって異なり、一定ではない。ひとつの編成に複数の電動車があり、それぞれで乗車率が異なる状況は普通だろう。それなのに、一律に加速力アップの指示を出せば、走りがギクシャクしそうである。

個別制御か、統括制御か

といったところで、第17回で取り上げたVVVF(Variable Voltage Variable Frequency)インバータの制御や、第49回で取り上げた協調運転に似た話が出てくる。つまり、電動車が備えるVVVFインバータに対して、混雑率に応じて適切な加速を指示するだけでなく、編成全体で足並みを揃えるようにする、という課題が出てくる。それを実現する際の考え方は、2種類ある。

  1. VVVFインバータには混雑率のデータを渡して、それを受けたVVVFインバータの側で個別に、最適な加速力を算出・実行する
  2. 編成を構成する個々の車両について混雑率を調べた上で、所定の加速度を発揮するために必要な制御を割り出す。それを、個々の電動車のVVVFインバータに対して指令する

VVVFインバータが1基だけならどちらの方法でも同じことだが、実際には複数あるし、電動車1両につき複数のVVVFインバータを持つこともある。となると、それぞれのVVVFインバータが個別に演算処理を行って加速力を算出する「1.」の方法よりも、トータルで制御データを割り出して指令する「2.」の方式の方が、スムーズに運転できるのではないかと考えられる。また、データやソフトウェアの修正が必要になったときにも、一ヶ所だけ手直しすればよいから話が楽だ。

その代わり、編成全体で統括制御するためには、本連載の第1回で取り上げている制御伝送化がワンセットにならざるを得ないだろう。制御伝送化を行わない場合、編成全体を見ながら加速のための制御データを算定して個々のVVVFインバータに指令を出す、なんていう器用な真似は実現しづらい。

つまりこれは、「どういう方法で問題を解決するか」というだけの話ではなく、問題解決に際して必要になるシステムのアーキテクチャをどうするか、という話でもある。そのアーキテクチャ次第で、円滑な加速を実現できるかどうか、システムのアップデートや保守を容易かつ迅速に行えるか、といったところが違ってくるわけだ。

執筆者紹介

井上孝司

IT分野から鉄道・航空といった各種交通機関や軍事分野に進出して著述活動を展開中のテクニカルライター。マイクロソフト株式会社を経て1999年春に独立。「戦うコンピュータ2011」(潮書房光人社)のように情報通信技術を切口にする展開に加えて、さまざまな分野の記事を手掛ける。マイナビニュースに加えて「軍事研究」「丸」「Jwings」「エアワールド」「新幹線EX」などに寄稿しているほか、最新刊「現代ミリタリー・ロジスティクス入門」(潮書房光人社)がある。