現有硬件和軟件的許多來源都可以整合到開源社區提供的新設計中。商業上可行的開源產品范圍從 Linux 等操作系統軟件到 BeagleBoard 等物理硬件設備。雖然此類基本構建塊通常可以免費使用，但它們仍受原始創建者發布設計時所依據的條款的約束，無論是 GNU 公共許可證、Apache 還是類似條款。

可擴展性的主要缺點是傳統范例是為底層硬件平臺構建一個板級支持包（BSP），然后在已從應用程序開發人員那里抽象出硬件的測試軟件平臺之上構建所有應用程序。如果底層硬件最終需要在現場進行更改，那么在大多數情況下，需要打開外殼，更換電路板，并且必須構建、測試和安裝新的 BSP。

克服這個缺點的第一步是嚴格定義一組最低級別的硬件接口，這些接口可以通過詳細的電氣和機械文檔公開，并由成為已發布 BSP 一部分的鎖定驅動程序代碼在最低層提供支持。這需要在產品的工業設計中進行規劃和適應。在大多數情況下，這不僅僅意味著簡單地選擇一個普遍存在的 USB 連接器并假設已考慮到可擴展性。USB 可能會在許多市場中造成實際的環境問題，例如缺乏對高振動用途的適用性。當以前未知的 USB 設備作為核心設備的新突出物連接時，也會對產品的美觀產生潛在的負面影響。

過去，個人計算機行業已成功使用定義通用電氣和機械擴展接口的方法。最早的 PC 機器模型在 IBM 的產品和隨后的許多克隆產品之間共享 ISA 總線通用性。不幸的是，由于各種物理原因，當前的 PC 擴展槽策略不能很好地轉化為大多數嵌入式應用程序，并且嵌入式設計缺乏 PC BIOS 的通用性，無法使不同的硬件在軟件開發人員看來相對統一。因此，對于嵌入式產品來說，為現場添加的硬件部署軟件支持可能會更加困難。

用于部署驅動程序軟件的 PC 模型也普遍優于嵌入式產品的行業標準。現代 PC 操作系統（包括基于 Microsoft 的各種 Linux 發行版）在新硬件枚舉時自動讀取設備信息，并自動從中央存儲庫中檢索相關的軟件驅動程序。對于最終用戶來說，這通常是一種非常令人滿意的體驗，如果現場可擴展嵌入式設備要取得成功，就需要重新創造這種體驗。

易于開發的硬件與易于部署且對現場安裝人員的影響最小的軟件支持相結合，在實際開發大多數最終產品的嵌入式空間中一直缺乏。通過考慮硬件擴展選項的平臺獨立性以及部署軟件的集中機制的深思熟慮的設計方法，可以在產品系列的嵌入式空間中復制 PC 方法。

盡管這種從標準化平臺創建可定制設備的方法可以應用于許多需要現場可配置性的設備，但它在以物聯網 （IoT） 空間連接為中心的設備中尤為重要。在考慮通用監控應用程序時，很容易設計一個實現一些標準接口的通信網關，但要提供一個與現有的各種傳感器和執行器通信的通信網關要困難得多。標準方法是選擇一個市場并利用該市場中最常見的接口。借助現場可擴展平臺，OEM 不再需要選擇特定的市場來追求。如果需要支持額外的傳感器或執行器，

圖 1 顯示了一個開放式 IoT 網關產品，該產品只能通過 GPIO、USB 或其他在制造時固定的接口進行擴展。作為傳統的嵌入式設備，它具有定制的 Linux BSP 以充分利用硬件提供的靈活性，并且沒有顯著的發布后擴展能力。USB 提供了添加功能的途徑，但如前所述，它對實際現場部署施加了限制。

圖 1：使用在發布時固定的硬件的傳統嵌入式方法。

為第二代產品采用了新方法，創建了擴展端口，因此除了可以在機械實用的情況下使用的傳統 USB 端口之外，還有許多其他接口可以在擴展時暴露出來卡，包括 USB 本身、UART、SDIO、I2C、Wi-Fi 等。這有助于確保網關架構在平臺設計中具有合理的使用壽命，因為它能夠在新的擴展端口卡可用時接受它們。作為一種開放策略，

下一步是確定合理的方法來利用這種標準化的硬件接口，同時提供一定程度的抽象，使其他軟件開發人員無需開發低級驅動程序或從頭開始構建新的 BSP 即可創建應用程序。

對于計算密集度較低的設備，ARM 的 mbed 方法提供了很好的解決方案，該方法旨在支持其 Cortex-M 系列設備。SDK 由 ARM 在 Apache 2.0 開源許可下提供給社區，對于過去從事過 OS 和非 OS 嵌入式軟件開發的人來說，感覺非常熟悉。使用 mbed，硬件的軟件支持可以放置在一個中央存儲庫中，供任何潛在用戶檢索和構建他們的應用程序。ARM 本身通過 mbed 在處理器 I/O 級別提供一定程度的平臺獨立性，因此可以將代碼從一個受支持的 mbed 設備遷移到另一個設備，即使這些設備來自不同的微處理器供應商。然后可以使用 ARM 的工具輕松構建具有正確平臺支持的用戶創建的軟件，或與可用于商業銷售的其他第三方開發環境一起使用。ARM 用于部署 mbed 代碼的本機部署機制就像在 USB 接口上拖放一樣簡單，但如果設備傾向于遠程部署并進行現場升級，OEM 可以選擇以更適合自己需要的方式擴展部署。

由于計算密集型應用程序可能無法在 Cortex-M 處理器上很好地運行，因此可能還需要考慮另一種方法。Linux 是一個顯而易見的選擇，因為大多數高端嵌入式處理器的供應商傾向于將他們自己的開發套件的初始 BSP 發布到社區中，并且通常與初始發布時提供的開源硬件一起發布。這種方法的挑戰在于認識到任何定制都需要精通嵌入式 Linux 的軟件工程師，或者需要構建抽象層。混合模型既支持更有限的嵌入式 Linux 開發人員，也支持在他們的 Linux 開發系統上構建完整平臺的開發人員，以及操作水平高于 Java、Python、Perl 或其他語言的工程師。

圖 2 顯示了一個 MultiTech 網關，它是 2014 年底推出的系列之一，將有公開記錄的硬件擴展槽。擴展接口是多網關產品通用的，所有支持的底層驅動代碼都將開放并提供給mbed和Linux。這允許 OEM 和第三方創建新的擴展板，這些擴展板易于啟動和部署到更廣泛的應用程序中。

圖 2：具有靈活硬件擴展和免費提供的接口驅動程序支持的開放平臺。

圖 2 所示的擴展卡定義了一種個性化機制，以便平臺知道需要哪些驅動程序資源，以及是否需要從基于云的存儲庫中檢索任何其他軟件。相同的卡可在產品線內的任何平臺上工作，允許最終開發人員選擇最適合單個應用程序的處理能力級別。在這兩種情況下，一般的嵌入式軟件工程師都會對這些開發感到滿意，因為該模型遵循可擴展標準硬件接口的傳統 PC 范例，其軟件本身存在于主設備上或從中央存儲庫自動下載。關鍵優勢在于，這種方法創建的平臺易于被廣泛的軟件工程師理解，并且基于已經獲得廣泛社區支持的開源工件。這導致產品可以在初始現場部署之前和之后快速定制，并且時間大大縮短。盡管提供的示例以物聯網應用為中心，但通用方法很好地適用于需要考慮現場可配置性和支持各種已知和未知功能的任何應用。

審核編輯：郭婷