Question 1

手機第一次開機日期Linn / 老娘才不是日本人 在Facebook 的評價

Accepted Answer

【踏上日本的第一天】  ⠀⠀  ⠀⠀六年多前，櫻花盛開的某一天，我第一次踏上日本國土。那天也是我開始在日本居住的日子。  ⠀⠀對，在那之前我從來沒有來過日本，第一次來就是開啟日本留學之旅。  ⠀⠀許多人都說我這樣的行為很有勇氣，但當時真的沒想太多，只是憑著一股莫名的大膽直覺，想著應該不會有問題。  ⠀⠀  ⠀⠀出發當天一早到機場，在等待時，很努力不展現太多情緒，但揮別家人朋友出關的瞬間，一轉身眼眶就紅了，又不敢回頭，怕被他們發現。  ⠀⠀到了成田機場，一下飛機，深呼吸一口，聞到的是跟台灣完全不同的氣味。原來不同國家的空氣聞起來是這麼的不一樣！這是第一次出國的我以前從不知道的事。  ⠀⠀   ⠀⠀＊ ＊ ＊  ⠀⠀  ⠀⠀殊不知挑戰接下來才開始。外面是陰雨天，搭上 Skyliner 離開機場，到達日暮里出站後，我發現自己必須兩手拖著行李，沒有辦法一邊走路一邊看地圖。  ⠀⠀天生就是路痴的我拖著 30 公斤的行李，在人生地不熟的東京，毫不意外的迷路了。  ⠀⠀在離家兩千多公里外的地方迷路，搞不清方向；而行李因為太重，行李箱的輪胎好幾次卡在導盲磚上面，使勁力氣也拖不動。  ⠀⠀ 不管我再怎麼用力拉，距離還是只能前進一點點，內心的情緒早已從緊張興奮變成無力。由於雙手都要拉行李，我也沒有多餘的手可以撐傘為自己擋雨，只能任由雨滴打在身上跟行李上。  ⠀⠀ 冷冷的陰雨天，來來往往的行人沒有一個人願意停下來幫我，甚至臉上表情很明顯的顯現出我擋到他們的路了，用無聲的眼神叫我趕快閃邊。  ⠀⠀當下內心真的好想好想回家。那是第一次，感受到東京的冷漠，感受到自己是個外來者。  ⠀⠀幾小時前在國境內忍住不潰堤的淚，到了這裡終於聚成雨滴，一起掉了下來。  ⠀⠀  ⠀⠀＊ ＊ ＊   ⠀⠀  ⠀⠀雙手一邊拖著行李一邊淋雨，在路上找到遮雨處時就查 Google Map 跟乘換案內，好不容易抵達秋葉原，找到要暫時落腳的 Airbnb 的所在地。  ⠀⠀是的，我的東京留學之旅第一個住宿處，不是學校宿舍，也不是飯店，而是一個素未謀面的人的家裡。  ⠀⠀出發前家人一直很擔心我，因為那時候我甚至還沒找到一個固定的住處，就直接飛來日本了，再怎麼看都是一個很莽撞的行為。  ⠀⠀我知道有些人會先來日本一趟，找房子順便簽約，但當時的我沒有時間、也沒有多餘的錢能這麼做。  ⠀⠀好不容易在網路上看到一間可以立刻入住、初期費用又比較便宜的 sharehouse，但還是必須到場看屋過後才能簽約入住，於是我在台灣時先在網路上預約好看屋日期，但在那之前必須先暫住在旅館或民宿，並且準備好手機號碼等聯絡方式。  ⠀⠀暫時住的地點，我想要選擇離大學近一點的地方，便上網搜尋，找了到一間位在秋葉原的 Airbnb。  ⠀⠀Airbnb 是一種把家裡空房當成民宿出租的服務，當時很流行。價錢會比住在一般飯店或民宿實惠許多，還有機會跟屋主交流，瞭解更多當地的文化。簡單來說，就像是要錢的沙發衝浪，但會提供你比較好的住宿條件。  ⠀⠀我找到的這間秋葉原 Airbnb 評分五顆星，而且所在位置交通方便，價錢又便宜，看起來也滿安全的。即使屋主是兩位男生，但評分中不乏女性的背包客說他們很友善而且是很棒的嚮導，因此我便抱著一點緊張的心情按下預約鍵。  ⠀⠀Airbnb 在預約時，必須寫一段簡單的訊息自我介紹，表明自己是誰、為什麼想預約這個房間。我在訊息裡說明，我是即將來東京的留學生，還沒有找到房子，因此想在你們那裡住兩三天，簽好租房契約再搬去新家。  ⠀⠀訊息送出。系統顯示預約成功。  ⠀⠀可是我馬上就後悔了。  ⠀⠀雖然嚮往，但以前從沒有住過 Airbnb，一個女生在人生地不熟的國家，住在男生家裡真的好嗎？  ⠀⠀雖然有數十筆來自不同人不同國家的評價，但如果那些評價都是假的怎麼辦？還是要住普通的旅館就好？  ⠀⠀不安的想法在我的腦海裡突然上演刑事劇場，一番天人交戰之下，我又按下了取消預約鍵。  ⠀⠀卻在此時，屋主 R 正好捎來了訊息。   ⠀⠀  ⠀⠀＊ ＊ ＊  ⠀⠀   ⠀⠀「嗨，你是台灣人嗎？要來東京留學啊？之前也有很多台灣人住過我們這裡喔！」  ⠀⠀「⋯⋯咦？要取消了嗎？」時機太過巧合，R 大概是送出了上一則訊息後，立刻收到取消的通知。  ⠀⠀『啊，抱歉，我⋯我還不確定去日本之後找房子要多久、需要住幾天，所以想說確定再重新預約。』這時候哪敢老實說，我怕你們是壞人所以才要取消的。  ⠀⠀「原來你還沒找到房子啊！真辛苦啊～」  ⠀⠀「如果你需要的話，可以多住幾天，等找到房子再搬走沒關係喔。雖然中間可能會有其他背包客入住。」  ⠀⠀『⋯⋯真的可以嗎？真是太謝謝你了！』此時我早已忘記什麼不安，只覺得遇到救世主了，立刻再重新預約一次。現在回想起來，真是不知道自己哪來的熊膽。   ⠀⠀＊ ＊ ＊  ⠀⠀   ⠀⠀於是我在東京第一個落腳的地方，就是那位在秋葉原附近的小而溫馨的家。   ⠀⠀屋齡看起來有二三十年以上，兩層樓的木造建築，地板是傳統的榻榻米。屋裡四處擺滿動漫公仔、遊戲機、各國啤酒的玻璃瓶，看得出來住在這裡的人熱愛次文化，與它傳統的木造外觀十分衝突。   ⠀⠀而我在東京認識的第一個朋友，就是 R 和他的室友 H，還有那天剛好從北海道來玩而留宿的 K。   ⠀⠀一整天長途跋涉的我全身狼狽，因為淋了雨覺得身體有點寒冷，好像心也著涼了。在東京街頭拖著大行李箱緩步前行時，只覺得自己不屬於東京這個大城市，沒有自己的「居場所」，也不敢想像未來的生活。  ⠀⠀可是不知道為什麼，這個燈光昏黃的老房子，卻讓我有種自在的安心感。是這裡接納了無處可去的我。  ⠀⠀那天他們跟我分享過往的背包客們留給他們的土產——來自世界各國以及日本各地的銘酒，以及有些好笑又有些曲折的旅行故事。  ⠀⠀我們四人就這樣徹夜長談，分享彼此的經驗和價值觀，以及一些無用的垃圾話。  ⠀⠀他們不停的說「妳實在是太有趣了」，然後我回敬「你們也不差啊」。我才知道，人與人之間聊不聊得來、能不能當朋友，跟母語或國籍一點關係都沒有。  ⠀⠀也是他們三人的親切與款待，讓我卸下心防，對東京的印象有了一百八十度的轉變。   ⠀⠀H 把電話號碼借給我，讓我可以申辦自己的手機門號；K 明明是要來東京玩的，卻說怕我迷路，特地陪我搭了一段車送我到離學校最近的車站。  ⠀⠀因為受到他們的幫助，我在留宿這裡的三天內，順利簽約了接下來要入住的房子，也跟教授見了面，完成了該辦的手續。  ⠀⠀『這三天謝謝你們的照顧了。』   ⠀⠀「有空隨時歡迎來玩啊！鑰匙放在外面，妳可以自己進來。大學院加油喔！」   ⠀⠀『好，我會的！』  ⠀⠀就這樣，我告別了秋葉原 Airbnb，順利搬到接下來要住的sharehouse，正式展開了新生活。雖然 30 公斤的行李還是很重，我的步伐卻輕快了許多。  ⠀⠀  ⠀⠀＊ ＊ ＊   ⠀⠀  ⠀⠀幾年之後，R 和 H 因為各自的工作和人生規劃而搬家了，秋葉原 Airbnb 也劃下了句點。  ⠀⠀但那個秋葉原的老房子，是我東京生活的起點，也是我永遠都忘不了的回憶之一。  ⠀⠀＿＿  ⠀⠀照片為R 跟 H 家附近的竹町公園，攝於 2015 年 4 月 2 日。那是我來日本的第二天，看到這株開得正美的櫻花樹，忍不住駐足許久。  ⠀⠀＿＿〈後記〉  ⠀⠀最近開始把以前留學時期隨手寫的一些文章重新整理、排版。  ⠀⠀朋友問我怎麼可以記得這麼鮮明，其實是因為我來留學第一年時，自己做了一個 365 計畫，在 IG 的私人帳號裡每天都 po 一張照片然後寫下簡短的日記。  ⠀⠀現在才知道，來日本第一年那種看見什麼都覺得新奇、每天都有許多新想法迸發的日子，真的特別珍貴，過去就回不來了。雖然 365 計畫只持續了一年，但很感謝當時的自己有做這件事，才能讓現在的我回頭想想初衷，跟過去的自己對話。  ⠀⠀【踏上日本的第一天】這則，是我自己也特別喜歡的一則故事，最美的地方是，這些都是真實的。  ⠀⠀真實的部分還包括，其實當我開始了充實的留學生活後，幾乎很少有機會再跟 R 和 H 見面了。有時候萍水相逢就是這麼一回事吧。  ⠀⠀這一則故事先在 IG 上面連載的，因為完結了，也放到粉專這邊來。IG 上面有不同的照片可以看，歡迎追蹤。  ⠀⠀#Linn日本留學物語，是我在日本留學期間發生的故事，今後也會在 IG 上繼續連載，請多多指教。￣￣￣￣￣￣￣￣￣￣￣￣💛 追蹤 Linn 的 IG 看更多日本生活故事｜（IG 跟臉書有不一樣的內容呦）｜@linzomajp  ⠀⠀💛這篇文章的多圖好讀版在我的部落格：｜https://bit.ly/3uYLDOS＿＿＿＿＿＿＿＿＿＿＿＿

