パートナー連携セミナー
「複合システムの開発支援で押さえておきたいポイント
〜自動運転システム開発支援を例にとって〜」
(オンライン開催)

2021年6月から11月にかけて、スパークスシステムズ ジャパンのパートナーと連携し、さまざまな情報を提供して参ります。第2弾は、インテグレーションテクノロジー様による「複合システムの開発支援で押さえておきたいポイント」です。

ご参加にあたり、Enterprise Architectの購入有無・サポートの有効無効は問いません。

セミナー内容

「複合システムの開発支援で押さえておきたいポイント 〜自動運転システム開発支援を例にとって〜」

昨年、国内自動車メーカーが、世界で初めて自動運行装置を備えた車両の型式指定を取得しました。さらに今年は、その車両が国内で販売開始となり、自動運転車両が社会に実装された年となりました。

これを受けて、創業当初からモデルベース開発によって、自動車を筆頭に各分野の開発や設計を支援してきた当社は、今後さらに加速すると見られる自動運転開発に対して、実務上想定される課題点を想定し、開発支援基盤の構築を進めています。

本講演では、複合システムの一例である自動運転システムを例にとり、背景や、想定される開発課題への支援の基盤として、現在進めているSysMLを用いた自動運転の概念整理についてお話しいたします。

ご講演者

インテグレーションテクノロジー株式会社 第２技術部 部長
小林 将之 様

2017年 インテグレーションテクノロジー株式会社（ITC）へ入社。 入社後は、電気精密産業を中心に主力事業であるMBDでのモデル構築業務に従事。その後、自動車産業でのシステムズエンジニアリング支援業務に携わり、現在に至る。

今回、新たな事業として自動運転開発支援を担当する。

録画

Q&A

セミナー当日にいただきましたご質問につきまして、ご講演いただいた小林様からの回答を掲載いたします。(当日に回答できた内容も含まれます。)

システムの要求と機能の関係付けはどのようにしていますか？また、機能はどこで抽出されるものなのでしょうか？

今回の説明では、細分化された各要求を実現するための要素として、各要求図にて機能を割り当てました。 説明の中盤でお話をさせて頂きましたが、一般的なSEプロセスでもレビュー済みの要求から機能を提案するようです。 例えば、"既定の時間内に目的地に到達すること"という要求に対して、"走行"機能や、"飛行"機能といった複数の案がでると思います。 個人的には、それらの複数案に対してコスト等のトレードオフを分析しながら、設計の幅を狭めつつ機能の深さを検討していくのだと考えています。

SysML以外に適切なモデリング言語はありますでしょうか？SysMLならではのメリットはありますでしょうか。

詳細な知識を持っていないため、明確な回答は控えさせていただきたく存じます。 私の知識の範囲内であれば、要求を階層的に表現することを得意とするUSDMという手法（言語ではありません）を存じております。 重ねての個人的な意見になり恐縮ですが、SysMLのメリットは、構造などが可視化される点にあると思っています。 情報をまとめられることと同程度に、コミュニケーションが取りやすくなることをメリットとして感じています。

システムの特性や分析、設計に対してSysMLは、ダイアグラム表記として、すべてをカバーできているのでしょうか？

回答が難しいため、明確な言及は控えさせてください。 個人的な感覚では、システム開発に必要な表現をするためのダイアグラムは揃っていると思いますが、 5番でも回答させて頂いた通り、SysMLに定義のない図（コンテキスト図）もあります。 すべてをカバーするというよりは、SysMLに定義されている範囲内で、開発にかかわる関係者が、 齟齬なく認識を共有するための表現をいかにするかが重要かと考えています。

自動運転システムにおいて、システムと外部とのインタラクション、および外部からの入力に対するシステム内部での制御仕様をどのようにモデル化してSYSMLダイアグラム表現しているのでしょうか？

