2018年5月28日月曜日

SysML初級講座 第4回 システム・モデリング誕生前夜の状況 ③

システム・モデリング誕生前夜の状況   ③

単位系の問題


単位系の問題ですが、国ごとに取り扱いに違いがありますが、概ねアメリカ合衆国を除いては、生活に密着した分野では地域や分野固有の単位系(例えば、ヤードや尺など)を使うことを認め、システム工学などの科学技術分野では国際単位系を使うのがだいたいのルールになってきています。
したがって、普段はインチやカラットを使っていても、理科の実験はメートルやキログラムを使って行うと言うのが、アメリカを除いては、一般的です。
ただ厄介なのは、「アメリカを除いては」、と言っても、アメリカが科学技術大国であり、システム・エンジニアリング分野では全く無視し難く、実際、少なくとも宇宙航空分野ではアメリカが強大な影響力を持っています。

また単位系の問題は、単に国際標準を遵守すれば済む、と言った性質を超えた問題が潜んでいます。

以前プロマネBlogで取り上げた「F16赤道上空反転事件」を見て見ましょう。

これは、F16ジェット戦闘機が赤道を越えるたびに上下が反転してしまうトラブルで、コンピュータ・シミュレーション上で未然に発見されたソフトウェア・エンジニアリング上、システム・エンジニアリング上有名なバグに起因します。

このバグが発生する背景として、あるいは都市伝説になるほど皆が十分ありえると考えてしまう理由の一つとして、単位系の問題があります。
地球上の位置を簡便に示す方法として緯度経度をもちいる方法は、国際的にほぼ完全に合意が取れており、長さや重さのような不一致はまず発生しません。
例えば、明石市は東経135度 北緯34度39分、ニュージーランドは東経174.76度 南緯36.9度など、こう言う表記は世界共通であり、アメリカでさえ奇跡的に(?)一致しています。
しかし、こう言う表記がコンピュータ・システムで扱うのに適しているかと言うと、そうとは言えません。
むしろ、極座標を使って、例えば南緯34度と言うのを-45度にしたり、西経と言うような逆向きに測る変則的なことをせず西経135度を -135度あるいは225度と表したほうが一貫した 処理が容易です。
従って、世界的に完全に合意された単位系も、内部処理系ではそれを変換して使用することが多く、そこに変換部分が潜在的に障害点(Failure point)になりうるリスクが生じてきます。

こう言った単位系の処理ルーチンは、個々の技術者や部署に任せるのではなくシステム全体で統合的にまとめて行うことが近年のプロジェクトでは主流のアプローチとなってきています。

バリュータイプ«valueType» の登場


こう言う動きに対し、SysMLではバリュータイプ«valueType»というクラス(ブロック)が用意されています。
簡単な例で見て見ましょう。

kは長さの変数で単位は Km、 mは長さの変数で単位はMile、型(type)は共に 実数(Real)とします。(90年代のソフトウェアでは、これが普通)
そうした場合、式: k + m は 明らかに間違いを含んでいますが、いわゆるセマンティック・エラー(意味論的誤謬)であって、コンピュータが機械的にチェックできる種類のシンタックス・エラー(文法的誤謬)ではなく、人間が式と値の意味を考えながらチェックしなければなりません。(機械は、文字通り、単純に機械的に計算してしまうだけです)


それに対し、右の図で示すバリュータイプKmとMileを使って変数kとmを定義すると、式: k + m  は  タイプが合わないためにシンタックス・エラーとなり、機械が自動的にチェックできる形になります。
また、バリュータイプは 次元(dimension: 長さL、重さM、時間Tなどの情報)を持っており、式の両側で次元が一致するか等の自動チェックも可能です。 (例 F = M・L・T^(-2) などが一致するか、式を機械的に検証可能)



0 件のコメント:

コメントを投稿