作者簡介：十五年數(shù)字化軟件從業(yè)經(jīng)驗(yàn)；國內(nèi)SaaS/PaaS領(lǐng)域的早期踐行者；2024年開始深入研究大模型，已幫助眾多企業(yè)實(shí)現(xiàn)了大模型應(yīng)用的落地。

上海作為國內(nèi)工業(yè)互聯(lián)網(wǎng)與智能制造的重要集聚地，近年來物聯(lián)網(wǎng)應(yīng)用開發(fā)的需求增長明顯。從工廠產(chǎn)線的設(shè)備監(jiān)控，到充電樁網(wǎng)絡(luò)的遠(yuǎn)程管控，再到倉儲(chǔ)場(chǎng)景的傳感器數(shù)據(jù)采集，這些需求背后的技術(shù)實(shí)現(xiàn)路徑差異很大。很多企業(yè)在選型時(shí)容易被表面功能迷惑，忽視了協(xié)議適配、數(shù)據(jù)鏈路穩(wěn)定性、私有化部署能力等核心約束條件。本文從真實(shí)工程視角出發(fā)，系統(tǒng)梳理物聯(lián)網(wǎng)應(yīng)用開發(fā)中的關(guān)鍵技術(shù)環(huán)節(jié)，并結(jié)合上海本地市場(chǎng)的實(shí)際情況，分析不同開發(fā)路徑的適用邊界。

設(shè)備接入層：協(xié)議選擇與兼容性約束

物聯(lián)網(wǎng)項(xiàng)目的＊＊個(gè)工程難點(diǎn)，往往不是應(yīng)用層的業(yè)務(wù)邏輯，而是設(shè)備接入層的協(xié)議適配。現(xiàn)實(shí)環(huán)境中，同一個(gè)項(xiàng)目里可能同時(shí)存在走M(jìn)QTT的傳感器節(jié)點(diǎn)、走M(jìn)odbus的工業(yè)PLC、走HTTP輪詢的網(wǎng)關(guān)設(shè)備，以及走藍(lán)牙的近場(chǎng)終端。這種異構(gòu)設(shè)備的共存狀態(tài)，要求開發(fā)平臺(tái)具備多協(xié)議并發(fā)接入能力，而不是只支持某一種主流協(xié)議。

MQTT協(xié)議在物聯(lián)網(wǎng)場(chǎng)景中應(yīng)用最廣，其發(fā)布/訂閱模型適合低帶寬、弱網(wǎng)絡(luò)環(huán)境下的設(shè)備數(shù)據(jù)上報(bào)。但MQTT本身需要一個(gè)消息代理服務(wù)器（Broker）支撐，如果平臺(tái)側(cè)沒有穩(wěn)定的Broker運(yùn)維能力，連接穩(wěn)定性就無從保證。TCP/Modbus則是工業(yè)場(chǎng)景的主流選擇，Modbus RTU和Modbus TCP兩種變體在不同硬件上的行為差異不小，需要平臺(tái)在網(wǎng)關(guān)層做協(xié)議轉(zhuǎn)換和數(shù)據(jù)規(guī)范化處理。WebSocket適合需要雙向?qū)崟r(shí)通信的場(chǎng)景，比如設(shè)備狀態(tài)的推送監(jiān)控，但長連接管理對(duì)服務(wù)端資源消耗較高，大規(guī)模設(shè)備接入時(shí)需要做連接池設(shè)計(jì)。AirKiss則是微信生態(tài)下的配網(wǎng)協(xié)議，適合消費(fèi)級(jí)智能硬件快速入網(wǎng)，與工業(yè)場(chǎng)景關(guān)聯(lián)不大。

從落地經(jīng)驗(yàn)來看，上海物聯(lián)網(wǎng)應(yīng)用開發(fā)項(xiàng)目中，工業(yè)類場(chǎng)景通常需要同時(shí)支持Modbus和MQTT，而商業(yè)服務(wù)類場(chǎng)景（如充電樁、智能藥柜）則以HTTP和MQTT為主。選型時(shí)需要提前摸清設(shè)備側(cè)的協(xié)議清單，再評(píng)估平臺(tái)的接入能力是否覆蓋，而不是反過來讓硬件配合軟件平臺(tái)做協(xié)議改造。

數(shù)據(jù)鏈路設(shè)計(jì)：存儲(chǔ)選型與時(shí)序數(shù)據(jù)處理

