マツダとパナソニック・オートモーティブの間でモデルを使った新たな取り組みが公表された。この情報はB to Bや学生、転職先を考えている方にぜひ読んでいただきたい内容だ。
この公表された2社の取り組みは2023年3月15日に「MBD推進センター」のシンポジウムで発表された内容で、それを個別に説明していただく機会に恵まれ、そこで語られた内容だ。
MBDの現状
まずはモデルベース開発の背景についてお伝えすると、車両、車両周辺機器開発に携わっている人は実感として感じているだろうが、SDV（Software Defind Vehicle）と言われる時代になり、ソフトウェアの領域は拡大している。
OEMからの仕様書は現在ワードやエクセルを使ったドキュメントでやり取りされていると思うが、2016年には約1億行あり、2024年には10倍の10億行にも達すると言われている。
その中には表現しきれないものや、言葉の誤解釈があって不思議ではない。さらに現場では「あいまい」なことも多く、手戻りするケースも多く経験していることだろう。
これは、かつてMBDの導入段階で言われていたことであり、MBDの本格導入によってこうした課題は解決方向にあると思うが、それは社内だけの話だ。サプライヤーとの共同開発といった領域では、再び、同じ課題を抱えてしまうわけだ。
そうした課題に向け、MBDの共通基盤をOEMとサプライヤーで持つことにより、課題解決と工数削減に繋げられる取り組みを実現したという具体例になる。
Vサイクル開発の流れ
OEMとサプライヤーとでは現在、要求内容の明確化がOEMの仕事であり、Tier1（サプライヤー）では、どういったアーキテクチャーで作っていくのかが検討がされる。そこで詳細設計が定義され、コーディングからテストを行ない、一つのユニットの中で正常に稼働することを確認し、OEMに納品。OEMは他のシステムと組み合わせて動くか確認しているという流れが多いと思う。
ベースになる仕様書はドキュメントだ。それを人が読んで理解し、詳細設計していくが、人的エラーは存在する。またサプライヤー側でも完成したものに対する内容報告もドキュメント・ベースであるため、OEM側も人が読んで理解する。または誤解釈が起こるといったことがあっても不思議ではない。
実際にあった失敗として説明されたのが、ナビで目的地までの距離がすべてkm表示だったことがあるという。つまり近距離になった時に0.1km表示よりは100m表示がベターであり、そうした指示が明記されていないため、手戻りとなったという。
こうした行き違いの発生する工程が上流であるほど、修正・対策工数は多く、実機テスト工程で不具合を見つけた場合より1.3〜1.6倍の工数がかかるという。つまり、ソフトウェアの要件定義の段階が重要であり、OEMの求める要求定義との擦り合わせが工数削減になると説明している。サプライヤー側でもOEMからの要求を分析し、システム設計、ブロック設計、モジュール設計としていく段階で誤解釈が生まれる可能性もあるからだ。
目指す姿として、人的エラーを防ぐことができるのがMBDであり、仕様書とシステムアーキテクチャーの設計段階で、モデルを共有すれば、名実ともに「動く仕様書」となり、さらに共通検証という環境となれば「あいまいさ」は排除できるわけだ。
とくに、海外サプライヤー、海外OEMとでは、言葉の違いはもちろん、価値観や文化の違いも影響しあうことが想像できる。そうした難しさはMBDによって解決でき、なおかつ共通基盤までたどり着けば、開発時間の短縮はもとより、あいまいさによる手戻りもなくなるわけだ。
車両モデルとIVIモデル
さて概念は伝わっただろうか。ここからはマツダとパナソニック・オートモーティブが行なった具体的な取り組みについてお伝えしていこう。かなり、踏み込んだ説明を受けており、貴重なスートリーだと感じている。
2社が開発したのはマツダCX-60に車載するIVI（in-vehicle infotainment）のマスターユニットの開発だ。
IVIは乗員に必要な情報や快適性、娯楽などを提供するもので、例えば、ナビゲーションやドライブレコーダーなどの外部機器も接続されるものだ。そしてこのIVIの領域は近い将来、ソフトウェアをサードパーティなどが開発したものが接続される時に重要なポイントになるもので、SDV（ソフトウェアで定義された車両）の要とも言えるものだ。
モデル交換仕様書
マツダとパナソニック・オートモーティブではそれぞれがSysMLという標準規格のMBDツールを使っているものの、マツダは要求仕様書、つまり上流の開発であり、システム設計に適したツールを使っている。一方で、パナソニック・オートモーティブは、その仕様書に基づく詳細設計を行ない、ソースコード生成までを行なうので、コード生成が得意なツールを使っている。
だから、マツダのモデルをパナソニック・オートモーティブ側で繋いでみてもエラーばかり発生していたという。その壁を乗り越えるために、サブセットを定義し、2社間の仕様書と位置付け、その定義＝規格で設計すればエラーはなくなり、双方で検証できるという「モデル交換仕様書」を作ったのだ。凄い！
タイミング検証
SysMLという標準規格のツールではあるものの、マツダは時系列のシミュレーション環境で、一方のパナソニック・オートモーティブはイベント・ドリブン環境だという。時系列と離散系/非同期系のシミュレーションであったため、同期信号をコマンドやレスポンスに変換してやり取りするが、やはり狂いは生じるため、タイミング検証ということも取り入れてMILS（Model in the Loop Simulatiion」にたどり着いたということだ。
これはかなり開発に苦労したと話をしており、ひとつの壁を突破し、モデル交換仕様書ができたことで、OEMとTier1のつながりはさらに強固になったとも言えるだろう。
そして共通基盤となるMBDにおいては、上流でもシミュレーションをしながら設計していくため、上流での工数が増えている。しかし、環境整備や人材強化により、将来的には工数が減っていくと説明していた。
具体的な課題としてはモデル交換仕様書の作成で苦労したように、開発ツールベンダーとの連携というのが存在していない、またモデルで設計できる人材が圧倒的に不足しているという現実があるという。
こうした課題を解決していくことで、グローバルで活躍でき商品力も上がり、チームJAPANのものづくりが高く評価されていくのではないだろうか。
こうした取り組みは企業にとって、開発時間の短縮や人的エラーの撲滅につながるわけで、場合によってはコンパイルも省く領域が広くなるメリットも出てくる。そのため、MBD推進センターでは共通基盤や共有領域を企業間で持つことを推進し、その結果、世界で戦える企業への成長につなげていきたいという狙いもある。
一般ユーザーとしては、こうしたMBDを一歩踏み込んだ技術が裏側で機能することによって、新しい体験につながる世界を容易に手にすることが可能になってくるということだ。B to Cという技術ではないが、クルマの進化はハイスピードで進んでおり、確実にその恩恵を得られることは明言しておこう。
