在數(shù)字化時代，物聯(lián)網(wǎng)和低代碼技術正逐漸改變著我們的工作和生活方式。本文將深入探討數(shù)智化物聯(lián)網(wǎng)平臺的發(fā)展，特別是低代碼理念在物聯(lián)網(wǎng)領域的應用和物模型的演化。

近期學習低代碼產(chǎn)品的設計理念，在不同平臺上看到了很多觀點，有的人認為低代碼技術是福音，特別是國內(nèi)外IT大廠的官方說法，總體對其保持樂觀態(tài)度。也有很多人拋出了低代碼簡直就是“毒瘤”的觀點。

在學習過程中，尤其是了解新事物的過程中，我們始終都應該帶著批判性的思維去看待各種觀點，與直接認同某個看起來正確的觀點相比，深入了解發(fā)言人的立場、了解他為什么抱有這種觀點，才是更高層次的學習方式。

01 為什么不看好？

低代碼所處的位置比較尷尬，很多人認為其恰恰處于一個半吊子的位置。尤其是從大多數(shù)程序員的視角來看，低代碼這個東西的定位非常雞肋。

首先，對于非技術人員，比如產(chǎn)品、運營、銷售甚至是甲方客戶來說，低代碼的操控并不算便捷，上手是有一定難度的，并且還需要系統(tǒng)的學習，才能初步掌握其使用方法。

而對于開發(fā)者來說，低代碼的自由程度和靈活性跟真正的代碼肯定無法比擬，一些用戶的靈活需求，如果要是一開始設計的低代碼系統(tǒng)能配置還好，如果不能配置，最終還是得在底層進行修改，而且修改起來肯定比直接按需開發(fā)的系統(tǒng)費勁的多。

這個東西就像混動汽車一樣充滿爭議，混動汽車的動力系統(tǒng)介于油車和電車之間。認為它好的人，認為它平時既能燒電省錢，萬一充不上電還可以加油續(xù)航，不用擔心趴窩，滿眼都是它的優(yōu)點?？床黄鸹靹悠嚨娜?，認為它燒起油來比油車費油的多，動力又不太足，總之滿是槽點。

其實，無論是用來舉例的混動汽車也好，還是低代碼這個工具也好，處在中間位置的這類工具，必然是優(yōu)劣兼具，甚至還將某些優(yōu)勢和劣勢進行了放大。關鍵還是要明確使用場景和使用者，之后恰當?shù)厥褂迷摴ぞ?，從而揚長避短。

講到這里，我們需要明確低代碼這一工具，真正的使用者應該是誰。筆者認為，應該是數(shù)字化轉型技術廠商的“產(chǎn)品運營”或“售后/售前技術支持”?？偠灾瑧摻唤o乙方的非技術人員使用。這些專門人員在經(jīng)過合理的上崗培訓后，也會熟練使用低代碼工具。

與此相匹配的工作流程是：產(chǎn)品研發(fā)者在大量項目中不斷積累經(jīng)驗，開發(fā)出不同場景下對應的低代碼產(chǎn)品，之后由乙方非技術人員操刀，通過與客戶進行持續(xù)溝通，使用低代碼工具為同場景下不同的客戶配置并交付符合其使用習慣的最終平臺，并在實際使用過程中發(fā)現(xiàn)問題，提出需求，為研發(fā)團隊迭代優(yōu)化低代碼產(chǎn)品提供依據(jù)。

（圖片來源：點維數(shù)智PM原創(chuàng)）

02 數(shù)智化，走向標準還是定制

任何一家提供數(shù)字化轉型服務的技術廠商都會告訴你，不同行業(yè)、甚至同一個行業(yè)的不同公司，數(shù)字化產(chǎn)品的設計都是千差萬別的。然而等他們以各種方式拿下項目后，研發(fā)人員一定都會想著在做系統(tǒng)時，能不能照搬和復用之前做過的系統(tǒng)，實在不濟，參考著改一下也行。

數(shù)字化轉型產(chǎn)品，到底是走向標準化還是定制化，其實是一個難以抉擇的問題。對于數(shù)字化轉型解決方案提供商來說，走標準化路線意味著可以大量、快速地復制并推廣其產(chǎn)品，從而極大減少邊際成本，實現(xiàn)持續(xù)盈利，也可以薄利多銷，讓數(shù)字化轉型技術普惠更多受眾。

