News and Views 2016 Spring / Vol. 17: オートモーティブ

自動車EEアーキテクチャのためのモデルベースシステムエンジニアリング

はじめに

2015年12月に名古屋と品川で開催されたIESF (Integrated Electrical Solution Forum) 2015 Japanでは、その基調講演において、自動車の電気電子(EE)設計に向けたモデルベースシステムエンジニアリングのアプローチが紹介されました。このアプローチは、ソフトウェア、ハードウェア、ワイヤ・ハーネス、ネットワークなどをすべて含んだ車載システムのエンジニアリングをコンピュータ上で行う手法で、数多くのメディアに取り上げられました(マイナビニュースより一例)。

そもそも「システム」という言葉はその定義が曖昧で、人や状況によって捉える範疇が異なります。半導体にマイクロコントローラが実装されたとき、チップ上にシステムが構築できるという意味からSystem-on-a-Chip(SoC)という言葉が生まれました。このSoCをプリント基板(PCB)に実装した組込みデバイスは組込みシステムと呼ばれます。また自動車のように、走行システム、操舵システム、ブレーキシステム、運転支援システムなど、複数のシステムによって構成され、それら個々のシステムが複雑に連携し合う大規模システムをSystem of Systems(SoS)と呼ぶことも多いようです。

図1. システムエンジニアリングの重要性を解説するメンター・グラフィックスのMartin O’Brien図1. システムエンジニアリングの重要性を解説するメンター・グラフィックスのMartin O’Brien

「Systems Architecting: Creating and Building Complex Systems」の著者であり、米国における航空宇宙システムの権威であるEberhardt Rechtin氏の談に、「1つのシステムとは、1つの構造体または異なる要素の集合体から成り、それらが一緒になることで単体の要素だけからでは得られない結果をもたらす。システムの価値とは、主として構成要素間の関係、つまり構成要素がどうつながるかによって実現される」とあります。単にECUとそのネットワークという分断された見方ではなく、ハードウェアやソフトウェア、ネットワーク、ワイヤ・ハーネスなどの構成要素がそれぞれどのように接続されているかを俯瞰できることが、システムエンジニアリングにとって大切であることは言うまでもありません。さらに、「複数の構成要素とそのつながりとして行われた設計の意志決定の是非が評価できることが重要である」と、IESFでは説かれていました。

図2. 異種ドメインを俯瞰するシステムエンジニアリング図2. 異種ドメインを俯瞰するシステムエンジニアリング

自動車のEEアーキテクチャ開発における課題

前出の通り、車載EEシステムは、ハードウェア、ソフトウェア、ネットワーク、ワイヤ・ハーネスなどといった異なる設計要素から構成されますが、個々の構成要素が統合されて初めてシステム全体としての実装が成されたことになります。しかし、ソフトウェア開発にはその道に応じた経験値が求められ、ワイヤ・ハーネス開発に求められる経験値とはまったく異なります。それぞれの設計担当は、通常、専門性と経験値に基づく「ドメインエキスパート」の集合として組織化されています。そこで、例えばマイコンの処理能力不足に伴うECU追加を検討する際には、ネットワーク負荷とワイヤ・ハーネスの製造コストへの影響を含めた検討が欠かせないため、組織を超えて異なるドメインエキスパートを集約した上で、膨大な作業と時間が求められることになります。設計総時間の半分以上が度重なる仕様変更や実装変更に費やされているとも言われている昨今、真の意味での「システム」を俯瞰した意志決定を図る方法が存在しないのが実情です。加えて、自動車の幅広いオプション装備やバリアントへの対応も問題の複雑化に拍車をかけています。

現状、ソフトウェア、ハードウェア、ネットワーク、ワイヤ・ハーネスの異種ドメイン間は、MicrosoftのWord、Excel、PowerPoint、Visioなどを用いて緩やかに連携しているものの、ドメインを超えた検討や影響度解析が行えるほどまでは緊密に統合されていません。今求められているのは、車両1台分のソフトウェア、ハードウェア、ネットワーク、ワイヤ・ハーネスの全領域を俯瞰しつつ、設計の初期段階から取り組むことのできるシステムエンジニアリングの手法なのです。

機能モデリング

各ドメインには、固有の設計プロセスやアーティファクトが存在します。異種ドメインを扱うには、システムアーキテクチャの技術的なコンテンツを機能抽象レベルの機能モデルと、個々の機能間の通信手段 — すなわちソフトウェア信号、電気信号、バス信号など — を用いて表現します。オプション装備やバリアントなどは、一定のルールに従って機能モデルへと関連付けます。このアプローチの概念を図3.に示します。

