盡管在IoT上下文中嵌入式設備具有潛力，但目前并不需要許多設備符合安全標準。但是在物聯網開發的敏捷世界中，在已經編寫和測試了代碼之后，合規性要求可能會晚得多。那么，如何為嵌入式物聯網設備的未來做好準備？

物聯網（IoT）術語是指發布和/或使用數據的具有網絡功能的設備，組件或服務的系統。物聯網應用正成為我們生活中不可或缺的一部分：從工業機器人和手術器械到自動駕駛汽車和自動駕駛無人機。今天，這些設備中的許多設備已經可以影響其用戶的安全性，隱私權和安全性。在某些情況下，故障的代價是致命的，因此，按現行標準制造這些設備至關重要。

盡管最好從一開始就將合規性活動嵌入軟件設計中，但眾所周知的事實是，嚴格的開發流程（尤其是沒有自動化的幫助）會影響產品上市時間。沒有多少開發人員喜歡在正常工作時間之外進行額外的測試和記錄可追溯性，因此，務實，敏捷和快節奏的團隊通常不能以在計劃中“可能需要”為前提建立合規性來失去動力。未來。取而代之的是，許多團隊選擇“在到達那座橋時越過那座橋”。

不幸的是，沒有魔術棒或銀彈可以追溯“使”代碼兼容。這些組織正在努力學習的是，在項目結束時增加合規性的成本要比開發初始工作產品的成本高幾個數量級。

那么，為了滿足明天的嚴格合規性要求，您今天可以采取哪些低影響的措施？

措施1：了解技術債務

了解您的項目目前的位置非常重要。技術債務的金額是由于代碼復雜性以及代碼中當前存在的任何剩余編碼標準和安全性違規導致的潛在返工成本。該債務歸因于隨后的代碼清理，修復和測試。掌握當前項目狀況的一種方法是使用自動靜態代碼分析。靜態分析可深入了解代碼庫的質量和安全性，并列舉適用的編碼標準違規情況。

不幸的是，許多使用C和C++開發嵌入式應用程序的團隊仍然依靠他們的編譯器或手動代碼審查來發現問題，而不是采用靜態分析。一些團隊出于各種原因而努力采用靜態分析工具，例如發現它們嘈雜且難以使用（如果您學習了正確的入門方法，就不會有問題），或者無法將其用于日常開發過程中由于緊急的日常事務。常見的（誤）理解是，確定哪些違規值得解決所花費的時間大于實際修復的價值。

但是我們發現，在項目后期面對功能安全審核時，采用少量關鍵性和強制性規則的團隊花費更少的時間來重新編寫代碼。通過實施（例如）CERT C安全編碼準則，從根本上構建安全可靠的系統要容易得多。您可以從小處著手。 CERT擁有完善的優先級劃分系統（使用嚴重性、可能性和補救成本，每三個級別，總共27個級別），并且，如果您使用Parasoft工具，則可以在預配置的儀表板中輕松查看合規性狀態。

靜態分析還可以通過收集數據點來幫助組織了解其技術欠債，這些數據點可以幫助管理層實現安全合規。管理人員可以輕松評估重要問題，例如：

• 我的基準是多少？我的代碼庫中存在多少個非關鍵編碼標準沖突？
• 趨勢數據：每個版本都報告新的和固定的違規？我們是好還是壞？
• 我今天的代碼復雜度是多少？它在增長嗎？

一些標準要求測量圈復雜度，以使其保持在一定閾值以下。復雜性指標也可以用于估計測試工作——例如，您需要證明100％分支級別覆蓋以符合IEC 61508 SIL 2的測試用例數量，將與該函數的McCabe環復雜性成比例。

下面是一個儀表板示例，顯示了Parasoft DTP（Parasoft的報告和分析中心）中項目對MISRA的遵守情況：

這與CERT C相同：

查看代碼指標的價值可能有助于揭露更復雜的區域，以便進行其他代碼審查，并監視測試對這些區域的覆蓋程度。這是度量指標儀表板的示例：

因此，您可以從基礎開始。一旦團隊對管理最關鍵的錯誤感到滿意，就可以增加違反標準的范圍。并非所有規則都是一成不變的，因此，重要的是要確定哪些規則在項目編碼標準之內或之外。至少，在幾個關鍵編碼標準中采用強制性規則集（例如MISRA強制性或CERT C規則）可以使連接設備將來的安全性和安全性論證更加容易。

措施2：建立合格的單元測試框架并衡量代碼覆蓋率

大多數務實的工程師傾向于同意盲目地為所有功能創建單元測試并不能提供良好的投資回報率。但是，如果您的團隊可以將單元測試框架作為項目沙箱的一部分進行訪問，則這是一筆寶貴的投資。當工程師認為需要單獨測試某些復雜算法或數據操作時，可以智能地使用單元測試。在開發單元測試的過程中，還有一個重要的價值——我們從組織中看到的是，簡單地編寫和執行單元測試的做法會使代碼更健壯和設計更好。

當出現安全性或安全性合規性要求時，組織可以通過臨時增加人員來迅速提高單元測試的工作量。但是，為了迅速擴大工作量，在整個項目過程中應該已經理解并記錄了單元測試框架和過程。考慮到未來合規性的可伸縮單元測試框架的共同特征是：

• 符合給定安全標準的預期用途（例如通過TüV證書）
• 集成到自動化構建系統中
• 報告所需的代碼覆蓋率指標（例如MC/DC）
• 記錄每次構建并隨時間推移執行的測試的結果和覆蓋范圍
• 可用于多個項目和團隊

關鍵要點是部署未來安全標準要求的所有測試技術，但要以最小的規模進行。當出現認證需求時，這比從頭開始更容易擴展。

措施3：隔離關鍵功能

設計嵌入式系統需要考慮很多“缺點”：簡單性、可移植性、可維護性、可伸縮性和可靠性，同時還要解決延遲、吞吐量、功耗和大小限制之間的折衷。在設計可能會連接到大型IoT生態系統的系統時，許多團隊并未將安全性和安全性放在其他一些質量因素之上。

為了使將來的安全合規性變得更容易（并遵循良好的架構實踐），您可以在時間和空間上分離組件。例如，您可以設計一個系統，其中所有關鍵操作都在單獨的專用CPU上執行，而所有非關鍵操作都在另一個CPU上運行，從而實現物理隔離。另一個選擇是采用“分離內核管理程序”和“微內核”概念。還有其他選擇，但是關鍵是采用關鍵架構方法，將關注點分離、縱深防御和盡早混合關鍵性分離。這些方法不僅減少了遵守安全標準的工作量，而且還提高了應用程序的質量和彈性。例如，以下是一些隔離關鍵代碼的方法：

• 空間域：
• 檔案
• 模組
• 目錄
• 圖書館
• 執行域：
• 線程，RTOS任務，管理程序
• CPU核心，獨立的CPU

將關鍵功能與非關鍵功能分開可以減少將來為證明合規性而進行的驗證工作的范圍。

總結

物聯網生態系統中的許多邊緣設備提供的關鍵服務可能屬于未來的安全標準。 當然，在不知道是否需要標準的情況下嘗試遵守標準并不是一種經濟有效的策略。為了為未來做準備，組織可以采用關鍵設計技術，單元測試方法和靜態分析工具，并收集度量標準來支持未來的需求。如果足夠早地開始，軟件團隊可以將這些方法無縫地應用到其現有流程中。從正確的方法開始，盡早進行擴展，然后再進行擴展，以防止在開發、測試和部署軟件代碼時合力地付出努力。