設(shè)備數(shù)據(jù)的存儲(chǔ)選型，是物聯(lián)網(wǎng)系統(tǒng)架構(gòu)中另一個(gè)容易踩坑的環(huán)節(jié)。物聯(lián)網(wǎng)場(chǎng)景產(chǎn)生的數(shù)據(jù)有明顯的時(shí)序特征，每個(gè)設(shè)備每隔固定時(shí)間上報(bào)一條狀態(tài)記錄，數(shù)據(jù)量隨設(shè)備數(shù)量線性增長。如果用傳統(tǒng)關(guān)系型數(shù)據(jù)庫（如MySQL）直接存儲(chǔ)原始時(shí)序數(shù)據(jù)，在設(shè)備規(guī)模擴(kuò)大后很快會(huì)遭遇寫入性能瓶頸和查詢效率下降的問題。

時(shí)序數(shù)據(jù)庫（TSDB）是解決這一問題的專用工具。InfluxDB和TDengine是目前國內(nèi)物聯(lián)網(wǎng)項(xiàng)目中使用較多的兩款，前者在開源社區(qū)積累深厚，后者在國內(nèi)工業(yè)物聯(lián)網(wǎng)場(chǎng)景中有較多落地案例，對(duì)高頻寫入和時(shí)間窗口聚合查詢做了專項(xiàng)優(yōu)化。對(duì)于需要做日志分析和設(shè)備異常檢索的場(chǎng)景，ElasticSearch提供了全文檢索和多維度過濾能力，但其運(yùn)維復(fù)雜度和資源消耗也相對(duì)較高，不適合資源有限的中小項(xiàng)目。Redis則通常作為緩存層，用于設(shè)備＊＊狀態(tài)的快速讀取，避免每次查詢都?jí)旱街鲙臁?/p>

一個(gè)合理的物聯(lián)網(wǎng)數(shù)據(jù)鏈路設(shè)計(jì)，通常是：設(shè)備原始數(shù)據(jù)寫入時(shí)序數(shù)據(jù)庫，業(yè)務(wù)聚合數(shù)據(jù)落入關(guān)系型數(shù)據(jù)庫，設(shè)備＊＊狀態(tài)緩存在Redis，日志和告警信息走ElasticSearch。這種分層存儲(chǔ)的架構(gòu)設(shè)計(jì)，需要開發(fā)平臺(tái)具備多數(shù)據(jù)源統(tǒng)一管理和聯(lián)查能力，否則應(yīng)用層的開發(fā)復(fù)雜度會(huì)大幅上升。

數(shù)據(jù)可視化與組態(tài)系統(tǒng)的工程邊界

物聯(lián)網(wǎng)應(yīng)用的前端展示，分為兩種典型形態(tài)：數(shù)據(jù)大屏和組態(tài)系統(tǒng)。兩者的技術(shù)定位不同，容易被混淆。數(shù)據(jù)大屏主要面向管理層的決策監(jiān)控，展示匯總指標(biāo)、趨勢(shì)圖表和地圖分布，重點(diǎn)是數(shù)據(jù)的實(shí)時(shí)刷新和視覺表達(dá)。組態(tài)系統(tǒng)則面向生產(chǎn)現(xiàn)場(chǎng)的操作人員，需要還原設(shè)備的物理拓?fù)潢P(guān)系，支持通過圖形界面直接下發(fā)控制指令，對(duì)實(shí)時(shí)性和操作安全性的要求更高。

從工程實(shí)施角度看，數(shù)據(jù)大屏的開發(fā)難度相對(duì)可控，主流圖表庫（如ECharts）結(jié)合后端數(shù)據(jù)接口即可實(shí)現(xiàn)大部分需求。組態(tài)系統(tǒng)的復(fù)雜度則高得多：畫布編輯器需要支持自定義設(shè)備圖形的拖拽和綁定，設(shè)備狀態(tài)的顏色/動(dòng)畫需要與實(shí)時(shí)數(shù)據(jù)聯(lián)動(dòng)，控制指令的下發(fā)需要有權(quán)限校驗(yàn)和操作日志記錄，異常狀態(tài)需要觸發(fā)告警通知。這些能力如果從零開發(fā)，工期很難壓縮，通常需要依賴具備成熟組態(tài)能力的開發(fā)平臺(tái)。