この機能モデリングのアプローチでは、ソフトウェア、ドライバ、センサ、アクチュエータを単一の抽象レベルで表現しています。また機能間の信号は、それぞれの実装ドメインに応じて示されます。このアプローチを衝突予防の警告を発するADASシステムの機能設計に適用した例を、図4.に示します。

図3. 異種ドメインを含む機能設計のアプローチ図3. 異種ドメインを含む機能設計のアプローチ

図4. 機能モデルを用いたADASシステムのダイアグラム図4. 機能モデルを用いたADASシステムのダイアグラム

論理プラットフォームと自動合成

図5. 論理プラットフォームへの機能割り当て図5. 論理プラットフォームへの機能割り当て

機能設計を正しく表現できれば、その下流となる実装設計を自動化でき、装備オプションやバリアントへの関連性を考慮することが可能となります。その基盤となるのが、論理プラットフォームです。これは、3次元の物理トポロジから自動的に導き出すことも、抽象化された論理ネットワークトポロジから開始することも可能です。各機能コンポーネントをオプションやバリアントへと割り当てることで、異なるオプション装備を含む車種に対して適用できます。

次に、論理プラットフォームに対して機能を割り当てていきます。これは、手動で行うこともルールベースで自動割り当てを行うことも可能です。割り当ての際には機能タイプも合致させます。機能タイプがソフトウェアの場合、AUTOSARなどで用いられるソフトウェアコンポーネントが作成され、制御ユニットへと割り当てられます。ワイヤ・ハーネスへの割り当ても、図5.に示すように配線自動合成技術を用いて自動化されます。

このように機能設計と論理プラットフォームの定義、およびルールに従ったEEアーキテクチャを自動生成する手法を、メンター・グラフィックスでは「Correct-by-Construction」と呼んでいます。これには、「構築することで正しい結果が得られる」という意味があります。手作業が介入する工程にはDRC(設計ルールチェック)を実行することで、設計の正しさを保全できます。

評価指標による意志決定

図6. さまざまな評価指標図6. さまざまな評価指標

論理プラットフォームから電気電子アーキテクチャを自動合成させることにより、制約やルールを変えて複数のアーキテクチャを探索できるようになります。アーキテクチャの判断に必要となるのが評価指標です。多重ネットワークであれば負荷、許容差、スループット、オーバーヘッドなどが評価指標となります。ワイヤ・ハーネスであれば、ワイヤ重量、スプライス、コネクタ数、バンドル直径、コストなどが評価指標となります。制御ユニットであれば、デバイス重量、CPU負荷、メモリ要件、PCBと筐体のハウジング条件、発熱量などが評価指標となります。この評価指標は、過去の設計ノウハウを用いて信頼性、再利用性などへと拡張することも可能です。評価指標の例を図6.に示します。

従来の開発手法ではソフトウェア、ハードウェア、ネットワーク、ワイヤ・ハーネスなどを異なる部門や企業が個別に開発して最終統合した際に初めて明らかとなる評価指標を、モデルベールのシステムエンジニアリング手法を適用すれば機能設計の早い段階から知ることができます。この手法で導き出される評価指標はリアルタイムで得られるため、設計上の判断や設計変更がアーキテクチャ全体に及ぼす影響、代替実装案の素早い評価などが可能になります。また、複数のアーキテクチャを探索し、早い段階から正しい意思決定を行うことができるようになります。もちろん、評価後の論理プラットフォームからの合成結果はそのまま下流の詳細設計へと引き継がれ、その際に使用されるデータは各ドメイン個別のフォーマットを遵守しています。

まとめ

メンター・グラフィックスでは、モデルベースシステムエンジニアリング手法を実践する電装システム設計ソフトウェアを、Capitalツールスイートとして提供しています。Capital Systems Captureは、複数ドメインからの抽象レベルの機能モデリングとダイアグラムによる機能設計をサポートします。Capital Systems Architectureは、機能モデルから論理プラットフォームを構築し、論理面、物理面の双方から実装へと自動合成します。Capitalは、「Correct-by-Construction」のアプローチを実践し、リアルタイムで生成されるさまざまな評価指標を用いてアーキテクチャを評価探索し、設計と設計変更への正しい意思決定を支援します。