【綠色觀點】沒停電不代表系統穩定:台灣電力調度的難題

電力系統做的事情簡單來說就是發電、輸配電和售電。發電的電力有幾個來源,煤、石油、天然氣、核能、抽蓄水力、再生能源,選項並不多。每種發電都有需要的喚醒時間,不是隨開隨用,也不是說關就可以馬上關。
評論
Photo Credit: REUTERS/達志影像
評論

本文作者吳進忠,年少時聽聞孫運璿運籌帷幄、指揮若定,如何在五個月內復原臺灣 80% 的供電系統,打敗日本人預言的傳奇故事。長大以後成為電力工程師,眼看著這個活兒就是一輩子。閉著眼睛就知道明天的備轉容量率要亮什麼顏色的燈,卻迷惘於國家的電力系統未來要往哪裡去。近年用心研究各國電力調度與市場的創新策略,曾獲邀擔任亞太經濟合作會議 (APEC) 特聘電力能源專家,同時為台灣科技大學電機系兼任副教授,也是綠學院的綠色帶路人。

共同作者楊雅雲, 受到紀錄片《不願面對的真相》啟發,2009 年大跨度轉行到台達電子文教基金會,領導莫拉克風災校園重建—那瑪夏民權國小重建工作。擅長融合營利型公司與非營利組織的強項,將設計思考、行銷溝通與環境效益三個領域跨界整合,2014 年創辦綠學院,同時為 Green Impact Lab 綠色創業加速器的共同創辦人,著有《綠領建築師教你設計好房子》一書。

原文刊登於綠學院,INSIDE 獲授權轉載。

前一陣子特斯拉大降價新聞洗版各大媒體版面,網路上一堆人留言說電動車無法普及是因為價錢太高,降價一半還是買不起。但是同一時間,我們的電動車系列文章也是洗版各大社群且更多人留言,因為他們和我們一樣都發現,電動車發展的關鍵並不是錢,而是背後涉及的電力調度問題。

我們在專欄裡常講,在能源業,可怕的不是能源高手比你努力,而是高手的全局思維比你正確太多。我和其他幾位綠色帶路人,會接棒「能源白話文運動」的任務,長期駐點在綠學院,我們會從電網設計的全局思維出發,以技術、政策、法律、市場為支點,為你建構系統性的電力系統知識框架,助攻在綠色產業裡尋找機會的人、工作者、創業家,以及政策制定者。

電力系統像一個超大的人體系統,做的事情就是四個字:發輸配售

電力系統是一個超大的人體系統,做的事情簡單來說就是發電、輸配電和售電,簡稱發輸配售。發電的電力有幾個來源,煤、石油、天然氣、核能、抽蓄水力、再生能源,選項並不多。每種發電都有需要的喚醒時間,不是隨開隨用,也不是說關就可以馬上關。

跟人體的健康狀況隨時都在變化一樣,電力機組也不會電一上就非常穩定,機組有它運轉的限制,不是說它的發電容量有多少,就可以發多少電。機組和人一樣也會「中暑」,例如當溫度高於攝氏 34 度的時候,燃氣的複循環機組就會中暑,因為溫度太高會影響它的進氣量,發電就沒辦法滿載。

這些「球員」都有它的脾氣,現在又新來一個再生能源,太陽能是一種間歇性能源(Intermittent energy),白天才有電,其他時間在睡覺,這使得白天時段傳統機組使不上力,有些機組只好解聯待機,但太陽能睡覺的時候用電需求還是在啊,這就是《能源高手的智慧電網商機攻略》中談到的鼎鼎大名的鴨子曲線

為了處理鴨子曲線,於是就讓很快可以喚醒的、不必太多熱身就可以上場的球員,例如讓燃氣的複循環機組早上 9:00 解聯,下午 3:00 再併聯,然後讓抽蓄水力機組調整至白天時段抽水,其他時段發電,適應太陽能的作息時間。