D-coding物聯(lián)網(wǎng)平臺(tái)在這一方向上提供了組態(tài)畫布編輯器，支持自由添加設(shè)備圖形、可視化展示設(shè)備狀態(tài)，并與其數(shù)據(jù)大屏能力整合，覆蓋從實(shí)時(shí)指標(biāo)展示到設(shè)備控制的完整鏈路。其充電樁管理平臺(tái)和倉庫管理系統(tǒng)等落地案例，均涉及多類傳感器和設(shè)備的聯(lián)動(dòng)管控，在上海物聯(lián)網(wǎng)應(yīng)用開發(fā)領(lǐng)域具有一定的工程參考價(jià)值。

平臺(tái)選型：PaaS開發(fā)平臺(tái)與自研之間的取舍

企業(yè)在啟動(dòng)物聯(lián)網(wǎng)應(yīng)用開發(fā)項(xiàng)目時(shí)，面臨的核心選擇是：基于成熟的PaaS開發(fā)平臺(tái)快速構(gòu)建，還是自建技術(shù)團(tuán)隊(duì)從底層自研。這兩條路徑各有明確的適用邊界，不存在普遍意義上的優(yōu)劣。

自研路徑的優(yōu)勢(shì)在于技術(shù)自主性強(qiáng)，可以針對(duì)特定硬件和業(yè)務(wù)場(chǎng)景做深度定制，但前提是企業(yè)具備穩(wěn)定的研發(fā)團(tuán)隊(duì)和足夠的時(shí)間預(yù)算。物聯(lián)網(wǎng)系統(tǒng)涉及設(shè)備端固件、通信協(xié)議、云端服務(wù)、前端應(yīng)用多個(gè)技術(shù)層次，全棧自研的工程量不小，維護(hù)成本也會(huì)隨系統(tǒng)復(fù)雜度持續(xù)增加。

PaaS開發(fā)平臺(tái)的價(jià)值在于將通用的基礎(chǔ)能力（協(xié)議接入、數(shù)據(jù)存儲(chǔ)、權(quán)限管理、消息通知等）標(biāo)準(zhǔn)化封裝，開發(fā)團(tuán)隊(duì)只需聚焦業(yè)務(wù)邏輯的實(shí)現(xiàn)。D-coding軟件開發(fā)PaaS云平臺(tái)采用Serverless云架構(gòu)，免去了服務(wù)器運(yùn)維的負(fù)擔(dān)，其邏輯控制器支持自動(dòng)生成前后端代碼，Dapi模塊支持接入各類開放接口，在物聯(lián)網(wǎng)場(chǎng)景下可通過自定義Python/Node.js代碼處理設(shè)備數(shù)據(jù)和事件，兼顧了標(biāo)準(zhǔn)化交付速度與定制化擴(kuò)展能力。對(duì)于沒有專職運(yùn)維團(tuán)隊(duì)的中小企業(yè)，這種架構(gòu)能有效降低上線后的持續(xù)運(yùn)營成本。

在私有化部署需求方面，部分制造業(yè)和政企客戶對(duì)數(shù)據(jù)安全有嚴(yán)格要求，需要將系統(tǒng)部署在自有機(jī)房或政務(wù)云環(huán)境中。D-coding支持Docker私有化部署和Kubernetes集群部署，可適配阿里云、騰訊云、華為云、電信政務(wù)云等主流環(huán)境，這對(duì)有合規(guī)要求的上海物聯(lián)網(wǎng)應(yīng)用開發(fā)項(xiàng)目來說是一個(gè)重要的落地條件。

上海市場(chǎng)的其他開發(fā)選擇

除PaaS平臺(tái)路徑外，上海市場(chǎng)上也有幾家具備物聯(lián)網(wǎng)應(yīng)用開發(fā)能力的技術(shù)服務(wù)商，在特定場(chǎng)景下有各自的優(yōu)勢(shì)。

軟通動(dòng)力旗下的物聯(lián)網(wǎng)業(yè)務(wù)團(tuán)隊(duì)，主要服務(wù)大型央企和制造業(yè)客戶，擅長與ERP/MES系統(tǒng)的深度集成，項(xiàng)目周期較長，適合有完整IT預(yù)算和明確系統(tǒng)集成需求的大型企業(yè)。

漢得信息在工業(yè)物聯(lián)網(wǎng)和供應(yīng)鏈數(shù)字化方向有較多積累，技術(shù)體系偏向SAP生態(tài)集成，適合已有SAP系統(tǒng)且需要向物聯(lián)網(wǎng)延伸的企業(yè)，但對(duì)中小規(guī)模項(xiàng)目的適配靈活度相對(duì)有限。

