システムエンジニアリングで SysML を使いこなす

第1章　概要編－システムエンジニアリングとしての SysML

1.1. 身近なモデルベース開発

1997 年に UML が OMG により認定され 12 年、組込みソフトウェア開発の現場でも UML を活用したモデルベース開発が浸透してきました。 オブジェクト指向という考え方も一般的になってきた一方、モデルベース開発やオブジェクト指向を何やら高級なものに感じ、組込みソフトウェア開発の現場に適用することに否定的な意見もあるようです。

しかし、モデルベース開発やオブジェクト指向は本当に小難しい技術なのでしょうか。 ものづくりの現場において、機械／電気／制御などソフトウェア以外の領域では、昔からあたりまえのようにオブジェクト指向でありモデルベース開発を行っているのではないでしょうか。

機械設計では、ドラフターで図面を手書きしていた昔から製図表記法には JIS B 0001 という標準があります。 図で表現される部品は意識せずとも「オブジェクト」と認識せざるを得ません。 たとえば扇風機で考えると、「風を送る」機能を直接機械にすることは不可能で、「モータ」「シャフト」「ギア」「羽根車」などのオブジェクトの組み合わせで機能が実現されます。 手書きしていた図面は 2 次元 CAD／ 3 次元 CAD と進化し、今では 3D モデルを基に干渉や構造解析などの分析を設計段階から行うことが普通に行われています (図 1)。

電気設計でも同様で、電気製図が古くから使われています。 図面で表現される回路はインターフェースとタイミングを規定した部品ですし、IC という物理的な「オブジェクト」が生成され、その IC は電気図面の中でさらに高度な機能を持った部品の一部として使われます。 機械製図と同様に手書きから CAD 化の道を辿りましたが、最近では VHDL や VerilogHDL というハードウェア記述言語で設計を行い、消費電力やタイミングのシミュレーションを行うのが主流になっています。 また、ハードウェア記述言語から自動的に回路合成を行うことが可能なため、ソフトウェア開発と類似点が多くなってきています (図 2)。

制御設計では古典制御理論の PID 制御から現代制御理論へ進化し、状態空間モデルによる最適制御のためのさまざまな制御モデルが構築されています。 モデルはブロック線図で表現され、ブロックは「オブジェクト」として再利用されます。 また、モデルを用いた安定性判別などさまざなシミュレーションが可能です。 制御モデルからソフトウェアのソースコードを自動生成するツールも一般的に活用される時代になってきています (図 3)。

このように見てくると、ようやくソフトウェア開発が他分野の開発体制に近づいてきたと考えることもできるのではないでしょうか。 とくに組込みシステムを考える場合、ソフトウェアも他と同じようにオブジェクト指向によるモデルベース開発に行き着くことは自然な流れと思えるのです。

1.2. MBSE の必要性

ここまで、ものづくりの現場において機械設計では機械図面、電気設計では電気図面やハードウェア記述言語、制御設計ではブロック線図、遅れてソフトウェアでは UML という表記を利用したモデルベース開発が行われていることを見てきました。 しかし、これらのモデルで表現されるのはものの一側面を捉ているに過ぎず、もの全体を表現していません。 それではどのようにもの全体を機械／電気／制御／ソフトなどの側面に切り分けるのでしょうか。

その問題に答えるのがシステムエンジニアリングなのです。

システムエンジニアリングは別段新しい試みではありません。 造船や建築などの大掛かりなものづくりでは、昔から組織的なシステムエンジニアリングが行われています。

その中では当然さまざまなモデルが使われています。 MBSE (Model Based System Engineering) と横文字を並べると何やら高尚で新しい感じを受けますが、筆者は「モデルを使わないで組織的なシステムエンジニアリングができるのか？」と思います。

小規模なものづくりではどうなのでしょうか。 一人ですべて検討できる範囲のものづくりであれば、そこにはシステムエンジニアリングという意識はないかもしれません。 しかし、ものをつくっている以上、検討している個人の頭の中では何らかのシステムエンジニアリングが行われているのです。 なぜならば、システムエンジニアリングをしないと「もの」を機械や電子回路、その上で動くソフトウェアに分割できないからです。