電力調度的目的是用最經濟、最有效率的方法確保電力系統的供電穩定與安全

所以你看,管理輸配電的電力調度中心,他的工作非常吃重,對內,他要掌握所有可用之兵的作息;對外,他要正確預測你什麼時候要用電、要用多少電,用最經濟、最有效率的方法確保電力系統的供電穩定與安全。

既然最重要的是確保供電穩定與安全,所以安全第一(包括人員安全、設備安全、系統安全),其次才是考慮必須符合其他非安全限制條件下的最低成本,例如環保限制(不可以排放過多的 CO₂、NOx、SOx 等),最後才是降低發電成本。換言之,如果影響到電力系統的供電穩定與安全時,可以不用考慮發電成本,甚至短時間內可以暫時放寬環保限制條件。

你可能會覺得在空污這麼嚴重的狀況下,放寬環保限制是不可思議的,但是這就跟人體系統一樣,遇到生死交關時會本能求生,身體會自動關閉某些器官的運作,減少耗能幫助你度過難關。所以電力調度是「選擇題」,而不是「是非題」,電力調度需要很多彈性空間,所有對電力調度的限制條件除了原則性的限制外,應該要提供一些可以例外處理的彈性,這樣電力調度人員就可以在盡量滿足諸多限制下確保電力系統的供電穩定與安全,盡量降低發生停、限電的機率。

走在馬路上不會突然暈倒不代表身體健康,同理可證沒停電也不代表電力系統很穩定

自遷台以來,我國遇到電力系統全黑(Blackout)的情況少之又少,以至於只要台電一談到要確保電力系統的供電穩定與安全時,大家都會覺得台電又在恐嚇人民了。

因為電力調度實在是一個相當複雜的議題,所以我們就再來用人體系統打比方。在高度壓力的商業社會中,我們幾乎每一個人都帶著身體不適與心理創傷在外面行走,表面上我們每天準時打卡上下班,但其實我們每個人都稱不上健康,我們只是走在馬路上不會突然暈倒而已。電力系統也是一樣,全黑就如同走在馬路上會突然暈倒,但我們現在每天的電力調度,常常都在走鋼索,因為球員常常生病(燃氣)、請假(燃煤)、睡覺(再生能源)、退休(核能),可用之兵越來越少。

我們常常聽到說用電吃緊的時候就要調頻,為什麼需要調頻?頻率是供需平衡的指標,頻率偏低表示系統電力供給無法滿足用電負載需求,也就是我現在能發的電少於你要用的電,這時只好低頻電驛動作卸載,供給少一點給用電的設備。

身體也會遇到同樣的狀況,大腦每天耗費大量的心神,因此需要大量的血液供給,而肝腎儲備不夠用了,只好每個器官都分少一點供血量。這種方式偶一為之是無所謂,但是如果常常這樣做,其他器官長期沒有足夠的血液,就會影響其機能,你的身體當然就得出問題。

電力調度就是如此。我們現在三不五時就用電吃緊,於是趕緊低頻卸載,表面上看起來電力系統沒有全黑,但這對用電設備多有損傷,這不是一個健康的電力系統長期該有的狀態。

尤其電力調度除了要考慮當下電力系統供需情況,還要考慮未來幾個小時、隔天或未來幾天可能面對的情境,也就是說電力調度不僅要解決當下的供需平衡問題,同時也要替未來可能的供需情況保留可行的空間。因此為了不要長期在耗損的狀態,我們要老老實實增加發電供給(也就是要補肝腎)才行。

台電有沒有動機藏電?

另一個大家常有的想法是,既然我們這麼少遇到電力系統全黑,怎麼折騰台電也不會死,那表示台電一定有藏電,有發電機組故意閒置在一旁,創造電力供應不足的假象。

而且當你攤開機組的發電容量和實際發電量,兩者數字真的都有不小的落差,你就會更加強化你的想法。

