RobotAIGeek

韓國希望制定一套統一的機器人電梯標準,但電梯業界卻已制定了三套。

南韓的新《特別法案》承諾為機器人進入公寓大樓及呼叫電梯提供標準化方式,但奧的斯(Otis)、通力(KONE)和迅達(Schindler)早在數年前就針對這項「手勢辨識」功能,各自開發了三種無法互通的專有 API,而目前僅有新加坡曾嘗試為此制定中立的跨製造商標準。

martti
4分鐘閱讀Posted: 2026年9月30日
韓國希望制定一套統一的機器人電梯標準,但電梯業界卻已制定了三套。

試想一台配送機器人停駐在首爾某棟公寓大樓的大廳門口,正等待搭乘一部由總部位於四個時區之外的製造商所製造的電梯,而該電梯運行著該製造商從未公開的呼叫協定。這單一的機器對機器握手過程——即機器人與電梯之間的通訊——正是韓國最新機器人法案承諾要解決的實際瓶頸。 這同時也是該法案未能觸及的技術層級之一。

由國會議員韓炳道提出、並與國土交通部共同起草的《移動機器人安全使用與商業化促進特別法》,目前正於韓國國會審議中,目標是在年底前通過。 該法案中最常被引用的條款,是將獲准運作的機器人如何在建築物大門處進行身份驗證並呼叫電梯的流程標準化,取代目前那種由現場的機器人供應商與該特定公寓大樓恰好聘請的門禁系統安裝商,逐棟進行協商的模式。 法案支持者主張,若能解決這種「拼湊式」狀況,機器人製造商只要在某棟韓國公寓大樓通過認證,便可將該模板直接應用於下一棟。

然而,這種「拼湊式」規範卻忽略了一點:電梯本身並不屬於標準化範圍。

三家公司,三種答案

每一家實際負責在樓層間運送該機器人的主要電梯製造商,早在任何政府提出要求之前數年,就已針對韓國正在立法規範的互操作性問題,建構出自己的解決方案。奧的斯(Otis)於 2018 年至 2019 年間推出了「整合調度」(Integrated Dispatch)應用程式介面, 此舉源於觀察到中國建築物內機器人的採用速度正在加速;該公司現表示,已與超過六十家獨立的機器人製造商在該平台上展開合作,包括與 Cobalt Robotics 的公開整合,以及在奧克蘭 Sudima 飯店的一項部署——該部署讓 Pudu Robotics 的配送單元能夠呼叫奧的斯電梯

獨立運作。通力(KONE)針對相同用途,同時運行並行的「服務機器人 API」與獨立的「電梯呼叫 API」,並透過其自有開發者管道進行推廣,作為自主清潔、配送及安防機器人之間的連結樞紐。 施耐德(Schindler)則開發了第三種版本,即整合於其所謂「BuilT-In」平台中的機器人 API,該平台透過建築自動化協定 BACnet 將機器人與電梯控制系統相連,而非採用專用線路。

這三套系統之間均無法互通。

當被問及為何業界未能匯聚成單一共享介面時,奧的斯(Otis)的設計策略資深總監尼克·科普(Nick Cope)給出了坦率的回答,而非行銷說辭:不同電梯系統之間始終存在專有資訊,而這種情況不會消失。 這並非企業在推諉責任。這家在該領域進行過最多公開整合工作的公司,公開表示這種碎片化是商業模式的刻意設計,而非某種疏失,無需等待行業協會會議來解決。

某個政府仍試圖強行推動此事

迄今僅有一個司法管轄區實際嘗試針對此問題制定中立且跨製造商的解決方案,而該國並非南韓。 新加坡國家標準機構於 2025 年發布了 SS 713 標準,這是一份技術規範,涵蓋將機器人連接至電梯或自動化門時所需的最低數據交換標準、硬體要求及安全處理規範。該標準由該國製造業標準委員會制定,起草工作則由機器人組織 CHART 與工程公司 HOPE Technik 共同主導。 配套規範 TR 130 則規範了機器人如何與建築物的中央指揮系統進行通訊。新加坡建築與工程局隨後發布了一份關於聯網電梯系統網路安全與互操作性的通告,而該標準機構也公開表示,希望將 SS 713 提升為完整的 ISO 標準,

旨在將一項國內規範轉化為所有電梯製造商最終都必須支援的參考基準。

