NECソリューションイノベータ
MBDの概要や必要性、メリットやデメリットについて解説
目次近年、自動車業界などでプロトタイプを制作する前にモデルでシミュレーションを行う、MBD(モデルベース開発)の導入が進んでいます。この記事では、MBDのメリットや課題などを紹介します。また、車載ソフトウェアの開発プロセスモデルであるA-SPICEについても、その概要やMBDで準拠すべき必要性について解説します。
MBDとは「Model Based Development」の略で、日本語では「モデルベース開発」と訳されています。モデルとは、コンピューター上で数式などを用い現実と同様の仕様を再現したもので、いわば動く仕様書のようなものです。そのモデルを使ってシミュレーションを行い、開発と検証を同時並行でより効率的に進めるのが、モデルベース開発です。従来の組み込みシステム開発では、テキストやフローチャートを用いた紙の仕様書をもとに妥当性を検証し、コーディングを経てからハードウエアでの検証を行っていました。この検証はフィードバックを重ねながら何度も繰り返されますが、そのたびにコーディングの修正や、プロトタイプの作り直しが必要になるため、多大な時間と労力がかかっていました。しかし、MBDでは専用のソフトウェアを使い、仮想環境でシミュレーションを行えるため、開発効率が向上してリリースまでの期間を短縮できます。すでに自動車業界では、車載システム開発などで導入が進んでおり、今後この開発方法はほかの業界や製品にも広く普及していくと考えられます。
自動車業界は日進月歩でテクノロジーが進んでおり、今後も電気自動車や自動運転が普及していくと考えられています。また近年、消費者の安全や環境に対する関心は高まっており、横滑り防止装置や衝突被害軽減ブレーキ、排ガス規制の基準への対応など、自動車に搭載する機能はますます複雑化しています。しかし、いくら搭載する機能が増えても、開発にかけられる費用や労力は限られています。製品の質を落とすことなく、年々拡大する市場ニーズにこたえるためには、開発工程で自動化できる部分は自動化して効率化を進めなければなりません。そのため、効率性と正確性を兼ね備えたMBDの導入が増えています。
MBDが活用されているのは、自動車業界だけではありません。リアルな検証を頻繁には行えない航空機や建機の開発現場でも、MBDは普及しはじめています。今後も検証のために広い場所を必要とする大型の製品などでは、コンピューター上でシミュレーションできるMBDのニーズが増えていくでしょう。さらに2021年7月9日には、MBDの全国普及を目指して、マツダやトヨタといった大手自動車メーカーと自動車部品メーカーが「MBD推進センター」を立ち上げました。オンラインの説明会では参画各社がMBDの意義を解説し、普及への取り組みを進めています。
MBDは開発期間を短縮するだけでなく、ほかにもさまざまなメリットがあります。ここからはMBDのメリットについて、さらにくわしく解説します。
MBDに使用される専用ソフトウェアは、構築したモデルから自動でコードを生成できます。従来のように人の手でコーディングを行っていると、時間がかかる上に人為的なミスが発生するリスクもあります。また、組み込みシステム開発では仕様書の作成、ソフトウェア設計、コーディングをそれぞれ別の部署が担当することも多く、作業が分断されるため、コミュニケーションミスも起こりがちでした。
しかし、自動コード生成なら一連の作業を機械が行ってくれるため、ミスが発生するリスクが減り製品の品質向上につながります。コンピューター上でシミュレーションできるため、網羅的な検証も可能になります。さらに、作成したモデルは複製や改良が容易なので、製品の完成後も継続して検証が可能です。改良したモデルを使ってシミュレーションを重ねることで、製品の品質を高め続けられるのも大きなメリットです。
二つ目の大きなメリットは、開発スピードを向上させられることです。従来はプロトタイプや試作品を作って行っていた検証や、大がかりな環境を整えなければならなかった検証も、MBDを使えば仕様書の段階から妥当性を検証できます。また、不備を発見した場合も、パソコン上で修正してシミュレーションできるため、時間と労力を削減できます。さらに自動コード生成が可能なことで、プログラミングの作業時間を大幅に短縮できるのもポイントです。修正が必要になった場合も素早く対応でき、人の手によるミスも防げます。人の手による作業を減らすことで、精度の高い検証を繰り返すことが可能になり、高い品質の製品を他社より早くリリースできるようになります。
従来の組み込みシステム開発でもプロセスの再利用は行われてきましたが、モデルベース開発では再利用のしやすさの点で、これまでよりいくつか有利な点があります。一点目は、モデルをSimulinkのブロックとして描けるため、再利用の際に機能や視覚面で体裁を整えなくてよいことです。二点目はモデルが仕様書となっているので、再利用のためにあらためて仕様書を作り直す必要がないことです。ブロックをコピーするだけで、プログラムと仕様書の両方を取り込めるため、すぐにシミュレーションとして動作させることが可能で、作業時間を格段に短縮できます。MBDで作成したモデルは企業の資産です。モデルは今後の開発や製品の改良、技術の継承に活用できるほか、改善を重ねることにより、製品品質の向上やさらなる開発の効率化にもつなげられるでしょう。
ここまではMBDのメリットについて紹介しましたが、良い点ばかりではなく今後改善すべき課題やデメリットもあります。工数や習得期間など、主なデメリット二点について以下にくわしく解説します。
開発工程を効率化できるMBDですが、実はプロトタイプや試作品の作成までの期間だけで考えると、工数は従来より多いというデメリットがあります。
従来の組み込みシステム開発のプロセスは「V字モデル」と呼ばれており、検証や適合・評価といったプロセスは、プログラムや試作品の作成後に行われてきました。しかし、MBDでは検証や評価を開発と並行して行えます。全体的に見れば、早い段階から検証が行えた方が開発後期の手戻りが減るため効率的です。しかしMBDでは開発対象のモデルとは別に、シミュレーションを行うためのプラントモデルも作らなければならず、妥当性を検証するための検証用データも必要になります。Vモデルの左側部分の工数が極端に増えるため、開発体制が整うまでは効率化の効果がさほど現れない場合もあります。場合によってはモデルを扱う設計者を増やしたり、技術をフォローする人材を入れたりするなど、開発体制や人材配置を見直す必要があるでしょう。
MBDでは設計者自身がシミュレーションを行うことが多く、モデル作成のための専用ツールを使いこなせるようにならなければなりません。これまでツールを使った経験がなければ、習得までにはある程度の時間を要します。また、プラントモデルの作成など従来のプロセスでは必要なかった工数も増えるため、戸惑うこともあるでしょう。もし、これまで設計を行っていたチームがそのままMBDの設計を引き継ぐのが難しい場合は、新しく人材を育成しなければなりません。MBDを本気で推進したいなら、研修制度を設ける、専門知識を持った講師を招くなど、じっくり時間をかけ、企業を挙げて教育制度の整備に取り組む必要があります。
車載ソフトウェアの開発においては、MBDが広く普及していることは前項でご紹介しました。近年、快適性や環境性、安全性などの観点から自動車にはさまざまな高い機能が求められるようになっています。空調の自動温度調節や、スマートフォンとの連携、自動ブレーキなど、高級車ともなると100個近くのECU（電子制御ユニット）が搭載されていることも珍しくありません。こうした自動車の高性能化はこれからも続くと考えられており、それに従い車載ソフトウェア市場も今後拡大していくことが予想されます。
しかしそれと同時に、ソフトウェア由来の不具合によるリコールも急増しています。こうした状況から、自動車メーカーはソフトウェアの品質に対しても厳しい基準を求めるようになってきました。それに従い現在、世界的に多くのサプライヤーが車載システム開発で準拠するようになっているのが、開発プロセスの標準フレームワークである「Automotive SPICE(A-SPICE)」です。
ここからはA-SPICEの概要や、同じく車両の機能安全規格であるISO26262との違い、A-SPICEを準拠する必要性についてくわしく解説します。
A-SPICEは、車載ソフトウェアの開発プロセスモデルのひとつで、目標達成のために実施すべき行動や、作るべき成果物などの指針が示されており、最初に正式版が発行されたのは2006年です。自動車に搭載されるソフトウェアの品質を統一して確保するため、欧州自動車メーカーが中心となり、ソフトウェアプロセスモデルの国際規格ISO15504を自動車業界向けに再編集して作られました。その後、何度かプロセスの見直しが行われ、現在は2017年に発行されたVer3.1が最新版として利用されています。
A-SPICEはマネジメントとエンジニアリング、それぞれの観点からプロセスが定義されているのが大きな特徴です。そのプロセスは「主要ライフサイクルプロセス」「支援ライフサイクルプロセス」「組織ライフサイクルプロセス」の3つのカテゴリに分類され、それぞれのプロセスごとに要件が定義されているので、プロセス定義は全部で32個にのぼります。定義の中では、実施すべきプロセスや作るべき成果物は具体的に示されているため、現段階での達成状況が分かりやすく、品質改善につなげやすいのもメリットです。A-SPICEでは各プロセスの達成度合いを0～5の6段階のレベルで評価します。車載ソフトウェアでは一般的に1～3のレベルが求められており、企業によってはそのレベルに達していなければ取引を行わないところもあります。
A-SPICEはISO9001などと違い公的認証制度はありませんが、世界基準として業界では広く活用されており、これを満たすことは安全性と信頼性が確保されていることの証明になります。
Automotive SPICEアセスメント支援サービスは、自動車業界のナビメーカーや車載制御装置メーカーなどの幅広いお客さまに向け、すでに豊富な導入実績があります。お客さまの開発プロセスの現状から、Automotive SPICE対応に向けた課題を発見し、成果物の作成、設計の改善、現場での対応要員指導をサポートします。
A-SPICE以外に、自動車の安全に関する規格で知られているのが、「ISO26262」です。では、この二つはどう違うのでしょうか。
A-SPICEは、車載ソフトウェアの品質を定量的に評価するために、開発プロセスのフレームワークを定めたプロセスモデルです。一方、ISO26262は自動車の機能安全に関する国際規格で、車載機器やソフトウェア開発を行う上で、準拠すべき機能安全開発プロセスが規定されています。A-SPICEの定義の対象は開発プロセスに限定されていますが、ISO26262は自動車の要求定義から、開発、生産、保守、運用、廃車にいたるまで、広範囲にわたって定義がされているところが大きな違いです。
また、ISO26262が国際規格で公的な認証を必要とする一方、A-SPICEでは公的認証制度はありません。ただ、自動車メーカーがサプライヤーの開発プロセスを評価する際に、基準として広く活用されているため、調達要件として充分な信用性があります。ISO26262は中国では推奨国家標準として指定されており、欧州や日本で車載ソフトウェアの調達要件としてあがることの多い規格です。一方、A-SPICEも欧米をはじめ世界的に準拠を求められるケースが増えています。また、ISO26262とA-SPICE両方の準拠が必要とされる場合もあります。
ISO26262とA-SPICEの親和性は高く、A-SPICE中の開発プロセスのフレームワークが、ISO26262の準拠に役立つと言われています。しかし、A-SPICEを取得しているからといって、必ずしもISO26262が認証されるとは限りません。A-SPICEで定義されているのはあくまでフレームワークのみで、具体的な形式や手法、安全への要求まではカバーされていないからです。そのため、ISO26262の認証を受けるためには、A-SPICEのソフトウェア開発プロセスをベースとしつつ、A-SPICEの対象範囲以外の定義にも対応する必要があります。
では、なぜ車載ソフトウェアの開発において、A-SPICEを準拠する必要があるのでしょうか。
一番大きな理由としては、A-SPICEがすでに自動車業界では世界的な標準規格のひとつになりつつあるからです。これまで、調達要件でA-SPICEの要件が求められるのは欧州が中心でしたが、その動きは世界各国に広がりつつあります。それに従い、欧米の多くのサプライヤーはA-SPICEへの対応を済ませており、中国や韓国のサプライヤーも追随するように対応を進めています。
日本はほかの先進国に比べ、A-SPICEの対応が大幅に遅れており、このままでは多くの自動車部品や電子機器のサプライヤーが、将来的に海外の自動車メーカーに製品を納入できない事態も考えられます。自動車の国内消費が低下している現在、グローバル市場での競争力まで失ってしまえば、日本の自動車産業は衰退してしまうでしょう。
また、A-SPICEの準拠は、安全確保の点から見ても重要です。車載ソフトウェアには、自動ブレーキや歩行者検知など、安全に関わるものが数多くあります。そうしたソフトウェアが適切なプロセスで作られていなければ、重大な事故にもつながりかねません。基準を満たしたソフトウェアであれば不具合によるリコールも減らせ、無駄なコストを削減できます。さらに、A-SPICEによって開発プロセスをモデル化することは、複雑化する開発プロセスの効率化や、技術者の能力向上にも役立ちます。世界の動きに合わせ、日本のサプライヤーもA-SPICEへの迅速な対応が急務となっています。
次々に新しいテクノロジーが登場する近年の自動車業界では、開発競争も激化し、少しでも早く優れた製品をリリースすることが企業の競争力向上につながります。
今後、開発効率を高めていくためには、仕様書の段階からプロトタイプの制作と並行して検証を進められるMBDの導入は欠かせません。
しかし、機能が複雑化するほど不具合が起こりやすくもなります。車載ソフトウェア開発においては、スピードの向上とともに、安全性や品質の確保も重要な課題となります。A-SPICEは、品質の確保にもつながる車載ソフトウェア開発プロセスの標準フレームワークです。その準拠が世界的に標準化されつつある現在、日本の自動車業界も早急な対応が求められています。
おすすめのコラム