另一方面，基于用戶使用體驗來說，客戶也期望看到數(shù)字化轉型服務商深入其一線調(diào)研，并對其實際出現(xiàn)的問題進行深刻的理解，并最終交付與其業(yè)務流程高度匹配的產(chǎn)品?？蛻舻南敕ㄒ埠芎唵危骸?strong>既然我給你錢了，那你的眼里只能有我，不要拿給別人做的東西復制過來糊弄我。”

而筆者個人的看法是，數(shù)字化產(chǎn)品也趨向于走入標準和定制的中間態(tài)模式。當然，這種和稀泥的結論，也意味著產(chǎn)品設計者需要結合具體情況，審時度勢，能力要求和主動程度都需要進行大幅度的提升。

在瀏覽過大量的項目案例后，筆者發(fā)現(xiàn)，在很多產(chǎn)品場景中，使用低代碼可以很好地解決系統(tǒng)在標準化和定制化之間的平衡問題。

流程引擎其實就是一個非常好的例子。目前很多低代碼或零代碼產(chǎn)品，都習慣性地往OA工具上發(fā)展，這就是因為低代碼高度靈活性和可配置性的特點，實實在在解決了企業(yè)審批系統(tǒng)的痛點。

比如說，一個大型制造業(yè)企業(yè)中，不同事業(yè)部、不同部門和不同產(chǎn)線上，審批流程花樣百出。還有的需要加很多規(guī)則在里邊，例如“資金超過200需要領導審批，低于200自動通過”。再加上頻繁的人事調(diào)動，也意味著審批環(huán)節(jié)上的每個人都需要及時更新。

假如所有的流程都是研發(fā)同事們直接開發(fā)出來的，那對于這種變動非常頻繁，規(guī)則復雜且繁雜的應用場景，幾乎每天都需要不斷迭代，耗費大量開發(fā)精力。

所以，如果OA系統(tǒng)靈活可配置，在日常運營過程中，即使流程千變?nèi)f化，也只需要安排一些普通員工隨時配置即可。現(xiàn)在的OA工具，低代碼基本已經(jīng)占據(jù)主導，但在其他領域，筆者認為，這種產(chǎn)品理念貫徹地還不夠深入。

（圖片來源：點維數(shù)智PM原創(chuàng)）

接下來，筆者將通過自己設計的產(chǎn)品案例，來進行低代碼這一產(chǎn)品理念在產(chǎn)品設計中應用的復盤。在實際項目中，筆者對這兩個產(chǎn)品進行了大膽創(chuàng)新，雖然還有很多地方需要完善，但這兩個案例，在低代碼解決數(shù)字化項目中標準與定制之間矛盾的問題上，已初具雛形。

03 案例：樓宇自控項目復盤

樓宇自控系統(tǒng)一般會在智慧樓宇項目中體現(xiàn)。我們平日所見的高樓大廈，內(nèi)部都安裝著復雜的電氣設備，來保障樓宇內(nèi)環(huán)境的舒適。其中包括調(diào)節(jié)溫度的空調(diào)系統(tǒng)、保持室內(nèi)環(huán)境清新的送排風系統(tǒng)、以及常見的給排水系統(tǒng)、變配電系統(tǒng)、照明系統(tǒng)等。

樓宇內(nèi)各種系統(tǒng)的詳細工作原理，日后再與大家做詳細討論。在數(shù)字化項目中，針對樓宇自控系統(tǒng)，我們一般需要做如下功能：

1. 設備臺賬管理，樓宇自控系統(tǒng)包含空調(diào)、送排風機、潛水泵等設備設施，照明、電梯、監(jiān)控等電器也包含在內(nèi)。按照統(tǒng)一標準為所有設備建立臺賬，構建逐一對應關系，并在其他流程中引用，確立系統(tǒng)與硬件之間的交互關系，都需要基于設備臺賬這一系統(tǒng)基礎。
2. 數(shù)據(jù)監(jiān)控，樓宇內(nèi)各個系統(tǒng)的傳感器或數(shù)據(jù)監(jiān)測點，都可以實時采集大量數(shù)據(jù)，例如當下的溫度、濕度、送風溫濕度、水箱水位等。數(shù)據(jù)監(jiān)控系統(tǒng)也是大多數(shù)綜合解決方案提供商所能做到的層次，核心技術就是協(xié)議解析、數(shù)據(jù)采集與分析。
3. 下發(fā)控制命令，有采集信息的點位，必然也有下發(fā)控制指令的點位，例如設置空調(diào)制冷溫度，打開送風閥，控制水泵開始運作等等。在產(chǎn)品設計層面，我們可以設計為手動控制，或根據(jù)一定的條件由系統(tǒng)自動控制。
4. 可視化，無論是組態(tài)圖繪制，還是數(shù)字孿生技術的使用，都是可視化的一種。
5. 自動調(diào)度，這也是最難但是能形成核心壁壘的東西，通過引入智能算法，根據(jù)現(xiàn)場條件，自動控制樓宇內(nèi)各個環(huán)節(jié)，達到環(huán)境舒適的同時，又能節(jié)能，且可以延長設備使用壽命的目標。

