# Final Exam gogo

## 第三題

### 3.a
#### IoT-A Unified Requirement
[IoT-A Unified Requirements list](https://scratch-itea3.eu/sota/iot_a_uni/list?orderby=uni_id&ordertype=ASC)
#### 題目要求:
大概是要我們從 Project 中想出兩種 usecases
並且根據這兩個 usecases 的使用情境中
標明它 有哪些 requirement 規格，至少舉出三個(FR,NFR,DC 就各一種吧)，並且按照IoT Reference Architecture.pdf p.88 的表格，填上規格

舉例：**使用者要開啟貨架**
requirement
1. rationale:user 需要開啟貨架
2. description:系統需要設計一個可以掃貨架QR Code的介面
3. ...

#### 補充FR,NFR,DC:
[FR,NFR比較](https://wayne265265.pixnet.net/blog/post/114240494-【筆記】功能性需求與非功能性需求比較)，簡單來講NFR比較抽象，有點像外行人開的需求XDD，FR則是比較具體的需求。

DC的話
我的理解是，為了要滿足某個功能(例如必須建DB)，但又要操控方便，所以被迫寫了一個控制DB的Server(較被動的被設計出來，不是原本就想到要做這個東西，因為FR,NFR比較像主動提出的需求)
### 3.b

### 3.c
#### Butler
butler 是一個串起整個系統的架構，
以 component 的觀點來看的話，最主要可以分為 3 種 entities
1. SmartObject: 一些 sensor，用來取得我們想要的環境資料
2. SmartServer: 資料數據處理中心
3. SmartMobile: 使用者可以用來跟系統互動的介面，像是手機等等

而以 layer 的觀點可以分成
* communication layers
* data management layer
* system/device management layer
* service layer

#### 解法
所以我覺得我們這一題應該要想辦法把我們的 project 對應到這 3 種 entities，
然後再把他們歸類到這幾種 layer 裡，並且說這幾種 layer 彼此之間怎麼互相溝通
#### 舉例
可以看這個 use case
他的
* SmartObject: 是停車位上的 sensor
* SmartServer: 就是綠綠的那台
* SmartMobile: 就是用來觀看系統狀態的平板
### 3.d
#### iCore
iCore system 是一個管理 object 的一個系統，可以想像他是一個指揮官，會讀取我們寫好的 requirement，來看要完成那些任務，然後去想要調用哪些 object 的功能，來完成特定的任務，然後就這一次運行的過程，來檢討自己。
這張圖要從上往下看，先看需要哪些服務，然後再呼叫 CVO level (composite virtual object)，然後 CVO 再去引入 VO，最後 VO 則會去執行相對應的 RWO (real world object)，藉此來執行上級長官指派的任務。
而右邊藍色以及綠色的線，就是指新的 RWK (real world knowledge) 和 SK (system knowledge) 減掉舊的 RWK 和 SK 所得到的經驗值，最後再回饋給 service level 和 cvo level
#### 解法
因此，他要我們寫出一個 icore system 來完成我們的 iot 系統，並且把我們的 object 寫成可以被 icore 操縱的 virtual object，並且落實
* aggregation: 將數個 object 整理及組裝成一個大的
* abstraction: object 抽象化，讓 icore 可以更簡單的了解到這個 object 的用處
* functional enrichment: 透過抽象的 object，可以輕易的新增新功能到系統中
* 
### 3.e
middleware 是中介軟體，用來串聯兩個 node 之間的媒介
1. OOM: object-oriented middleware，
2. OEM: message-oriented middleware
3. EBM: event-based middleware
#### 解法
我應該直接寫 EBM，也就是 MQTT 的模式，分為 publisher 跟 subscriber，每一次的 publish 都是一個 event，然後藉由 broker 把訊息轉發到 subscriber 那邊
### 3.f
Digital shadow 就是就是可以用來代表一個人的代表物，上面有一些資訊可以間接的本人，但卻沒有儲存本人最重要的 ID、指紋等等，像是有寫著醫師姓名的白袍，可以間接的表達醫師在醫院裡的角色。
## 第四題
### 4.a
#### Agent-based sensor middleware
也就是為每一個 sensor 設立代理人，將所有的 sensor 彙整起來，統一向外提供 service，而這個代理人也可以對 sensor 進行管理、詮釋、參數調整等等

#### 解法
所以我覺得這一題得重點應該著重在寫出一個 use case，需要大量 sensor 互相彼此配合，且 sensor 很有可能會時常會有增減，所以需要能快速的調整 sensor。
### 4.b
### 4.c
#### MQTT
Pub/broker/Sub
#### 解法
可以著重在一個設備，會有許多的小裝置的 use case，像是客廳可以有燈泡、電視，topic 就可以寫成 `url/livingroom/light` 或`url/livingroom/tv ` 這樣我們就能很方便分開管理每一個裝置
### 4.d
* system dependability: 系統的可靠程度，例如系統不會做出使用者意料之外的事情或者是毀損使用者的資料
* protocol and network security: 要在不同的裝置進行通訊，期間的通訊管道必須經過加密以及保護，才不會在與 smart phone 或者是 server 通訊時，不小心就把重要資訊給外洩。
* identity management: device 除了具備 ID 以外，可能還具備有多種 feature，來讓其他 device 可以辨識他，但又不會讓他洩漏太多自己的身分
.
為了讓上層的 service manager、proxy 等等可以順利的取用他，又額外提供一些 grouping 的功能。
.
身分也有可能會被造假，所以還要提供 mutual auth 的功能
* trust and governance
* IoT 服務需要一套機制讓使用者能夠信任
* 需要有一套機制可以管理（governance）
* 例如：有人對其他人做壞事，要有辦法懲罰做壞事的人
* data & service privacy
* privacy: 必須提供一套給使用者使用的動態認證機制，選擇自己想要曝光多少隱私
* transparent: 使用者可以知道自己有多少 data 被使用
* data management: 讓所有取用使用者 data 的 device 可以遵守因應不同情況所訂定的規則。
* fault tolerance
3-step
* 所有的裝置一開始就要很 secure
* 就算沒辦法保持在 secure 的狀態，裝置還是要可以察覺自己當前的狀態
* 裝置必須可以抵抗連線失敗或者網路攻擊，或是在失去控制時關閉自己，免得其他裝置也受到攻擊
## 第五題
### 5.a
#### OPC UA
real object: 系統內真實的物理物件或者是軟體。
addressspace: 整個系統的 virtual obejct。
#### 解法
把我們系統寫成許多的 node，並且把他加入 address space，最後寫出一些 monitoritem，來訂閱我們 adress space 裡面的 node，使的有任何 event 發生時，可以通知使用者。
## 第六題
[Fog Computing, Mobile Edge Computing, Cloudlets - which one?](https://www.iaria.org/conferences2016/filesICSNC16/Softnet2016_Tutorial_Fog-MEC-Cloudlets-E.Borcoci-v1.1.pdf)
[Cloudlet](https://en.wikipedia.org/wiki/Cloudlet)
### 補充
[論文](http://www.eurecom.fr/en/publication/5193/download/comsys-publi-5193_1.pdf)