人とシステム

季刊誌
NTTデータエンジニアリングシステムズが発行する
お客さまにお役に立つ情報をお届けする情報誌です。

No.99 | システム紹介
モデルベース開発における制御系モデル情報交換システムの構築
ー日本自動車工業会(JAMA)様における取り組みについてー
株式会社NTTデータエンジニアリングシステムズ
オートモーティブソリューション事業部 先端ソリューション推進部
開発課 高橋 修司、加藤 智之, Dr. Eng.

はじめに

近年、自動車業界ではCASEに代表されるように、産業構造の変革を余儀なくされ、製品ライフサイクルの短縮化に加えてシステムの複雑度が上がっています。この状況に対応するためには、設計情報(要求、仕様情報など)を複数の企業間、複数のツール間でやり取りせざるを得ず、情報のトレーサビリティが担保されていることが求められます。設計情報のトレーサビリティ担保が可能になれば、モノを作製することなく、設計内容の確からしさをシミュレーションすることが可能となり、工数の削減や製造コストの低減が期待できます。そのためには、ハードウエアだけでなく制御系(ソフトウエア)についてもモデル化を行い、製品全体をシステムとして取り扱うことを可能にすることが不可欠です。

私たちはMBSE・MBDサービスの一環として「モデル」に基づいた設計情報のシミュレーション環境をクラウド上に構築しており、日本自動車工業会(以下、JAMA)様におけるOEM-サプライヤ間の電子制御設計情報流通のコンセプトの実現手段としてふさわしいと考え、本取り組みを実施しました。本稿ではMBSEに関する基本的な考え方を整理した上でJAMA様の取り組みの内容およびアプローチについて言及し、私たちが提供するMBSE・MBDサービスについてご紹介します。

先端ソリューション推進部のご紹介

本題に移る前に、MBSE・MBDをご提案するオートモーティブソリューション事業部先端ソリューション推進部(以下、先ソ)についてご紹介します。先ソは2019年に発足した新規事業を創出する部門です。私たちの原点は、日立造船のシステム部門から独立した組織体ですが、現在では自動車業界のお客さまとも多くのお付き合いがあります。先に申し上げた通り、自動車業界ではCASEなどのパラダイムシフトが生じています。自動車業界だけでなく、DX(デジタルトランスフォーメーション)がさまざまな産業で求められている昨今の経済状況において、お客さまに新たな価値をご提供することを目的に本組織が立ち上がりました。各専門分野のエキスパートが集結するこの組織は、外資系ツールベンダやアカデミックに従事した者、制御開発のエキスパート、OEMにて自動車開発に携わった者など外部の経験者と、内部の精鋭エキスパートとの創発を実現しました。先進的な取り組みとして、MBSEサービス事業やオフショアによるCAEサービスなど新たな試みを実践し、お客さまと共に価値創造に取り組むためのご提案をいたします。ご興味がございましたらお気軽にお問い合わせください。

次項よりMBSE領域の取り組みについてご説明します。

MBSEとは何か

MBSE(Model Based Systems Engineering)という言葉が昨今の自動車業界を中心に話題となっています。自動車業界ではこれまでMBD(Model Based Development)という言葉も使われてきています。いずれもModel Based(MB)というワードを冠しているため、違いが分かりにくいと思います。本題に入る前に、私たちが捉えているそれぞれの言葉についてご説明します。まず、どちらの言葉もBetter productのためにSystems Engineering(SE)を実行することが前提です(図1)[1]。SEはBetter product、Better engineeringを実現するための手段であり、MBSE・MBDはSEを実行する上での手段だということを認識することが重要です。したがって、MBSEとは入れるだけで全てを解決できる魔法のツールではなく、あくまでモデルを活用することによりエンジニアリングをうまく、確実に行うための手段に過ぎません。