システムと外部とのインタラクションについては、今後機能を深堀して検討を進める中で、 どのように外界からの情報を獲得するかが定まった際に改めて追加することを考えています。 外部からの入力に対するシステム内部での制御仕様も同様ですが、こちらは今回定義した概念的な機能群などを細分化して、 それらの作用として仕様が定まっていくものと考えています。ただし、実際の製品開発ではないので、本プロジェクトでは 仮説的な内容になるかと考えます。

コンテキストの図を内部ブロック図を利用したことに、どのような理由があるのか教えていただけますか？

コンテキスト図はSysMLダイアグラムに存在していないため、代替する方法で作成する必要がありました。 SysML 1.6の仕様書 "OMG Systems Modeling Language (OMG SysML™) Version 1.6"、 Annex Dの4.2章（p.241〜p.242）にコンテキスト図を内部ブロック図を使用して作成している 事例があります。今回はこちらを参考に作成いたしました。 特筆する理由はありませんので、表現しやすい方法で作成頂くのが良いかと思います。

ブロック定義図において機能とブロックとの関係、及び機能間の関係はどこかで明らかにしているのでしょうか？また、機能間の関係については内部ブロック図において明確にしているのでしょうか？

今回の例では、ブロック定義図におけるそれぞれのブロックは各機能そのものを表現しています。 また、ご質問のとおり、機能間の関係については内部ブロック図で表現しています。 概念的な表現でしたので、入出力の定義などがなされておらず説明不足な点がございました。誠に恐れ入ります。

今回の説明資料を後日入手することはできますか？（配布はありますか？）

確認の結果可能でしたので、セミナーに参加いただいた方に資料を共有させて頂きます。

車両状態管理はシステムとしての機能なのですか？

弊社の現段階の検討結果として、当該要素はシステムとしての機能に含みました。 今後、次の詳細度レベルでの検討や、お客様からのフィードバックによってはシステムの外部にする可能性もございます。 概念レベルで詳細度の低いダイアグラムではありましたが、可視化されることで今回のような疑問点やご意見などを頂けることがわかりました。 ご質問ありがとうございます。

自動運転システムの制御モデル、プラントモデル、共にSysMLで設計しているのですか？

制御モデルに関しては、将来的には"Yes"となる、と考えています。 現段階では概念レベルでのシステム検討であるため、具体的な機能を検討出来ておらず、設計とは言えない状況です。 今後、詳細度レベルを上げた検討では、Autowareを中心に実際に駆動している機能を参考に検討を進めますので、 設計を最大の目的にはしていませんが、結果的に制御モデルをSysMLで設計する形になるかと考えています。

p.19で、対象システムが乗員車両複合系ならば、uc図の境界内に乗員アクターを入れるべきではないでしょうか。

貴重なご意見、誠にありがとうございます。 弊社の現段階の検討結果として、乗員には運転手以外の役割もあると考えて、システム外部のアクターとして表現しています。 したがって、"乗員車両複合系"という境界の命名が適切でないことに気づきました。 別途、今回は自動運転システムに焦点を絞った検討ですが、MaaSなどのさらに大きな複合システムを考慮するため、 アクター”乗員”を拡張点ととらえて頂ければ幸いです。

SysMLモデル設計とシミュレーションへシームレスにつなぐ検討をされていたりますか？

現段階では概念レベルのため具体的な計画はございません。 個人的には、Enterprise Architect にも MATLAB/Simulinkと連携する機能が追加されましたので、 さらにシステムモデルの詳細度が高くなった際に、シミュレーション側へつないでみたい希望はございます。

ucとしては、どのような運転シーンを想定されていますか。

今回のユースケースとしては、従来車（非自動運転車）では、私たちが普段、一般道で車を運転しているシーンを想定しました。説明不足で誠に恐縮です。 自動運転車では、そのユースケースのうち、今回はドライバーの行動をシステム側へ置き換えました。 SAE Level 3以上を目的に検討を進めましたが、結果的にはSAE Level 5に近い、文字通り自動運転の概念を表現した形になったかと思います。