Question 2

手機第一次開機日期台灣物聯網實驗室 IOT Labs 在Facebook 的評價

Accepted Answer

佈署 IoT Edge 和霧運算技術以開發智慧建築服務2021年2月19日 星期五《3S MARKET》這篇報導把物聯網的架構與實作，描寫的非常詳細，雖然在建築的細節上描述不多，但報導中也提及這是個實際驗證，可適用在很多的場域。不知道，有多少人真正看得懂？當然，連這篇都看不懂的人，就別說他真正了解物聯網、Edge 與 Cloud。事實上這篇報導的描述不難了解，真正物聯網與邊緣運算的挑戰，是在實作。實作真正面臨的，是這些數據處理、融合、分析上的完整度，還有 —— 找到實作的場景！ 摘要基於 SoC 架構的嵌入式系統的進步，使許多商業設備的開發變得足夠強大，足以運行操作系統和複雜的算法。這些設備整合了一組具有連通性、運算能力和成本降低的不同感測器。在這種情況下，物聯網（IoT）的潛力不斷增加，並帶來了其他發展可能性：「事物」現在可以增加數據源附近的運算量；因此，可以在本地系統上，佈署不同的物聯網服務。這種範例稱為「邊緣運算」，它整合了物聯網技術和雲端運算系統。邊緣運算可以減少感測器與中央數據中心之間，所需的通信頻寬。此方法需要管理感測器、執行器、嵌入式設備，和可能不連續連接到網路的其他資源（例如智慧手機）。這種趨勢對於智慧建築設計非常有吸引力，在智慧建築設計中，必須整合不同的子系統（能源、氣候控制、安全性、舒適性、使用者服務、維護和營運成本）以開發智慧設施。在這項工作中，分析和提出了一種基於邊緣運算範例的智慧服務設計方法。這種新穎的方法，克服了現有設計中與服務的互操作性，和可伸縮性有關的一些缺點。描述了基於嵌入式設備的實驗架構。能源管理、安全系統、氣候控制和資訊服務，是實施新智慧設施的子系統。1. 簡介建築自動化系統使用開放式通信標準和介面，可以整合多種不同的建築控制規則，例如供暖、通風、空調、照明和百葉窗、安全功能和設備。但是，現有建築物通常不具有這些系統。通常，每種安裝類型都提供特定的服務：供暖通風和空調（HVAC）控制氣候服務，攝影機和感測器提供安全服務等。僅當設計能源管理系統時，不同的子系統相關，但僅透過以下方式，連接建築物的能源管理系統。能源管理服務，集中在專用軟體中。對於使用者和維護技術人員來說，提供不同服務的不同製造商，發現很難整合新的服務和功能。自動化建築將用於控制和數據採集的軟體，與工業協議和介面整合在一起。此外，將新服務整合到這種解決方案中並不容易，這取決於已安裝軟體的開發。這些工業發展還為能源管理，提供了雲端連接解決方案和智慧服務。這些服務，也在集中式電腦系統中開發。數據被傳輸到這些系統或雲端進行分析。本文提出使用佈署在物聯網（IoT）技術中的邊緣和霧運算範例，主要有兩個目的：A. 在自動化和非自動化建築物中，促進新的智慧和可互操作服務的整合（整合）。B. 允許在建築物的所有子系統之間，分配智慧服務（互操作性）。透過該建議，可以促進建築物子系統之間的關係。它還促進創建新的智慧服務（例如，新的分佈式智慧控制算法；使用電源管理捕獲的數據，來檢測人類活動；捕獲設備連接的模式辨識，運算可再生電力預測，在安全服務中使用電力數據等）。在這項工作中，我們設計了一個中間軟體的體系結構，該體系結構具有兩個主要層，這些層基於嵌入式設備、IoT 通信協議和硬體支援，來開發人工智慧算法（圖1）。為了實現這一目標，我們在建築物的設施中添加了兩個概念等級：邊緣節點和霧節點。每個等級都有不同種類的設備和功能。我們佈署並實現了基於層的中間軟體的體系結構，以對模式進行實驗。 本文的組織結構如下：第 2 節回顧了智慧建築技術，建築物中的 IoT 佈署以及邊緣運算範例。第 3 節提出了一種在建築物（自動與否）中佈署邊緣和霧運算範例的方法。第 4 節介紹了進行的實驗。最後，第 5 節介紹了結論和未來的工作。2. 相關工作本節介紹與這項工作相關的主要研究領域。首先，我們在分析雲端運算層之後，回顧了基於邊緣運算範例的資源和服務供應。最後，我們研究了實現智慧建築的技術，並在最後的小節中，總結了先前研究的貢獻。2.1. 邊緣運算資源和服務供應最近，網路在兩端被標記為「邊緣」和「核心」，以查明處理發生的位置。邊緣端靠近數據源和使用者，核心端由雲端伺服器組成。透過這種方式，邊緣運算範例將運算推送到 IoT 網路的邊緣，以減少數據處理延遲，和發送到雲端的數據數量。基於雲端的後端，可以處理對時間不太敏感，或源設備本身不需要結果的處理請求（例如，物聯網網路狀態下的大數據分析）。在邊緣運算資源供應方面，正在進行的 Horizo​​n 2020 RECAP 項目，提出了一種整合的雲端 - 邊緣 - 霧端架構，目的在解決應用放置、基礎架構管理和容量供應。雲端/邊緣基礎架構監控功能豐富了應用，基礎架構和工作負載模型，這些模型又被回饋到優化系統中，該系統可以協調應用並持續配置基礎架構。徐等人進行的研究。 提出了一種用於邊緣運算的實用感知資源分配方法，稱為 Zenith。借助 Zenith，服務提供商可以與邊緣基礎設施提供商，建立資源共享合同，從而允許延遲感知資源調配算法，以滿足其延遲需求的方式，來調度邊緣任務。邊緣節點資源管理（簡稱 ENORM），是管理邊緣/霧節點資源的框架，可透過監控應用需求，來自動擴展邊緣節點。可以透過靜態優先等級分配，來確定特定應用的優先等級。供應和自動縮放機制，是基於線性搜索的相對簡單的實現。當源本身是可行動的時，邊緣雲範例也是可行的。 Chen 等人研究了行動設備向邊緣節點（特別是在無線電接入網路邊緣）的智慧運算分流。在這項工作中，作者提供了任務卸載算法，將分佈式運算卸載決策表述，為多使用者運算卸載功能。在同一項工作中，Wang 等人研究了聯合協調卸載任務，到多個邊緣節點的問題，並提出在邊緣等級引入及准入控制，以及兩階段調度方法，與傳統的最近邊緣選擇方法相比，改進了卸載性能。 2.2. 雲端運算服務配置就社會和行業採用資訊技術而言，雲端運算範例是最具創新性的策略之一。提供的優勢提高了效率，並降低了成本，同時提供了可透過 Internet，普遍存取訪問的按需 IT 資源和服務。當前，雲端運算服務種類繁多，甚至如何提供，這是一個受到廣泛研究的主題，正在提出許多的方案。甚至有評論總結了雲端運算範例的相關研究。本小節介紹了有關以下問題的先前工作，這些問題與本手稿的主題有關：（i）安全性； （ii）服務品質（QoS）； （iii）提供邊緣服務。（i）安全是雲端運算中一個具有挑戰性的問題。雲端服務位於應用環境之外，並且超出了防火牆的保護範圍，因此，需要附加的安全層。另外，邊緣和霧運算應用的行動性和異構性，使得難以定義單個過程。因此，需要一種分佈式安全策略。此外，必須有一個標準化的環境，才能正確解決此問題，並指定霧運算和邊緣設備，如何相互協作。網路邊緣上的多個霧節點之間的敏感數據通信，需要資源受限的事物的輕量級解決方案。另一個與安全性相關的問題是數據位置。在雲端中運行數據分析是很常見的。因此，關於數據安全或隱私的公有雲與私有雲的爭論就出現了。（ii）分配給雲端應用的資源，通常是根據合同規定的服務水準協議（SLA）所設置的。但是，實際上，由於偶爾執行大量事務，而導致分配的基礎結構飽和，可能會出現瓶頸。為了解決此問題，可以在資源可用時，動態擴展雲端基礎架構。當前，最具創新性的趨勢，目的在建構自動 SLA 合同合規系統。在 Faniyi 和 Bahsoon，以及 Singh 和 Chana 進行的研究中，可以找到與品質服務管理相關建議的詳盡綜述。考慮到這一點，提出了幾種策略來預測，應用的資源需求和 QoS 的要求。最近的工作試圖將安全性和 QoS 問題結合起來，以提供全面的性能指標。（iii）最後，濫用雲端服務，是該領域的另一個問題。物聯網環境是霧和邊緣設備不斷加入或離開，動態的執行前後關聯。因此必須在網路邊緣提供彈性的服務。為此，在網路的可用設備之間，共享應用工作負載，可以為高階運算應用提供靈活性。提出了可靠的服務供應方法，來為系統提供更高的彈性，並提供靈活和優化的雲端服務。在本主題中，將雲端框架和中間軟體技術，設置為與雲端層，以及具有不同介面操作系統，和體系結構的設備之間，進行通信的平台。 2.3. 物聯網在建築服務工程中物聯網開發為在建築物上，開發數位服務提供了新資源。建築物中常見的物聯網應用，包括節能的過程環節、維護改進、雜務自動化和增強安全性。由於全球變暖，建築物的節能是一個重要的課題。物聯網技術引入智慧建築，不僅可以減少本地溫室氣體排放，還可以將減少溫室效應擴大到更大的領域。目前，物聯網還被用於建築領域，以協助設施管理。物聯網使營運系統能夠提供更準確和更有用的資訊，從而改善營運，並為房客租戶提供最佳體驗。有基於物聯網的建議，這些建議顯示建築系統，如何與雲端進行通信，並分析所獲取的數據，以開發新的業務見解，從而能夠推動真正的增值和更高的績效。實驗研究顯示，物聯網平台不僅可以改善，工業能源管理系統中實體的互連性，而且可以降低工業設施的能源成本。 FacilitiesNet 表示，建築物聯網（BIoT）正在推動我們獲取資訊，彼此互動和做出決策的方式發生重大轉變。BIoT 不僅與連接性或設備數量有關，而且還與交付實際和相關結果有關。當前，有很多基於物聯網的智慧家庭應用的例子。然而，智慧設備或「物」，僅僅是連接到網路的設備或嵌入式系統。增值來自設計協調系統，和提供智慧服務，以提供實際收益的能力。這些特徵基本上，取決於對不同類型連接事物的異質性，及其互操作性的管理，並取決於數據處理提供的情報潛力。Tolga 和 Esra 進行的研究得出的結論是，就智慧家庭系統中的軟體和硬體而言，物聯網技術尚未變得穩定。原因之一，有可能是物聯網技術仍處於發展階段。McEIhannon 所撰寫有關物聯網應用的邊緣雲和邊緣運算的未來，其評論得出了類似的結論。這篇評論提到概念和發展，目前還處於早期階段，從學術和行業的角度來看，許多挑戰都需要解決。物聯網帶來了新的機會，但許多企業仍在尋求了解和分析，其將如何影響，並與現有的 IT 結構和管理策略整合。為此，必須創建專門的使用模式和技術，來彌合這一差距。2.4. 發現以下結論闡明了這項研究建議的新穎之處：雲端運算作為「實用」的一般概念，非常適合智慧家庭應用的常規需求。但是，在某些情況下，將所有運算都移到雲端中，是不切實際的。邊緣計算作為一種計算範例而出現，可以在物聯網設備生成的數據附近執行計算。這種範例可能有助於滿足最新應用的安全性和 QoS 的要求。當前，控制子系統的高級建築設施，通常使用 Internet、IoT 協議和 Web 服務。專有系統是使用標準的 Internet 通信協議設計的，用於管制和監控。先前的工作顯示，基於無線感測器網路、Web 介面和工業控制模式，用於氣候控制、電源管理或安全性的控制系統，使用不同的監視和控制技術。監控應用分析，得自監控和數據採集系統中的這些子系統。對於不同的子系統，有不同的解決方案。考慮到上述情況，本工作中提出的模式，引入了以下新穎元素：A. 介紹了一種分層架構（整合了邊緣和霧端等級），以及提供子系統之間互操作性，以及在建築物控制中開發智慧服務的方法，該方法使用了邊緣和霧端範例，這些範例將 IoT 協議整合在一起，並在本地 Intranet 中操作 AI 技術，讓雲端服務的通信層，完善了該層的架構。B. 介紹了一種基於使用者為中心的方法，用於在互操作性需求下設計、驗證和改進新服務。C. 該提案允許使用可以在已建的建築物中，實施的非專有硬體和軟體系統。 3. 計算模式設計建築物中的設施子系統分為有照明、氣候、能源、安全、警報、電梯等。在自動化建築中，這些子系統由專門的控制技術控制和監控。在非自動化建築物中，不存在這些服務，並且子系統透過電子和電氣方式進行控制。在這兩種情況下，所有子系統都為建築營運，提供必要的服務。從邏輯上講，每個子系統都在其場景中起作用，並且不能與其他子系統互操作。嵌入式電子控制器和連接的不同感測器，可以使每個子系統自動化。這些服務都是基於直接反應性控制規則。除了嵌入式控制系統和感測器之外，通信技術（基於 Internet 協議）和新的行動設備還為開發管制、監控和數據訪問服務，提供了新的可能性。在智慧型動設備上開發，並連接到 Web 伺服器的人機介面和專用應用，是近年來已實現的服務的範例。每個子系統中的專家（氣候、安全性、電源等），都具有可以轉換為專家規則的知識。這些規則被轉換為用於管理、維護、控制、優化和其他活動的控制算法。這些規則是可以，在可程式設備上編程和實現的。但是，它們是靜態的，不會在出現新情況時發生變化，並且不能互操作，也無法適應每個安裝的特性。例如，氣候或安全專家決定，如何使用標準啟動條件，來配置每個子系統。每個控制規則僅在一個子系統（此範例中為氣候或安全性）中工作，因此，這些子系統之間沒有互操作性。考慮到這種情況，提出的模式有助於並允許，基於不同子系統的互操作性，來整合新的數位服務，並將人工智慧（AI）技術的新服務，引入當前設施。例如，諸如電梯控制的設施，可以用於安全服務或建築能源管理服務。氣候控制設施，可以與安全子系統整合在一起。整合到模式中的天氣預報軟體系統，可以由能源管理服務，或建築物空調服務使用。目的是讓每個子系統中的專家，參與設計整合服務，並將所有子系統轉換為可互操作的系統。該模式會開發自動規則，並允許在考慮安裝行為本身的情況下進行決策。該模式基於一個過程，該過程包括四個開發階段（圖2）和分為不同級別的硬體 - 軟體體系結構（圖3）。該體系結構的主要等級，是邊緣等級和霧等級。這兩個層次介紹了在建築物中，應用物聯網技術的新穎性。下面介紹了模式的各個階段（分析、設計、實施和啟動）。 ．分析：在此階段確定了不同的專家使用者（氣候、安全、電力、水、能源、管理人員，以及資訊和通信技術（ICT）技術人員）。諮詢專家使用者，以指定需要控制的主要過程。資訊通信技術專家作為整合環節，參與了這一過程。第一種方法產生了設計控制規則，和潛在服務所需的事物（對象）。在此階段，使用以使用者為中心的方法，並捕獲子系統的需求。．設計：我們提出了一個三層架構（邊緣、霧端和雲端），如圖 3 所示。．實施和數據分析：在此階段中已安裝和整合了子系統。服務基於每個子系統中的規則，分析事物（對象）生成的數據，以設計基於機器學習的服務。．啟動：最初，在每個子系統的監督下制訂專家規則。然後，使用回饋過程安裝規則。最後，透過人工智慧技術，可以推斷出自動的和經過調整的規則。3.1. 分析與設計專家使用者對此過程，進行不同的審查。以使用者為中心的技術，用於設計整合流程。目的是獲得所需的所有事物（對象），它們之間的關係，以及潛在的服務。一旦指定了事物（對象）和服務，就必須關聯通信協議和控制技術。選擇了物聯網協議和嵌入式控制器；提出了人機介面；指定了邊緣層和霧層及其功能；分析專家規則和智慧服務。最後，提出了維護和操作方法。所有這些任務在專家技術人員，和資訊技術專家之間共享。結果是事物的定義，它們之間的關係，以及與邊緣和霧層的交互作用。該過程中代表了建築物的所有子系統，數據感測器、執行器、控制器、規則和過程經過設計，可以整合所有子系統。數據集、對象和設備，由物聯網概念表示。事物由具有狀態和配置數據的實體，和前後關聯組成。事物數據位於霧和邊緣節點中，儲存的不同配置中的關聯性。事物以數據向量表示：[ID、類型、節點、前後關聯情境]。– ID是辨識碼。– 類型可以是感測器、執行器、變量、過程、設備、介面、數據儲存，或可以在 IoT 生態系統中寫入、處理、通信、儲存或讀取數據的任何對象。– 節點指定建築物子系統、功能描述、層類型（邊緣、霧端、通信或雲端）、IoT 協議和時程存取訪問。– 前後關聯表示在 IoT 生態系統中，用於發布或讀取數據的時間、日期、位置，與其他事物的關係、狀態和訪問頻率。表 1 是由事物（[ID、類型、節點]）。所有事物都可以訪問配置文件（CF），以了解如何使用可用數據，以及如何使用適當的訪問權限配置新數據。前後關聯數據位於內建記憶體，或是靜態儲存。使用定義的事物，設計不同的控制規則。這些控制規則是分佈在連接到網路的不同嵌入式系統中，控制過程的一部分。事物表示佈署在安裝的不同子系統中，所有的可用資源。在此等級上，設計師對所有事物進行分析、指定和關聯。基本控制算法是使用此資訊實現的。配置關聯性允許層和設備之間，所有事物的互操作性。在此階段的另一級設計，必須提出物聯網管理中，使用的節點要求和規範。設計的流程和服務，將在邊緣或模糊節點中實施。必須指定每個節點，以確定其內部功能、通信及其服務。在獲取數據的地方，開發了智慧和處理能力。邊緣和霧層的節點，位於數據感測器、執行器和控制器附近。本文提出的方法，使用具有兩個功能的兩層（邊緣和霧端）。每一層都可以佈署互連節點的網路，以促進互操作性。邊緣和霧層的功能是：邊緣層功能：在連接感測器/執行器的嵌入式設備上，開發的控制軟體。某些 AI 算法可以安裝在邊緣節點上。中央處理器（CPU）和計算資源有限。安裝了通信介面，以允許在本地網路中進行整合。霧層功能：局域網級別的通信、AI 範例、儲存、配置關聯性和監控活動。霧節點透過處理、通信和儲存，來處理 IoT 的Gateway、伺服器設備，或其他設備中的數據。在此等級實施本地、全球的整合服務。利用這些節點的硬體、軟體和通信功能，開發了基於機器學習範例的算法。霧層設備還可以在很少單位的設施或服務中，執行邊緣節點功能。透過這兩個等級，可以優化建築設施，以獲得不同子系統之間的整合和互操作性。表 1 顯示了每件事與關聯性配置，和節點規範的關係。節點標識其所屬的子系統（控制、能源、氣候等），層（霧端、邊緣、通信和雲端）及其執行的功能。3.2. 架構設計在分析和設計階段，獲得對象（事物）及其關係。規範和要求用於實現每個層。實施取決於提供所需功能的設計，和現有技術（硬體、通信和軟體）。在此階段，開發了一種適合現有設施的體系結構。物聯網協議提供互操作性，而 AI 範例則提供了適應性和優化性。邊緣運算節點用於控制設備，霧運算節點安裝在本地網路節點上。這些等級為配置、安裝和運行新流程，提供了強大的資源。物聯網協議，傳達所有子系統數據。每個子系統由對象/事物（虛擬等級）組成，安裝為可連接的感測器/執行器/控制器設備（硬體等級）。物聯網通信中，針對建築場景建立的要求是：標準協議、低功耗、易於存取訪問和維護、支援整合新模組，非專有硬體或軟體，以及低成本設備。MQTT 協議，是目的在用於提供整合和互操作性資源，異構通信場景的主要物聯網協議之一。該協議被提議作為感測器、執行器、控制器、通信設備，和子系統之間的通信範例。MQTT 協議的一些主要功能，在不同的著作中有所顯示，這使其特別適合於這項研究。他們之中有一些是：．它是針對資源受限的場景開發的發布 - 訂閱消息協議。．它具有低頻寬要求。．這是一個非常節能的協議。．編程資源非常簡單，使其特別適合於嵌入式設備。．具有三個 QoS 等級，它提供了可靠和安全的通信。MQTT 開發了無所不在的網路，該網路支持 n-m 節點通信模式。任何節點都可以查詢其他節點，並對其進行查詢。在這些情況下，任何節點都可以充當基地台的角色，能夠將其資訊傳輸到遠端處理位置。無處不在的感測器網路（USN）中的節點，可以處理本地數據。如果使用 Gateway，則它們具有全局可訪問性；他們可以提供擴展服務。節點（邊緣或霧），可以具有本地和全局存取訪問權限。這些設施具有不同的可能性和益處。本地數據處理，對於基本過程控制是必需的，而全局處理則可用於模式檢測和資訊生成。從這個意義上講，擬議的平台使用了組合功能：連接到 IoT 雲端服務，本地網路區域上不同的 USN。在這種情況下，運算層（邊緣或模糊等級）將用作控制流程和雲端服務之間的介面。該層可以在與雲端進行通信之前，進行處理數據。 實現邊緣和霧端運算節點需要執行三個操作：．連接和通信服務：所有設備必須在同一網路中，並且可以互操作。所有感測器和執行器都可用於開發服務。此活動的一個示例，是在 Internet 上遠端讀取建築物的電源參數、環境條件和開放的天氣預報數據。此活動中應實現其他功能，例如連接的安全性、可靠性和互操作性。．嵌入式設備（邊緣運算層）中的控制算法和數據處理：在此活動中，這些設備中實現的基本控制規則和數據分析服務，可以開發新功能。此階段可以應用於數據過濾、運算氣候數據或分析功耗、直接反應控製，或使用模式辨識技術檢測事件。．Gateway 節點（霧運算層）上的高階服務：此等級使用和管理 AI 範例，和 IoT 通信協議。霧運算節點對數據執行智慧分析，對其進行儲存，過濾並將其傳遞到不同等級，以糾正較低級別的新控制措施，或者生成雲端中服務感興趣的資訊。此階段的應用示例，包括分析新模式、預測用水量，或功耗、智慧檢測和其他預測服務。 3.3. 測試與回饋在測試階段使用標準方法，邊緣和霧層提供不同的功能。提出了針對不同子系統的機器學習模式，並且可以將其安裝在邊緣或霧節點上。必須執行以下操作，來測試機器學習應用：A. 定義和捕獲數據集：必須辨識、捕獲和儲存主要變量。在不同的建築子系統中，過程數據集是由連接到邊緣層的感測器捕獲的數據。使用通信協議監控和儲存數據集。一個案例是電表，該電表在配電盤中連接到嵌入式設備（邊緣節點），該嵌入式設備傳送電力數據，以在霧節點設備中儲存和處理。B. 訓練數據集和形式辨識模式。先前數據集的一個子集，用於訓練不同的模式。評估針對從未用於訓練的數據測試模式，此過程的結果已由專家使用者驗證。目的是獲得一組代表性的結果，以了解模式在現實世界中的表現。C. 實際場景中的驗證：必須在邊緣和霧節點上，實施新的服務和控制算法。這些模式具有用於分析數據，實施特定模式，並使用結果開發最佳參數的算法。在此階段，可以修改或進行改善模式。D. 用統計術語和模式演變，得出測試結果：基於 AI 算法的模式而將產生近似值，而不是精確的結果。分析應用結果以確定置信度，並允許模式演化。該活動支持開發新的 AI 服務，或對已實現的算法進行修改。有監督的自動更改，是維護和改進系統的過程。此階段的過程，包括所有模式層。建議對使用邊緣和霧，任何的安裝進行這些活動。如前所述，該模式既可以安裝在既有舊的建築物中，也可以安裝在新建築物中。對於新建築設計，基於建議模式的安裝更易於整合。此外，可以提供的服務的潛力，也使其對於既有建築物具有吸引力。4.在建築子系統中，實施智慧服務該模式在預先存在的住宅建築物上，進行了測試。設計和實施電源管理、管制和監控服務。物聯網協議（MQTT 和 HTTP）和 ML 範例，用於建議的層體系結構。基於 KNN 的機器學習方法，和樹決策算法用於管理功耗（家用電器），和可再生能源發電（風能和太陽能）。使用房屋中的霧節點，在雲端平台上實現監控和統計數據。該節點連接到控制可再生，和家用電器子系統的不同邊緣節點。在圖 6 中，邊緣節點，整合在先前安裝的可再生子系統中。透過邊緣層上的這種新設備、電源管理、安全控制和操作流程得以整合，並且可以與其他子系統互操作。可以設計新的智慧服務。邊緣節點將數據傳輸到霧節點 Gateway，該 Gateway 管理功耗和發電，並控製家用電器。該節點中的輸入，是可再生能源發電的數據。輸出控件是 ON-OFF 開關，用於優化發電、安全性和操作。4.1. 分析與設計分析了住宅建築，以設計電源管理，安全和控制服務。 在第一種方法中，所需的主要事物（對象），它們之間的關係和不同的服務，如表 2 所示。4.2. 執行分析房屋中的建築子系統，以整合這個執行模式層：邊緣控制、霧服務，與雲端的通信和雲端服務。 選擇了本實驗工作中使用的感測器、執行器和控制過程（事物）。 表 3 列出了使用的嵌入式設備。家庭服務中的控制過程，需要反應時間和互操作性。人機介面、數據存取訪問和分析服務，是本地和雲端運算上的服務。上面提到的兩個需求，都使用不同的協議處理：控制/通信上的 MQTT，和雲端服務上的 HTTP（RESTful API）是用於整合，並使所有子系統互操作的 IoT 協議。在提出的該層模式中，還使用 MQTT 協議、控制、數據處理，以及使用 RESTful 協議，到雲端的數據通信，來開發機器對機器（M2M）應用。MQTT 使用開放的消息協議，該協議可以將遙測樣式的數據（即在遠端位置收集的測量結果），以消息的形式，從設備和感測器，沿著不可靠或受約束的網路傳輸，到伺服器（BROKER）。消息是簡單、緊湊的二進制數據包，有效載荷（壓縮的標頭，比超連結傳輸協議（HTTP）少得多的詳細資訊），並且非常適合推送簡單的消息傳遞方案，例如溫度更新或移動通知。例如，消息也可以很好地用於，將受約束的或更小的設備，和感測器連接到 Web 服務。MQTT 通信協議，使所有對象可以互操作。透過此協議實現的發布者和訂閱者模式，可以互連所有設備和事物。該通信層由安裝在霧節點上的代理設備管理。不同的發布者和訂閱者，在不同的節點上實現。安裝了一個 Gateway 設備（霧節點）和兩個嵌入式控制器（邊緣節點），來控製家用電器和電源管理。事物和流程佈署在所有節點上。邊緣節點控制子系統，霧節點根據決策樹，以及專家定義的規則，實現 AI 範例。霧設備將數據傳輸到雲端平台，以開發儀表板螢幕，來監看子系統的狀態。可以開發新的雲端平台服務：事件檢測、機器學習處理、統計分析等。專家使用者設計基本的控制算法。在學習和訓練過程之後，將根據專家系統的結果，對這些算法進行調整和修改。在這項工作中，目標是在不損失生產力的情況下優化資源（控制和能源）。在邊緣或霧節點中，執行不同的控製過程；分類過程和決策樹在霧節點中實現。算法以 Python 語言實現。此語言的開源庫用於不同的應用。4.3. 佈署與測試對於現有建築物，邊緣節點交錯插入已安裝的控制器、配電板，以及感測器和執行器中。如果在分析階段指定了新的東西（電錶、氣候和控制器），則會安裝一些新的感測器/執行器。這項工作中佈署的邊緣節點具有以下優點：．請勿干擾先前的安裝操作。．他們使用新的專家規則和自動規則，引入新控件。．他們測試和重新配置，在分析、學習和測試驗證中，設計更新的專家規則。 圖 7. 佈署在配電盤中的節點。 使用 IoT 協議通信，在不同節點中開發數據捕獲、控制算法、數據分析、儲存和通信服務在電力管理過程中，專家使用者根據電力消耗、發電量、消耗負荷曲線、氣候數據和氣候預測數據，對具有選定流程的時間表，進行可程式處理。邊緣節點捕獲數據，並將其發送到霧節點。 霧節點處理室內和室外環境的日記數據，以及天氣狀況。霧節點還可以捕獲其他感測器數據。對房屋中的這些數據消耗和生成方式，進行檢測和分類。消費和發電結果，作為數據添加，以便與儲存的數據一起進行分析。可以使用機器學習方法開發，作為家用電器或人類活動檢測的智慧服務（圖8）。 4.3.1. 機器學習：數據捕獲過程（邊緣節點）和家用電器分類（霧節點）連接在主配電盤中的電表，用於捕獲數據，並使用標準的 K 近似值，最近鄰（KNN）分類算法，來開發形式辨識模式。 KNN 是機器學習系統中最常見的方法之一。電表捕獲電流；如果連接了新的家用電器，則電流數據會更改。不同的家用電器具有不同的變化等級。用於辨識家用電器的不同模式的主要變量，是連接時的電流水準差異。數據捕獲過程流程圖（圖9），顯示了在邊緣節點中實現的算法，以捕獲預處理並傳遞電力數據。 在此過程中，監督階段使用訓練數據集。接下來，真實場景中的驗證，將測試分類模式。家用分類設備將用於不同的服務：人類活動的辨識、負載控制、可再生能源管理、空調、安全性等。在訓練階段，已捕獲了不同的家用電器開機，以獲得一組形式。每個家庭都有一個矩心向量，將用於分類過程中的檢測。如上面所示的算法所示，分類器處理將產生連接時的電流數據作為輸入。KNN 分類過程流程圖（圖10）描述了 KNN 方法，它在霧節點中實現。 4.3.2. 可再生電源管理。控制電力自耗的決策樹每個建築物都有不同的需求曲線，以及在接入電網方面的特定情況。為此，整合和可互操作的設施，可以實施適用於每種情況的不同解決方案，從而提供對太陽風資源的最佳管理，優化電源效率，簡化管理流程，並實現最高的成本節省。當可再生能源超過消耗的能源時，在使用 AC 耦合到電網的設施中，會出現問題。在實驗工作中，太陽能在一天的中央時段的能量，大於所消耗的能量（圖11）。但是，在分析了消耗曲線之後，可以在這段時間內連接負載，以避免注入電網。可以透過設計一種算法，來滿足這一要求，該算法可以預測，何時發生此事件，以自動連接不同的負載。利用所有感測器和執行器的整合，和互操作通信，已經開發了在不同節點中，所實現的算法（圖12）。 13. 在電源管理子系統上開發的決策樹。 它由專業使用者設計，並整合在邊緣節點上。該決策樹的目的，在優化可再生能源的使用。4.3.3. 基於 Edge 和 Fog 節點的 Control Home圖 14 顯示了安裝在住宅房間中的邊緣節點。 該節點可以控制四個設備（設備），並捕獲感測器數據（功耗、發電量、溫度、濕度等）。該設備可以使用 MQTT 協議進行通信。該協議允許設備之間，進行其他類型的通信：智慧手機、新邊緣節點等。圖 7 和圖 14 顯示了可以在其他建築物中，佈署的標準實現。在所有系統中，都有配電板，這些配電盤佈署了霧節點和邊緣節點，如圖所示。4.3.4. 使用物聯網協議的雲端服務雲端服務可以監控，透過霧節點或人機介面（HMI）訪問的數據。 IoT 協議（MQTT）從任何已連接 Internet 的設備推送數據。事件檢測、儲存統計分析等其他服務，完善了該資源的功能。提供類似服務的不同平台，顯示了商用物聯網技術的狀態：Amazon IoT、Microsoft Azure、Ubidots 和 Thingspeak，是提供 IoT 平台的公司一些案例。提供了資源以及客戶端，和 IoT 平台之間的應用程式介面（API）通信，以便可以使用它們。用於設計儀表板監控和管制的 HMI 資源，是這些平台上的主要實用功能之一。霧節點使用雲端 API 傳達數據和資訊，可以實施其他控制服務。在這些雲端平台上，預先建構了用於監控數據的儀表板設計。使用 API​​ 實用功能，霧節點中的過程處理，會將數據發送到每個儀表板。API 文件指定了在設備、IoT 平台和 Mobile-Alerts Cloud 之間，交換數據的結構，以及用於加速項目的代碼案例和形成資料庫。圖 15 顯示了在 Ubidots 雲平台上，設計的儀表板。Ubidots是本實驗工作中使用的物聯網平台。該模式可以在實現這些協議的層，和平台中使用不同的標準協議。圖 16 顯示了在雲端平台中，IF 變量 THEN 動作的事件配置。大多數物聯網平台，都提供此功能。5. 結論為了設計物聯網系統，越來越多地提出邊緣霧模式。但是，每個範例都提供特定應用領域的解決方案。不同子系統之間的整合和互操作性，可以改善這種情況，並提供更好的服務。這項工作的主要目的，是透過提出一種基於邊緣層和霧層，兩層體系結構的運算模式，來解決這個問題。透過這兩層，可以基於使用邊緣或霧節點中，嵌入式的設備捕獲數據所產生的新型有用資訊，來設計和開發新服務。這些節點使用雲端平台和 IoT 協議（例如 MQTT）。MQTT 是作為不同層（霧 – 邊緣 – 雲）之間提出的通信協議，並進行實驗的。雲端平台用於開發儀表板的面板資訊和 Internet 上的新服務，例如控制、儲存和通信事件。該平台可用於透過 API，交付不同的服務。該模式可以在現有建築物和新建築物中，開發這些服務。在這種情況下，要求每個子系統中的專家和專業人員，參與新服務的設計。為了測試該模式的功能，並顯示如何在實際設施中，實現該模式，在住宅中進行了一項實驗性工作。在此霧和邊緣節點前後關聯中，描述了實現的幾個範例。開發了模式辨識和決策樹方法，以展示人工智慧在設計 IoT 解決方案中的潛力。已安裝服務的結果顯示，邊緣和霧節點佈署，產生了預期中整合和互操作性的好處。提出的工作演示了，如何將邊緣和霧範例，整合到可以增強其優勢的新架構中，從而擴展了應用領域。該體系結構的主要科學貢獻，是整合、技術的互操作性，及其為開發 AI 服務提供的設施的範例。所有這些改進，都在已開發的實驗的不同示例中顯示。具體的優化和改進，將在以後的工作中進行。此外，使用機器學習平台，和 AI 範例的新控制規則，將確保可以創建和改進新的智慧服務。附圖：圖1.自動建構子系統和資訊技術環境。圖2.基於使用者為中心關係的模式。圖3.通信架構。 每個等級都有不同的功能。 提出了兩個通信等級：IoT（使用消息隊列遙測傳輸（MQTT））和 Web（使用代表性狀態傳輸（REST）協議）。這些協議的層，涵蓋了已建立的整合和互操作性要求。 圖4. 在建築物的現有設施上實施的邊緣霧架構示例：邊緣節點是較低的層次，必須與安裝的設備進行新連接。互連所有子系統的霧節點，是透過整合連接到邊緣節點的新設備來實現的。邊緣和霧節點，可以佈署在所有建築物子系統中。圖5. 住宅建築中的第一個實驗工作。 圖6. 整合在先前安裝的可再生子系統中，邊緣節點的示例。 該節點可以使用新算法控制 ON-OFF 開關，以管理發電過程，以及通信和監控電源數據。表1.事物示例描述。寫入 ID、類型和節點數據，以配置 XML 文件。配置關聯性儲存在霧節點中。表 2. 實驗工作中的分析和設計要求。表 3. 實驗室內使用的嵌入式設備。圖 7 顯示了分佈在配電板上的節點（邊緣和霧狀）。在此節點中，設計並安裝了功率計、ON-OFF 開關控件和 AI 服務。圖 8. 佈署的智慧電源功能。在霧節點中實施的分類過程，可用於檢測電連接和人類活動。可以使用 IoT 通信實現其他服務圖9. 邊緣節點中捕獲，並預處理的用電量數據；MQTT 協議用於通信數據。另外，其他節點可以使用捕獲的數據，來提供其他智慧服務，佈署了整合和互操作性。圖10. 分類過程。處理捕獲的電數據以檢測家用電器連接。可以使用 IoT 協議整合，來設計其他智慧服務。圖11. 該圖顯示了實驗工作中的消耗和生產數據。 在自儲存的電力自備設施中，沒有儲存並且沒有注入電網，所產生的能量必須即時使用，並且不得超過所消耗的能量。 能源經理必須預測此事件，並提前連接電荷。 圖 12. 用電自耗設施中的可再生電源管理。圖 13 是在電源管理子系統中，開發的算法的示例。 可以在邊緣節點上安裝此過程。該節點獲取氣候數據預測，並預測系統是否可以在不儲存的情況下，使用可再生能源。 圖14. 佈署的邊緣節點。該節點可以使用新算法，控制 ON-OFF 開關，並可以在每個房間或建築物中，通信和監控感測器數據。圖 15. 在雲平台上配置的儀表板。顯示了風力發電數據和預測風力。圖 16. 在雲端平台上配置事件的儀表板：IF 事件 THEN 動作。 該服務顯示了，如何使用雲端訪問來控制設施。與霧節點的 Internet 通信，可以控制建築物中的不同子系統，並使用電子郵件，SMS 或其他 Internet 服務來通報事件。 資料來源：https://3smarket-info.blogspot.com/2021/02/iot-edge.html?m=1&fbclid=IwAR0uijX5WdNrfzmGjVsakFGaEsWivPgyH1zumxVr7fwvvgqtdFFTI6jJXS8