このように考えると、システムエンジニアリングは意識的、無意識的に限らず行われている活動であり、今さら取り上げる必要のない分野のように思えます。 なぜ今、システムエンジニアリングが MBSE という形で注目されているのでしょうか。 理由はいろいろあるのでしょうが、筆者はシステムの大規模複雑化と市場要求や技術トレンドの変化が大きく影響していると考えています。

個々の商品開発において、システムエンジニアリングは必ず必要という訳ではありません。 まったくの新商品の場合はシステムエンジニアリングを実施しますが、既存商品の後継機種を開発する場合は、既存商品のシステムエンジニアリング結果を基に機械／電気／制御／ソフトを初めから個別に開発するケースが多くなります。

そのため、次第に商品開発からシステムエンジニアリングが消えていくことになるのです。 組織的なシステムエンジニアリングの手法が確立している場合は、機械／電気／制御などの切り分けが開発プロセス中に規定されるようになり、後継機種開発では、各分野に割り振られた担当者は自分の担当分野に特化していきます。 小規模開発では、最初にシステムエンジニアリングを行ったときは一人で検討できる規模だったシステムも、後継機種での機能追加により一人では対応しきれない規模となり、機械担当、電気担当、制御担当と担当が細分化されていきます。 どちらの場合も、時間の経過とともに一人が担当する範囲がより狭く深く専門化していくことになり、システム全体を俯瞰的に見渡す能力が欠如していくのです。

それでも市場要求や技術トレンドが大きく変化しない範囲では、分野間の多少の不整合は「すり合わせ」開発をすることにより埋め合わせが可能であり、それが日本のものづくりの強みでもありました。

しかし、エンジン駆動の車がモータ駆動になる、環境負荷軽減の要求が高くなり部分最適では対応し切れなくなるなど、トレンドが大きく変化する局面では細分化された専門領域を超えた発想が必要となってくるのです。 たとえばロボットの複数の指先を同じ圧力になるように制御したい場合、純粋な制御工学の視点ではセンサからの入力を基にアクチュエータに指示を与えることを考えるでしょう。 しかし視点を変えて油圧システムの視点で見ると、パスカルの原理で単純に圧力一定にすることが可能になるかも知れません。 ある面に対してつねに一定の角度に制御したい場合、同様に複雑な制御系を構築しなくても機構学の視点で考えると、平行リンク機構を応用することによって機械的につねに一定角であることを保障できるかもしれません。

このような局面ではシステムエンジニアリングが必要となるのですが、開発組織が特定商品の開発に最適化すればするほど、システムレベルの検討ができなくなっていくのです。 筆者は組込みシステムのコンサルティングを生業にしているのですが、クライアントに「何でそれはソフトウェアで実施するのですか」と質問してみると「前からそうだから…」という類の返答を頂くことが多くなりました。 年配の方と会話していると「私が若いころは一人で全部こなしていたけど、最近は…」という話も多いです。 開発組織にシステムエンジニアリングを行う能力が継承されていない現実を表していると思います。

システムが大規模複雑化し、市場要求や技術トレンドが変化しやすい現在、システムエンジニアリングが見直され始めているのではないでしょうか。 いや、担当が細分化され専門化されている現在では、初めてシステムエンジニアリングに接する方も多いのかも知れません。

このような状況の中で MBSE を実践しようとすると、どのモデルでシステムエンジニアリングをするべきか？という問題が出てきます。

もともと組織的なシステムエンジニアリングが確立している企業であれば、既存のシステムエンジニアリング用モデルを用いればよいでしょう。 ただし、大規模複雑化するシステムに対して複数の企業が協力してシステム構築を行う場合、企業内ローカルルールで書かれたモデルでは社外で通用しない可能性が出てきます。

システムエンジニアリングが過去の遺産となり現在に引き継がれていない組織では、機械／電気／制御／ソフトウェアの各担当が集まってシステム検討をすることになるでしょう。 物事を空間で考える機械担当者、時間で考える電気担当者、周波数領域 (ラプラス変換後の世界) で考える制御担当者、下請けのソフトウェア担当者という構図で、機械図面／電気図面／ブロック線図／UML…。 共通言語がないと話がまとまりそうにありません。

