安全面や環境への配慮など、現在の自動車にはさまざまな制約条件が求められるようになっている。それに伴い、エンジンの制御システムは複雑化、大規模化の一途を辿っている。一方で自動車メーカーは、商品開発期間の短縮とコスト削減という普遍的な命題を抱えている。こうした数々の課題を解決するためにトヨタ自動車が取り組んだのがMBD（Model Based Development）やMBD Frameworkの導入だ。Oracle Days Tokyo 2013で登壇したトヨタ自動車 東富士研究所 エンジン技術開発部 主幹の石崎直哉氏が、その取り組みについて語った。
執筆：西山 毅
複雑化／大規模化の一途を辿るエンジン制御システムの開発プロセス
トヨタ自動車
東富士研究所
エンジン技術開発部
主幹
石崎 直哉 氏
東富士研究所
エンジン技術開発部
主幹
石崎 直哉 氏
また次世代環境車の開発にも取り組んでおり、水素と酸素を化学反応させて電気を作る燃料電池を動力源とする燃料電池車（FCV：Fuel Cell Vehicle）も研究段階にある。
エンジン専用の開発部隊に所属する石崎氏は、「こうした流れを背景に、我々は色々なバリエーションの車を同時に開発していなかなければならない。しかしエンジン制御もまた非常に多様化してしまい、制御システムの開発プロセスを管理していくことがとても難しくなってきている」と現状の課題を説明する。
エンジンはハードウェアだけでは動かない。コンピュータシステムによって最適な燃料噴射量と点火時期を制御することで、優れた動力性能とクリーンな排気、スムーズな運転性能を実現している。
たとえば現在、1つのエンジンにおける制御モジュールの数は600～800で、各モジュールはC言語の1つの関数だ。
あるいは販売先の国に応じた個別対応も必要で、たとえばASEANならより安く車を作らなければならない制約があり、欧州なら厳しい排気ガス規制に対応しなければならない。さらには多様化する代替燃料エンジンへの対応も必要だ。
現在では1年間に100車種のエンジン制御開発を同時並行で行っている。「開発現場はまさに混沌とした状況」（石崎氏）という。
実機での評価では、数か月単位の遅れが発生する場合も
自動車IT関連記事
1980年代初頭に登場した最初のエンジン制御システムは、4ビットのCPUと4kバイトのROMで構成され、入力としては、アクセルの操作、空気量、エンジンの回転数、酸素濃度、水温／吸気温の5つ、出力が、燃料噴射量と点火時期の2つのみだった。 これが現在のエンジン制御システムでは、CPUが32ビット、ROM容量が1Mバイトで、入力数は55、出力が48にもなっている。かつ最近では車載のCAN（Controller Area Network）を介して、駆動系システムなど他システムとも300以上の通信信号をやり取りしている。
またエンジン制御システムの仕様書をプリントアウトした紙の枚数は、1988年で約90枚、2002年には2000枚、それが現在では約5000枚にもおよぶ。
「ここまで来ると、一人のエンジニアがすべてを理解するのは不可能だ。そこで、あるメンバーは空気の制御、また他のメンバーは点火の制御というように役割分担が進んできており、チームとしてエンジン制御システムを開発するという状況になってきている」
実際の開発プロセスとしては、まず制御への「要求」を決定する。たとえば“2018年に発売する車の酸素濃度はこれ以下にする”という制約を達成するためには、どういう制御が必要なのかを考える。
次にその要求を具体的な「機能」に落とし、ソフトウェア部分については「仕様」を決めて「コーディング」を行い、ハードウェア部分についてはCASEツールなどを使って「設計図」を描く。
実際のソフトウェアおよびハードウェアの作成は外部のサプライヤーに依頼し、納入してもらった後に実機での「評価」を行う。
実際に評価を始めても、思った通りに動かないということは起こる。その際にはまた要求段階に戻って考え直す。「これを開発期間中、繰り返す。そのため数か月単位の遅れが発生する場合もあった」という。
こうした課題を解決するためにトヨタが採用したのが、コンピュータによるシミュレーションを多用するMBD（Model Based Development）という開発手法だ。
シミュレーションによる評価時間は、実機評価の30分の1
MBDは大きく2つの特徴を持つ。開発プロセス自体は同じだが、従来型の開発と比べて、シミュレーションの比率が大きい。また、コンピュータ上で適合検証を行うためのリアルタイム・シミュレーションを実施する。「開発初期の段階からコンピュータによるシミュレーションを採り入れることで、エンジン制御システムの完成度を高めていく」。 MBDではまず、“Controller Medel”という最初の制御モデルを開発し、それを使ってコンピュータ上でシミュレーションを行う。ここで簡単なバグ出しをするなどして、早い時期から仕様の精度を上げていく。
次にモデリングや動作検証などの機能を提供するSimulinkというソフトウェアを使ってシミュレーションを重ね、また制御モデルをC言語に変換する作業も自動化する。
さらにソフトウェアによるシミュレーション（＝SILS：Software In the Loop Simulation）、ハードウェアによるシミュレーション（＝HILS：Hardware In the Loop Simulation）を経ることで、実機での評価を減らし、開発プロセスの工数自体を削減する。
ちなみに実機評価前に行うHILSは、1つのラック内に、エンジン、モーター、ブレーキなどの各構成要素を模擬するシミュレータと電源を設置して繋ぎ、実機のエンジンと等価な動きを実現するものだ。
「HILSによるシミュレーション結果は、実機での評価結果と97％一致する。また評価にかかる時間も30分の1に短縮された。これまで30日かかっていた工程が1日でできるようになった」
今後は全エンジニアで共有できるデータベースの構築を目指す
しかしこのMBDはエンジニアからは不評で、かつノウハウや経験がチームで共有されないなどの課題を抱えているという。「開発プロセスの役割分担が進んでいくと、他の人の担当領域には関心が無くなってくる。つまり、組織が縦割りに硬直化していくという問題がある。またHILSのセットアップには、入出力が多岐にわたることもあり、実は1～2週間程度かかる。それを待つのをエンジニアは嫌がる」
さらにHILSのセットアップは専門のエキスパートが担当するが、必要な情報を収集した後、必要なものだけを個人的に管理し、メンバー全員で共有する仕組みがない。また集めた情報が正しくなかったり、古かったりする場合もあり、情報管理に対するガバナンスも欠如しがちだ。
そこで現在、トヨタが構築を目指しているのが、「MBD Framework（MBDF）」という仕組みだ。端的にいえば、エンジニアの情報基盤となるデータベースの構築である。
最終的に目指す姿は、ハイブリッド系、駆動系といった各部門のエンジニアが、制御システムの開発時に作成した仕様書などの成果物をMBDFに登録すると、それが車両ごとに一元管理される。そしてシミュレーションを実施するエンジニアが、担当する車両に関する情報を取得し、SILSもしくはHILSを構築して実際にシミュレーションを行い、得られた評価結果をまたMBDFに格納する、という作業フローだ。
今後トヨタでは、このMBDFの展開を3つの段階に分けて進めていく。
「STEP1で、現行の制御開発のプロセスやデータを管理できる情報基盤を構築する。今がまさにこの段階。」
次のSTEP2で、SILSやHILSなどとの連携を図り、情報管理をさらに効率化していく。
そしてその先のSTEP3では、先進的なV＆V（Verification and Validation：検証と妥当性確認）ツールやモデリングツールなどとも連携を図り、社内展開の加速も目指すとのことだ。
0 件のコメント:
コメントを投稿