MBSEはSEの手段と述べましたが、そもそもSEとは「システムを成功裏に実現するための複数分野にまたがるアプローチ及び手段」と定義されています[2]。つまり、システムを構想から実現するまでの全ての活動のことを指します。SEの世界標準の1つとされているISO15288[3]では、図2のように4つの大プロセスとそれらの分類に含まれる30個の小プロセスを定義しています。プロセス群にはシステムの設計・開発に関わるものだけでなく、それらのプロセスをマネジメントするためのプロセスも含まれています。

図1 SE、MBSEの関係([1]より筆者作成)
図1 SE、MBSEの関係([1]より筆者作成)
(クリックすると拡大画像が表示されます)
図2 ISO15288のプロセス群([3]より筆者作成)
図2 ISO15288のプロセス群([3]より筆者作成)
(クリックすると拡大画像が表示されます)

次に、MBSEとMBDの関係についてご説明します。MBSEとはすなわち、モデルを活用することによりSEプロセス群を実行する活動を指します。一方で、MBDはCAEや1Dシミュレーションなどのシミュレーション技術を用いて自動車開発における検証(Verification)をバーチャルに行うことが主な目的です。つまり、MBDはエンジニアリングのための技術そのものを指しており、実現プロセスなどへの言及がないことになります。そのためこれらは似て非なるものだと考えられます。MBDには他にModel Based Designという意味も当てられます。Designとは「設計」と訳されることから、Vモデルによる開発工程の左側を指すニュアンスが強いと思われますが、ここでいうDesignもエンジニアリングのための技術を指すことが多く、SEのような全ての活動を含んでいるわけではないと考えられます。

以上のことから、(MB)SEは、システムを実現するための全ての活動のことであり、Model Based DesignとModel Based Developmentを合わせたものが、ISO15288における技術プロセス領域に相当すると考えています。

ここまで、(MB)SEやMBDについて一般的な定義に基づいて整理しました。続いて、なぜモデルベースでの仕事が推奨されるか、その要因についてご説明します。例えば、宇宙業界におけるSEは文書ベースで行われることが多くあります。宇宙機システムは、作動環境や振る舞いが明確に規定されていることから要求も明確となり、文書だけでもエンジニアリングができるためです。一方、日本の製造業が得意とするすり合わせ開発では、より良いモノを生み出すために開発完了の間際まで要求が変わり設計変更が生じます。そこで、宇宙業界のように厳格な文書で開発を行うのではなく、モデルを活用した開発を行うことで何がいつ変更されたのかを瞬時に把握できる開発手法が求められます。この「モデル」とはさまざまな意味がありますが、MBSEの世界では対象システムをステークホルダーのさまざまな懸念に基づいて漏れなく表現した図式[4]として扱われています。また、モデルの代表的な記法であるSysMLのガイドブックでは、MBSEで記述すべきシステムモデルのことを、対象とするシステムのスペック、設計、分析、検証に関する情報を網羅したものと表現しています[5]。つまり、MBSEの扱うモデルは開発の全ての情報が含まれた図式であるということです。例えば、SysMLでは「構造」「振る舞い」「要求」「パラメトリック(制約)」の4つの分類、11の図式(ダイアグラム)を用いてシステムを表現することになります。このようなモデリング言語を用いて表現されたシステムのモデルは「システムモデル」と呼ばれます。システムモデルと開発の関係は図3のように表現されます。外部からの要求は要求図に変換され(図3の①)、要求図と既存のアーキテクチャや開発プロセスを元にシステムの構造モデルや振る舞いモデル、制約モデルへと落とし込まれます(図3の②)。設計された各モデルの確からしさは各種解析やシミュレーションで確認します(図3の③)。最終的に設計が決定されるとモデルがそのまま仕様として提供されます。各ダイアグラムは、それぞれの視点から見た時のシステムを表現しています。設計図面における三面図をイメージいただけるとわかりやすいでしょう。したがって、各ダイアグラムはつながっている(=トレーサビリティがある)状態となります。このトレーサビリティのおかげで、設計変更に伴いあるダイアグラムを変更すると、それに連動して関係のある他のダイアグラムの情報が変更される、または変更が必要であることのフラグが立つことになります。そうすると、モデルの活用はコンピュータと非常に相性が良いということになります。高精度のモデルを構築し、ITを使うとシステムの開発の効率が格段に上がります。

