過去のブログ記事 Forge の未来 でも触れているファイルを超えた新しいデータ管理の方法に、クラウドを利用した High Frequency Data の利用があります。オートデスクは、この High Frequency Data を利用する仕組みを High Frequency Data Management（HFDM） と呼んでいて、ファイルに替わるオートデスクの次世代データプラットフォームに位置付けています。
HFDM は、Web ブラウザで動作する Fusion 360、Fusion 360 Web、Web ブラウザで動作する次世代の BIM コラボレーション CAD、Project Quantum、TinkerCAD などのクラウドサービスで既に採用、または、採用されることが決まっています。
今回は、この HFDM を理解する上で基本となる考え方を背景とともにご案内していきたいと思います。
HFDM の必要性
クラウドの登場から大分時間が経過していますが、日本でもデザインや設計の分野でクラウドが活用されつつあります。もはや、なぜ、クラウドが必要なのか？、セキュリティに問題があるのでは？という疑問についての解説は避けますがが、クラウドに関する議論には枚挙に暇がありません。改めて、クラウドの利点や利用すべき理由をお知りになりたい方は、"クラウド 利点" をキーワードに Web 検索 をしてみてください。
さて、HFDM の解説の前に、少し違った視点でクラウドの利用を考えてみたいと思います。昨今、あたりまえのように語られているテクノロジに IoT があります。IoT センサーからは、日々、検出・測定されたデータが生み出されていきます。もし、それらのデータを自社内に設置したサーバーに保存、蓄積しようとすれば、ストレージをどんどん追加していかなければなりません。また、蓄積された膨大なデータ、いわゆる、ビックデータ を解析して一定の傾向や、何らかの特異点を見出そうとするのには、膨大な時間を費やす必要があるのは想像に難くありません。もちろん、データ解析をおこなうソフトウェアを開発したり、購入したりする必要もあるかもしれません。仮に、それらを自社内でまかなえたとしても、データ解析に CPU パワーを使い切ってしまい、他の作業の支障が出るようでは本末転倒です。
そこで、クラウドの登場です。クラウド ストレージは比較的安価で、自社内に物理的なデータ サーバーを用意するよりも簡単にストレージ量を増やすことが可能です。また、解析に必要となる CPU パワーも、必要に応じて伸長的に追加できるのは周知のとおりです。
ファイルをバックアップするストレージとして利用され出したクラウドですが、現在では、クラウドを複合的にどう使っていくかが問われる時代になっています。IoT に話を戻すなら、IoT がもてはやされだしたのは、IoT センサーが生み出すデータの受け皿として、コスト面で優れたクラウドが選択され出したため、と捉えることが出来るはずです。つまり、クラウドの利用が進んだうえの必然的な結果なのです。
さて、設計やデザインの領域ではどうでしょう。一般的には、デザイン データ（ファイル）をクラウド ストレージへバックアップしたり、関係者間で共有する場としてクラウドが利用されているのではないでしょうか。事実、CAD ソフトウェア内ですべての情報を付加してしまう設計手法、例えば、デジタル プロトタイプ や BIM・CIM では、デザイン データ ファイル内に様々な情報を包含するようになり、ファイルサイズが益々肥大化する傾向にあります。メールに添付するには大きすぎるはずです。
他にも問題があります。設計から製造、施工までには、多くの関係者/関係会社が携わるという点です。設計段階につきまとう設計変更やデザインフィードバックの度に、すべてのデザイン情報が含まれる大きなサイズのファイルを関係者の間でやり取りするのは、たとえ、クラウド ストレージを利用したとしても面倒です。同時に、沢山生じることになるデザイン ファイルから、個別の変更点を共有する方法も煩雑になってしまいます。やりとりされるデザイン データは、あくまでファイル単位で、クライアントでファイルを開き、修正、ファイル保存後に再度クラウドストレージへアップロードして共有といった手順です。
なお、オートデスクは、このようなファイル単位のデータを、更新頻度が低い Low Frequency Data と呼んでいます。
ファイル単位のデザインが無事、共有出来たとしても、設計変更の履歴や変更にともなう他社担当デザインへの関連性を見出すのは困難でしょう。ちょうど、IoT 例でのビックデータ解析に近い状態です。
そこで、HFDM の登場です。HFDM では、CAD ソフトウェア毎に異なるファイル単位でのデータ処理に替わって、クラウドにあらゆるデータを蓄積し、履歴や関連性を自動的に記録しながら、多くの関係者間で個別、あるいは、リアルタイムに変更履歴の確認やデザイン評価などを効率的におこなう仕組みを提供します。クライアント側のアプリケーションやサービスは、一元的にクラウドで管理されたマスター データへ、設計変更が生じた部分のみを送信して更新したり、自社に必要な部分のデータのみを抽出、利用することが出来るようになります。これら変更は、リアルタイムにクラウド上のデザイン データに反映されていきます。
オートデスクは、このようなデータを、更新頻度が高い High Frequency Data と呼んでいるわけです。
それでは、HFDM の考え方を詳細に見ていきましょう。
差分データだけの送信
HFDM では、クラウド上に一元管理されたデザイン マスター データがあり、あらゆる情報が蓄積されています。あるクライアントから CAD アプリケーション、または、クラウド サービスを使って新規のデザイン プロジェクトを立ち上げた状態を考えてみましょう。設計者が見ている作図領域（下図左手）は何も作図されていません。当然、クラウドへ保存されるべきデータもありません（下図右手）。
次に、設計者が作図領域に半径 2、中心座標 (2, 2) で青緑色の円を追加したとします。この時、円の追加は、即座にクラウドに反映されていきます。ご注意いただきたいのは、クラウドに送信される情報は、追加された円についての情報のみという点です。
続いて、中心座標 (4, 5) の位置に、幅 2、高さ 3 の青い矩形を追加します。この矩形の追加も即座にクラウドへ反映されますが、送信されるデータは矩形に関するものだけで、作図領域にある円の情報は送信されません。すでにお気づきのように、ファイル単位でデザイン データを扱う場合には、一旦すべての情報をファイルに保存し、クラウドにアップロードしてデータを更新しなければなりません。この方法は、ネットワーク負荷の観点からも無駄が生じていることがわかります。
作図済みの矩形の色を赤に変更した場合も同様です。データ更新でクラウドに送信されるのは、矩形の色に関する部分のみです（矩形を識別する名前や識別子を除く）。矩形の幅や高さ、位置は送信されません。
矩形の幅を変更した場合には、その情報のみが更新データとしてクラウドに送信されることになります。
矩形の位置を変更した場合も同様です。
このように HFDM では、クラウドにデータの集合体としてでデザインがあり、差分データの送信のみでデザイン全体が更新されていきます。
自動的な履歴管理
デザイン データがクラウドで一元管理され、クライアントからのデザイン変更の度に更新データだけが送信されてくるなら、変更が発生した時間、変更の内容、更新データを送信してきたクライアントの特定等の記録は容易です。HFDM では、このような履歴管理機能が最初から備わっているので、過去に遡ってデザイン データの状態を把握することが可能です。
前述の例では、図形の追加や編集内容がすべて記録されていることになります。
もちろん、特定のデザイン データの状態を簡単に復元することも出来るわけです。
ブランチ（Branch）とマージ（Merge）ー 非同期コラボレーション
HFDM では、デザインに関わる各関係者が、個別にデザイン評価や検討をおこなえる仕組みを提供します。この仕組みには、ブランチ（分岐）とマージ（結合）という概念を利用します。
ブランチ
簡単に説明するなら、独自にデザイン評価/検討をおこなう際にブランチを作成し、クラウドで一元管理されたデザインのマスター データに影響を与えずに、つまり、設計変更等の差分データをマスター データに反映せずに、設計変更をおこなうことができる仕組みがブランチです。
次の例では、青い矩形を作図してクラウドのマスター データに反映した後にブランチを作成すると、この設計者独自に三角形を追加、色を変更する設計評価をした状態となります。
各ブランチでおこなった設計変更の検討が関係者間で合意された場合には、ブランチの内容をグローバル ブランチとも呼ばれるマスター データにマージすることが可能になります。マージが完了すると、関係者全員が参照出来るマスター データに、ブランチの内容が反映されることになります。
ブランチによる独自の設計変更は、複数の関係者が同時進行でおこなえる点に注意してください。設計のプロセスでは、他社の設計変更を待たなければならい時があり、いたずらに時間を消費してしまうことがあります。もちろん、必要なプロセスと考えられますが、事前に打ち合わせに応じた考えられるデザイン パターンを用意できれば、全体の時間短縮に繋げることが出来るかもしれません。
あるブランチのデザインをマスター データにマージした場合でも、マスターへのマージ前後の履歴は自動的記録されているので、いつでもマージ前の状態に戻ることが出来ます。もし、複数ブランチからのデザイン マージで競合・矛盾が発生した場合には、ユーザが介在してそれらを解決出来るだけでなく、事前に決めたルールや標準的なルールを適用して競合を解決することも可能です
余談ではありますが、でに Forge サンプルの利用も含め、プログラム開発で GitHub をお使いの方は、Git で利用されているブランチとマージとほぼ同じ考え方であることにお気づきかと思います。また、Fusion 360 でもブランチとマージの考え方が導入されているのはご存じのとおりです。
このように、ブランチとマージは設計者に関係者との非同期コラボレーションの場を提供します。
リアルタイム コラボレーション ー 同期コラボレーション
ブランチとマージで実現可能な非同期コラボレーションですが、場面によっては、関係者間で同時にデザイン評価・変更を検討したいときもあります。よく、リアルタイム コラボレーションと呼ぶこの方法は、関係者全員が参照可能なグローバル ブランチ（マスター データ）を使って、各クライアントからの変更をリアルタイムにマージしていくことで実現可能です。
このリアルタイム コラボレーションは、ちょうど、過去のブログ記事 TinkerCAD Beta で見る High Frequency Data でご紹介した動画でも把握していただけるはずです。なお、現在 TinkerCAD は日本語化されて Beta ではなくなっています。
アクセス管理
すべての設計者、関係者が一律にマスター データにアクセスしては混乱が生じてしまいます。HFDM でも、アカウント管理によってアクセス可能なデータや書き込み／読み込み等のアクセス権限を設定することが出来ます。
ここまでの説明を理解いただくと、HFDM データは永続的にアクセスすることが保証されているのか？、既存のデザイン ファイルをインポートして HFDM データ化出来るのか？、また、HFDM データを特定のデザイン ファイル形式でエクスポート出来るのか？など、多くの疑問を持たれるかもしれません。
By Toshiaki Isezaki
Subscribe
コメント