筆者在設備臺賬管理、數(shù)據(jù)監(jiān)控和下發(fā)控制命令層面，引入了低代碼的設計理念，設計了一套自由，可配置化程度比較高的通用型產(chǎn)品。

首先，要想實現(xiàn)樓宇自控的基礎功能，大體需要規(guī)劃兩個模塊，一個是軟件平臺，另一個是協(xié)議解析模塊。

先說協(xié)議解析模塊，如果我們遇到比較好的硬件商家，從系統(tǒng)平臺上直接提供API接口，那開發(fā)就可以直接寫代碼對接了，省時省力。如果硬件商家提供的是遵循某個協(xié)議的數(shù)據(jù)傳輸服務，那我們就需要解析協(xié)議，并封裝成標準接口或消息推送，常見的物聯(lián)網(wǎng)傳輸協(xié)議包括obix、modbus等。

總之，提供給軟件平臺的，必然是已經(jīng)封裝好的標準化接口，按照以往的開發(fā)方式，我們都會先按照客戶需求，開發(fā)好對應的界面，之后由開發(fā)同事進行接口對接，提取數(shù)據(jù)進行分析，并做一些按鈕，下發(fā)控制指令。

這樣做的劣勢是，系統(tǒng)的定制化屬性太強，特別還是智慧樓宇這種，不同客戶差異性比較大的項目，幾乎每換一個客戶，都要重新開發(fā)一次。而且還需要拿到所有電氣及弱電系統(tǒng)的點位、設計圖之后，才能進行分析、開發(fā)，不僅開發(fā)量大，工期也難以保障。

所以，為了使系統(tǒng)更為靈活，筆者從數(shù)據(jù)角度出發(fā)，對點位數(shù)據(jù)進行分類整理，設計了一套智慧樓宇低代碼產(chǎn)品。產(chǎn)品部署完成后，可以由非技術人員進行配置，在拿到設備點表以及接口列表后，可以快速配置并上線。

（圖片來源：點維數(shù)智PM原創(chuàng)）

對智慧樓宇場景下的數(shù)據(jù)來說，如果按照數(shù)據(jù)類型來劃分，總共也就數(shù)字類型和模擬類型兩種。工科的同學可能清楚，數(shù)字類型無非就是0或1，例如設備的開和關，設備的在線/離線，就可以用0和1來代替。模擬類型則代表連續(xù)值，例如溫度值、濕度值等連續(xù)且可以在一定范圍內(nèi)任意取值的數(shù)據(jù)指標。當然，在實際場景中，受制于設備采集精度，也只能取離散值。

如果按照功能類型來劃分，所有的數(shù)據(jù)分為兩種，采集數(shù)據(jù)和控制數(shù)據(jù)。例如某些接口中的數(shù)據(jù)，我們需要調(diào)用接口將其采集上來，而某些接口中的字段，我們可以通過調(diào)用進而控制其開關或進行溫度、濕度等數(shù)值的設定。

基于此，我們可以開始設計智慧樓宇低代碼管理系統(tǒng)的雛形。首先，在主頁面設置一個列表，列表橫向分為三個區(qū)，一是設備信息區(qū)，用來導入設備臺賬；二是數(shù)據(jù)采集區(qū)，用來讀取各個點位所檢測的數(shù)據(jù)；三是控制指令區(qū)，用來手動發(fā)送控制指令。

在設備信息區(qū)，我們可以添加一個導入功能，將設備臺賬中的設備導入進去，并且獲取其設備ID。這樣就可以明確，每一行數(shù)據(jù)在調(diào)接口時，采集的是哪個設備的信息。當然，在設備信息區(qū)，我們也可以隨設備臺賬加入其他設備屬性，例如設備名稱、設備位置、設備自定義編碼等。

在數(shù)據(jù)采集區(qū)，我們可以逐個為指定設備添加一個個需要采集上來的字段，在配置每一個字段時，我們需要配置以下幾點信息：