図3 システムモデルと開発プロセスの関係([1]より筆者作成)
図3 システムモデルと開発プロセスの関係([1]より筆者作成)
(クリックすると拡大画像が表示されます)

MBSE領域におけるNDESの取り組み

それでは、MBSEに関する私たちの取り組みについて紹介します。私たちは、前述のISO15288のプロセス群の中でも、技術プロセスと技術マネジメントプロセスに関して支援する仕組みを構築しています。これまでに触れたようにMBSEはMBDを含む大きな概念でありますが、MBDの方が先にさまざまな業界に浸透しており、混乱を避けるために私たちは図4のようにMBSEをMBDがカバーしていない領域として定めています。

私たちのMBSEに関するメインサービスはクラウド上に統合的なSE環境を提供することです。すでにお客さまの中にもさまざまなエンジニアリングツールを導入されていると思いますが、全てのエンジニアリングプロセスを1つのツールで完結させることは不可能だと言えます。そこで、複数のツールを有機的に組み合わせてトータルにSEを実現することが必要であると考えています。私たちはクラウド(Manufacturing-Space®)上に複数のエンジニアリングツールを実装し、それぞれのツールを組み合わせて情報を正しくつなぎ合わせることでSEを実現するプラットフォーム(TSF:Technical Service Framework )の実証を行っています(図5)。TSFのユースケース実証の一部を次の項でご説明します。

図4 MBSE・MBDに関するNDESのサービス領域
図4 MBSE・MBDに関するNDESのサービス領域
(クリックすると拡大画像が表示されます)
図5 Technical Service Framework
図5 Technical Service Framework
(クリックすると拡大画像が表示されます)

構築したモデルベース開発における
制御系モデル交換システムについて

さて、自動車業界におけるモデルベース開発(MBD)の拡大に伴い、JAMA様では増大するモデル流通の課題と解決の方向性について議論されています。モデル流通の課題には、次の3つが挙げられています[6]

①受け渡すべき情報の内容が定義されていないこと

②受け渡しのやり方が統一されていないこと

③受け渡したモデルを連携させて動かす事ができないこと

課題②を細分化すると、次の問題が見えてきます。

(a)構成管理システム(Excel管理台帳を含む)を各社が準備する負担が発生すること

(b)取引先システムを利用する際に利用料が請求される場合があること

(c)取引先指定のツールを都度購入しバージョンアップする負担が発生すること

(d)メールベースでのモデル流通により社内の管理システムとの関係性が断絶すること

私たちは、これらの課題を解決するためのモデル流通の共有インフラシステムの要件を定義し、プロトタイプを作成してJAMA様が想定するモデル流通に関わる要求の仮説検証を実施しました。

本取り組みで想定するシチュエーションは、完成車OEMであるA社が、エンジンサプライヤのB社に対してエンジン開発を委託するというものです。図6はA社とB社が制御モデルを交換するための共有インフラシステムのコンセプトを示しています。A社はエンジンモデルがブランクとなった車両制御モデル(Simulinkモデル)と、エンジンに対する要求仕様をB社に提示し、B社はその要求に合致したエンジンモデルを設計して要求に対する検証情報と共にA社に渡します。モデルをやり取りする際は「共有ハブ」と呼ばれるIT基盤にモデルを置くことで、各モデルの保存に加えてトレーサビリティ情報を付与します。トレーサビリティ情報とは、1つひとつの要求がどのように実現されており、かつ検証されているのかが後追いできる(=Traceableである)ようにするために付与する情報のことです。トレーサビリティに関する詳しい内容については割愛しますが、トレーサビリティ情報が付与されていることで複数企業での開発であってもシステムが保証されている根拠となるため、複雑なシステムの開発においては不可欠な情報となります。