そこで SysML の登場となるのです。

1.3. SysML 概要

SysML は、"OMG Systems Modeling Language" の略称であり、2006 年 7 月に OMG (Object Management Group) により仕様が策定されました。

図 4 に示すように、UML の言語仕様の一部を再利用した部分と、SysML のために新たに拡張した部分から構成されているので、コンパクトな仕様となっています。 また、ダイアグラムの種類を次ページの図 5 に示します。

定義されているダイアグラムは全部で 9 つと、UML の 13 個より少なくなっています。

パッケージ図／ユースケース図／シーケンス図／ステートマシン図は UML と同じです。

ブロック定義図はクラス図の拡張、内部ブロック図は複合構造図の拡張となっており、アクティビティ図にも拡張が加えられています。

SysML 独自の図は要求図／パラメトリック図の 2 つです。

よく見てみると、電気担当者にとって必須と思われる UML のタイミング図が SysML には含まれていません。 このダイアグラムに関しては OMG でもさまざまな議論がされたようですが、結局システムレベルよりも下位のレベルで必要となるダイアグラムであり、システムレベルのタイミング記述はシーケンス図で十分と判断されたようです。 ただし SysML1.1 の仕様書では、システムエンジニアリングの場面で SysML を補完する資料として UML のタイミング図を使用することは有効な手段と謳っています。

弊社は UML によるモデルベース開発を推進してきたので、クライアントに SysML を紹介するとたいていの場合「UML では駄目なのか」「UML があるのになぜ似通った別の言語が必要になるのか」という質問を受けます。

筆者の答えは「UML を理解している人のみでシステムエンジニアリングをするのであれば、新たな言語を覚えるよりまずは UML で表現するとよいでしょう」です。 システムを表現するという目的に対して UML では不可能かというとそうではないのです。 図 5 で示した通り、SysML のダイアグラムの大部分は UML そのままか、UML の拡張であり、新たなダイアグラムの内パラメトリック図は内部ブロック図の派生、つまり基は UMLの複合構造図です。 まったくの新規ダイアグラムは要求図ですが、ユースケース図やクラス図を使って要求図と似たような表現は不可能ではありません。

では、なぜ SysML が必要なのでしょうか。 そのおもな理由は 2 つあります。 ひとつは SysML の利用者が必ずしも UML の利用者ではないことで、もうひとつは UML で記述した場合、図の解釈がローカルルールに頼らざるを得なくなることです。

これまで述べてきたように、ものづくりではさまざまな分野の担当者がさまざまなモデルを利用してモデルベース開発をしています。 しかし、UML はモデル表記法としては新参者で、ソフトウェア担当者以外には普及していません。 また、覚えなくてはならないダイアグラムの数も多く、他分野の担当者が一から覚えるには負担が多くなります。 そこで SysML ではダイアグラムの数を減らし、コンパクトな仕様となったのです。

また、SysML は UML を「拡張している」と説明していますが、実際は「拡張している」というより「制限している」と説明したほうが理解しやすい点が多い言語です。 UML は汎用的な言語なのでさまざまな使い方ができ、利用者が独自に拡張することができます。 その典型的な例がステレオタイプと呼ばれるモデル要素の分類なのですが、SysML における UML の拡張とは、多くの場合がこのステレオタイプをシステムエンジニアリング用に規定したものなのです。 つまり、システムエンジニアリングではこのステレオタイプを使いなさい制限している訳です。 これにより SysML では UML に比べて汎用性が下がり、システムエンジニアリングに特化した言語仕様となっていますが、その分誰が見ても同じ解釈ができる言語となったのです。

筆者がシステムエンジニアリングに興味を持ったクライアントに「UML を理解している人のみでシステムエンジニアリングをするのであれば、新たな言語を覚えるよりまずは UML で表現するとよいでしょう」と答える理由は、SysML はシステムエンジニアリングのための手段のひとつに過ぎず、大切なことはどのような手段であれ、まずシステムエンジニアリングをやってみることだと考えているからです。 UML で不便を感じるようになれば他の手段を検討するようになるでしょうし、そのころには SysML 以外の解が出てきているかもしれません。

