MBSE

モデルベースデザインの成功例としてマツダの例がしばしば取り上げられます。主任設計者の方のインタビューでは、「金が無いからモデルベースを進めた」ということをおっしゃられていました。実機を作成するには費用がかかりますが、時間もかかります。モデルであれば、作成も修正も(慣れれば)容易です。結果的にModel In the Loopの手法で他社よりも早く開発することができました。モデルベースの開発のメリットは早さだけでなく、ステークホルダー(利害関係者)の間で仕様の認識違いの無いことを、従来の自然言語ベースの仕様書よりも担保しやすくなります。一方で、従来のドキュメントよりも抜け漏れが無いように作りこむことから、しばしば工数は(そこだけ見ると)増加します。

SysML

従来モデル記述言語にはUMLがありましたが、UMLはその仕様が大きくて使いにくい面があり、近年はSysMLを使うユーザが増加しています。SysMLは2006 年 7 月に OMG (Object Management Group) により仕様が策定された言語でUMLを一部使いやすく制限し、一部で拡張しています。拡張の部分の大きな点は要求図を入れたことであり、これは大きな進歩だと考えています。なぜならISO 26262では安全要求ベースで開発が進むためです。具体的には、大きな安全要求、つまり大目標のことを安全目標と呼び、それを抽象度を下げることにより、細分化していきます。抽象度を下げるとは、最初機能であったエレメントのつながりが、最後には物理的なエレメントのつながりに変化していくことを意味します。つまり、要求の抽象度を下げるというよりも、それを割り当てるエレメントを細分化していき、結果として要求が細分化されます。その中で、機能であったエレメントがハードエレメント、ソフトエレメントに細分化されます。

これは設計プロセスそのものですが、抽象的に表現してもわかりにくいので、前回は出張を例にとり具体的な例で示しました。

SysMLに関して大変参考となるページがあるので、ご紹介します。

http://www.ogis-ri.co.jp/rad/webmaga/rwm20100806.html

前のブログ 次のブログ

要求

要求について考えてみましょう。ところで似たような言葉に要求と要件とがあります。似たような概念であるため、混用して使用されることも多いですが、ここでは異なる意味として定義をはっきりさせておきたいと思います。

まず要求ですが、顧客の要求を意味することが多いです。顧客要求は文字通り顧客の要望であり、それは整理されておらず、たまには矛盾する要望が存在します。それが開発側に伝えられるわけですが、開発側はそれをシステマティックに整理し、矛盾は取り除き、開発側の要件とします。従って、同一のようなものでありながら、顧客からリリースされた時点では要求であるのに比べて、要求分析を実施し、再定義することにより要件となります。

仕様

それでは仕様とは何でしょうか。要求も仕様も、これもまた混用して用いられますが、本来ははっきりと異なった意味があります。以下の参考URLを見て頂ければわかりますが、端的には要求(要件)はWhatであり、仕様はHowだということです。要求は、方法はともかくこのように動いて欲しいという振る舞いを機能的に(=機能要求)、非機能的に(=非機能要求)表すのに対して、仕様はどのようにそれを実施するかを記述します。

https://wellfire.co/learn/requirements-and-specifications/

要求と仕様の具体例

要求を細分化して実現可能な仕様に落としていく作業のことを「設計」と呼びますが、抽象的な概念であるため、理解のために具体例を挙げてみます。例えばあなたが支社に勤務しているとして、上司から「本社に出張してくれ」と言われたとします。まぎれもなくこれは要求です。手段はどうあれ、物理的に移動することが目標となります。もちろん、暗黙の非機能要求として「時間、費用を最小にしてくれ」という要求もあります。従って、支社から本社に一足飛びにヘリコプターで行くのは採用できません。公共交通機関を利用するとして、支店もよりのA駅、本社最寄りのB駅を結ぶ鉄道を思い浮かべます。

この頭の中で一瞬で行うのはおおまかな「支社→本社」という要求を実現可能な手段に合わせて「支社→A駅」(徒歩)、「A駅→B駅」(鉄道)、「B駅→本社」(バス)という要求に分割したことにほかなりません。これは出張を設計したことになります。

安全設計

ここまでは機能安全に関係ない、一般の設計でしたが、ここからが関係してきます。出張においての安全設計とはなんでしょうか？例えば前記本社への出張で、鉄道が不通になったら「鉄道が不通になったのでいけません」ということになります。重要な会議の場合は「なんとしてでも行ってくれ」ということになると思います。 機能安全では回路の中でも重要とそうでないものを識別するように要求されており、安全に関連するものとしないものを区別する必要があります。安全に関連するものは、場合によってはどうしても達成する必要があります。この場合のどうしてもというのは、例え一点故障があってもの意味合いです。 さて、出張に戻り安全設計を考えると、本来の要求の冗長の要求を導出します。導出といっても同じ要求のコピーです。ただし、異なる手段が必要となります。例えばA駅とB駅間で私鉄とJRが並走していれば、別の鉄道を使うことになります。そうでない場合は、例えば「支社→C駅」(バス)、「C駅→D駅」(別の鉄道)、「D駅→本社」(バス)ということになります。

前のブログ 次のブログ

システム工学

近年システム工学の隆盛により、自動車分野にもその流れが来ています。その中で、次第に上流まで言語設計をする動きがあります。その理由は、従来ドキュメント(紙)により仕様を関係者に伝え、順次具体化して来ていたわけですが、その行き詰まりが、特にソフトウェア分野で顕著なためです。関係者の例としては顧客、サプライヤー間、サプライヤー、ソフトウェアハウス等があり、様々な局面で仕様がブレークダウンされ取り交わされます。

車載ECUの開発は、ハードウェアよりもソフトウェアに多大な工数がかかるのは良く知られており、デバッグに大変な労力をかけています。それは仕様の思い違いだったり、ユースケースの抜け漏れだったり、単なる論理ミスだったり様々な原因がありますが、仕様に関するものだと、場合によるとテストもその仕様で作成された場合にはテストでバグを検出することができません。

バグは入れなければ取る必要も無いことから、ソフトウェアの自動生成が考えられてきました。このようにしてコンピュータの言語の歴史はコンピュータに近いほうから、アセンブリ言語、コンパイラ言語、システム言語(ドメイン固有言語)と進化してきました。システム言語は、人も含めたあらゆるシステムを、ユースケース図、シーケンス図、状態遷移図、ブロック図等の人間が紙に記述してきたドキュメントをなるべく形式的な形で、自然言語を使わない形でコンピュータに取り込むことを目指しています。この取り込む形のことをモデルと呼び、ここで述べたような設計手法のことを、モデルベースシステム工学、簡単にはモデルベース設計と呼びます。

前のブログ 次のブログ