可惜這種想法是錯的!前面提到,機組也有它運轉的限制,不是說它的發電容量有多少,就可以發多少電,機組和人一樣也會生病中暑,而且機組也有勞工權益,需要休假,進場保養檢修。

更重要的是,我們要檢驗台電有沒有動機藏電。

台電的存在就是為了確保電力系統的供電穩定與安全,把明明有生產力的機組閒置在一旁,創造電力供應不足的假象,不就正好無法確保供電穩定與安全?台電的員工不會因為藏電而拿到更多獎金,董事長甚至會因為沒有達成供電穩定與安全的 KPI 而下台,怎麼看都不是養生之道啊。

下一篇,我們來談另一個常見的思維謬誤,「南電北送」的自掃門前雪思維。

責任編輯:Mia
核稿編輯:Chris

延伸閱讀:



蛻變敏捷開發組織並不難! AWS Amplify幫前端工程師從雲端快速建立REACT程式

台灣企業勢必需要明確轉型策略,搭配適合的雲端工具作為入場券,一來降低數位化門檻、二來減少摸索資源的浪費。
評論
shutterstock_1451794139.jpg
評論

打造敏捷開發流程、加速前後端工程師的協作效率,是許多企業在面臨疫情之後,認為亟需將彈性元素納入為企業文化當中。雲端運算服務領導業者 AWS 台灣,觀察到前端工程師主要負責處理最貼近用戶的 Web、行動應用程式,但他們往往需要與後端團隊合作過程,遭遇耗費大量討論時間,才能處理使用者介面事項。

為了降低前後端的溝通成本,有些前端工程師在掌握介面管理能力之後,開始橫跨到後端的伺服器、資料庫開發經驗,甚至進一步培養技能,成為能負責測試、安全、效能多面向的全端工程師。

有的人會透過 Side Project(利用業餘時間開發有興趣的專案)或參加 Hackathon(黑客松)方式,運用 AWS 雲端工具嘗試自行擴展後端,並建立簡單易用的工具程式。究竟,AWS 平台提供哪些資源幫助前端工程師擴展更多元的技能樹?

掌握入門教學!前端工程師如何將 REACT 程式快速上雲

前端工程師運用 AWS Amplify,快速在雲端建立 REACT 應用程式

事實上,AWS 的入門課程指出,運用 AWS Amplify 在雲端建立 React 應用程式及服務集,只需五個學習歷程,包含建立 React 應用程式、初始化本機應用程式、新增身份驗證、新增 API 和資料庫、新增儲存體。如果想快速了解 REACT 程式快速上雲的方法及示範教學,本文節錄 AWS QUICKSTART 學習資源內容,幫助前端工程師更快掌握重點。

首先,何謂 AWS Amplify?AWS Amplify 是一項全托管 Front-End Web & Mobile 服務,採取無伺服器模式,在後端建立、部署和託管單一頁面 Web 應用程式或靜態網站的 Git 型 CI/CD 工作流程,加速開發過程直接整合其他 AWS 服務。舉例來說,像是整合封裝好的 Library 資源、或運用一些 Components UI 軟體去配置後端,以及利用 Admin 的 UI 做資源上的管理。

透過 AWS 增加雲端技能 在組織發揮你的影響力

AWS Amplify加速Develop、Deliver 與 Manage流程

AWS Amplify 主要優勢展現在三大項工作階段,分別是 Develop、Deliver 和 Manage。Develop 部分可利用 CLI(Command-Line Interface)或 Admin UI 設定後端,使用 GraphQL 或 REST API 設定也是可行的,進而快速建構一個前後端專案。此外,開發者還能搭配 AWS 其他服務,例如使用 AWS Authentication 全托管認證服務,或 DataStore、Storage 等多項 Feature Categories。