• 字段名稱：為這個數(shù)據(jù)指標起一個自定義的名稱，例如出風閥溫度，進水流量，室內(nèi)溫度，設備在/離線狀態(tài)等。
• 字段類型：作為數(shù)據(jù)監(jiān)測字段來說，字段類型共分為兩類，一類是模擬類型，這種類型的字段直接取返回值即可，例如溫度，濕度等。另一類是枚舉類型，該類型一般能夠包含數(shù)字類型，不同的是，數(shù)字類型一般就是0和1兩種枚舉，而廣泛的枚舉類型，一般可以有多個枚舉值。枚舉類型的數(shù)據(jù)，一般返回值都是枚舉值，例如0,1,2這樣的編碼，我們需要根據(jù)接口定義，對每一個枚舉值定義其含義，例如0代表關閉、1代表設備在線等等。
• 接口地址：對于系統(tǒng)來說，我們需要明確調(diào)用哪個接口，輸入對應的調(diào)用值以后，才能返回我們需要的監(jiān)測數(shù)據(jù)，一般每個接口在一定網(wǎng)絡范圍內(nèi)都會提供一個唯一的接口調(diào)用地址，我們將接口地址配置好，系統(tǒng)就知道找哪個接口去執(zhí)行調(diào)用操作了。
• 對應字段：一個接口調(diào)用后，往往會返回一大堆值，那么具體返回的哪個值能對應上我們配置的這個字段呢？這時候就需要明確所配置字段與實際接口返回字段的映射關系，將接口中對應的返回值填入對應字段輸入框。

控制指令區(qū)與數(shù)據(jù)采集區(qū)的道理基本相同，我們在控制指令區(qū)配置控制字段時，每個字段都需要配置字段名稱、字段類型、接口地址和對應字段這幾項，不同的是，數(shù)據(jù)采集區(qū)錄入的對應字段要從接口的輸出值中找，而控制指令區(qū)錄入的對應字段要從接口的輸入值中找。

（圖片來源：點維數(shù)智PM原創(chuàng)）

04 物模型

以上章節(jié)都是在沒有相關理論知識儲備的情況下，作為一個新入門的產(chǎn)品經(jīng)理，在行業(yè)通用產(chǎn)品的設計過程中普遍的思考邏輯。

在對市面上成熟的物聯(lián)網(wǎng)平臺產(chǎn)品進行使用和分析后，我們可以發(fā)現(xiàn)，雖然與低代碼工具有一定差別，但物聯(lián)網(wǎng)平臺要實現(xiàn)其靈活性，貫徹低代碼的理念是非常重要的。

面對復雜多樣的物聯(lián)網(wǎng)設備，現(xiàn)行的通用且先進的解決方案是將具有同一類功能的設備定義為一個產(chǎn)品，之后為這個產(chǎn)品匹配物模型。物模型在物聯(lián)網(wǎng)平臺中也是一個重要的概念，受篇幅限制，本次只進行簡單介紹，后續(xù)有機會我們可以詳細拆解。

當我們把同一類功能相同的設備集合成一個產(chǎn)品后，對產(chǎn)品物模型的定義，要從三個維度進行，分別是屬性、服務和事件。

1. 屬性：設備的功能模型之一，一般用于描述設備運行時的狀態(tài)，如環(huán)境監(jiān)測設備所讀取的當前環(huán)境溫度等。應用系統(tǒng)可發(fā)起對屬性的讀取和設置請求。（相當于給設備定義一個數(shù)據(jù)庫，并且把表頭寫好）
2. 服務：設備的功能模型之一，設備可被外部調(diào)用的能力或方法，可設置輸入?yún)?shù)和輸出參數(shù)。相比于屬性，服務可通過一條指令實現(xiàn)更復雜的業(yè)務邏輯，如執(zhí)行某項特定的任務。（相當于給設備定義好相關的功能接口）
3. 事件：設備的功能模型之一，設備運行時的事件。事件一般包含需要被外部感知和處理的通知信息，可包含多個輸出參數(shù)。例如，某項任務完成的信息，或者設備發(fā)生故障或告警時的溫度等，事件可以被訂閱和推送。（相當于給設備加上幾個消息推送，并把消息體定義好）

物模型定義好以后，相當于在物聯(lián)網(wǎng)軟件平臺上構建好了相關設備的虛擬數(shù)字化實體，該虛擬實體實時映射實際設備，而我們接下來在搭建應用時，如設備臺賬、設備巡檢、組態(tài)可視化、邏輯編排等，可以直接面向已經(jīng)設置好物模型的虛擬數(shù)字化實體進行操作。所謂數(shù)字化的第一步——數(shù)據(jù)采集，我們也算踏過了其中一個門檻。