SysML のダイアグラムについては実践編でシステムエンジニアリングの一環として説明しますが、その前にダイアグラムとは独立した特徴的な概念として「ブロック」「割り当て」「ビュー」「値」について紹介しておきます。

SysML で一番特徴的な概念は「ブロック」という概念です。 これは UML のクラスという概念を制限ではなく文字通り拡張したもので、システムエンジニアリングで表現したい対象を表します。 機能／物理的な部品、システムの一部分、人、制約条件、振る舞いなど、あらゆる分析対象がブロックという単位で扱われます。

グラフィカルな表現では、四角にステレオタイプ <<block>> を指定します。 UML のクラスと同様に、SysML の「ブロック」はプロパティと操作から構成されますが、クラスではグラフィカルに表現される区画がクラス名／属性／操作の 3 つであるのに対し、SysML はパーツ／参照／値／制約など、プロパティの種類に応じて個別の区画 (図 6) を持つことができ、利用者独自の区画を定義することも許されています。

SysML ではモデル要素間のトレーサビリティを確保するために、「割り当て」という概念が導入されており、あらゆるダイアグラムで使用されます。 図 7 に示すように、「割り当て」はノート形式で「allocatedTo<<要素種別>>要素名」や「allocatedFrom<<要素種別>>要素名」で記述したり、ブロックの allocatedTo 区画や allocatedFrom 区画として記述したり、ステレオタイプ <<allocate>> を指定した依存関係として記述することができます。

要求がどのように表現されるのか、テストケースに反映されているのかなどを追跡可能とするために有効な記述です。

UML では「ビュー」といえば RUP (Rational Unified Process) のユースケースビュー／論理ビュー／コンポーネントビュー／並行性ビュー／配置ビューが有名ですが、SysML はソフトウェア記述に限定した言語ではないので、システム記述の「ビュー」を定義する必要があります。 このため、<<viewpoint>> と <<view>> という 2 つのステレオタイプが定義されています。 <<viewpoint>> はモデルのある視点を定義したブロックであり、この視点でモデルを集めたパッケージが <<view>> となります。 SysML を用いて MBSE を実践する場合、「ビュー」を決定して視点を明確にする必要があります。

SysML では、「値」は「値型」という概念で指定します。 「値型」は 2 つの属性「次元」と「単位」を持ち、「値」の意味を特定します。 たとえば "20" という「値」に "高さ" という「値型」が指定され、それは "長さ" の「次元」の "cm" という「単位」となります。

あたりまえの話でどうでもいいことに思えますが、だからこそ手を抜きがちで、誤解による不具合となりやすいのです。 単位を勘違いしてシミュレーションにかけ、その結果を基に設計したら性能が出なかったという例は枚挙に暇がありません。 システムエンジニアリングでは異なる分野の担当者が協力して作業を進めることが多くなります。 あたりまえのことを明文化することも重要になるのです。

1.4. SysML を活用するために

SysML は、表記法を規定した言語という点では UML と同様であり、システムエンジニアリングプロセスを規定している訳ではありません。

SysML を活用するためには、活用するためのシステムエンジニアリングプロセスが必要です。 システムエンジニアリングプロセスに関する規定は、IEEE1220、ANSI/EIA632、ISO/IEC15288 (JIS X0170) などさまざまなものがありますが、一例として ISO/IEC15288 (JIS X0170) 規定のテクニカルプロセスの設計工程において利用可能な SysML 要素を選定してみました (表 1)。

実際のシステムエンジニアリングの現場では規定のプロセスをそのまま適用できることはまずありません。 ソフトウェア開発プロセスと同様、状況に応じたシステムエンジニアリングプロセスを再定義していくことが必要です。 SysML はシステムエンジニアリングプロセスの中で活用できるツールの 1 つという位置づけです。 SysML のみではシステムエンジニアリングプロセスのすべては表現できないことを、心に留めておいてください。

第2章　実践編へ続く・・・