到了 Deliver 階段,若是要透過 AWS Amplify 執行 Web Hosting 任務,可拆解出三個流程。首先是將 Repository 與 AWS Amplify 進行連結,這邊可整合 Amplify Console 提供的支援資源包含 Github、Bit Bucket、Gitlab、以及 AWS 的程式碼代管工具 AWS CodeCommit。一旦連結以後,開發者可透過自己的 Configuration,决定在各個不同的 Build 要執行什麽樣的指令,最後再透過 Deploy 方式,幫助工程師進行前端的 Hosting。

在最後一個 Manage 階段,開發者則可利用 AWS Amplify 的 Admin UI,以開啓瀏覽器方式,透過視覺化介面統一管理資源。例如在 Admin UI 介面左側選單,涵蓋 Content、User Management 的區塊,讓參與專案但沒有 AWS Console 權限的使用者,可利用 E-mail 方式邀請使用者進到 Admin UI,進行一些設定或觀看其他相關資源;甚至在 Set Up 區塊還有相關選項,例如要針對 Data Modeling 或 APP User 做權限管理,以及可連結到 AWS 其他服務。

運用開放資源 AWS Amplify Framework,打造高效能應用服務

AWS QUICKSTART 學習資源還介紹到另一個 AWS 提供的開放資源 Amplify Framework,一樣可利用 Amplify CLI 的方式,配置 Web 和行動應用程式的前後端,以及開發者需要用到的服務,讓應用程式更易於構建,並獲得安全、高性能的使用體驗。

Amplify CLI 一樣有支援多個不同 Category,例如較常使用的幾個 Comment Line,像是Amplify Init 指令做初始化或創建幾個不同資源;或是 Amplify Status 指令,隨時在開發過程查看各個 Category 狀態;甚至專案結束後,可利用 Amplify Delete 直接把 Amplify 所創建的資源做一次性删除。另外也可透過 AWS Amplify Client 利用比較抽象化方式,讓開發者直接利用 Component 實現想要完成的項目。

填寫表單 找到適合你的快速上雲服務與工具!

實際示範給你看,設定 React 程式可以如此簡單

假設前端工程師現在要快速部署一項有驗證功能(Authentication)還要搭配 Rest API、GraphQL、Analytics 等服務的應用,如何快速設定 React 程式?在 AWS QUICKSTART 的學習資源後半段,有詳細說明要啟動這類型專案的操作方法。

開發者可以先利用 AWS Lambda Function 結合 Amazon API Gateway 方式,創建出一個 Rest API,到了 Authentication 階段,則使用到 AWS Cognito 的服務,接著針對 GraphQL 需求,可利用 AWS AppSync 服務,以及最後如果有 Analytics 的需求,也可以串聯 Amazon Pinpoint 工具。Amazon Pinpoint 是一項彈性而可以擴展的行銷通訊服務,開發人員可利用 Amazon Pinpoint API 追蹤 Web 使用者的行爲,或是針對 APP 推送、電子郵件、簡訊點擊行為蒐集到具體的資訊。

在這整套流程示範之後,值得特別強調的是,AWS AppSync 是一項全托管的服務,能及時更新,甚至在使用者離線時仍可以持續去創建和修改數據。一旦設備連上線之後,這項應用程式就可重新連線,並接到後端同步數據,達成彈性、自動化擴展或減縮各式 API 的請求。

打造第一個你在 AWS 上的應用程式

AWS 最後強調,Amplify 是相當適合建構出一個靜態 Web、Apps 服務模式,例如說像是打造部落格,或者是一項 APP 內的代辦事項應用等;加上 Amplify 具全托管服務特色,可串聯上述 AWS 在雲端所提供的資源,都能在部署過程加以整合,加速開發流程及效率,並且有效節省開發資源。如果想用低門檻的雲端解決方案,其實前端工程師是能在開發流程更靈活配置資源,甚至為公司的商業、服務模式挖掘出創新價值。

了解更多:AWS 開發者系列