你有看過不打開Revit、不依靠任何操作，僅選擇Revit專案檔，就能完成接合模型元件嗎?這篇文章中，我們會使用【Design Automation】、【 Revit API】和網頁開發的技術來建構這類全自動化的操作。我們會逐步介紹Design Automation環境的運作機制，並解釋Revit API和網頁平台在Design Automation環境中扮演的角色。
上傳下載，接合完成
先來看一下我們的最終成果。
如果你有興趣玩看看，連結在此。
（如果你選擇跳過影片，這裡我們來解釋一下內容：影片裡選擇Revit專案檔並選擇Revit版本後，瀏覽器會自動處理模型，並下載接合好的Revit專案檔。）
發生什麼事
自動接合模型的腳本，在Autodesk App Store、Revit API（註1）範例、Dynamo範例中並不是新鮮事，但這些應用程式與範例，都需要在Revit的環境下執行；也就是說，若使用手機、平板，Mac作業系統的使用者，或甚至我的Windows電腦裡沒有安裝Revit，都會因為沒有Revit環境而無法執行自動接合模型任務。
Design Automation為了解決這個問題，建構了一套雲端環境。若要用一句話解釋Design Automation環境，就是「在雲端跑一個Revit讓所有人執行Revit的外掛。」然而，要建構這樣的環境，需應用到多樣技術，包括Revit API和網頁開發，才能在使用者的終端設備、網頁、雲端環境、雲端環境中的Revit間互相溝通協作。
下圖一展示了Design Automation環境的運作機制，可以粗分為「Design Automation」和「網頁應用程式」兩大模塊。Design Automation模塊為Autodesk架設的雲端環境，運行了無數個Revit應用程式，並開放一系列Design Automation API供開發者調用。開發者可運用這些API來掛載客製化的Revit外掛（Design Automation Apps）至雲端Revit應用程式，也可呼叫這些API來執行已掛載至雲端的Revit外掛。
另一模塊為網頁應用程式，此模塊與多數的網頁應用程式架構相同，負責處理網頁與使用者的互動，大多包含網頁前端（front-end）與與後端（back-end）兩部分，前者處理互動介面，後者處理資料、服務串接等系統邏輯，然而依不同的使用情境，可能會更細分網頁應用程式的架構，在此先不討論。而在「Design Automation」和「網頁應用程式」兩大模塊之間，會以呼叫Design Automation API來溝通，並以傳遞Revit 專案檔（.rvt）作為媒介。
圖一、Design Automation運作機制概念圖
註1：應用程式介面（Application Programming Interface, API）:一種計算介面(computing interface)，定義多個軟體中介（middleware）之間的互動。(https://zh.wikipedia.org/zh-tw/应用程序接口)
Design Automation反思
Design Automation的雲端環境，看似打破以往應用的藩籬，讓使用者不需開啟Revit應用程式即編輯Revit專案檔，卻讓Revit模型檔不可避免地經過Design Automation開發者和Autodesk的伺服器。部分公司與使用者可能因公司慣例或資訊安全而對Design Automation 環境卻步。
筆者認為，以營建產業數位轉型的角度而言，使用雲端服務是不可避免的。舉例而言，雲端服務，如：Microsoft Teams, Gmail, Google Drive, Dropbox，提供了便宜且可靠的應用，在日常生活與工作中，幾乎無法擺脫這些雲端服務。因此，我們應把焦點放在，如何在便利的雲端服務與資訊安全間取得可接受的平衡。每個人或公司可能有不同的標準，但筆者在此分享個人觀點，拋磚引玉：多數人能接受使用大公司提供的雲端服務（如：BIM 360，Google Drive，Microsoft Teams）來儲存專案資料，信任大公司的雲端服務不會盜用使用者資料，因其有明確資訊規範並受大眾監視；相反地，小公司因規範不透明，也不受大眾監視，而有資料盜用風險。因此，在Design Automation的導入中，團隊或公司內應自行建立基於Design Automation的服務，而非使用第三方開發者提供的Design Automation服務。如此一來，Revit專案檔僅會經過自己與Autodesk的伺服器，大大減低資訊被盜用的風險。
我們專注於加速營建產業的數位轉型，也樂於嘗試各項新興資訊技術。若有任何自動化、數位化的想法或需求，歡迎和我們團隊聯絡。
Comments