Comments
Description
Transcript
SysML による機能要求の分析と評価検証のためのモデリング
講演 西村 秀和氏 それではわたしの方から、 「SysML による機能要求の分析と評価検証のためのモデリング」 という内容で話をさせていただきます。 先ほどの前野研究科委員長の話からすると、少し下界に下りたような話になりますが、ど うぞお聞きください。 まず内容的には、モデルベースでシステムズエンジニアリングをどうやって進めて行く のかということの全体的なお話を最初にさせていただきます。 特に、最初に、VISUALIZING PROJECT MANAGEMAENT という狼元研究科委員長がお話しした 書籍にある Dual Vee についてお話をさせていただきます。 それから SysML というのを使うということをわたしたちは今、推奨しているのですが、 モデルベースでやって行く時に、最初に比較的上流の工程でやる要求の分析のあたりの話 をさせていただき、事例として二輪自動車、バイクですが、バイクに対してある制御シス テムを追加するような時にどんなふうに考えていくと良いかということを紹介させていた だきます。 それから２つ目の例は、比較的最近はビデオカメラですとか、皆さんお使いのノートパ ソコンなんか小型化していますが、そういったコンシューマーエレクトロニクスのシステ ム開発を進めて行く上でどんなことに注意していくことが必要かということを、SysML の観 点でいろいろ考えたことを紹介させていただきます。 まず最初の Dual Vee とか、あるいは Entity Vee というあたりをお話させていただきま す。Vee モデルというのは皆さんソフトウエアの中でもいろいろ使われていますので、もう 既にお分かりかと思いますが、こういったことはビジュアルにしっかり描いておいて、自 分が一体どこを今、担当しているのかということを把握することが非常に重要なことでは ないかなと思います。 まずこれは、Dual Vee と呼んでいるもので、この黄色の部分が Architecture Vee という Vee モデルです。それから立体的に描いているんですが、手前にまた Vee が出っ張っている ようなイメージです。黄色の方の Architecture Vee は、Architecture をシステムからサブ システム、コンポーネントへ分解するのと、右側の Vee では統合していくという過程が示 されています。 こういう形で表現するというだけだと思われがちですが、実はこの手前に出っ張ってい るこの Vee はそれぞれが Entity Vee になっています。これは皆さん良く使う Vee Model だ と思うのですが、それぞれのレイヤーでこんな Entity Vee が動いているんだということは、 実は単に分解をしてそれぞれの Entity Vee を動かせば良いというものではなくて、上下で のやり取りというのが必ずあるはずなのです。そういったことが今、どこでどんなことが 起きていて、どういう状況にあるのかということをこの全体で把握しておくと、比較的分 かりやすいというか、トラブルなども防げるのではないかというふうに考えています。 1 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved. 例えば、全体のシステムとしてある大きなシステムがあって、それを Eytity Vee で始め て行く時に、最初のコンセプトの段階から、もちろん最初に利害関係者の要求というのを 把握するということがありますが、ある程度のアーキテクチャが決まってきて、サブシス テムやコンポーネントへそのシステム要求を落としていくということをするフェーズがど んなところに落ちて行くかということです。いきなりコンポーネントまでその要求が行く のかと言いますと、そうではなくてサブシステムに一度落ちてしてからまたコンポーネン トに行くかもしれないし、場合によっては本当に直接コンポーネントへ何か要求が落ちる かもしれないということです。 あるいは、インテグレーションのフェーズでも、コンポーネントが出来上がって、上に 上がって来てサブシステムができて、それをさらにシステムに上げて行って、インテグレ ーションして検証して、妥当性確認というフェーズが起こるはずです。 そういったことを少し頭の中で概略はつかんでいると思うんですけれども、それを明確 にすると良いのではないかと思います。もちろんこのサブシステムやコンポーネントの所 にはソフトウエアやいろいろなハードウエアも含まれているわけです。 それで特にこの Entity Vee として最初の段階には、①Operational view と書いてありま すが、システムがどんなシナリオで動いているのかというようなところを表します。そう いったところには利害関係者が必ずいて、その人たちが何を要求しているのか、システム がどのように動けば良いか、というようなことが定義されます。そういったところから要 求が明確化されるはずで、そういったことを実現するようなシステムはどのようものでし ょうかということで、概念設計とかアーキテクチャになります。アーキテクチャも幾つか の代替案があって、それを何かの指標で選定していくフェーズがあります。 この辺では、まだ具体的なものというのはまだ見えてない可能性があり、Functional view として見るということになります。これはいわゆる機能が明確化するようなところです． これが明確になりますと，さらにサブシステムやコンポーネントへ持って行く仕様が決ま ってきて、そうすると Physical view というのが明確に出てきます．このようにして，①、 ②、③という view としての段階を経る、プロセスを経るということになります。 その３つの view、視点は非常に重要で、アーキテクチャの３つの視点と言っていますが、 Operational view では今言いましたように，システムはどんなふうに、どのように使用さ れるのかということです。Use Case Scenario とか、そういうある種の Operational Scenario というのを描くわけです。今、開発しようとしているシステム、設計しようとしているシ ステムが外部のシステムとどう関係しているのかと、どのような相互作用をするのかとい うこと。これは非常に大事なところです。 それから Functional view では、今、開発しよう、設計しようとしているシステムの内 部で「何を」しなければならないかということが大事なわけです。「何を」というのが、実 は機能、サービスあるいは提供するべき機能ということになります。あるいはシステムの 内部のあるブロック間のインタフェースというのが実はほぼ機能というふうに定義できま 2 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved. す。 最後に Physical view で、機能を遂行するためのハードウエアやソフトウエアを定義す るということです。この段階で初めて、一部はハードウエアで実現し、一部はソフトウエ アで実現するというような区分けが出てくるはずで、そうするとそういうモジュール間の、 あるいはアイテム間のインタフェースをどうするかということが明確になります。 今言ったことが，このスライドには同じようなことが書いてあります。要求を明確にす る、初期の段階で Operational view が重要ですということです。最初にこれをやらないと 一体何のためにシステムを開発しているのかということが分からないわけです。 あるいは問題を浮かび上がらせるということも大事で、まだ明確にこれを開発するとい うことが決まっていない段階では、一体何が問題だったのかということが、実はこのフェ ーズで分かるはずです。また，さらにそこで考えたシナリオというのは、ここの Verification and Validation Planning という Planning がこちらのフェーズからこうやっ て来ています。ですから、ここで考えているシナリオというのは、実は、後で検証や妥当 性確認をする時のテストケースとして使えるはずですので、非常に大事です。 それから Functional view に持っていくのですが、機能として何が必要かということを 考えなければいけないわけです。緑色で書いておいたのですが、わたしはもともと機械屋 なものですから、「システムでこういう問題があります」と言われると、すぐに「それはこ んな物理的なものでやればできるでしょう」と言って、ソリューションを出してしまいが ちです。しかしそれは、相当天才的な人か、あるいは相当な熟練の人でしたらそれは本当 に正しいソリューションかもしれませんが、必ずしもそうではない。もっとうまいやり方 があるかもしれないので、それは一体、機能としては何を実現すれば良いのかということ をまずは明確にし、それから物理に持って行くことが大事です。もちろん最初からどうし てもこの物理的な要素を使ってやってくださいということでしたら、それは制約として考 えるということになります。 ということで、このような３つの View で進めて行くのですが、わたしの比較的専門で機 械屋としてあるいは制御屋として進めて行くという面では、最初のこのあたりは SysML と いうモデルベースシステムズエンジニアリングのためのツールがあって、それからまだも のがない段階の Functional view のあたりでは、どうしてもシミュレーションなどでいろ いろ検討をしなければいけないです。MATLAB/Simulink、あるいは最近では Modelica Language など、そういった物理的な現象をシミュレーションできるような言語もあります。 そういったものをうまく活用すると良いです。こういった Physical な view でものができ てくると、どうしても CAD の世界になるだろうと思います。あるいはソフトウエアの世界 ではプログラムをコーディングするというようなことになると思いますが、当然、それぞ れに仕様が与えられて設計していくことになります。 概略、今、お話ししたのですが、ではどのように機能要求の分析をしていくのでしょう か？SysML というのはもうご存知でしょうか。SysML のダイアグラムにはこのようなものが 3 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved. あります。UML に対しては要求図やパラメトリック図が追加されました。わたしはこれらの ダイアグラム全てをうまく使いましょうということを実は言っていません。必要に応じて 使えば良いのではないかと考えています。これはわたしだけが言っているのではなくて、 文献 Practical Guide to SysML にもそのように書いてあります。SysML の導入をお勧めす ると良く言われるのですが，細かいダイアグラムを一々書いているような時間はないと。 私は，そうではなくて，必要な粒度で記述するべき内容に応じて SysML のダイアグラムを 使えるのではないかと考えています。 例えば、これも実は先に挙げた文献の最後の方に図が載っていて、そこから持ってきて いますが、構造を表すもの、それから振る舞いを表すもの、これは要求図、それからパラ メトリック図。これが非常にわたしは有力だと思っていて、パラメトリック図の存在がな ければ，恐らく私は SysML に食い付いていなかったかなと思います。パラメトリック図は 大変有効だと思います。 構造が明らかになり、それからどんな振る舞いをするのかということが明確に図に描け て、それらはどのような要求から来ているのかと、関連付けるわけです。自動的な関連付 けがあるかどうかはツールに依存しますが、絵的に関連付けを手動でやっても良いと思い ます。 それからこのパラメトリック図ですが、数式の表現とか運動方程式という制約をこのダ イアグラムに入れることができます。図的にこれれらの制約を表現できます。例えば、力 学的な問題で言うと、運動方程式、あるいは支配方程式は，システムが拘束されています。 方程式にシステムが拘束されているということで、その範囲でしか動きようがない。そう いうことを描くことができるわけです。 ということは、このダイアグラムの中で，シミュレーションができて、ある入力に対し て，システムがどのような応答をするのか、出力が出て行くのかということが、この絵で 描けるということです。 SysML 自体は executable ではないので、何らかのシミュレーションのできるツールとう まく連携させて実行させるということが必要です。そうしたうまい表現ができますという ことが非常に有効だと私は思います。 このスライドも先の文献に書いてある図ですが、少し修正しています．このシステムの モデルを、Dual Vee で言う最上位のシステムレベルで記述してあげて、ソフトウエアのモ デル、あるいはハードウエアのモデルとうまく連携してやり取りすると良いと言っていま す。良くありがちなのは、メカ屋の方からすると、システム全体はこんな感じで、最初に ハードウエアを作り上げてしまって、それで困ったら「ソフトウエア屋さんにお願いしま す。」といったことがあるようです。そういうことをしては駄目ですと言っています。しっ かりとシステム全体としてモデルがあり、ソフトウエア、ハードウエア、それに両者の関 係も含めて、そういった関係性がしっかりとシステムとして記述してあるということが重 要です。このあたりが非常に SysML ではやりやすくなります。いわゆるコンカレントエン 4 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved. ジニアリング，協働作業を進めて行く上で非常に有効なツールだと思います。 くどいかも知れませんが、そういったことを具体的にやっていく時に外部からの要求を しっかりと把握する。このへんがわたしは比較的専門ですけれども、あるいは解析をする のでしたら、どのような解析をする必要があるのかということに応じて、適切なツールを、 適宜連携することができるというわけです。それからもっと詳細なレベルに行って、CAD な どとの連携が取れるはずです。わたしは大学にいる者ですから、あまり詳細な設計までは しないので、なかなかこういうところは具体的にやりませんが，，， 例えば CAD の設計を進めて行くと、どうしてもシステム仕様というのは、詳細なところ は多少の変更がある可能性もあります。大きく変更するということがない場合でも，シス テムがより詳細化されて行く過程でパラメータの変更があるかも知れません．そうした時 に，もともとの要求とどのような関係性があって、そのパラメータが詳細化されて行くの かというトレーサビリティを確認できます。場合によってはパラメータの数値が最初考え ていたものとは少し違っているが、それは大丈夫か？ということがあると，もう一度それ をチェックできると良いわけです。その場合，こちらにある解析ソフトを使って、そうい う変更による他のサブシステムへの影響をチェックできます。そういう連携がこの SysML を中心にしてできるということをこのスライドは表しています。これは非常に有効ではな いかと思います。これを完全に使いこなしているところはまだないと思うのですが、こう した考え方はこれからますます普及して行くのではないかと、思っています。 それで Operational view で考えたことは、非常に重要であるということを先ほど言いま したが、Operational view で考えることはどのようなシナリオで何が起きるかということ です。こういう入力が入った時にはこのような出力があれば良いのですねというようなこ とが明確になってくると、それは当然、検証や妥当性確認というようなフェーズで使えて 非常に有効です。 それで、たとえばソフトウエア側から言うと、ソフトウエアは出来上がりました。しか しハードウエアはまだちょっとプロトタイプぐらいしかないという時に、そういう状況で もソフトウエアとハードウエアをうまく組み合わせてシミュレーションをやりましょうと いうことになります。Hardware In the Loop simulation、あるいは Software In the Loop Simulation です。あるいは人，オペレータが関与して、操作をしてみてうまく行きますか ということを、先に Operational view で決めたシナリオに基づいてやってみる。そういう プランニングの関係性、これが非常に大事です。 それからよく言われるのは、ノミナルだけではなくてオフノミナルを考えるということ です。想定外というのはなかなか難しくて、想定されていない状況を考えて設計するのは 難しいわけです．想定外と言いながらある程度、想定しているわけですけれども、でもそ ういう通常の使い方ではない時でも大丈夫か？ということをしっかりと考えておいて、そ れをこのフェーズで試してみるということです。特に人が操作するような時には、思って もいないよう操作をしてしまうことがあるので、そこは大変重要なところです。 5 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved. そんなことを最初の左側の要求のフェーズで順番にやって行く時に、これは後で例題と して示しますが、最初に言いましたとおり、外部システムとの関係をコンテクストレベル でしっかりと考えましょうということです。この時，ユースケース分析をして，振る舞い の分析をして，機能の分析をするという順番でやって行く。そして，さらに内部に入って 行って、同じようにユースケース、振る舞い、機能とやって行きます。これを繰り返して どんどん詳細化し、システムを分解して行く、サブシステムやコンポーネントはどのよう な機能を持っていれば良いのかということが明確になります。 こうしたことを二つの事例でお見せしたいと思います。特に今、お見せした要求分析の ところはこの１番目の事例です．ものを見た方がやはり分かりやすいと思うので、お見せ ます。 バイクというのは安全な走行はもちろんできているのですが、どうしてもやはりライダ ーのスキルに依存するところが大きいです。うまいライダーは、わたしが提供しようとす るような制御システムはいらないと言われるのですが、けれども必ずしも最初からうまい わけでなく最初は下手な人もいます。そうしたライダーが何かしらの突発的な外乱を受け てしまったらどうなるのか？例えば、路面上に何か物が転がっていて、ステアリング周り にドンとインパルス状の外乱を受けてしまったとします。あるいは、何か旋回というかカ ーブを回っている最中に急に凍結した路面に入ってしまい、安定性を失ってしまうという 場合、うまいライダーならば何とか立て直しができるかもしれません。しかし，スキルの 低いライダーには，制御で何とかできないでしょうかというような問題設定をしたとしま す。そうしますと、いろいろ考えてみて、既に四輪のいろんな知見があるので、ABS （Anti-lock Brake System）が良いのではないかとか、Traction Control をやれば良いの ではないかとか、いろいろとアイデアが出てきます．これらは実は既に市販のバイクに実 装されています。 まだメーカーがやっていないのは、パワーステアリングみたいに前輪操舵をアシストす るシステムです．わたしはこれをずいぶん前に提案して、これはその時の実験装置なので すが、走行実験をやってみました。 これを SysML の要求分析のあたりで考えてみたらどうなるかということを、今日、示し たいと思います。 これはユースケース図です。当然、お分かりだと思います。この赤で囲った部分が開発 範囲です。開発範囲を限定するわけです。中に入っている赤い丸が機能を表します。前輪 操舵アシスト制御システムというのを開発しようと決めて、これはもちろん要求としては ライダーが不適切な操作をしたとしても、バイクが安定化されるようにするといった要求 があって、その中でいくつか代替案が出てきて、先の ABS や Traction Control と比較して これを選定したと仮定します。 では一体、どのような機能を提供してあげたら良いでしょうかというのはまだ明確では 6 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved. ないです。もちろんある程度分かっているのですが明確ではないので、それを SysML で考 えましょうということです。 開発する対象と、それから、アクターが周りにいる絵になっていますが、これらは外部 のシステムです。外部のシステムとの関係性は一体どうなっているのでしょうか？という ことを見ると、既存の車両に搭載するということです。バイクは既に何らかの開発された モデルがあって、そこに新しいシステムを追加するということです。あるいはバイクはラ イダーが乗る。それからバイクは路面上を走ります。こういうことが書けるわけです。当 たり前じゃないかと言うかもしれませんが，これらを明記することで，さまざまな問題が 浮かび上がります． それから既存車両には、後輪フレーム，前輪フレーム，前輪，後輪がある。それからラ イダーの体の動きを考えるとしたら、上肢、下肢があります。もちろん、路面とタイヤの 間には摩擦があり、路面の µ は状況によっていろいろ値が変わるでしょう。 後々シミュレーションすることを考えると、こういうライダー、既存車両があることを 考えると、力学モデル、そのシミュレーションに使うようなモデルとして，ライダーとバ イクの何かしらの連成のある力学モデルというのが必要であって、そこに制御システムが 搭載されるということがこのユースケース分析をすると見えてきます。 それから先ほどコンテクストレベルでのユースケースとして前輪操舵アシスト制御とい う機能があがったわけですが、それをシーケンス図を使って詳細化してみると、 「車体を安 定化させる」という機能が大事であることがわかります。これは当たり前です。もともと 不安定になるのを安定化しましょうということです。こういうシステムを考えているので シーケンス図に現れるのです。 機能のコンテクストレベルをブロック定義図で表現してみると、前輪操舵制御システム のブロックがあって、それと車両とライダーの関係性が見えてきます。車体に対して「安 定化する」というインタフェースがあります。ここでインタフェースというのはこのブロ ック間の間をつなぐという意味です。インタフェースとして「車体を安定化させる」とい う言葉が出てくるのです。これはこのシステムが持っているべき機能です。当然、外部の システムに対して、こんな機能を提供していますということが分かります。 ということで、これをもう１回クリックすると、この機能をもう少し分解してあげるこ とができ、「車体を安定化させる」というのが一つ出てきました。今、これしか書いていま せんけれども、これ以外にもたくさんあって、レーンチェンジの時でもライダーをアシス トする、旋回中でもライダーをアシストすると、そうした機能がたくさん並びます。実は それは、シナリオを考えているようなもので、どんなシナリオでこの制御系を機能させる 必要があるのですかというようなことが非常に分かりやすくなります。 こういうのは，一人でやっていてもなかなか描けるものではなく、やはりいろんな人た ちとコンカレントにやらなければいけません。ライダーにも来てもらい、バイク開発者、 それからソフトウエア開発者もやって来て、「どのような機能が必要か，そのシナリオは？ 7 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved. どのようなシミュレーションで検証するか？」などを考えながらダイアグラムを作ってい くと良いです。 そのシーケンス図をもう少し詳細に描いたものはこれです。FACS というのが、今、開発 しようとしているシステムで、ライダーがもちろん車両に乗って FACS を使うのですが、路 面もここにあります。例えば、ライダーがレーンチェンジ操縦をします。ライダーはレー ンチェンジ中に路面の状況を確認しながら運転していますが、外乱を受けたということで す。レーンチェンジをやっている最中に、ドンと前輪のハンドル周りにトルクを受けたと いう場合です。こうしたときにライダーはすぐには反応ができないということを仮定して います。うまくすぐに切り抜けられるライダーは良いのですけれども、そうではなく先に この FACS というコントロールシステムが車両を安定化させてくれて、ライダーは後から外 乱を受けたことを認知して、何かしらの操縦の調整をするのですが、その前にシステムが ライダーアシストをやってくれているので、ライダーが気が付かないうちに車体は立て直 されているということです。「わたしはうまくなったのかな？」とライダーに思わせる、そ んなことをシーケンスとして書いています。本当にできるかどうかは，制御系設計をしっ かりとやることによりますが，こんなことを描いていくということが、実は後でシミュレ ーションをやる時にも非常に重要になります。 今言ったことを進めて行くと、いろんなインタフェースが出てきます。さっき言いまし たが一番下の Stabilize Motorcycle、これが車体を安定化させるということです。レーン チェンジ中でもアシストするとか、旋回中でもアシストするというのがたくさん並んでい ます。この FACS というシステムが提供するべきインタフェースは何かということを明確に できるということです。 これも先ほど言いましたが、既存車両とライダーが関係するので，力学モデルは必要で あるとか、ライダーが操縦すると言っています。路面上で車両が走行していて、ライダー が運転します。そうすると路面の状況をライダーが認識し、どのような操縦をするのかと いうことを明確にしたいので、ライダーの操縦モデルが必要になります。ブロック定義図 を描いてみるとこうしたことが分かってきます。 それから先ほど「分解」と言いましたが、このコンテクストレベルの機能をアナリシス レベルで分解してみると、テストケースが得られます。ユースケース分析をした結果とし て、どんなテストをしなければいけないというのが並び，これはテストケースとして使え ます。もちろんこれだけでは何をテストするべきか明確ではないのでもっと詳細化しなけ ればいけませんが、こういう状況でテストすると良いことが分かります。 それからこれは先ほど FACS とと外部との関係でブロック定義図を書きましたけれども、 内部をもっと明確にしていくということが必要です。コントローラーが、測定して制御器 の実行をする CPU があって、A/D 変換，D/A 変換を構造的に書いていますが、実はサーボモ ーターというのを動作させて前輪操舵軸を回すというようなことが記述されています。も ちろんどんな機構であるかということを決めていかなければ出てきませんけれども、そう 8 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved. いうことがこのような絵を描くとわかってきます．実は内部のシステムがこの赤で囲った 部分で、開発範囲外にある既存の車両の中の前輪操舵軸にサーボモーターでトルク入力し なければいけないということがわかります。機構的には明確ではないですが、こういう図 を描いて、この部分で外部と関係していることがわかって，何かしらの方法でトルクを伝 達することが必要ということがわかります。その一つの形として、この写真に示すような ことが考えられます。プロトタイプとしてですが，前輪操舵軸に直接モーターを取り付け， ガソリンタンク側に固定するという形です。これに乗って時速 30km くらいの低速領域で、 実験をやりました。バイクというのは比較的低速の方が不安定で、こういう時に前輪操舵 軸周りにトルク外乱が入った時でも安定化できることを実験でやってみたということです。 それで実験で全部できれば良いのですけれども、ライダーが乗ってレーンチェンジをや って，外乱が加わるというのは危険です。そうするとシミュレーションに頼らなければな らない。そこで，このパラメトリック図が有効です。先ほどから言っている力学モデルと いうのがここにあって、これは一生懸命マルチボディダイナミクスなどいろんな手法でモ デル作りしなければいけないのですが、その専門家がやってくれれば良いです。そして， 制御屋さんがやって来て、制御器を作りましたということです。そうすると、ソフトウエ アさんは「これを実現するソフトウエアを CPU に実装しなければいけないのですね」と言 うわけですけれども、実装するようなソフトウエアを作ったら、「テストする時はこのルー プでテストしてください」と。ライダ－の操縦モデルは専門領域の方に作って提供しても らいます。ライダーは操舵トルクを与え、リーントルクを与えます、外乱はここからこの 大きさで入りますという条件がそろって、テストができるわけです。 それから評価指標もここに並べておいて、これらを満たしているかどうかチェックしま しょうとなります。これをいろいろな専門分野の方々に配って、「これでテストしてくださ い。それで OK だったら受け取ります」ということができます。 それで、例えば、妥当性確認をしました。走行中に、3.6m 幅のレーンチェンジをしたと いうことです。時速 60km で、インパルス外乱は 25Nm で０秒から始めて 0.7 秒から 0.88 秒 の間にこういうトルク外乱を与えられて、ライダーが未熟練ライダーなので、補償動作は 外乱が入ってから 0.3 秒後にふと我に返って始めるということです。0.3 秒間は何もできま せんでしたということを想定して、アシスト制御は外乱が入ったらすぐに動作するという、 そんな仮定でやった時に、うまいライダーは青の点線で制御しなくてもレーンチェンジが できます。制御なしの時の未熟練ライダーは点線で，転倒します。ロール角は－30 度、－ 40 度とずっとそのまま増加するのでこれは転倒に至ります。ですが、制御すると、この赤 い線のように少し振動的ですが、何とかレーンチェンジの方向には行ってくれることをシ ミュレーションで示しています。こういったことを検討して，SysML はある程度使えるので はないかと考えています。 それから違う事例として、コンシューマーエレクトロニクス全体の開発においていろん な手戻りが起こるので、SysML の手法をうまく使って解決できないかなということをトライ 9 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved. した事例です。 これはあるメーカーのコンシューマーエレクトロニクス開発に携わる方と一緒にやって いる事例です。細かい話は今日はカットしてありますが、こうした機器の開発では，国際 的な分業が進んでいます。昔はある敷地内に建物がたくさん並んでいて、いろいろな部署 があったので，開発で困ったことがあればお互いに集合して、これはどうするああすると 言って大体問題は解決したと言っていたそうです。それがなかなかそういうのは許さなく て、たとえば，一部は台湾，一部は中国に外注となっていて，国内では，九州で分業をし ています。 システム全体の開発はたとえば，東京の本社ビルでやりましょうというようなことで開 発を進めて行くのですが、国際的に分業すると，どうしても手戻りが発生します。「本当は この期日までにデリバリーしたかったのだけれども間に合いませんでした」とか、「そのた めにコストがいくら増加してしまいました」というようなことがあるので、品質はなかな か良いが、コストとデリバリーあたりで間に合わないということがあるようです。 それでどうしたら良いでしょうか？ということです。手戻りを減らしたいということで す。モジュール設計をしているわけですが、あるモジュールは台湾にお願いして、別のモ ジュールは中国にお願いしてと、そういう設計でうまくやって行くにはどうしたら良いの でしょうということを考えています。 例えばこんな四角い M4 という筐体（モジュール）の中に、M1 というモジュールがありま す。M1 には M2 が載っていて、M3 がこの辺にあるということです。ノートパソコンで言う と、メインボードに CPU が載っていてハードディスクがあると、そんな感じでしょうか。 筐体にもファンを付けるか、ファンレスでやるかと，いろいろそういうのがあると思いま す。当然、ソフトウエアも絡むわけですが、ソフトウエアを絡めると非常に難しい問題に なりますので、ここではハードウエアのみで考えています。 モジュール M1、M2、M3、M4 というブロックに関して，ブロック定義図を書いてインタフ ェースを明確にしてみると、このように非常に複雑なります。主に熱関係のサーマルデザ インをする上でのやり取りなのですが、M1 が熱を発生し、M3 も熱を発生し、この間の熱の やり取りはどうなっているのかとか、M2 と M1 の間の熱のやり取りはどうなっているのかと いうことを細かくそれぞれのモジュール間で考えなければいけないかに見えます。 このままモジュール設計で進めて行きましょうというと、M1 の開発をやっていた人が「M2 が途中で何か設計変更しました」と言われると、「熱設計の値が変わってきました。さぁど うしよう」となって，設計変更をしていると、実はそれは M3 にも影響していたのではない かということになり，大変な複雑な設計問題になってしまいます。 そこで一つ、cavity というのをモジュール的に持って来て、要するに空間ですが，モジ ュールが共有する空間を一つのモジュールと見て、同じ内容ですが、ブロック定義図で書 いてみるとこんなにすっきりした形になります。cavity の間でのインタフェースだけで関 係しているのですねというふうに書けるのです。こくした図を書かなくても，すでにこう 10 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved. した考えを取り入れている人はいらっしゃると思います。しかし，SysML でブロック定義図 に書いてみると、非常にシンプルでわかりやすくなって，誰でも気づきます。こういう図 を見ると、他にもいろいろできそうですねと思います。モジュール設計を進めて行く、あ るいはシステム全体の設計を進めて行く上で、機能や構造で分解していくということが重 要です。この cavity をひとつのブロックとして構造として考えることができます。それか らこちらも非常に面白いと思うのですが、たいていシステム設計するというと、最初に非 常に詳細なモデルを作って、シミュレーションをまわして十分に最適化して、 「はい、発注」 とできれば良いのですけれども、３カ月とか半年で何か開発するように言われてもそう簡 単にはシミュレーションはできないのです。開発にはいろいろなタイミングがあります。 そうすると、そういうタイミングによって、次のページで詳細は出ますが、この ITV と 書いてある，いろいろなモジュールの外側の協会条件をある程度仮決めで与えて、「これで 設計してください」とやります。最初からどこがどう相互作用するかということが分かっ ているので、 「あるモジュールが開発されました。熱設計の結果、こんなふうになりました」 というふうにもらったら、それを即座にその関係するモジュールを開発している所に与え て、 「今、前の仮決め値はこうだったけれども、これがこのぐらいに変更になっていますよ」 ということをこういう絵であらかじめどんどん渡してしまいます。最初からそういう設計 にしておきます。 そうすると、その観点で開発側がその熱設計でまたじゃあこうしましょうとか、あるい はシステム全体として実はモジュールをいじるのが良いのか、あるいは全体で、例えばフ ァンの大きさを少し大きくすると OK なのだという判断をした方が良いのか、そんなことも 全体としてできるようになります。今、ITV と言ったのは、初期目標値みたいなものをシス テム全体としては最初に仮決めで与えて「はい、じゃあそれで設計してください」とやる のですけれども、それが本当に達成されるかどうか分からないので、各モジュール設計に アサインして行くのです。分業で進めて行った時に cavity モジュールという特性の中での 値の変更を許して、そうするとそれがシステム全体として最適化することも可能で、それ からモジュール側にそれを渡して少し変更しましょうということも可能という意味です。 これは比較的斬新な設計手法だと思います。 従来の手戻り的にやっていることと何が違うのかというご批判があるかも知れませんが、 簡単に言うと、手戻りすることを意図していると言うか、最初からそういうことが起こる ことを想定して，各モジュール開発者に知らしめているということです。 これを表すためのパラメトリック図ですが、仮決めで決めた値をモジュール開発者に渡 すのですが、その人たちが設計して行く上で、 「再設計しました」と言って値が出てくると、 「それを OK か」と、設計変数を初期値として与えるのですが、それでやってみて「再設計 が来ました」と言ったら、ここでその再設計されたやつを見て OK だったらこれで終わりで す。場合によってはこちらに戻して、ここでもう一回検討する、あるいはもう一回やり直 しましょうとことになります．ループを最初から描いておくということです。もちろん永 11 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved. 遠にグルグル回ったら開発は終わらないのですけれども、先ほど言いましたとおり，最初 から手戻りがあり得るということを示すことが重要なのではないかと考えています。 それで、事例の２例目が今、終わったので、もうまとめで良いのですけれども。今日お 話した内容は、SysML をうまく使うことを推奨しています。モデルベースでやって行きまし ょうということです。わたしは何でもかんでもモデルを使えば良いとは思っていなくて、 有効に使う、適切に使うことが重要と思っています。 今日はユースケース図、シーケンス図、それからブロック定義図を使ったわけですが、 そういうので十分に機能要求の分析はできるのです。 機能というのはまずインタフェースとして明確になるわけですが、評価検証する、妥当 性確認をチェックするとか、そういうことをやって行く上でのテストケースがこういう要 求の分析をして行く過程で分かります。 検証は、設計者とは別の所でやるべしということもありますが、システム開発の最初の 段階でユースケース図からさまざまなテストケースが出てくるので，これを使わない手は ないということです。 それからパラメトリック図をお見せしましたけれども、これが協働作業に非常に向いて いて、専門分野をまたぐような協調設計、先ほどお見せしたモジュール間のやり取りや、 そういったことを評価し、トレードオフをとるといったことをします。あるいは仕様の詳 細化ということもあります。先ほどのブロック間で設計値が流れているのは、ある意味詳 細化 refinement しているわけです。 「最初はこんな値です」と言ったけれども、設計を進 めて行く上で「少し設計値が変わってきました」と、より正確に値が決まってきたという 意味では refine しているわけです。そういったことを陽に示すということです。これらは 知らない間に変わっていましたということでは困るわけで、陽に、それを示すことが大事 です。 以上です。資料の最後の方には、文献が並んでいます。 ＜質疑応答＞ 質問：どうもありがとうございました。今日お話しされていたことからは外されていたと 思うのですけれども、今、ユースケースの話をおっしゃったのですが、disuse case とか fail case とか、いわゆるリスク分析と SysML との相性とか、やはりパラメトリック図でや って行くということでしょうか。 西村：そうだと思います。わたし、機能安全という所まで興味は持っているのですが、な かなか力不足で至ってないですけれども、今、勉強中で、やはり最初のユースケースでし っかりそういう fail が起きた時にどうするのだということは考えるべきで、例えばさっき の電動パワーステアリング的なものですと、勝手にモーターが回っては困るわけで、そう いう時にどうやって fail を検出するのかと、そんなことは考えるべきだと思います。 ただ、 わたしはまだやっていなくて、もしやるとしたら、多分パラメトリック図でどのような fail 12 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved. が起き得るかということ、もちろんユースケース図で考えた上で、それをパラメトリック 図で fail の条件みたいなものを記述してあげるとか、そんなことでうまく表現できるので はないかと思っています。 質問：わたしの感想的なところだと、そういう意味では SysML だけではなくて、ADL とか、 SOI 記述マーカーの方が相性がいいのかなというふうに思います。見えないことはなかった ものですから、コメント出させていただきました。 西村：そうですね、記述上の問題と言いますか、SysML では実行するというわけではないの で、こんな fail があり得ますよということを記述しておくという意味では良いかなと思っ ています。 質問：Ｖの形がありますね。そこの検証の所ですが、verification と validation、２つあ りますね。それは結構難しいと思います。特に validation の方がもっと難しいと思うよう な気がするのですが、アメリカの NASA ではかなり開発されていると聞いていますけれども、 日本ではアカデミックも含めてどこまでそこは解明されているのでしょうか。 西村：解明ということの意味は、こうあるべきというのが本当にあるのかどうかというの が問題だと思います。どこまで妥当性確認をしたら、それで受け入れてくれるのかという ことです。それはやはり利害関係者との関係性で決まると思います。例えば、白坂さんな んかが NASA とやっている時に、JAXA 関係で、NASA が言っているからそれで OK というもの じゃないという話もあるようです。NASA 以上のことを要求したって良いわけです。そうす るとそれは要するに、設計者の、あるいは利害関係者との関係性の中で決めるべきことで はないかと思っています。例えば、本物で、いろんな自動車なんかだと、何万キロ走行テ ストして、それで OK というふう言う人もいるだろうし、場合によっては数千キロで OK と 言う人もいるかもしれないということです。海外の自動車メーカーでも最近のニュースを 見ていると、何万キロとか何十万キロ走ってテストしてきましたということを訴えていた りしていますけれども、それを全部の会社がやりなさいとは言わないです。なので、それ はいろいろなのではないかと思います。 質問：本当の信頼性というのは一体何をもって検証でき得るのかということです。特に NASA みたいに人を宇宙まで運ぶような乗り物でしたら、人間というのは誤操作というのは絶対 起こしますので、どこまで例えば認知科学的にも考慮すべき部分なのかということなのだ ろうと思いますけれども。そこは素人なので、ここの分野ではどこまで進んでいるのかと いうことです。 西村：自動車の関係では、最近、ISO26262 というのが出てきて、あれでやればいいんだと 言っている反面、もう少しいろんなケースを洗い出すということです。これは比較的やっ ぱり制御の世界から言うと、フィードバック制御する相手があるのです。ソフトウエアや， 13 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved. あるいは何らかのメカトロ機器というのが、アクチュエータやセンサー、そういうのが fail するというだけでなくて、対象そのものがあるはずで、そのフェイルが起きた時のフィー ドバックループ全体としての安定性とかいう問題もあるわけです。 そういうことを考えると、いろんなケースがあり得るので、それをアジャイル開発と言 っていいのか分かりませんけれども、いろんなケースで試すということです。それがどん なことが起こるかというのをいろいろ洗い出すしかないと、わたしは思っています。それ はコストとの関係性があるので、どこまでやるのかというのが問題だと思うのですが、そ ういうことを言っている人が最近いると思います。もし、白坂さんが次のコーナーで補足 できるのでしたら、お願いします。 質問：どうもありがとうございました。わたしは SysML は分からなくて UML しかやってい ないのですけれど、お話を聞いた時に Operational View と Functional View があるという お話だったのですけれども、ほとんどの分析は Operational View の所でやられている分析 なのかなと思ったのですけれども、最後にインタフェースのところで、協働できるインタ フェースのあるモジュールを作られたので、それは中の話かなと、Functional View のとこ ろが入っているなあという具合に思いながら聞いているのですけれども、そこのスコープ があまり事例とか聞いた時にどこなのかなということですが。 西村：確かにわたしが示した、例えば、パラメトリック図みたいなものをお見せした時に は、あれはどうも見ても Operational View の外部との関係性であるというわけです。それ が一つ妥当性確認だと思います。検証のフェーズではもう少し内部の信号のやり取りがで きているのかとかいうことを検証すると思います。 今日の話では確かに、ここの Functional View で、少しだけ A/D converter みたいなブ ロックを見せましたけれども、あれの検証をしましたという絵は省いてしまいました。本 来は当然やるべきだと思います。 質問：UML だと多分、そこのところがロバストネス分析を入れてコンポーネントに落とすと 思うのですけれども。Operational View の所ですね。恐らくそのへんの議論のように思え たのですけれども。すみません、SysML は全部知らないものですから。 西村：SysML そのものがそういう分析をしなさいということを言ってはいないと思っている のですが、逆にわたしはそのロバストネス分析で何をされているのかを存じ上げないので、 少しそこはお話をさせていただきたいと思います。すみません。 14 Copyright© 2011 慶應義塾大学大学院 SDM 研究科, All Rights Reserved.