図6 想定される制御モデル交換ユースケース([6]より抜粋)
図6 想定される制御モデル交換ユースケース([6]より抜粋)
(クリックすると拡大画像が表示されます)

モデル流通共有インフラシステムを構築するにあたっては、次の点に留意し、実装しました。

  • 特定のツールに依存しないオープンなフォーマットにすること
  • 流通させるモデルの情報に秘匿性があること
  • 異なるツールでもトレーサビリティを担保できること

図7は、本取り組みにおける共有ハブがトレーサビリティ情報をどのように付与しているかについて示しています。今回はI~IVの4つのシーケンスによってトレーサビリティ情報の付与を実現しています。それぞれのシーケンスについて次に示します。

I:A社は要求モデル(要求仕様のことで、今回はシーメンス社のPolarionというツールを用いて要求リストを作成)と車両モデル(Simulinkモデル)を共有ハブに送付します。共有ハブは要求モデルをハブ上で標準化したフォーマットで読み込み、要求に対応するように車両モデルのファイル名を書き込みます。この処理はTASK1として共有ハブで記録されます。これにより、A社から送付された要求モデルと車両モデルを関連づけることができます。

II:共有ハブはB社に対し、共有ハブの持つ要求モデルと車両モデルを送付します。共有ハブで持つ要求モデルを送付することにより、A社独自の採番情報(A社の機密情報として想定した情報)は渡されず、セキュアな情報のやり取りを可能にすることにつながります。B社はモデル群を受領した後、要求に合うようなエンジンモデルを設計していくことになります。

図7 実装したトレーサビリティ担保の仕組み([6]より抜粋)
図7 実装したトレーサビリティ担保の仕組み([6]より抜粋)
(クリックすると拡大画像が表示されます)

III:B社は送られてきた要求モデルに基づき、エンジンモデル(Simulinkモデル)と検証情報が加えられた要求モデルを共有ハブに送付します。共有ハブはB社から送られた要求モデルに含まれる検証情報およびエンジンモデルのファイル名を記録します。この処理はTASK2として共有ハブで記録され、A社の要求仕様とB社の設計したモデル、要求の検証情報を関連づけることができます。

IV:共有ハブは共有ハブの持つ要求モデルとエンジンモデルをA社に送付します。

以上のような共有ハブを媒介としたモデルをやり取りするプロセスを通すことで、元の要求モデルとエンジンモデル、各要求に対する検証情報を紐づけることができ、設計情報のトレーサビリティが担保されます。

アジャイル・アプローチによるプロジェクト推進

本取り組みでは、従来のシステム開発で採用されているウォーターフォール型開発ではなく、アジャイルの考え方を開発に適用しました。これは、本取り組みがJAMA様において構想段階であり、さまざまなステークホルダーの要求をまとめあげ、仕様へ落とし込むことが必要であり、図8のようにイタレーションと呼ばれる短い期間で小さく開発したものをレビューして次の機能の開発に移ることが大きな特徴[7]であるアジャイル的アプローチを取ることにしました。各イタレーションのアウトプットをベースに議論することで、顧客が気づかなかった要求や、機能の優先度の変更などに柔軟に対応できます。JAMA様との間でもプロトタイプの提示を数回行うことで、当初想定していなかった要求事項やプロトタイプが持っていたユーザビリティの良さなどを発見することができ、現場適用へのイメージが具体的になりました。このようにアジャイル開発の手法を用い、顧客のコアとなる要求を中心に実装することで、短期間のプロジェクトでありながらJAMA様が目的とする仮説検証のためのプロトタイプ構築が実現できました。これにより、JAMA様との信頼関係も構築できたと考えます。

