國巨併購奇力新擴大被動元件版圖,再攜手鴻海布局半導體,搶攻小IC市場

國巨併購奇力新擴大被動元件版圖,再攜手鴻海布局半導體,搶攻小IC市場
Photo Credit: 中央社

我們想讓你知道的是

國巨與奇力新召開董事會通過,取得其百分之百股份,進一步擴大「被動元件」版圖。另一方面,國巨也將與鴻海合作,深化半導體產業佈局,成立合資公司,鎖定小IC產業,透過創新整合服務發揮綜效,攜手打國際盃。

近日國巨集團動作不斷,自2018年併購美國天線大廠普思電子(Pulse),同年又以540億元收購美國被動元件大廠基美後,今(2021)年再度出手,與奇力新召開董事會通過,取得其百分之百股份,進一步擴大「被動元件」版圖。另一方面,國巨也將與鴻海合作,深化半導體產業布局,成立合資公司——國創半導體,鎖定小IC創新產業,透過整合服務發揮綜效,未來將攜手打國際盃。

被動元件大廠國巨布局有成邁向國際盃

日前國巨集團與奇力新召開董事會通過,由國巨取得奇力新百分之百股份。

國巨是台灣電子元件製造商,1977年成立,產品包括多層陶瓷電容器(MLCC)、鉭質電容、晶片電阻)、無線元件等,統稱為「被動元件」。另外,奇力新則是台灣唯一有能力提供全系列磁性材料以及電感元件的製造廠商。

被動元件:是一種不會產生電力,但會耗用、儲存或釋放電力的電子元件。常見的被動元件例如:電阻器、電容器、電感器為電子產品中使用量最多且不可或缺的重要元件,合稱為「三大被動元件」。

一般來說,被動元件主要分為三類,分別是一、電阻器,主調節電流及電壓的大小;二、電感器:主要過濾電流中雜訊、防止電磁波干擾,並穩定電流;三、電容器:主要儲存電能,進行耦合及協調等功能。

受惠於智慧型手機、電動車與車用電子需求強勁,進而帶動被動元件的應用面擴大。

尤其,隨著產品功能的複雜化及多元化,耗電量也將隨之增加,因此需要更多被動元件來進行穩壓、穩流、過濾雜訊等,藉以維持終端裝置正常運作。

若以過去傳統汽車為例,過去傳統汽車一輛約使用到1000至2000顆被動元件,進入電動車或是自動駕駛,預估將使用到5000至10000顆被動元件,需求量將倍速成長。

《關鍵評論網》訪談資深投資人黃柏堃指出,國巨為台灣被動元件大廠,回顧近三年策略,包含2018年併購美國天線大廠普思電子,同年又以540億元收購美國被動元件大廠基美,國巨的商業策略,一向是快、狠、準!

國巨近年來,透過國內外整併,集團結構已經發生變化。原來被動元件的毛利不高,但近年來技術提升毛利成長,也受惠於高規特殊品開發成功,比重也大幅拉升。

6月30日國巨董事長陳泰銘,再把原先持股11%的關連企業電感廠奇力新透過換股100%合併,他高喊目標到2023年,納入奇力新的新國巨,將有八成產品屬於高階特殊品。

黃柏堃強調,併購後新國巨的組織和規模將大幅度擴增,屆時面對的競爭對手為村田、TDK、VISHAY和Littelfuse等國際被動元件大廠,也算是正式走向國際盃。

陳泰銘認為,在納入奇力新後的新國巨,形成的組織和規模,顯現國巨已脫胎換骨、「質變」成功,新國巨產業地已更上一層。

而法人則認為,國巨一年營收1000億元,MLCC佔29%、鉭質電容佔22%、晶片電阻佔17%無線元件佔15%以及其他佔17%,被動元件產品版圖已趨近完整。

另外,奇力新一年營收則為190億元,電感本業佔70%,帛漢網路變壓器佔12%、磁性元件佔12%、LTCC等佔6%,未來使新國巨的生產線更多元。

陳泰銘強調,過往奇力新電感主攻PC、NB與中國手機市場消費性電子為主力,通路商比重略高,可望藉由此次併入國巨後,降低奇力新的通路商客戶比重,並在銷售區域上逐步往歐美市場擴充。

國巨策略結盟鴻海搶攻電動車

國巨新聞稿表示,與鴻海在長期合作中已發展出絕佳的策略和模式,雙方透過多樣的創新整合服務發揮綜效,在此多變的時局中替彼此提升營運效率和實績。

未來,兩集團新的合資公司在海外登記名稱為「國創半導體」,將更深化雙方在半導體領域的布局,初期鎖定平均單價低於兩塊美金的功率、類比半導體產品,簡稱小IC,進行多樣的整合與發展。

目前該公司已和多家世界級半導體公司展開討論,近期將宣布相關半導體領域的合作案。

鴻海董事長劉揚偉表示,目前半導體產業正經歷三十年來最大變局,產業秩序將會面臨重組,現在無疑是進行多方策略合作的最佳時機。

鴻海在半導體的布局已依中長期藍圖展開,作為集團布局的三大核心技術之一,產業鏈中已有相關IC設計、晶圓廠與系統級封裝等能力,配合鴻海在電動車、數位健康、機器人三大新興產業的轉型需求,進而擴大垂直整合產業鏈。

國巨旗下的半導體公司所切入的小IC產品,將扮演鴻海發展藍圖中至為關鍵的一環,不僅對集團現有資通訊及未來新興產業提供穩定的半導體供應來源,同時亦可滿足全球客戶需求,進一步提升集團獲利。

陳泰銘表示,國巨著眼的是提供客戶一次購足的長期發展,此合作更符合客戶優化供應鏈的需求。

《關鍵評論網》訪談業內人士指出,國巨近年來整併快速,又加上鴻海對於電動車市場掌握靈敏,兩大集團合作,對於台灣產業是劑強心針。不過以被動元件來說,材料還是非常關鍵,目前技術是由日本村田製作所掌握。

他指出,日本MLCC製造商擁有競爭優勢,能夠做出微型化的元件,目前連中國和南韓等強勁對手,仍無法複製、追趕上,日本製MLCC產品,台灣在這塊還需要多著墨。

不過,國巨提到這次與鴻海合資,小IC公司的成立,可進一步將產品線從被動元件擴及至半導體主動元件,提供現有客戶更完整的元件供應,可望帶來極大的成長空間。

未來合約協議生效,功率半導體產品市場在2025年將達到400億美金的規模,類比半導體產品的市場則有250億美金,而一台電動車的半導體使用數量比例,歸類小IC的部分超過百分之九十。


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

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

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

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

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

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


猜你喜歡