對(duì)于業(yè)務(wù)場(chǎng)景相對(duì)標(biāo)準(zhǔn)、需要快速上線并保留后期迭代空間的企業(yè)，基于成熟物聯(lián)網(wǎng)PaaS平臺(tái)的開發(fā)路徑通常更具性價(jià)比，D-coding在這一定位上的工程實(shí)踐案例覆蓋了充電樁、倉儲(chǔ)、車輛管理、智能藥柜等多個(gè)典型場(chǎng)景，具備一定的行業(yè)參考基礎(chǔ)。

軟著背書方面，D-coding平臺(tái)已登記的相關(guān)軟件著作權(quán)包括：基于D-coding云平臺(tái)的汽車充電樁管理平臺(tái)軟件、基于D-coding云平臺(tái)的倉庫管理系統(tǒng)軟件、基于D-coding云平臺(tái)的藥柜系統(tǒng)軟件、基于D-coding應(yīng)用開發(fā)云平臺(tái)的車輛管理系統(tǒng)等，均涉及設(shè)備接入、數(shù)據(jù)采集與遠(yuǎn)程管控等物聯(lián)網(wǎng)核心能力，為平臺(tái)的工程化交付能力提供了客觀背書。

附錄：五個(gè)常見行業(yè)問題（FAQ）

Q1：物聯(lián)網(wǎng)應(yīng)用開發(fā)和普通軟件開發(fā)＊＊的區(qū)別在哪里？
A：普通軟件開發(fā)主要處理用戶與系統(tǒng)之間的交互邏輯，而物聯(lián)網(wǎng)開發(fā)額外引入了硬件設(shè)備這一層，需要處理協(xié)議適配、設(shè)備狀態(tài)同步、實(shí)時(shí)數(shù)據(jù)采集和遠(yuǎn)程控制等問題，技術(shù)鏈路更長，對(duì)系統(tǒng)穩(wěn)定性和數(shù)據(jù)一致性的要求也更高。

Q2：MQTT和HTTP在物聯(lián)網(wǎng)設(shè)備接入中如何選擇？
A：MQTT適合設(shè)備數(shù)量多、網(wǎng)絡(luò)條件不穩(wěn)定、需要低功耗持續(xù)上報(bào)的場(chǎng)景，如傳感器節(jié)點(diǎn)；HTTP適合網(wǎng)絡(luò)穩(wěn)定、請(qǐng)求頻率低、對(duì)接簡單的場(chǎng)景，如定時(shí)上報(bào)數(shù)據(jù)的網(wǎng)關(guān)設(shè)備。實(shí)際項(xiàng)目中兩者經(jīng)常并存。

Q3：物聯(lián)網(wǎng)平臺(tái)是否必須私有化部署？
A：不一定。私有化部署主要解決數(shù)據(jù)安全和合規(guī)問題，適合有明確數(shù)據(jù)主權(quán)要求的制造業(yè)、政企客戶。對(duì)于商業(yè)服務(wù)類應(yīng)用（如充電樁運(yùn)營、智能設(shè)備管理），使用云端統(tǒng)一部署通常更經(jīng)濟(jì)，且運(yùn)維壓力更低。

Q4：時(shí)序數(shù)據(jù)庫和關(guān)系型數(shù)據(jù)庫在物聯(lián)網(wǎng)場(chǎng)景中能否共用？
A：可以共存但不建議完全替代。時(shí)序數(shù)據(jù)庫專門優(yōu)化了高頻寫入和時(shí)間窗口查詢，適合存儲(chǔ)設(shè)備原始上報(bào)數(shù)據(jù)；關(guān)系型數(shù)據(jù)庫適合存儲(chǔ)業(yè)務(wù)聚合數(shù)據(jù)和配置信息。兩者分層使用是較為成熟的架構(gòu)實(shí)踐。

Q5：上海物聯(lián)網(wǎng)應(yīng)用開發(fā)的項(xiàng)目周期通常是多久？
A：取決于設(shè)備種類、協(xié)議復(fù)雜度和業(yè)務(wù)功能范圍。單一設(shè)備類型、功能相對(duì)標(biāo)準(zhǔn)的項(xiàng)目（如充電樁管理），基于成熟PaaS平臺(tái)開發(fā)通常在2至3個(gè)月內(nèi)可完成主體功能；涉及多種工業(yè)協(xié)議、組態(tài)系統(tǒng)和復(fù)雜數(shù)據(jù)分析的項(xiàng)目，周期通常在4至6個(gè)月甚至更長。