這正是韓國目前尚未嘗試解決的更棘手問題。新加坡的標準定位在機器人與電梯控制器實際交換資料的層級,而奧的斯(Otis)、通力(KONE)和迅達(Schindler)各家都以專有 API 將此層級封鎖起來。 韓國的法案則位於更高一層,即建築物對機器人的義務:由哪個委員會批准、保險與事故調查如何處理、以及如何計算稅務用途的樓面面積。這些針對現有嚴重碎片化流程所提出的修正,既切實又實用。但這並非同一個解決方案。

為何這種區別對機器人供應商的財務報表至關重要

一家計劃向一百棟韓國公寓大樓銷售的機器人公司,會非常在意哪一層級被標準化,因為未被觸及的那一層級,正是決定其工程團隊還必須建置多少個獨立整合方案的關鍵。 如果一個國家的公寓大樓使用四、五個不同的電梯品牌(就像大多數國家市場的情況一樣),即使某家供應商已獲得某棟大樓的監管批准,仍需與該大樓特定電梯群背後所使用的製造商 API 建立合作關係,才能在隔壁大樓複製這項成功。 這項特別法案消除了法律上的不確定性,也免除了與大樓管理委員會的協商。但它並未消除在某棟大樓必須使用奧的斯(Otis)系統、而在隔壁大樓又必須使用迅達(Schindler)系統的要求。

一項全國性法律可以命令某棟大樓向機器人開放大廳門,但無法命令三家競爭的電梯製造商發布相同的介面。

這並非對該法案的批評。針對穿梭於住宅空間的機器,將大樓治理、保險義務及事故調查流程標準化,是一項真正艱鉅且確實必要的政策工作,而韓國的版本是在九場會議中,匯集了三十五家企業的意見後制定的

這份文件——其中包含三星電子、現代汽車集團、Naver Labs 以及外送業者 Woowa Brothers——讀來彷彿是由那些已在實際試點建築中親身遭遇這些問題的人所擬定,而非僅僅在白板上草擬而成。 針對適合機器人運作的建築所提供的容積率優惠,以及對營運商強制要求的責任保險,正是這類看似不起眼卻至關重要的基礎設施,它們實際上決定了試點計畫能否在面對業主委員會時倖存下來。
目前尚無人立法的層面

該法案並未像新加坡的標準那樣,強制奧的斯(Otis)、通力(KONE)、施耐德(Schindler)或任何其他在韓國營運的製造商,公開共享其專有協定。 這項特別法案中沒有任何條文要求如此,而電梯製造商的商業立場也完全沒有跡象顯示他們會自願這麼做。專有 API 會產生轉換成本,而正是由於這種轉換成本,導致機器人車隊營運商一旦在建築物組合中與某個電梯品牌整合後,往往會繼續簽訂該品牌的服務合約,其持續時間遠遠超過硬體本身應有的使用壽命。

我們營運的平台會追蹤整個地區的機器人部署情況——這點在大多數電梯案例研究中往往被完全忽略——而這種模式給人的感覺是熟悉而非令人意外。 無論是馬尼拉的公寓大樓還是首爾的住宅大樓,通常都使用著那幾家全球知名的電梯品牌;而機器人供應商在其中一處遭遇的整合阻力,在另一處同樣會遇到,無論哪個國家的立法機關剛剛通過了法案。 政策僅能解決選民看得見的那一層:誰能進入大廳、發生故障時由誰買單。它極少觸及立法者無法想像的那一層——即機器人調度系統與電梯控制器韌體之間的軟體協定——因為這層從一開始就從未公開過。

新加坡的賭注在於,由政府起草的技術標準最終能勝過三大

若市場有足夠多的參與者採用該標準,且對 ISO 標準的推動形成足夠大的壓力,便能取代那些不相容的企業標準。與以年底通過為目標的全國性法案相比,這是一項進展較慢、較少吸引媒體頭條的賭注。此外,在當前這兩項方案中,這也是唯一針對「一旦遊說大門開啟便不會消失」的問題環節所提出的解決方案。

本分析反映截至發佈日止的公開資訊,不應被視為投資、財務或專業建議;其僅供一般資訊參考之用。

首圖:LG CLOi 服務機器人在貿易展上展示奧的斯「Enhance Cab for Robots」電梯整合方案。奧的斯全球官方攝影。

RoboticsServiceRobotsSouthKoreaSingaporeStandardsInteroperabilityBuildingAutomationAsia