Question 3

手機第一次開機日期航空迷因 在Facebook 的評價

Accepted Answer

史上最長投稿《疫情之後的貨機人生》 by 物流老司機［零：前言］近一年來，受到疫情的影響，航空客運幾近停擺。人流嘎然停止，四肢癱瘓，物流卻像顆不放棄的心臟，持續跳動朝四面八方輸液，替全世界的經濟保住一線生機。在油價走跌的加持之下，各家航空公司的貨運業務逆勢竄起，成為營收與獲利的重要支柱。全球30大航空公司裡，僅有四家業者有獲利，台灣的華航和長榮就佔了榜單上的兩個名額 ，貨運部門從深夜墊檔節目躍身成熱門八點檔，組員的生活也成為各界關注的焦點之一。敝公司擁有18架747貨機，數量居全球之冠。這架經典的空中皇后，機艙胃納量大，也因為貨運的榮景，迎來遲暮之年的第二春。以下所提的貨機組員，皆是以747機隊飛行員為例。貨機大部分是往美國飛的越洋長程航班，就算是偶爾穿插的區域短班，出發時間也多在半夜。組員晝伏夜出，活動範圍離不開貨機坪，也甚少進入旅客的視線。身處同一間公司，掛著同一個職稱，穿著同一件制服，客機組員也不見得了解貨機機隊的生態。若要剖析貨機組員的生活，不外乎從這幾個關鍵字下手：［班表］、［外站］、［安克拉治］，還有無可避免的［隔離］。組員背景天南地北，男女老少或有差異，但八九不離十，生活和話題都脫不了這幾個重心打轉。［一：班表］無論客貨機，無論長短程，每個月的一張班表，主宰了組員30天內的生活。生活兩個字筆畫不多，但鉅細靡遺，包山包海，充滿各種變數。如果班表是一道料理，那麼熬夜和時差，就是長程機隊飛行員的主菜，無從替換，也往往是雙品招待。同是吞著熬夜配時差，但客機和貨機組員吃的菜色不同，滋味更是南轅北轍。長程客機的派遣，多是單點來回，例如直飛紐約、法蘭克福、雪梨，在當地休息一到三天不等，然後飛回台北。貨機的派遣模式較為複雜，飛往美國內陸的停靠航點較多，天數也拉得較長。舉例來說，貨機組員出門派遣一趟的班表常常是這樣：從台北飛大阪，落地中停2小時，繼續從大阪飛安克拉治，在安克拉治休息40小時，飛去芝加哥中停2小時接著飛西雅圖，在西雅圖休息18小時，然後飛回台北。離家飛個長班，以下例子是客貨機的差異，一目瞭然：客機：台北－紐約－台北貨機：台北－大阪－安克拉治－芝加哥－西雅圖－台北疲勞很難量化，不同機隊之間的作息也無從比較，但貨機組員的班表較為複雜，航點也較多，起降比較頻繁，隨之而來的風險也較高。另外，貨機組員要面對的另一個挑戰，是在美國內陸各航點間的時差。以安克拉治為基準，西雅圖快了1小時，芝加哥快了3小時，紐約快了4小時。組員在多航段執勤後，在不同外站休息後，必然會面臨跨時區的副作用，就是日照時間與生理時鐘的紊亂。［二：外站］如何在外站調整作息，也算是組員工作的一部分。無論身處東西半球，在外站下班之後，得在或長或短的休息時間內，想方設法讓錯亂的生理時鐘重開機。如何實作，人人自有心得，各憑本事。文的武的方法不拘，只要在下一次上座時，在握住操縱桿之前，能夠撐起眼皮敲醒腦袋進入飛航模式，那就是好方法。客機會停靠的外站，無非是觀光勝地，或是人聲鼎沸的都會區。疫情之前，組員在外站能抽空遊歷知名景點，跋山涉水尋幽訪勝，品嚐四方美食，體驗異地風情，這是辛勤工作之餘的福利，一點小小的犒賞。就算只是暫時離開旅館，在市區搭車或鄉間散步，讓風景流轉，也是種調劑與沈澱，好轉換心境迎接下一趟任務。對貨機組員來說，常會頻繁飛往美國內陸各大貨運站。最具代表性的外站，就是安克拉治。無論搭配的是紐約、亞特蘭大、芝加哥或邁阿密，安克拉治都是必經的門戶。ANC三個字未曾缺席，按月換個日期烙印在班表上，有時候一個月還得造訪兩次三次。貨機組員的第二個家，就是安克拉治。［三：安克拉治］飛機航程越遠重量越大，飛行時耗油就越多。以747貨機為例，受限於最大起飛重，在油箱加滿的情況，可以飛到13小時左右，但只能裝進約七成滿的酬載（Payload，賺錢的貨物重量）。若要增加酬載，勢必要減少飛時，不能飛得太遠。簡言之，載得重就飛不遠，要飛遠就得減重。因此位在阿拉斯加，離台灣約8個半小時的安克拉治，就是一個很好的中停點。安克拉治人口數和新店差不多，機場貨運量卻是全球排名第五大。Fedex和UPS是主場，華航、長榮、大韓、國泰都是常客，AN-124偶爾出沒，運氣好一點還能遇到全球最大運輸機AN-225。飛機從台北出發時可以裝滿酬載，在安克拉治落地補足油料後，接著往美國其他航點移動，例如6個小時外的紐約，7個小時外的邁阿密。除了位在美西的洛杉磯、舊金山、西雅圖，要飛往內陸或東岸的航點，飛機大多以安克拉治當作進出的中停點。機坪內偶爾會出現三架自家貨機比鄰的景象，例如左邊的從大阪飛來要再戰芝加哥，中間的要先飛邁阿密再折返跑去西雅圖，右邊的打了一趟紐約來回終於要踏上歸途朝台北前進。此起彼落，你來我走，輪番上陣排隊卸甲，燒肝打拼都是為了把滿機腹的酬載平安送到目的地。飛機地停加油，只消數十分鐘後即可再度升空，不曾聽過機器有過半句怨言，但人總得闔著眼伸直腿睡覺。飛機齊聚一堂有多熱鬧，就有為數不少的組員得在此落腳歇息，進出安克拉治皆然。至於能在旅館裡待多久，端看手機螢幕裡那一個小方塊，班表APP來決定。有時是三人派遣的底線，18個鐘的休時。有時則在房內欣賞了兩次晨曦晚霞，待了近48小時才往下一站前進。人是動物，籠子關久了難免想伸展筋骨透透氣。由於造訪頻率高，留宿時間比其他外站來得長，若在安克拉治沒有些嗜好，時光肯定特別難消磨。除了日常的上街採買覓食，這裡地廣人稀，往深郊野外跑是再合理不過的。偶遇前輩分享安克拉治的外站生活，說道在這塊景緻優美的自然勝地，登山健行，騎馬滑雪，坐船看冰河，野溪釣鮭魚，戶外活動包羅萬象，聽者常心生嚮往。但疫情爆發，世道丕變，一個四季都還沒輪完，這些軼聞趣事突然變得遙不可及，像是曾祖母的兒時照片一樣斑駁難辨。無論哪個外站，所有未曾探訪之勝地，未及體驗之樂趣，未能品嚐之珍饈，一夕之間都封印成旅遊書上的一行行墨漬和一幀幀相片插圖，只剩銅版紙的氣味飄著活著。［四：隔離］病毒橫空出世，是前所未見的兇猛對手。疫情初始，各國政府只能在節節敗退之際，盡快釐清病毒的底細。有的採取群體免疫想和病毒自然共存，有的端出各項封城管制的措施，期盼在經濟窒息之前能先把病毒悶死。效果不一，但大多數國家的醫療資源和經濟活動都受到病毒重擊。台灣在初期反應迅速，守下第一波攻勢，決戰邊境，把損害控制到最低程度。但若是每個執勤返台的飛行組員，入境後都要隔離14天，航空公司很快地就會面臨無人可調派的窘境。幾經波折與轉彎之後，疾管署和航空業者協調出一套模式，在防疫和營運間取得平衡。組員從公司勤務報到開始，全程配戴口罩，視客貨機需求著配護目鏡或隔離衣，抵達外站後專車接送，入住旅館期間不得外出，不與當地民眾接觸，僅透過外送或客房服務方式用餐，返台後自行駕車、專車接送返家，或是入住防疫旅館，不得搭乘大眾運輸。貨機組員三天內／客機組員五天內居家檢疫，不可外出或派飛。14天內自主健康管理，不出入人潮眾多景點或參加大型集會。概念是這樣的，對疫情互信的國家之間有旅遊泡泡。組員在本站和外站之間，就是個執勤泡泡。若能落實各項防護措施，與疫區的生活圈隔絕，讓染疫的風險能被降到最低，那麼在三天／五天居家檢疫期間渡過之後，組員就能夠離開家門或檢疫旅館，回歸社區生活。組員返台後手機沒有被追蹤定位，在外站時也沒有早晚點名確認是否擅自外出。這套模式從春季運行至今，除了公司各單位的後勤支援，仰仗的是客貨機無數班值勤組員的自律，以及對自身工作的責任感。大家有共同的目標，離開國門時保護自己，回到台灣保護我們的家。海外各國動輒停班停課，關餐廳封城，確診數不斷攀升第二波第三波。 2020年的台灣，宛若世外桃源，馬照跑舞照跳，除了無法出國旅遊，沒什麼特別。為了保護家園不受侵擾，疾管署、各家業者、頻繁進出疫區的第一線組員，大家都在不同戰線和病毒長期對抗。與此相比，泰山與鴻毛之輕重，被關在外站旅館隔離，失去移動的自由，其實也不足掛齒。［五：疫情之後的外站］自此開始，組員的外站生活不再立體鮮明，只剩二維空間的兩點一線。機場一點、旅館一點，還有往返接駁的車程拉成一線。對貨機組員來講，就是從安克拉治繼續往外延伸的更多點和線疫情嚴重的城市，例如紐約，也取消外站駐防，就改成從安克拉治派遣飛來回，但所需飛時較長，落地之後的休息時間也必須拉長。另外為了減少返台次數，貨機組員也會以安克拉治為出發點，派遣兩次內陸航班後再返台。在旅館大廳偶遇時，問候語不外乎是：「你是飛來還是回台北？」「我接下來飛亞特蘭大，你從芝加哥回來嗎？」「你還要在這裡待幾天？」一個疫情後的班型如下：台北－安克拉治（住）－芝加哥（住）－安克拉治（住）－紐約（中停）－安克拉治（住）－大阪（中停）－台北。從台北派遣一趟，出門八天打了七腿，安克拉治住了三次。飛行里程足以繞地球一圈，但除了機場和旅館，哪裡也沒去，哪裡也去不了，哪裡也不該去。疫情之後的外站，除了熬夜和時差，還多了COVID-19這個隱形魔王，得矇著眼和他打擂台。從外站落地開始，接過的每一份文件、摸的每一扇門把、送到房間的每一份餐點、頭靠的每一顆枕頭，不用酒精噴霧伺候都覺得心虛，深怕一次疏漏就讓健康和職業生涯同時劃上句點。若聽到遠方傳來隱約的咳嗽聲，隔著口罩都想收著鼻翼抿著嘴。自此，所有的外站糊成一個大麵團，形狀全都是一個模子印的，味道全都是一只雜燴鍋煮的。外站就是一個七坪大的房間，一張得噴酒精消毒的床，一扇晨昏顛倒的窗，一具上班前會鈴鈴作響催命符的電話。組員們自力更生，自樂自得，每個人斜槓再斜槓，文組追劇閱讀，武組瑜伽健身，學習與自己相處，學習面對被迫離群索居的孤獨。計時結束，服刑期滿，走出這扇門遲早得回頭。往下一站或下兩站移監的車程，反倒是令人期待的旅途，一趟小確幸。腳下踩的是安克拉治夾著樹葉的積雪，不是帶著污漬的陳年地毯。屁股坐的是芝加哥霓虹燈光加長禮車，不是硬邦邦的旋轉辦公椅。眼睛看的是高速公路旁的西雅圖楓紅，不是了無生趣的旅館停車場。耳朵聽的是機坪上貨盤車嘎拉作響，不是一片漆黑裡嗚噎整夜的旅館空調。進到駕駛艙後就是小小的烏托邦，以金屬蒙皮築牆的理想國。艙門關上，油門一推，飛機離地後跟著把所有的顧忌和擔憂拋在腦後。腳下是病毒統治的塵世，三萬英呎的雲隙還是天空，曬得皮膚發痛的還是陽光，讓人昏昏欲睡的還是黑夜。和過往的2019、2018沒有兩樣，還是起降巡航，還是一桿兩舵，除了臉上多了張口罩，疫情沒有在這裡改變什麼。直到，落地開了艙門，COVID-19說，歡迎回家。向櫃檯領了鑰匙，房門哐啷一聲關上，換個外站，計時重新開始。熟練地將房間內消毒一遍，確認每個開關按鈕把手都鍍上了酒精，才能寬心摘下口罩呼吸，躺在陌生的又熟悉的床上休息。隔離週而復始，直到班表大人批准返台。如果運氣稍差，班表稍微凶險一點，可能會在返台三天檢疫期滿後，隔沒一天又被派遣安克拉治，然後繼續飛美國內陸班。那麼將會是有整整兩個禮拜，除了勤務派遣時間以外，組員都得在家裡或旅館內隔離。一如傳世名言：「我不是在隔離，就是在往隔離的路上。」離台灣七千公里外的安克拉治，冬天日照只有六小時，零下十度是家常便飯。旅館內隨時都有三四組貨機飛行員駐防，在客房內或睡或醒或彌留，靠著Ubereat和Line便當群組外送供應三餐。入住時來自四面八方，離去時目的地不一，退房兩天內又拖著行李箱掛著黑眼圈，鬼打牆一樣現身在旅館大廳迎接另一段隔離。 這就是疫情之後的貨機人生。［六：寫在案例765之後］和歐美國家不同，17年前的我們經歷過SARS，對於病毒和口罩有著熟悉的共同記憶。戒慎恐懼，是全民防疫成功的關鍵。但蛋殼再密也有縫，身為全台灣唯一頻繁進出疫區的族群，機組員成為防疫的破口，彷彿是種宿命，早破晚破的問題而已。本土0確診的天數拉得越長，破蛋之後，輿論的後座力就越猛烈。曾經被譽為天空國家隊，客貨機組員不分彼此，都持續肩負著運送防疫物資的重任。而在嚴峻的疫情之下，貨運同仁依然全年無休，倉庫24小時燈火不滅。機坪上永遠都鋪滿貨櫃，等著一趟趟貨機往返消化。這個海島國家能夠物暢其流，進出口轉運順暢，組員多少也透過操縱桿出了一份力量。然而，在案例765－紐籍機師事件發生後，全台灣的機組員，猶如身處中世紀的歐洲，被視為滿街散疫的過街老鼠，避之唯恐不及。如果可以舉辦公投，組員返台後隔離14天的方案，應該會是毫無懸念地高票通過。在被輿論的口水戰淹沒之前，必須先理解一個事實。在這253天內，無論是當天來回或是過夜班，無論是載客或送貨，敝公司就有一萬五千個航班飛回台北，全台灣加起來有超過兩萬個架次的組員，在這段期間接觸旅客，進入疫區過夜再返台。這麼龐大的航班數量，這麼多的人員反覆進出疫區，返台後並沒有隔離14天，為什麼在過去的253天內，可以維持本土的0確診？如果現階段的執勤泡泡，各項防護措施效果不佳，讓組員在執勤時避不了染疫，那麼在這兩萬多個航班內，應該會有一定比例的機組人員中鏢。不會人人都是無症狀感染者，也不會每個人居家檢疫期內就保證痊癒。經過九個多月後，疾管署應該會收到一堆居家檢疫通報有症狀，篩出一堆確診的組員。或是組員染疫而不自覺，經過三天／五天後無論是外出或執勤，再度傳染給其他人。台灣不會保持這麼久的本土0確診紀錄。如果在案765之前，台灣的社區是乾淨的0，那麼也是間接證明，過去九個多月以來，這樣的執勤泡泡模式是有足夠的防護力。台灣並沒有來源不明的社區感染，也沒有一堆機組員在居家檢疫時發病確診。組員最有可能染疫的源頭就在國外，與當地生活圈隔絕是最直接的方式。源頭不防堵，就算延長回台後的隔離天數，再補上執勤前的篩檢，也是治標不治本。重點是組員執勤時，有沒有確實配戴口罩，落實自我健康管理，以及在外站時各項防護措施是否嚴格執行。眾家媒體披露，該位紐籍機師執勤時不願意配戴口罩，也不配合疫調，甚至不是第一次在外站擅自離開旅館，同事通報公司也沒得到積極處理，那為什麼要為了個案改變通則，連坐處罰過去253天戰戰兢兢執勤的無數組員？若是又有組員7天檢疫後確診，是否要上調到14天？若是有旅客檢疫14天後才發病確診，疾管署需不需把旅客入境隔離上調到20天呢？現在應該關注的是事件的調查結果，若是紐籍機師在外站沒有離開旅館，執勤時一切合規，結果還是不幸染疫，那麼現行的執勤泡泡得通盤檢討，確認在外站的哪個環節是防護的弱點，接車司機生病、旅館消毒不周、外送餐食人員疏失、病毒變種後傳染力變強，都是可能的原因。找出造成感染的根本原因，才能據此改進。若沒有從源頭防堵漏洞，過一段時間後累積足夠的航班量後，還是有可能再次出現類似的組員染疫案例。輿論看到的是253天的0，我們看到的是兩萬多個航班的0。沒有人希望看到0變成1，因為我們很清楚，若是疏於防備，幾週之內，1就能變成難以置信的數字。這麼多架次之後維持的0，隱藏的是無數客貨機組員的心理壓力。進入疫區小心翼翼，返台後就算檢疫期滿仍不得鬆懈，時刻注意自己是否有流鼻水、腹瀉、肌肉痠痛等症狀。鎮日精神緊繃，深怕自己已成病毒溫床，不慎將病毒帶進社區造成大規模傳染。居家檢疫期對家庭生活造成的不便，以及反覆陷於隔離的處境，對組員的身心狀況，難免都會有負面且長期的影響。熬夜、時差、隔離，就是這一年來組員生活的三元素，在全球航空業如此困難的時刻，能夠換上制服領著班表出勤，已是萬幸。檢疫規定也隨著國際國內疫情調整，昔寬鬆今嚴峻。待疾管署一聲令下，公司頒佈細則，組員只有逐條遵循，以免自己成為防疫破口，賠上健康也壞了名聲。但案765的事件，帶來了排山倒海的輿論壓力，風行草偃，組員動彈不得，無力辯駁。明明執勤時很謹慎，返台後都很自律，在規定的檢疫期滿才離開家門用餐採買，卻還是有種莫名的罪惡感，覺得自己是個通緝犯，只是還不曉得犯了什麼罪。一旦確診染疫，馬上回溯14天丟石判刑。天下大亂的2020年還沒過完，在英國發現的變種病毒已在2021年埋伏，超前部署蓄勢待發。這是一場寒夜裡的越野馬拉松，疫苗的成功研發，還沒完全帶來曙光，在病毒追擊前，我們得摸黑找到終點存活下來。共體時艱，這四個字只差沒刺在背上，提醒自己沒有退路。在世界恢復平靜之前，能再走多久的0就交給老天爺了。

關於 手機第一次開機日期 ，我們在網路上蒐集到這些相關的討論、資訊與評價

「手機第一次開機日期」的推薦目錄：

手機第一次開機日期 在 Linn / 老娘才不是日本人 Facebook 的最讚貼文

About author

手機第一次開機日期 在 台灣物聯網實驗室 IOT Labs Facebook 的精選貼文

About author

手機第一次開機日期 在 航空迷因 Facebook 的最讚貼文

About author

手機第一次開機日期 在 我是nAka / 走吧一起玩! Youtube 的最讚貼文

About author

你可能也想看看

搜尋相關連結

關於手機第一次開機日期，我們在網路上蒐集到這些相關的討論、資訊與評價

手機第一次開機日期在 Linn / 老娘才不是日本人 Facebook 的最讚貼文

手機第一次開機日期在台灣物聯網實驗室 IOT Labs Facebook 的精選貼文

手機第一次開機日期在航空迷因 Facebook 的最讚貼文

手機第一次開機日期在我是nAka / 走吧一起玩! Youtube 的最讚貼文