目前因Greengrass IoT有協助解決原本存在於Greengrass上的問題，因此打算這階段就恢復使用Greengrass取代MQTT。

以Greengrass的概念我們必須把所有東西container化。因此在這個階段就先使用之前已經準備好CI/CD搭配Jenkins+ArgoCD的部分，把DevOps概念先導入。

整體而言我們可以將架構圖改成以下:

紅色虛線框框代表我們這次要著重的，在於cloud的virtual環境。

主要三項重點如下:

• API design first
  因為我們未來會需要實際供應給，不同教育單位(or廠商)在雲端上可以模擬device的運算機器，所以在API一開始就應該以不同orgainzation做分離。

POST /organization/<organization_id>/device/
GET /organization/<organization_id>/device/<device_id>
GET, POST /organization/<organization_id>/device/<device_id>/message/<topic_name>

上面包含要取出的設備ID，與該設備可以監聽與送出的ROS topics(包含自定義topics)

GET /organization/<organization_id>/device?type=physical
GET /organization/<organization_id>/device?type=virtual

還可以依照虛擬或是在local端真實的edge devices，各別做取出設備列表資料的動作。

• Creator動態產生virtual devices運算環境。
  

為了方便控管運算配置資源(cpu/memory)與動態擴展VM node，我們將整個ROS cluster的機制建置在EKS上，這個在前幾篇文章有提到。

unity_env_creator程式會在當前端呼叫POST /organization/<organization_id>/deviceAPI時，在EKS上產生一個新的EKS POD，該POD中的device會自動與Greengrass做Authorization，且裡面包含Unity以及要跑的Unity 3D model(含modeling過後的sensors)，和要執行的AI訓練程式。

訓練過程，Unity node會主動將資料交由Greengrass Bridge ndoe，把ROS topics訊息傳給Greengrass，同時也將ROS topics的資料按照timestamp順序儲存在DynamoDB。client端的用戶可以透過不管是Web(上一篇提到的前端讀取檔案格式與顯示的方式)，又或是直接開啟Unity來同步取得(call API)訓練過程的ROS topics的資料，來同步呈現畫面。

訓練完畢後，產生的pre-trained model(.pickle)就會儲存在AWS S3中，提供給後續不管是virtual還是地端physical的devices使用。這部份詳細流程，與之前在我medium提到PAIA系統怎麼在雲端上train model大同小異。但這裡與PAIA稍微不同的是，這些virtual devices在訓練完畢後，大部份是不必自動刪除掉(可利用API帶參數控制)，因為DigitalTwins(數位雙生)的概念，我們會有狀況是實體與虛擬同時存在互為mirror。

• Jenkins搭配Greengrass做設備(virtual and physical)動態更版部署。
  

Deployment是在架構圖中顯示綠色的部份。因為Greengrass除了MQTT的功能外，它也包含了與設備(virtual and physical)之間的TLS認證，與元件(component)更版的流程控制。

因此當我們元件的code(commit or tag)有更版的時候，因統一由Jenkins決定更新哪一個service(API, Creator, or trigger Greengrass deployment process)或component，這個部分就需要寫較多大量的scripts(可使用Greengrass cli)來完成。

這樣就完整利用到AWS cloud的服務，完成我們這專案要做的POC架構。

其中Virtual環境的部分，AWS有提供robomaker的solution，但因為在今年6/27號的時候，robomaker的features有一些change，暫時先不考慮變動比較大的service。

目前這架構還在與AWS討論階段，期望可以在鐵人賽結束前完成這架構的POC。