モデルベース開発手法によるリアルタイムシミュレーション

モデルベース開発手法によるリアルタイムシミュレーション
神田 吉孝
1. まえがき
モデルベース開発（MBD：Model Based Development）とは，コンピューター上で再現した“モデル”を用いることで，設計時からシミュレーションによる検証を繰り返し実施する開発手法である。その結果，従来の仕様書ベースでの開発に比べ，手戻りを排除し，効率化・短時間化を図ることができる。自動車業界では既に標準的な開発手法のひとつであり，航空宇宙分野でも成果を上げている。当社の防衛・宇宙事業へのモデルベース開発の適用を図るべく，人型遠隔操作ロボット“DiaroiD”を題材に，2019年度から開発に取り組んだ。開発を通じ，MILS(Model-in-the-Loop Simulation），自動コード生成などの成果を得るとともに，モデルベース開発の長所・短所の知見を蓄積することができた。その成果を活かして，リアルタイムシミュレーションによる“DiaroiD 操縦支援システム”を製作した。本稿では，これら開発の経緯，成果及び事業展開への展望について述べる。
2. 開発概要
防衛・宇宙事業でもモデルベース開発の適用を図るべく開発をスタートした。企画当初は，技術アピールのためのデモンストレーション素材の作成が目標であったが，その後，自動コード生成環境及びリアルタイムシミュレーション環境の構築を通して，技術要素確立，さらには，事業展開できる技術力の獲得に目標を改めた。ターゲットは，デモンストレーション素材として人々の興味を引くことができ，機械的動作が分かりやすい人型遠隔操作ロボット“DiaroiD”とした。DiaroiD は，胴体，腕，手指，首の各部が操縦者からの遠隔操作によって動作するロボットである。開発ツールは，MATLAB/Simulink に加え，ロボットのプラントモデル製作にSimscape Multibody を採用した。モデルベース開発手法によるリアルタイムシミュレーション22.1 DiaroiDDiaroiD とは，図1 に示す人型遠隔操作ロボットである。1 号機を三菱電機先端技術総合研究所，2 号機を三菱電機通信機製作所が製作した。図 1．人型遠隔操作ロボット“DiaroiD”2 号機胴体6，腕7×2，手指6×2，首3，合計35 自由度を一人で操縦できる。操作者の腕に沿わせて装着する入力装置により腕部と手指部を，音声入力により胴体部と首部を操縦する。また，あらかじめプログラミングした定型動作を実行することもできる。脚部はクローラ型の移動台車になっており，リモコン操作により移動することが可能である。ソフトウエアを当社が，メカ設計，製造を三菱電機エンジニアリングが，全体構想設計と電気設計を三菱電機通信機製作所が担当した。2.2 開発ツールモデルベース開発環境のデファクトスタンダードとなっているMATLAB シリーズの図2 の枠線で囲った製品を採用した。図 2．開発環境2.2.1 MATLAB関数やアルゴリズム開発，行列計算など様々なことを可能にしている数値解析ソフトウエアである。また，その中で使うプログラミング言語の名称でもある。2.2.2 Simulinkブロック線図を描いて時間軸でのシミュレーションを行う環境であり，オプションによりブロック線図をC ソースコードへ変換することができる。2.2.3 Simscape Multibody3D 機械システムで使用する剛体シミュレーション環境であり，ボディ，ジョイント，拘束，力学的作用及びセンサーなどを表すブロックを用いて，3D 剛体システムをモデリングし，シミュレーション結果を3D アニメーションにて可視化することができる。3. モデルベース開発図3 にモデルベース開発の流れを示す。特徴は，設計段階から製作対象をモデリングし，そのモデルを用いてMILS により検証を行うこと，及び，検証後のモデルから実装コードを作成することである。以降，今回の開発内容について述べる。※RCP：Rapid Control PrototypingMILS：Model-in-the-Loop SimulationSILS：Software-in-the-Loop SimulationS-PILS：Simulated Processor-in-the-Loop SimulationHILS：Hardware-in-the-Loop Simulation図 3．モデルベース開発の流れモデルベース開発手法によるリアルタイムシミュレーション33.1 モデリングDiaroiD のモデルは，以下の3 つに大別できた。外部入力や駆動スケジュールにより，駆動指令入力を行う“コマンド入力モデル”入力された指令で機械制御を行う“制御モデル”ロボット本体をシミュレートする“プラントモデル”3.1.1 コマンド入力モデルコマンド入力モデルは，ロボットの駆動指令を生成又は，外部から入力する。あらかじめ設計した時系列の駆動スケジュールによる“コマンド再生”と，外部から駆動指令を逐次入力する“UDP(注1)通信”の2 種類のコマンド入力モデルを作成した。“コマンド再生”は，設計した動作を何回でも再現できるため，モデル更新時の比較検証に向いている。Simulink標準ライブラリーの“Signal Builder”ブロックを用いて作成した。“UDP 通信”は，DiaroiD の操作入力装置からのUDP 通信コマンドの入力を可能にしたものである。操作による挙動の確認や，後述するリアルタイムシミュレーションに使用する。UDP 通信機能はSimulink 標準ライブラリーには用意されておらず“C Caller”ブロックを用いて自作した。3.1.2 制御モデル制御モデルは，入力したコマンドを座標変換し，位置指令を生成する。本節では，座標変換として胴体部のキネマティクス(注2)手首部のキネマティクス位置指令生成としてサーボ制御の特徴を述べる。胴体部のキネマティクスDiaroiD 2 号機の胴体部分は，産業ロボットによく見られる6 軸垂直多関節ロボットの構造を採用している。図4に胴体部構造を示す。6 軸垂直多関節キネマティクスは，式1～式4 を用いて数値演算する。各関節(アクチュエーター)の角度[𝜃𝐴𝑍1 𝜃𝐸𝐿1 𝜃𝐸𝐿2 𝜃𝐴𝑍2 𝜃𝐸𝐿3 𝜃𝐴𝑍3]から姿勢[𝑥 𝑦 𝑧 𝜃𝑥 𝜃𝑦 𝜃𝑧]を求めることをキネマティクス，姿勢から各関節の角度を求めることを逆キネマティクスという。姿勢の要素のうち位置ベクトル[𝑥 𝑦 𝑧]は式1 のAffine 行列による変換結果となる。ここで，𝑇𝑟𝑎𝑛𝑠(𝑃𝑥)は関節から次の関節への平行移動を指す。姿勢の要素のうち方向ベクトル[𝜃𝑥 𝜃𝑦 𝜃𝑧]は式2 と式3 の行列が同じ方向を示すことを利用して，式4 で求められる。𝑄𝑙𝑚は，3×3 行列[𝑄]のl 行m 列目の要素を指す。図 4．DiaroiD の胴体部構造[𝑥 𝑦 𝑧 1] = 𝑅𝑜𝑡(𝜃𝐴𝑍1, 𝑧) ∙ 𝑇𝑟𝑎𝑛𝑠(𝑃1) ∙ 𝑅𝑜𝑡(𝜃𝐸𝐿1, 𝑥) ∙ 𝑇𝑟𝑎𝑛𝑠(𝑃2) ∙ 𝑅𝑜𝑡(𝜃𝐸𝐿2, 𝑥) ∙ 𝑇𝑟𝑎𝑛𝑠(𝑃3) ∙𝑅𝑜𝑡(𝜃𝐴𝑍2, 𝑧) ∙ 𝑇𝑟𝑎𝑛𝑠(𝑃4) ∙ 𝑅𝑜𝑡(𝜃𝐸𝐿3, 𝑥) ∙ 𝑇𝑟𝑎𝑛𝑠(𝑃5) ∙ 𝑅𝑜𝑡(𝜃𝐴𝑍3, 𝑧) ∙ 𝑇𝑟𝑎𝑛𝑠(𝑃6) ∙ [0 0 0 1]𝑡 ･･･式1[𝑄] = 𝑅𝑜𝑡(𝜃𝐴𝑍1, 𝑧) ∙ 𝑅𝑜𝑡(𝜃𝐸𝐿1, 𝑥) ∙ 𝑅𝑜𝑡(𝜃𝐸𝐿2, 𝑥) ∙ 𝑅𝑜𝑡(𝜃𝐴𝑍2, 𝑧) ∙ 𝑅𝑜𝑡(𝜃𝐸𝐿3, 𝑥) ∙ 𝑅𝑜𝑡(𝜃𝐴𝑍3, 𝑧) ･･･式2[𝑅] = 𝑅𝑜𝑡(𝜃𝑥, 𝑥) ∙ 𝑅𝑜𝑡(𝜃𝑦, 𝑦) ∙ 𝑅𝑜𝑡(𝜃𝑧, 𝑧) ･･･式3𝜃𝑥 = 𝑡𝑎𝑛−1 −𝑄23𝑄33, 𝜃𝑦 = 𝑠𝑖𝑛−1 𝑄21 , 𝜃𝑧 = 𝑡𝑎𝑛−1 −𝑄12𝑄11･･･式4(注1) User Datagram Protocol：インターネットなどのネットワークで，IP(Internet Protocol)の一段階上位層のプロトコル(通信規約)として標準的に使われるもののひとつ。(注2) Kinematics：運動学。運動の原因，つまり力を考慮せずに，幾何学的な運動のみに注目した力学の一体系。本稿では，各関節の変位量から先端の位置姿勢を求める問題として使用している。モデルベース開発手法によるリアルタイムシミュレーション4[𝑆] = (𝑆𝑎𝑥 𝑆𝑏𝑥 0𝑆𝑎𝑦 𝑆𝑏𝑦 0𝑆𝑎𝑧 𝑆𝑏𝑧 0) , [𝑇] = (𝑇𝑎𝑥 𝑇𝑏𝑥 0𝑇𝑎𝑦 𝑇𝑏𝑦 0𝑇𝑎𝑧 𝑇𝑏𝑧 0), 𝑇𝑎 ̂ = (001) , 𝑇𝑏 ̂ = (001) ･･･式5[𝑆′] = 𝑅𝑜𝑡(𝜃𝑣, 𝑦) ∙ 𝑅𝑜𝑡(𝜃𝑢, 𝑥) ∙ [𝑆] ･･･式6|S′a ⃗⃗⃗⃗⃗ − (Ta ⃗⃗⃗ + 𝑙𝑎Ta ̂ )| = |Sa ⃗⃗⃗ − Ta ⃗⃗⃗ |, |S′b ⃗⃗⃗⃗⃗ − (Tb ⃗⃗⃗⃗ + 𝑙𝑏 Tb ̂)| = |Sb ⃗⃗⃗⃗ − Tb ⃗⃗⃗⃗ | ･･･式7式1，式4 は角度[𝜃𝐴𝑍1 𝜃𝐸𝐿1 𝜃𝐸𝐿2 𝜃𝐴𝑍2 𝜃𝐸𝐿3 𝜃𝐴𝑍3]について直接的に解くことができないため，逆キネマティクスを求める場合は，ニュートン＝ラフソン法による収束演算を行う必要がある。手首部のキネマティクスDiaroiD 2 号機の腕部のうち，手首部分の2 自由度は，パラレルリンク構造を採用しており，2 本の直動リンクにより手首の𝜃𝑢と𝜃𝑣の回転を実現している。図5 に手首のパラレルリンク構造の概念図を示す。シリンダー駆動の位置[𝑙𝑎 𝑙𝑏 ]から姿勢[𝜃𝑢 𝜃𝑣]を求めることをキネマティクス，姿勢から各シリンダー駆動位置を求めることを逆キネマティクスという。パラレルリンクキネマティクスは式5～式7 を用いて数値演算する。式5 の[𝑆]は𝜃𝑢 = 𝜃𝑣 = 0時の回転側の2 つのユニバーサルジョイントの座標， [𝑇]はシリンダー側のユニバーサルジョイントの座標，𝑇𝑎 ̂,𝑇𝑏 ̂ はシリンダー駆動方向の単位ベクトル，|Sa ⃗⃗⃗ − Ta ⃗⃗⃗ |,|Sb ⃗⃗⃗⃗ − Tb ⃗⃗⃗⃗ |は2 本のリンクの長さである。図 5．手首パラレルリンク構造リンクの長さは変わらないことから，式6 と式7 にて逆キネマティクスを演算できる。パラレルリンクも垂直多関節と同様にキネマティクスは収束演算により回転角を求める。サーボ制御DiaroiD のサーボ制御は，ソフトウエア内でフィードフォワード制御を行い，ポジションボード内でフィードバック制御を行っている。これに合わせて，制御モデルもフィードフォワード制御とした。コマンドに対し速度制限と駆動範囲制限を処置し，位置指令を生成するモデルを作成した。サーボ制御モデルを図6 に示す。3.1.3 プラントモデルプラントモデルは，制御対象の振る舞いを再現する。最も困難であり，最も力を入れた部分である。本開発では，メカ設計図であるCAD(注3)モデルを基に，モデリングした。モデリング手順は，CAD モデルのリダクションCAD モデルをSimscape で読込み部品の整列と相対位置の算出部品の接続接続点に回転機構を挿入回転機構へ位置指令を接続となる。加えて，実空間での現象を再現するため衝突の実現を行った。図 6．サーボ制御モデル(注3) Computer-Aided Design：コンピューターを用いて設計，作図をすること，あるいはその設計支援ツールのこと。モデルベース開発手法によるリアルタイムシミュレーション5図7 に作成したプラントモデルを示す。図 7．プラントモデルCAD モデルのリダクションメカ設計のCAD モデルはボルト1 点まで詳細に部品分割されているが，Simscape でこれらを1 点1 点変位シミュレーションすると膨大な演算量になり現実的ではない。そこで，CAD モデルの各部品を一体と見なせる単位まで結合し部品点数を減らす処置が必要であった。これをリダクションという。当社にはこの技術がなかったため，リダクションは三菱電機通信機製作所に協力いただいた。CAD モデルをSimscape で読込みCAD ソフト“Creo Parametric”のモデルをSimscape が読み込めるSTL 形式(注4)のデータに変換し，Simscape へ読み込んだ。形式変換にはプラグイン“Simscape MultibodyLink”を使用した。部品の整列と相対位置の算出読み込んだモデルは，全ての部品がグローバル座標上の絶対位置に浮いている状態であった。これら部品同士を接続するために，部品同士の相対的な位置関係を求める必要があった。そこで，Simulink 上で機構順に部品を並べ，部品間の相対位置を算出した。相対位置の算出にはSimscape の“Transform Sensor”というブロックを利用した。(注4) 三次元形状を表現するデータを保存するファイルフォーマットのひとつ。名称の由来は光造形法を意味するStereolithography である。部品の接続“Rigid Transform”という座標変換ブロックに算出した相対位置を設定し，これを介して部品を接続した。これにより，一例として，ロボットの前腕の位置は上腕からの相対位置で決定されるようになった。接続点に回転機構を挿入“Rigid Transform”で接続しただけでは，部品と部品が固定された状態である。ここに“Joint”という回転機構ブロックを挿入した。“Joint”の回転座標系と部品の座標系は異なるため，“Joint”の回転軸と動かしたい回転軸が一致するよう座標変換する必要があった。部品A－座標回転－Joint－座標逆回転－部品B といったように，座標回転と座標逆回転を挟みながら“Joint”を挿入した。これにより，ロボットの関節を動かせるようになった。回転機構へ位置指令を接続回転機構の指令入力に制御モデルからの位置指令を接続した。これにより，制御モデルからの指令で，プラントモデルを駆動できるようになった。衝突の実現部品は初期状態では，互いをすり抜けることができてしまう。図8 の左側は，下した右腕が左腕をすり抜けて重なってしまった場面である。図 8．衝突の有無図8 の右側のように，下した右腕は左腕に衝突し，停止又は，跳ね返るようにする必要がある。Simscape では，部品間に垂直抗力という力学的作用を定義することで，衝突という現象を実現する。モデルベース開発手法によるリアルタイムシミュレーション6垂直抗力の定義により，部品同士が衝突し，互いにすり抜けられないようにした。Simscape では，垂直抗力や摩擦力といった力学的作用は，部品そのものに定義するのではなく，部品間の関係性として定義する。3.2 MILS（Model-in-the-Loop Simulation）でき上がったモデルを利用して次のような検証を行った。キネマティクス演算の設計検証駆動順序による衝突の回避検証詳細は割愛するが，この他にも，アクチュエーターの駆動範囲アクチュエーターの駆動速度をシミュレーションで検証した。3.2.1 キネマティクス演算の設計検証不定解の回避回転軸が一致し不定解となる（解の個数が無限になる）問題があった。不定解となるケースは以下の3 とおりであった。ケース1： AZ2 とAZ3 が不定(図9 左)𝜃𝐸𝐿3 = 0 のときケース2： AZ1 とAZ2 が不定(図9 左)𝜃𝐸𝐿1 = − 𝑠𝑖𝑛−1 𝑏𝑎かつ 𝜃𝐸𝐿2 = −𝜃𝐸𝐿1 のときケース3： AZ1 とAZ3 が不定(図9 右)𝜃𝐸𝐿2 = − {𝑠𝑖𝑛−1 (𝑎 𝑠𝑖𝑛 𝜃𝐸𝐿1√𝑏2+(𝑐+𝑑)2) + 𝑡𝑎𝑛−1 𝑏𝑐+𝑑+ 𝜃𝐸𝐿1}かつ 𝜃𝐸𝐿3 = 𝜃𝐸𝐿1 + 𝜃𝐸𝐿2かつ 𝜃𝐴𝑍2 = 0 のとき不定解発生時に操作者にとって扱いやすい挙動をMILSで検証した。その結果，𝜃𝐴𝑍3と𝜃𝐴𝑍2は不定解発生直前の角度で固定し，𝜃𝐴𝑍1のみを駆動する方法を採用した。このように，設計上の問題点とその対策結果を，実機なしで検証できることを確認した。図 9．キネマティクス不定解操縦者の感覚に合わせる理論的なキネマティクスが操縦者の期待とは異なる結果を生じることがMILS で判明した。正面を向いた状態から“12 度左に向く”と指令した場合，操縦者は図10 の左側のように胴体全体を向ける動きを期待している。しかし，キネマティクスの演算結果は図10 の右側のように胸の位置座標を固定し胴体を捻じった動作となる。加えて，この捻り動作では部品の干渉により15 度程度までしか回転できないことが分かった。このように，設計が人の感覚に合致しているかどうかなど曖昧な妥当性も，実機なしで検証できることを確認した。図 10．胴体部回転動作の様子3.2.2 駆動順序による衝突回避の検証一例ではあるが，示指を何度以上曲げていると，拇指と衝突するかなど，機械的な衝突をMILS で検証した。衝突回避のためプログラムで制限を加えた場合も，所望動作の確認だけでなく，望まない副作用がないかどうかも，目視で検証できることを確認した。モデルベース開発手法によるリアルタイムシミュレーション73.3 自動コード生成MATLAB の自動コード生成機能を用いて，検証された制御モデルから実行コードを作成した。実行コード作成には，コード生成を支援する“コード生成アドバイザー”を利用した。“コード生成アドバイザー”により，コード化のための手順が提示されるため，容易にコードを生成することができた。本項では，自動コード生成手順として離散化手書きコードとの結合実施動作検証を，自動生成したコードの評価として処理時間評価を述べる。3.3.1 離散化Simulink で書かれたモデルの時間系は連続系と離散系の2 種類がある。シミュレーションモデルはトリガーを必要としない連続系の方が作りやすいが，コード化するモデルは離散系に変更（離散化）しておく必要がある。注意点として，ライブラリーブロックによっては，“Continuous”グループや“Simscape”グループなど連続系でしか動作しないものもあり，再設計が必要になる場合がある。3.3.2 手書きコードとの結合図11 はDiaroiD 制御プログラムのブロック構成図である。作成済みの手書きコードを元に，制御部の手書きコードと制御モデルの自動コードを入れ替えてビルドした。その他の部位は手書きコードを使用した。3.3.3 実機動作検証ビルドしたプログラムをDiaroiD に搭載し動作を確認した。ここで特筆するべきは，動作確認開始時から問題なく動作したことである。MILS で検証したモデルは，コードレビューを必要とせず，コーディングミスを混入する余地もなく，実機で動作した。自動コード生成の優位性を証明する事象であった。3.3.4 処理時間評価制御部の処理時間には動作の遷移により4～8ms のばらつきがある。同一の動作をさせたときの手書きコードの平均処理時間は5.80ms，自動生成コードの平均処理時間は5.93ms であった。図12 は手書きコードと自動生成コードの処理時間のばらつきを，横軸：処理時間，縦軸：出現割合で示したグラフである。処理時間のばらつきも含めて自動生成コードの処理効率は，手書きコードと遜色のないレベルにあることが分かる。図 12．処理時間のばらつきの比較4. リアルタイムシミュレーションリアルタイムシミュレーション技術を用いて，DiaroiD操縦者を支援するシステムを構築した。本章では，“DiaroiD 操縦支援システム”について述べる。図 11．実機構成とシミュレーション構成モデルベース開発手法によるリアルタイムシミュレーション84.1 DiaroiD 操縦支援システム4.1.1 実時間への対応MILS による検証が目的のシミュレーションでは，コンピューターのパフォーマンス不足によって，1 秒間の事象の演算に2 秒かかっていても，問題にはならない。しかし，操縦支援が目的ならば，実時間内でシミュレーションを実施できなければ意味がない。シミュレーション時間を計測したところ，実時間を超えていたため，操縦支援にはあまり影響しない手首のパラレルリンク機構を削除し，実時間内に納めるようにした。具体的には，①制御モデルで逆キネマティクス演算前の角度指令を，プラントモデルの手首の“Joint”ブロックへの角度指令として接続した。さらに，②上腕と手首を接続しているリンクをプラントモデルから削除した。これによりプラントモデル演算は軽減され，シミュレーション時間を実時間内に抑えることができた。4.1.2 実周辺環境を仮想空間へ反映Lidar(注5)を用いてDiaroiD を取り巻く実周辺環境を仮想空間へ投影する手法への取組みについて述べる。仮想空間にDiaroiD 本体しか存在せず，作業対象物との距離の把握には，役に立っていなかった。そこで，DiaroiDに取り付けたLidar により作業対象物を認識し，仮想空間に出現させることができないか検討を進めることにした。検討当初は，Lidar による点群データを小さな球体として仮想空間に浮遊させる方法を考えたが，Lidar の解像度2 百万点に対し，Simscape に実時間内で処理させられる球体は100 個程度であり，実現は不可能であった。次善策として，点群データからSTL データを作り，剛体として仮想環境に投影する方法を試行した。当社はLidar を保有していないため，Lidar による撮影は，三菱電機情報技術総合研究所に実施いただいた。図13 の実周辺環境をLidar で撮影すると，図14 のとおり視線距離によって色分けされた点群データとなった。この点群データをSTL データに変換し，仮想空間に読み込んだ結果が図15 である。1 部品となるため色分けはできず，単色（緑色）で表示した。(注5) Light Detection and Ranging（光検出と測距）とは，光を用いたリモートセンシング技術のひとつ。パルス状に発光するレーザー照射に対する散乱光を測定し，遠距離にある対象までの距離や方向を計測するものである。図 13．実周辺環境図 14．Lidar による点群データ図 15．仮想空間に取り込んだ実周辺環境図 16．仮想空間に取り込んだ実周辺環境（横から）モデルベース開発手法によるリアルタイムシミュレーション9この方法において大きな問題点が2 点あった。1 点目は，対象の更新にはSTL データを入れ替えて再ビルドする手続きが必要であり，最速でも1 分かかることである。リアルタイムシミュレーションにおいて実周辺環境の動的変化に追従することができない。2 点目は，単一方向からのLidar 計測では，1 面しか捉えることができず，視点を移動すると図16 のようになり，物体に見えないことである。今後，“①仮想空間をUNITY などの3D プラットフォームに移行し，点群データ再現を高速化する。”,“②LidarをDiaroiD の腕に装着し，多視点からの点群データを取得可能にする。”などの機能向上を検討する。4.1.3 仮想視点リアルタイムシミュレーションにおける仮想空間の長所のひとつは視点を自由に追加できる点である。DiaroiDの操縦システムでは，ロボット取り付けられたステレオカメラ2 視点（頭部と胸部のステレオカメラ）のみであるが，仮想空間では俯瞰視点はもちろん，可動部に仮想的なカメラを取り付けたかのような視点を作ることができる。そこで，操縦者に任意の視覚情報を与えるため，手のひらに仮想視点を設けた。図17 は，左手に固定した視点でのモニター例である。図 17．シミュレーションによる仮想視点4.1.4 双腕衝突警告操縦支援システム導入前は，右手の操作に気を取られている操縦者が，左腕への注意を配ることができず，双腕を衝突させてしまう事故があった。そこで，双腕の衝突を警告する機能をプラントモデルに組み込んだ。定義された2 つの部品間の距離が近づくと間欠音を発し，さらに，部品間の距離が近くなるほど間欠音の周期を短くして，操縦者に接近の度合いを伝えるようにした。衝突警告を，衝突する可能性のある全ての部品間に適用すると，リアルタイム性が確保できなかったため，右手部と左手部の衝突に限定した。さらに，衝突判定件数を下げるため指の駆動範囲の形をした透明な仮想部品を作成し，双腕の接近を警告するようにした。5. 事業展開への展望本開発の最大の目標である事業，製品開発への展開について，これまでの成果を踏まえて考察する。5.1 長所と短所モデルベース開発の長所については，様々な文献がその有用性を示しているが，今一度整理する。5.1.1 長所明確な仕様伝達が可能である。モデルが動く仕様書であり，従来のソフトウエア設計にあったような日本語の曖昧な表現が入り込む余地がなく，シミュレート可能であるため誤解を生じる可能性も少ない。また，シミュレートによるレビューでは，レビューアの技量に設計品質が左右される傾向も減じることができる。MILS による早期の検証ができる。コーディングすることなく，シミュレーションによる設計検証が可能であり，ハードウエアの完成を待たずに妥当性検証が行える。自動コード生成ができる。コード作成工数を大幅に削減することができ，コーディングに起因するヒューマンエラーも無くすことができる。モデルが資産になる。従来，ソフトウエア資産といえば，ソースコードとその仕様書であったが，モデルは仕様書と動作検証が一体化しており，資産の利用者にとって再利用にかかる手間を大きく削減できる。技術継承に有利である。取り上げている文献は少ないが，技術継承のツールとしてもモデルは優れている。シミュレーションによる直感的理解から理論的理解へ進むことができる。5.1.2 短所技術の習得に手間と時間がかかる。MATLAB，Simulink，Simscape を習得しなければ，効率的な開発が望めない。特にSimscape の習得には時間がかかる。プラントモデル作成に手間と時間がかかる。モデルベース開発手法によるリアルタイムシミュレーション10プラントモデルには製作対象である制御モデルより多くの工数を必要とする。従来の開発では，制御対象の模擬には通信用シミュレーターを作成していたが，通信用シミュレーター作成工数とプラントモデル作成工数の差は大きい。ただし，可視化したプラントモデルは，モデルベース開発の最大のメリットであるMILS による早期検証に大きな役割を持つため，安易な工数削減は推奨できない。従来のメトリクス指標が使えない。従来開発と比べてV 字モデルにおける設計フェーズと試験フェーズの配分が変わり，設計フェーズの比重が大きくなる。そのため，従来のメトリクス指標を適用することができず，モデルベース開発用のメトリクス指標が必要になる。5.2 ソフトウエア部位視点MATLAB/Simulink は，行列演算ツールを元に発展したツールであるため，得意分野と不得意分野がある。5.2.1 得意とする分野演算処理高度な演算ライブラリーが充実しており，非常に有用である。手続き処理分岐，繰り返し，状態遷移はブロック化できるので，複雑な状態分岐の検証には有用である。5.2.2 不得意とする分野ユーザーインターフェースMATLAB/Simulink はユーザーインターフェースを構築する能力は脆弱である。ユーザーインターフェースが主機能となる製品には向かない。外部インターフェースSocket 通信のライブラリーがなく，自作するより他なかった。コンピューターリソースを使用するインターフェース部分はモデルを自作する必要がある。データを型変換して引き渡すようなインターフェースが主機能となる製品には向かない。スレッディングスレッド生成や割込みハンドラー登録などを書き表すことができない。異なるタイミングで動作する離散化ブロックを定義し，離散化ブロックの自動生成コードを手書きのスレッドプログラミングとマージする処置が必要である。5.3 開発工数視点図18 は，制御部について，従来開発手法の開発工数を“1”としてモデルベース開発手法の開発工数を比較したものである。図 18．開発工数制御対象となるプラントモデルの構築に多くの工数が必要になるため，モデルベース開発は従来手法の約４割（38.5%）の工数増となる結果が得られた。なお，プラントモデルを流用する場合は従来手法の約４割（37.5%）減の工数で開発できることが分かった。5.4 考察これらの成果を踏まえ，プラントモデルを含むモデルベース開発の事業化について考察する。適用部位を広げすぎないことユーザーインターフェース，外部インターフェースとスレッディングなど不得意な分野は従来手法で，演算機能，手続き処理など得意とする分野はモデルベース開発手法で製作し，マージする処置が必要である。制御対象を理解していることプラントモデルを作成するには，制御対象の構造を理解し振る舞いを定義する見識が必要である。プラントモデルを流用できることプラントモデルを一度しか使わなければ，損失になる。パラメーターを変えながら何度も検証を行うような開発や，よく似たハードウエアを繰り返し使用するプロダクトラインに適用するのが良い。自動化試験の導入検討とよく似ているが，自動化試験ではコードの流用率が高いこと。モデルベース開発ではプラントモデルの流用率が高いことが選定の基準になる。モデルベース開発手法によるリアルタイムシミュレーション11初期費用が確保できること導入時は技術習得コスト及びプラントモデル作成コストのため費用が増大する。初期費用が確保できない状況で実施すると，有意義なプラントモデルを製作できなくなり，後の改善効果も見込めない事態が予想される。予算の範囲で，少しずつ適用部位を広げていく方法が適切と考える。上述の条件がクリアできる事業であれば，モデルベース開発の適用を検討する価値があると考える。謝 辞モデルベース開発にあたり，DiaroiD の使用を許可いただいた三菱電機通信機製作所インフラ情報システム部をはじめ，同製作所技術部，三菱電機先端技術総合研究所，三菱電機情報技術総合研究所，三菱電機エンジニアリングに，深く感謝の意を表する。商 標DiaroiD は，三菱電機（株）の登録商標である。MATLAB，Simulink，Simscape は，米国The MathWorks,Inc.の登録商標である。Creo Parametric は，米国PTC Inc.の登録商標である。UNITY は，米国Unity Technologies 又はその関連会社の登録商標である。参考文献春名正樹，川口昇，猿田祐輔，星野隼人, 岡本俊樹，道田塁，上田賢，神田吉孝，佐藤亨，小池俊昭，荻野正樹：人×機械の遠隔融合システムの開発 - 視覚的力触覚を利用した操作提案と基礎検証 -，情報処理学会インタラクション2020 論文集，448～453 （2020）Shota Narasaki，Noboru Kawaguchi，Masaki Hirano，Toshitaka Nakaoji，Yutaka Ezaki，Yusuke Saruta，Hayato Hoshino，Masaki Haruna，Rui Michida，YosukeTomida，Yoshitaka Koda，Toru Sato：Developmentof labor-saving system for the maintenance ofthe telescopes under the extreme environmentusing a remote-controlled robot ， SPIEAstronomical Telescopes + InstrumentationConference (2020)執 筆 者 紹 介神田 吉孝（こうだ よしたか）1991 年入社。衛星通信・宇宙開発に関するソフトウエア開発に従事。現在，第１事業部に所属。