#Q博展知識
【祖父母節快樂!】
每天八月的第四個禮拜天是祖父母節,祝天下的爺爺、奶奶、阿公、阿罵、外公、外婆、grandpa、grandma祖父母節快樂!
祖父母在年輕時辛勤的奔走,才為我們墊下家庭穩固的基礎
在這個特別的日子,就讓我們來看一些關於銀髮族健康及快樂的科學吧!
【老年科技的介紹與應用】
物聯網輔助健康照護
隨著物聯網的發展,各裝置間透過網路雙向溝通,並透過雲端手機APP軟硬體系統整合,已能達到智慧生活。其中,對於蒐集健康、運動、飲食等生活資訊的智慧穿戴裝置,更成為健康照護領域發展的重點。在健康照護產品的發展上,智慧穿戴裝置與物聯網結合的遠距照護型產品最符合民眾的需求,實用性也最佳。智慧穿戴裝置具有長時間自動感測、蒐集、顯示,並連網傳送資訊的功能。
培力遊戲化:從寵物養成遊戲開始
寵物對現代人來說是伴侶關係,相當於家庭的成員。寵物和人類有密切的依附關係,人透過寵物的陪伴,能增加幸福快樂感。銀髮族對於寵物更是投入較多的情感或依附感,寵物則持續提供銀髮族記憶、安慰與安全感。
寵物養成遊戲的設計,以物聯網技術結合穿戴裝置,偵測與蒐集銀髮族生理資訊、運動狀態,做為遊戲角色成長的依據。讓銀髮族從參與寵物養成遊戲中,提升健康度、參與力和安全感,以達成功老化、健康老化、活躍老化及健康維持為最終目標。
健康數值視覺化
銀髮族玩家依據健康生活數值管理系統的設定,填入個人健康數值,系統會據以建議他們每日的健康生活模式,例如:日行萬步、每周運動333、BMI指標、社交活動分析、系統養成角色成長變化分析等,並依據建議模式擷取健康資料做為角色成長的依據。透過視覺角色的設計以及生活模式活動紀錄,顯現銀髮族玩家的健康狀況。健康的維持是持續性的行為習慣,透過健康數值視覺化的表現方式,如遊戲的角色養成、獎勵徽章等,可以讓銀髮族玩家不要太在乎單次量測數值的差異,而應著眼於生活型態及健康的促進上。
https://scitechvista.nat.gov.tw/UrlMap?t=ciU
【以新科技創新長照模式】
長期照顧服務不再只是單純地提供住宿、飲食等基本生活需求,長輩們漸漸重視心靈層面的滿足,如何提供被照顧者生活中的社會支持、成長、休閒、交誼等服務,已是刻不容緩的課題。因此,亟需產業界的介入共同開發資通訊管理系統與服務連結器,達到一站式的服務平台。
智慧化長照服務
運用創新e化科技產品,加強長期照顧服務模式的連結,以滿足被服務長輩社會支持、休閒、交誼等需求。結合安全防災監控、健康照護管理、便利舒適服務、系統整合應用等項目,進行優化建築物的智慧化基礎建設。然後配合彈性化傳輸網絡架構,提升系統相容性,透過簡易的人性化管理操作介面,以「安全偵測」及「系統整合」的改善需求為出發,導入高科技智慧化無線安全防護設備形成照護雲,創造安全無虞的長期照顧居住品質。
行動護理車
有鑑於機構的護理人員每天必須花費較多的時間在生命徵象的量測上,為降低人為操作的時間,使數據的記錄與保存更為精準,提供照護人員掌握被服務者的即時動態,機體輕巧的行動護理車便應運而生。
當護理人員至長者的住房內,只需帶著行動護理車,並與遠距健康照護平台連結,直接透過網路把生理資訊上傳整合。行動護理車可配置7種生理量測模組,包括血壓計、血糖機、吐氣流速器、心電圖機、體重計、耳溫∕腋溫計及血氧計。
https://scitechvista.nat.gov.tw/UrlMap?t=dsQ
監控系統基本架構 在 台灣物聯網實驗室 IOT Labs Facebook 的最佳貼文
從火星探測系統到輔助工業製程,美國工業用 AI 新創 Beyond Limits 如何在台灣做到技術在地化應用?
李佳樺 2021/08/13
從2012 年美國太空總署成功將探測車「好奇號」送上火星至今,已經過了3000多個「火星日」,肩負著火星探測的重要任務,8年來好奇號傳回許多對火星的重要觀察與發現。背後更不為人知的,則是好奇號的 AI 運算系統,其實是由美國新創 Beyond Limits 的團隊建立的,公司發展至今也將觸角伸到能源、先進製造等產業,建立 SaaS 服務,為產業提供 AI 輔助平台,2020 年更獲得 1.3 億美元的投資,拓點到台灣、日本、新加坡、香港等地。
Beyond Limits 將 AI 應用到產業製程的契機,源自於當時跨國石油集團 BP 在墨西哥灣發生的漏油事件,企業希望導入 AI 優化決策過程,合作中也發現了石化能源產業的痛點,研發出石油配方建議系統、石油製程操作檢引系統等 SaaS 產品,不僅受到美國石油公司歡迎,日本市場也買單。
有了日本的先例,這套美國研發出的產品,照理說要拓展到亞洲市場應該不成問題,不料到了台灣卻窒礙難行,甚至需要重新開發不同的產品。
Beyond Limits 的台灣團隊究竟面臨了什麼挑戰?
台灣市場與美國差異大,Beyond Limits 台灣團隊必須如創業般從頭研發產品
台灣分公司總經理張中宜說明,台灣產業的先天特性,讓美國母公司已開發的產品都面臨市場可行性低落的問題,以石油產業的產品舉例,在台灣只有中油、台塑兩個客戶,且台灣的石油公司並不做研發工作,多半直接向國外公司購買配方,因此團隊必須在美國 SaaS 模式 的技術基礎下,研發出符合台灣市場、針對不同產業需求的商品。
「Beyond Limits 在台灣設立公司時的處境,跟重新創業差不多。」張中宜表示,AI 應用產品的開發不僅需要能夠從零開始寫演算法的工程師,也要有懂產業製程的專家團隊,龐大的研發費用與對產業專家的需求,讓每一次產品開發都像募資活動,團隊必須透過產業訪談做足市場研究找到痛點,說服製造公司與他們合作開發能解決產業問題的軟體。
然而開發全新市場對張中宜來說並不陌生。
她曾經在孟加拉創立幫助偏遠地區孩童課輔的非營利組織 e-Education ,第一年就讓偏鄉學子考上孟國最高學府卡達大學,更順勢搭上鼓勵企業與 NPO 合作的開放式創新風潮,讓卡西歐、 AI 新創、安永都找她擔任顧問,執行戰略布局或開發新通路的工作,面對 Beyond Limits 在台灣的難題,團隊選擇了電動車電池研發、面板機器手臂維修與人流異常預警系統等三個產業切入。
延伸既有美國產品技術,尋找合適的台灣在地產業切入開發產品
選擇電動車電池產業與 Beyond Limits 在美國石油產業的經驗有關,研發電池的過程與石油廠研發機油的邏輯相似,痛點都在於漫長的研發過程,就像做菜時要多次嘗試才會知道多少的鹽與油才是最佳的調配一樣,電池配方更要經歷至少半年的實驗,且實驗設計也要在無數次團隊與客戶的交鋒後才能成型,溝通成本相當高昂。
使用 Beyond Limits 導入認知 AI 架構的電池配方建議系統,研發人員只要以自然語言輸入期望的電池規格、價格與電車轉速,系統即可在 43 分鐘內提供數百種配方與實驗方式供選擇,縮短約 2 千倍的研發時間。
Beyond Limits 也在 7 月 29 日宣布與日本的三井物產公司進行策略結盟,以其認知 AI 的核心技術,協助三井投資的液化天然氣廠進行巨量資料分析,並整合作業人員專業知識與數位化作業模式,制定出精簡有效率的解決方案。日本三井整合數位策略部部長常務董事真野雄司氏說,透過與 Beyond Limits 的合作可以改善與再造營運流程,更有效率執行現有事業群的高附加價值項目。
另外,Beyond Limits基於公司在美國既有的輔助風電機維修平台,投入面板機器手臂維修建議系統的開發,「雖然也想在台灣用同一套產品幫助風電產業,也與風電廠陸續接洽,但台灣的風電仍在建設階段,缺乏營運經驗,目前的維修需求也不高。」張中宜談到,市場開發的大方向是要在台灣尋找具備預測維修需求,且市場密集、成熟的產業,公司在與投資人仁寶電腦的合作中,發現光電面板產線中機器手臂的維修概念與風機維修類似,而且痛點也類似:包含高昂的維修成本、未經標準化的維修流程,以及依賴經驗的維修決策。
目前輔助維修系統正與日本機器手臂原廠合作開發,由廠商提供維修資料與產業專家, Beyond Limits 透過 AI 分析維修數據,建立資料背後的邏輯推演,系統最終能判斷機器損壞的原因,並建議耗材種類與維修方式。從管理者的角度能降低維修、備料倉儲成本,對維修人員來說也有可依循的維修建議,長遠更能累積產業知識 ( domain know-how ) ,促進升級。
以邊緣運算技術,與北捷合作開發人流異常預警系統
而將技術從太空拉回到地面,Beyond Limits 也能在大眾運輸犯罪預警上有所發揮。他們與北捷合作,使用等同於在火星探測時、消弭與地球時差的邊緣運算技術,原理是透過分散式的運算提升效率,達成在監控系統的邊緣節點就進行異常人流的辨別,降低反應時間落差。
張中宜舉例,正常的人流像是乘客擠進車廂內的固定位置,開始滑手機,異常的人流可能是人群往四面八方散去,產生快速移動的樣態,異常訊息可以在 10 秒內將送到中控室,大幅縮減以往需要 4 分鐘以上的訊號傳輸時間,也能避免踩到人臉辨識的紅線,未來希望擴張應用到大樓監控,或是銷往他國的大眾運輸系統。
源自NASA,認知型AI成為技術優勢與門檻
與其他單純使用機器學習技術分類數據並預測結果的數值 AI 系統不同,Beyond Limits 的 AI 服務融合了數值 AI 與符號 AI ,前者的數值 AI 是透過大量數據讓模型認知「此為何物」,而符號 AI 則是藉由邏輯定義數值 AI 判斷的結果是好還是壞,並加以做出決策與判斷,以電池配方為例,將實驗室過去的實驗數據導入數值 AI 系統後,會得出樹種配方組合,再藉由符號 AI 判斷個配方辦法的優劣,並給予客戶回饋與建議。藉由結合數值 AI 與符號 AI 兩大系統的結合,讓人工智慧的每項建議都能以人類可理解的思路解釋,輔助人類做最後決策,也使人機協作的製程模式成為可能。
對於這項技術,張中宜表示這其實是源自於 NASA 將探測器「好奇號」送上火星後,由於火星與地球之間的數值傳遞有時間差,人類基本上不可能遙控好奇號,而且火星上的數據在這之前是 0,所以數值 AI 也無法運作,為了能夠讓好奇號自行在火星上探測與行動,勢必須要模擬人類大腦的認知型 AI 系統,當時才會開發出符號 AI。
根據研究報告,2025 年工業用 AI 規模將達 160 億美元,其應用開發仍具高度可能性,Beyond Limits 在台灣也希望更全面地研發產品打進該市場。除了正在培養市場的風電產業外,未來也希望協助優化晶圓半導體產業的製程,團隊更積極與社會、產業溝通,讓社會了解 AI 進入產業能讓人類更有餘力進行創意發想與決策,也讓產業正視轉型需求,近期將與台灣新創基地合作舉辦 AI 科普講座,持續促進製造業的人機共榮合作。
創業快問快答
Q:服務的創意來源,是因為發生甚麼事情而有這樣的想法?
A:台灣數位轉型瓶頸
Q:創業至今,做得最好的三件事為何?
A:用國際薪資招聘頂尖人才、台灣市場國際定位清楚、客戶分潤共創模式的商業模式
Q:要達到下一步目標,團隊目前缺乏的資源是?
A:能見度
附圖:BeyondLimits 台灣總經理 張中宜
Beyond Limits 以數值AI及符號AI兩大關鍵技術,達到人機互補智能
圖片來源 : Beyond Limits
擠捷運
圖片來源 : diGital Sennin on Unsplash
圖說:BeyondLimits Hybrid AI導入流程說明
BeyondLimits Hybrid AI導入流程說明
圖片來源 : BeyondLimits
資料來源:https://meet.bnext.com.tw/articles/view/47993?fbclid=IwAR2HbB5FrPIBoV9kDL27OnhNF-JDNzfYdsoLoVKn85yAA7GUjzDzI3y5Lw0
監控系統基本架構 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
ref: https://ably.com/blog/no-we-dont-use-kubernetes
八月第一篇,就來個有趣的文章,來看看 ably 這間 SaaS 公司為什麼沒有使用 Kubernetes,不但當前沒有使用,甚至短期未來內都不會想要使用
更是直接的說如果你有興趣來加入團隊,千萬不要把將 Kubernetes 導入到團隊中是一個可能發生的事情。
我個人覺得這篇文章滿好的,因為是認真的去比較導入 Kubernetes 帶來的改變,而這些改變對團隊來說到底是可接受還是不可接受
而不是所謂的人云亦云,人家要我也要,人家不要我也不要...
文章分成兩部分,前述介紹當前 Ably 的環境架構是什麼,而半部分則是很技術的去探討如果導入 Kubernetes 帶來的好處與壞處是什麼
最終權衡比較之下,會發現導入 Kubernetes 沒有帶來實質上的好處。
文章開頭先簡述了一下 Kubernetes 這幾年的風潮,從最初 Google Borg 的開發開始談起,作者特別提到當初 Borg 的用法可是將一堆實體機器給搭建出一個 Private Cloud 的叢集給團隊使用,
而目前 Kubernetes 更多的用法則是搭建於 Public Cloud 上面的虛擬機器中,透過將 Kubernetes 部署到這些不同的 Cloud Provider 似乎帶來了介面統一的結果,對於 DevOps 人員來說
不同 Cloud Provider 如今看起來都是 Kubernetes 的樣貌。
Ably 目前到底怎麼部署應用程式
Ably 主要使用 AWS 作為其 Cloud Provider,並且於 EC2 機器上使用 docker/container 來部署團隊中的應用程式。
作者團隊中沒有使用任何已知的 Orchestration 服務來管理多節點上的 docker/container,取而代之的則是每個 VM 開機後則會根據 autoscaling group 的機制來判斷
每個機器應該要部署哪種 container/docker。
對於 Ably 來說,團隊中沒有任何 scheduler 相關的服務來調度各種服務,這意味每個 VM 就代表一種服務,所以將 VM 上的服務從 Core 轉換成 frontend 這種行為不會發生。
今天需要針對需求轉換服務時就以 VM 為基準來整批換掉即可。
每個節點上面都會有一個輕量的監控服務,用來確保運作的 Container 如果掛掉後可以被重啟,甚至如果當前運行的版本不符合需求時也能夠將該服務給停止。
流量方面,因為每個 Autoscaling Group 就代表一個服務,所以直接使用 NLB 與 Target Group 來將流量導入該 Autoscaling Group 即可。
至於容器與容器之間的內部流量(譬如 k8s service 等)作者認為也不是太大問題,畢竟每個機器本身都會被 VPC 賦予一個 IP 地址,所以使用上沒有什麼太大的問題。
接下來作者從幾個層次去探討當前設計與使用 Kubernetes 帶來的改變,分別有 (原文很多,這邊摘要不然文章會太長)
題外話,由於 Ably 的 Infra Team 數量有限,所以要考慮 K8s 只會考慮 K8s Service,如 EKS。
1. Resource Management
Ably:
a. 根據服務的需求來決定每個服務要用到的 VM 等級
b. 不需要去煩惱如何處理將多個小服務給部署到一個適合的大 VM 中
c. 作者稱這種行為其實就是 AWS 官方強調的 Right Sizing, 譬如只能跑兩個 Thread 的服務不需要 16vCPUs, 久久寫一次硬碟的服務也不需要一個 90,000 IOPS 的 SSD
d. 選擇一個正確的元件來搭建一個符合服務的 VM 讓團隊可以控制成本同時也減少額外的管理負擔
K8s:
a. 必須要使用一個比較強大等級的 EC2 VM,畢竟上面要透過 Container 部署很多服務
b. 針對那些需要小資源的服務來說,透過這種方式能夠盡可能的榨乾機器的資源,整體效能使用率會更好
c. 但是針對資源量沒有很辦法明確定義的服務則是會盡可能地去吃掉系統上的資源,這種被稱為 nosy neighbors 的常見問題已經不是首次出現了, Cloud Provider 本身就需要針對 VM 這類型的服務去思考如何處理資源使用,而 Cloud Provider 都有十年以上的經驗再處理這一塊
而所有 Kubernetes 的使用者則必須要自己去處理這些。
d. 一個可能的作法則是一個 VM 部署一個服務,不過這個做法跟團隊目前的作法已經完全一致,所以就資源管理這一塊,團隊看不到使用 Kubernetes 的優勢。
2. Autoscaling
Ably:
a. EC2 VM 本身可以藉由 Autoscaling Group 來動態調整需求
b. 有時候也是會手動的去調整 EC2 的數量,基本上手動跟自動是互相輔佐的
c. 團隊提供的是 SaaS 服務,所以其收費是針對客戶實際上用多少服務來收,如果開了過多 EC2 VM,則很多不要的花費與開銷都是團隊要自行吸收
d. 團隊需要一個盡可能有效率的方式能夠即使遇到流量暴衝時也能夠保證良好的服務的機制
K8s:
a. 可以透過不少方式來動態調整 Container 的數量,
b. 甚至可以透過 Cluster autoscaler 來針對節點進行調整,根據需求關閉節點或是產生更多節點
c. 動態關閉節點的有個問題是關閉節點時通常會選擇盡可能閒置的節點,但是閒置並不代表沒有任何服務部署再
上面,因此該節點上的 Container 都要先被轉移到其餘節點接者該目標節點才可以被正式關閉。這部分的邏輯作者認為相對複雜
d. 整體來說,k8s 有兩個動態調整的部分,動態節點與動態服務,而現有的架構只有一個動態節點。所以使用 k8s 則會讓問題變得更多更複雜。
3. Traffic Ingress
Ably:
a. Traffic Ingress 基本上每個 cloud provider 都提供了很好的解決方案,基本上團隊只要能夠維持每個服務與背後的機器的關係圖,網路流量基本上都沒有什麼需要團隊管理的。
b. 使用者會透過直接存取 NLB 或是透過 CloudFront 的方式來存取團隊內的服務
K8s:
a. EKS 本身可以透過 AWS VPC CNI 使得每個 Container 都獲得 VPC 內的 IP,這些 IP 都可以讓 VPC 內的其他服務直接存取
b. 透過 AWS LB Controller,這些 Container 可以跟 AWS LB 直接整合,讓封包到達 LoadBalancer 後直接轉發到對應的 Container
c. 整體架構並不會比團隊目前架構複雜
d. 唯一缺點大概就是這個解決方案是完全 AWS 綁定,所以想要透過 k8s 來打造一個跨 Cloud Provider 的統一介面可能就會遇到不好轉移的問題。
4. DevOps
Ably:
a. 開發團隊可以透過簡單的設定檔案來調整部署軟體的版本,後續相關機制就會將 VM 給替換掉,然後網路流量也會自然的導向新版服務
K8s:
a. 開發團隊改使用 Kubernetes 的格式來達到一樣的效果,雖然背後運作的方式不同但是最終都可以對開發團隊帶來一樣的效果。
上次四個分析基本上就是,使用 k8s 沒有帶來任何突破性的好處,但是 k8s 本身還有其他的功能,所以接下來作者想看看 k8s 是否能夠從其他方面帶來好處
Multi-Cloud Readiness
作者引用兩篇文章的內容作為開頭,「除非經過評估,否則任何團隊都應該要有一個跨 Cloud-Provider 的策略」
作者表明自己團隊的產品就是那個經過評估後斷言不需要跨 Cloud Provider 策略的團隊,同時目前沒有往這個方向去追求的打算。
同時作者也不認為 K8s 是一個能夠有效達成這個任務的工具。舉例來說,光 Storage 每家的做法都不同,而 K8s 沒有辦法完全將這些差異性給抽象畫,這意味者開發者終究還是要針對這些細節去處理。
Hybrid Cloud Readiness
管理混合雲(Public Cloud + Private Cloud based on Bare-Metal servers)是作者認為一個很合理使用 K8s 的理由,畢竟這種用法就跟當初 Google Borg 用法一致,是經過驗證可行的。
所以 Ably 如果有計畫要維護自己的資料中心時,底層就會考慮使用 Kubernetes 來管理服務。畢竟這時候沒有任何 Cloud Provider 提供任何好像的功能。
不過 Ably 目前沒有任何計畫,所以這個優點也沒有辦法幫助到團隊
Infrastructure as Code
團隊已經大量使用 Terraform, CloudFormation 來達成 IaC,所以透過 k8s YAML 來維護各種架構不是一個必要且真的好用的方式。
Access to a large and active community
另外一個很多人鼓吹 K8S 的好處就是有龐大的使用者社群,社群內有各種問題分享與探討。
作者認為
a. AWS 的使用者社群數量是高於 Kubernetes
b. 很多情況下,一個迭代太快速的產品其實也不一定對團隊有太大的幫助。
c. 很多人都使用 k8s,但是真正理解 k8s 的人微乎其微,所以想要透過社群來幫忙解決問題其實比你想像的還要難,畢竟裡面的問題太雜,很多時候根本很難找到一個真正有效的答案。
Added Costs of Kubernetes
為了轉移到 K8s, 團隊需要一個全新的 team 來維護 k8s 叢集以及使用到的所有基本服務。舉例來說,EKS, VPN CNI, AWS LB 帶來的網路好處並不是啟動 EKS 就會有的,
還必須要安裝相關的 Controller 並且進行設定,這些都是額外的維運成本。
如果找其他的服務供應商來管理 Kubernetes,這意味公司就要花費更多的$$來處理,所以對團隊來說,金錢與工作量都會提高,不同的解決方式只是這兩個指標的比例不同而已。
結論:
1. Ably 覺得 Kubernetes 做得很好,但是團隊目前沒有任何計畫去使用它,至少目前這階段沒有看到任何實質好處
2. 仔細評估後會發現,導入 k8s 其實也會帶出不少管理上的問題,反而並沒有減輕本來的負擔
監控系統基本架構 在 監控系統基本架構【監視器小學堂】 - YouTube 的推薦與評價
監視器系統架構說明|安裝一套監視系統要用到什麼監視器設備?| 監控系統基本架構 監視器小學堂重新啟動啦!第一集要跟大家說明監視器系統架構中, ... ... <看更多>
監控系統基本架構 在 監視器需要安裝的線路有什麼?|監控系統基本架構 - Facebook 的推薦與評價
監控系統基本架構 | #監視器小學堂#第二課#監視器線路架構第一課了解監視器基礎設備接下來要教大家監視系統的「線路」架構監視器線路接法、安裝時要用 ... ... <看更多>
監控系統基本架構 在 監視器需要安裝的線路有什麼?|監控系統基本架構 ... - YouTube 的推薦與評價
監控系統基本架構 本集要跟大家說明的是監視器最基本的架構最基本的架構,其中內容會提到監視器線路接法、監視器安裝時會用到什麼線路?監視器佈線的 ... ... <看更多>