MTIジャーナル
MTI Journal.04
エンジニアによるエンジニアのための開発ストーリー
射手 陽平
船舶技術グループ 主任研究員
※職名は掲載当時
安全運航が第一
2012年に初めて陸上のオフィス勤務となり、バルカーの燃節活動を担当しました。それからLNG船2隻の乗船を経て、2016年、MTIに着任し研究員としての生活が始まりました。
機関予防保全の高度化に向けて
MTIでは、安全運航実現のための取り組みの一つとして、「機関予防保全の高度化」へ向けた研究開発に力を入れています。今までのように、機器の“使用時間”に基づいた整備をするのではなく、機器の“状態”に基づいた合理的な保守整備(Condition Based Maintenance: CBM）の実現を目指しています。そのためには、運航ノウハウを持ったユーザー（乗組員）と船の設計ノウハウを持ったメーカーが協力して取り組むことが不可欠です。両者間で、実運転データや情報を共有し、設計にフィードバックすることで、機器の性能を向上させることができるようになります。また、CBM実現により、異常を早期に発見し事故を防ぐと同時に、各機器の状態を把握して、システム連携させる「システムインテグレーション（高度なネットワーク）」を、今まで以上に効率化することが可能となります。これから紹介する製品「きらりNINJA」と「M0チェックシステム」も、これらを実現するためのツールの一つとして開発されました。
エンジン内部を、もっと手軽に・詳細に点検できないか？
従来、エンジン燃焼室内部を点検する方法は2通りあります。シリンダカバーを外し、内部に人が入る開放点検と、掃気孔から内部をのぞきこむ無開放点検です。前者は内部を詳細に点検できますが、高温環境での長時間作業となるため乗組員にとって大きな負担となります。一方、後者は掃気孔から手を入れて写真を撮ったり、顔を近づけたりして内部の状況を把握します。無開放点検は気軽に点検できる反面、シリンダ上部が遠くてよく見えず、さらには掃気孔に手を入れた時に、ピストンにはさまれて大けがをする恐れがあるなど、デメリットもあるのが難点です。
そこで、無開放の手軽さはそのままに、なんとか開放せず安全に燃焼室内部を点検できないかと、同じく機関士である私の前任者が常々考えていたところ、偶然テレビで360°カメラを見かけ、「これだ！」と思ったのが本製品開発のきっかけです。その後、試作機を作り実際に船で撮影してみると様々な問題が浮かび上がりました。たとえば、エンジン内部は、想像以上に高温になるため、冷却材が必要だったり、掃気孔の大きさが船によって異なるため本体の大きさに工夫が必要だったり…。このような問題を解決しつつ試行錯誤を繰り返して完成したのが、「きらりNINJA」です。これを、燃焼室のピストン上部に置くだけで、約10分間（ピストン上下1往復間）で、燃焼室内部全周方向が自動で撮影でき、エンジン内部を全天球画像で見ることができます。
きらりNINJAを使った無開放点検
きらりNINJAを活用すれば、“誰でも、簡単、安全、頻繁に”シリンダ内部の状態把握ができるようになります。撮影した画像は単体で見るだけではなく、過去の画像と比較したり、さらにその間にどのような運転をしたのかという運転データをあわせて確認したりすることで、事故予兆や不具合原因の早期特定が可能になります。これにより、機関事故の未然防止・整備間隔の最適化が図れ、ライフサイクルコストの低減も期待できます。
膨大なM0チェックリストを電子化
もう一つ、開発にエンジニアが関わった案件を紹介したいと思います。 本船では、毎日「M0チェック」をおこないます。M0チェックとは、機関室を夜間に無人運転する前に、また各機器の状態を確認する目的もあり、乗組員が1000～2000項目におよぶチェックリストに沿って、機関室内の機器の温度や圧力を確認・記録するものです。これは紙ベースで実施しており、1週間のチェックで使用する紙の量はA4で約50枚と膨大な量となります。また、紙でのチェックは数字が並んでいるだけなので、数値の変化に気づきにくく、過去の情報を確認したい場合は、膨大な紙の中から必要なものを探さなければなりません。また、トラブル発生時など、陸側へ数値データを送る際には、まず紙からエクセルへ転記しなければなりません。そのため、陸との情報共有にも時間がかかります。MTIでは、これをどうにか簡単にできないかというエンジニアの発想から、チェックリストを電子化してタブレット端末で入力できるシステム「M0チェックシステム」を開発しました。
いざ開発を始めると、現場からの反応は良く、さまざまなフィードバックが上がってきました。「ボタンの位置を変えてほしい」など、細かいものから技術的に難しいものまで、たくさんの要望に応えていくのは、苦労もありましたが、大変やりがいを感じました。また、課題の一つとして、各機器の名称が船によって微妙に異なっていることがありました。同じ機器でも船によって名称が異なっていると、グラフを作成するにも個船毎となってしまい、各船のデータに横串をさして、全船のグラフを作成することができません。その微妙に異なる名称を、他のエンジニアの力も借りながら3か月ほどかけてひとつずつ紐づけていきました。また、いざソフトを作り込んで全船展開を考えていた矢先に、セキュリティーポリシーの変更という予想外の事態への対応が必須となり、また１からソフトを作り込むことなるなど、思いがけない苦労もありました。
データを電子化することで、必要な情報をすぐに検索でき、またグラフなどで見える化することで、異常の早期発見が期待できます。チェック中に、異常を発見した場合、タブレット端末で写真や動画を撮影し、入力データと共に保存することができるので、状態の共有が簡単にできるようになりました。また、このシステムからデータを陸へ送ることもできます。SIMS（Ship Information Management System）でも取得できない補機データについても陸側から確認することができるため、陸上からも本船のサポートが可能です。
今後は、このシステムで異常を検知して、さらに”知らせる”機能の開発を考えています。なるべくシンプルな分かりやすいアラームが実現できたらと思っています。また、このシステムはM0チェックだけでなく、他のチェックリストにも応用できる可能性があるので、さまざまなチェックにも活用できるように、開発を進めています。
将来の診断技術向上に期待
今後、診断技術が向上していくことで、異常をより早く見つけることができるようになると思います。大きなトラブルに発展する前に対応できるようになると思うと、乗組員としては頼もしいかぎりです。私が船に戻った時には、自分が開発に携わった製品が乗っていると思います。それらを実際に使用するのがとても楽しみです。今までの開発側の視点とはまた違った角度から、製品を見直すことできると思います。
システムメンテナンスで訪船時