図8 アジャイル開発のイメージ
図8 アジャイル開発のイメージ
(クリックすると拡大画像が表示されます)

本取り組みを成功させるための体制構築

本取り組みを成功させるには、アプリケーション開発を柔軟かつ高速に実行することが求められました。そこで、インドのWipro(ウィプロ)社にオフショア開発を依頼することでリソースの効率化を図りました。Wipro社を選定した理由として、主に次のようなことが挙げられます。

①自動車業界向けの業務経験が豊富である

②幅広く技術をキャッチアップしており、前提となる知識の共有に割く工数を最小限にできる

③日本語および日本文化の教育に力を入れており、コミュニケーションが円滑にできる

とりわけ、③の教育については営業部門だけでなく技術部門にも高レベルな日本語で会話できる担当者が複数人いて、互いに歩み寄ってワンチームで目標に向かって前進する気概が非常に感じられました。本取り組みを成功裏に導くことができたため、今後のMBDおよびMBSEのためのサービス開発、さらにはお客さまへのご提案をWipro社と共同で実施していくことを検討しています。私たちとWipro社がコラボレーションすることでお客さまの価値創出と事業発展のためにご提供できることを図9に示します。お客さまの目の前の課題のみならず、ライフサイクル全体を俯瞰した問題解決のためのロードマップ構築に対して、私たちとWipro社の技術力を掛け合わせることでお客さまを強力に後押しできると考えています。

さらに、COVID-19の世界的流行に伴い、ビジネスモデルを変革せざるを得ない昨今において私たちとWipro社のアライアンスは、お客さまにとって強力な後ろ盾となることを確信しています。

図9 NDESとWipro社のアライアンスにより提供できる価値
図9 NDESとWipro社のアライアンスにより提供できる価値
(クリックすると拡大画像が表示されます)

おわりに

本報では、MBSEに関する情報の整理を行った後、私たちの取り組みについてご説明させていただきました。本取り組みでは、複数企業間における制御モデルの交換をツールに依存しないで実現するためのプロトタイプを構築し、実際の開発業務に適用するための基本的な機能を有していることを実証しました。また、本取り組みの実施にあたり、要件定義からプロトタイプの作成、顧客レビューのプロセスを短期間で繰り返し行うアジャイルなシステム開発を行いました。これにより、顧客ニーズを的確・適時的に反映することに貢献したと考えています。

今後の展開として、非競争領域(協調領域)における制御モデルの交換について、今回の1企業対1企業の取り組みをベースに複数企業対複数企業間の制御モデル交換ソリューションを構築することで実際の業務に適用できるシステムとして進化させていく予定です。

参考文献

[1]西村秀和「SEC高信頼化技術セミナー モデルベースシステムズエンジニアリング入門 ~システムを考えるハンズオンワークショップ~」、独立行政法人 情報処理推進機構、https://www.ipa.go.jp/sec/old/users/seminar/seminar_tokyo_20170113-01.pdf

[2]西村秀和監訳「システムズエンジニアリングハンドブック第4版」、慶應義塾大学出版会、2019

[3]ISO/IEC/IEEE 15288:2015 Systems and software engineering - System life cycle processes、2015

[4]Cole, B.,C. Delp, and K. Donahue. “Piloting Model Based Engineering Techniques for Spacecraft Concepts in Early Formulation.”, California Institute of Technology, INCOSE, 2010

[5]西村秀和監訳「システムズモデリング言語SysML」、東京電機大学出版局、2012

[6]自動車工業会デジタルエンジニアリング部会「OEM-サプライヤ間の電子制御情報流通のコンセプトモデルの紹介」JAMA電子情報フォーラム2020、http://www.jama.or.jp/it/event/jdf2020/report/pdf/jdf2020_pm_B_05.pdf

[7]Jonathan Rasmussen「アジャイルサムライ-達人開発者への道-」、オーム社、2011