盡管嵌入式設備在物聯網中的作用可能十分重要，但目前并未強制要求這些設備都符合安全標準。由于物聯網發(fā)展很快，合規(guī)要求可能滯后很多，有時候甚至在代碼寫好并測試之后才出現。那么，如何為嵌入式物聯網設備的未來做好準備？

物聯網（IoT）是由網絡設備、組件或服務組成的系統，能產生和/或使用數據。物聯網應用逐漸成為人們生活中不可或缺的部分：從工業(yè)機器人和手術器械，到自動駕駛汽車和自主飛行的無人機。今天，很多這些設備已經對用戶的安全、隱私和安防產生影響，有一些甚至是致命的。因此，為物聯網設備制定通用標準至關重要。

如果軟件設計一開始就能符合規(guī)范當然是最好的，但眾所周知，嚴格的開發(fā)流程，特別是在沒有實現自動化的情況下，會影響產品上市時間。沒有幾個開發(fā)人員愿意加班完成額外的測試工作并記錄可追溯性，如果費時費力地建立合規(guī)性只是出于將來“可能需要”，務實、敏捷和快速的開發(fā)團隊是不會為此而損失元氣的。相反，許多團隊相信“船到橋頭自然直”。

然而，沒有什么魔法可以讓時光倒流“使”代碼從開始就符合規(guī)范。這些團隊最后得到的教訓是，等項目結束時再考慮合規(guī)性所需的成本，比開發(fā)伊始就考慮的成本要高出幾個數量級。

所以，為了滿足未來嚴格的規(guī)范要求，現在可以采取哪些有效措施呢？

措施1：清楚了解自己的技術負債

了解項目當前的狀況非常重要。由于代碼太復雜，加上代碼中存在任何原本的編碼標準及安全違規(guī)時，需要重寫代碼花費的成本即技術負債量。技術負債來自隨后要完成的代碼清理、修復和測試。靜態(tài)代碼自動分析是掌握項目當前狀況的一種方法，它可以對代碼庫質量和安全性進行深入分析，并列出編碼標準的違規(guī)（如果有的話）。

然而，許多用C和C++語言開發(fā)嵌入式應用程序的團隊并沒有采用靜態(tài)分析法，而是依賴編譯器或通過手動檢查代碼來找出問題。一些團隊因為各種原因，如發(fā)現靜態(tài)分析工具噪聲太多且很難使用，或者由于緊急的日常事務而不能將其納入日常開發(fā)流程，而難以決定是否使用靜態(tài)分析工具。一種常見的誤解是，確定哪些違規(guī)值得修復所需的時間，遠超過實際修復的價值。

但我們發(fā)現，如果一個團隊在項目的前期就強制性地采用了少許重要的規(guī)則，那么當項目后期面臨功能安全審查時，重寫代碼花費的時間要少得多。如果從一開始就將安全性植入其中，例如實施CERT C安全編碼規(guī)則，則更容易建成一個安全可靠的系統。我們可以從簡單的規(guī)則開始。CERT擁有先進的優(yōu)先級系統（包含嚴重性、可能性和補救成本三個指標，每個指標分為3個等級，總共27個級別），如果使用自動化測試工具，通常很容易在預先設置好的控制面板（dashboard）中查看合規(guī)狀態(tài)。

靜態(tài)分析通過采集數據點，幫助管理安全與安防合規(guī)性，使公司能夠了解其技術負債。管理者可以輕松評估一些重要的問題，比如：

·底線是什么？代碼庫中不嚴重的編碼違規(guī)有多少？

·趨勢數據：是否每個新版本都報告了新的和已修復的違規(guī)？情況變好了還是變差了？

·目前的代碼復雜度是什么？復雜度在增加嗎？

有些標準要求衡量環(huán)路復雜度（cyclomatic complexity），并使其低于某個閾值。復雜度指標也可用于估計測試工作量——例如，對某個函數進行IEC 61508 SIL 2合規(guī)測試，若要達到100％的分支級覆蓋率，則所需的測試用例數與該函數的McCabe環(huán)路復雜度成比例。

圖1的例子來自一個控制面板，顯示了某項目的MISRA合規(guī)性。

圖1：項目的MISRA合規(guī)性。

圖2顯示的是CERT合規(guī)性。

圖2：項目的CERT合規(guī)性。

查看代碼指標有助于暴露更復雜的地方，從而進一步檢查代碼，同時監(jiān)控測試是否對這些地方實現了良好覆蓋。圖3是指標控制面板示例。

圖3：指標控制面板示例。

首先從基本的開始。一旦開發(fā)團隊能夠輕松自如地管理最嚴重的錯誤，就可以增大管理標準違規(guī)的范圍。并非所有規(guī)則都是“一成不變”的，因此決定將哪些規(guī)則納入項目編碼標準非常重要。在一些關鍵編碼標準中至少采用一組強制性的規(guī)則（例如MISRA強制性規(guī)范或環(huán)路復雜度C規(guī)則），將使聯網設備未來的安全與安防論證變得更容易。

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

大多數務實的工程師都會認同，盲目地為所有功能設置單元測試并不能獲得良好的投資回報率（ROI）。但是，如果開發(fā)團隊可以訪問的單元測試框架是沙盒（sandbox）項目的一部分，那么這就是一項有價值的投資。當需要單獨測試某些復雜的算法或數據操作時，可以根據實際情況來選擇進行單元測試。完成單元測試這個過程本身也很有價值——從公司的角度來看，僅僅是編寫和執(zhí)行單元測試就可以使代碼更加強健，并且代碼設計得更好。

當安全與安防合規(guī)要求增加時，公司只需臨時增加測試人員，就可加快單元測試工作。但要快速擴展測試工作，就需要在整個項目進程中了解單元測試框架和流程，并形成文檔。一個考慮了未來合規(guī)性的可擴展單元測試框架應具有以下特征：

·適合指定安全標準的應用（例如通過TüV認證）

·集成到自動打包系統中

·報告所需的代碼覆蓋率指標（例如MC/DC）

·按時間記錄每個版本完成的測試結果和覆蓋范圍

·適用于多個項目和開發(fā)團隊

最重要的是，要以最小的規(guī)模來部署未來安全標準需要的所有測試技術。這樣的話，如果需要認證就更容易擴展，而不用從頭開始。

措施3：隔離關鍵功能

構建嵌入式系統需要考慮大量的“非功能性需求”，如簡單性、可移植性、可維護性、可擴展性和可靠性，同時還要綜合考慮延遲、吞吐量、功耗和尺寸限制等因素。在設計可能與大型物聯網生態(tài)相連的系統架構時，許多團隊優(yōu)先考慮的是一些與質量相關的因素，而不是安全與安防。

如果將組件在時間和空間上分離出來，未來它們便更容易符合安全規(guī)范（并具有良好的架構）。例如，在設計系統時，可以將所有的關鍵操作都放在單獨的專用CPU上執(zhí)行，所有的非關鍵操作放在另一個CPU上執(zhí)行，從而實現物理隔離。另一種方法是采用分離內核管理程序（Separation Kernel Hypervisor）和微內核（Microkernel）概念。當然還有其它方法，但重點是要盡早采用關鍵架構方法，如關注點分離、深度防御和混合關鍵性分離。這些方法不僅減少了遵守安全與安防標準所需的工作量，還提高了應用程序的質量與復原性。例如，以下是隔離關鍵代碼的一些方法：

·空間域：

文件

模塊

目錄

庫

·執(zhí)行域：

線程、RTOS任務、管理程序

CPU內核、獨立CPU

將關鍵功能與非關鍵功能分離，未來檢查合規(guī)性時，驗證范圍就可以縮小。

結語

物聯網生態(tài)中的許多邊緣設備提供關鍵性服務，它們可能需要符合未來的安全與安防標準。努力滿足標準要求卻不管是否真正需要，顯然并不是一種合算的方法。但我們還是應該為未來做好準備，比如采用關鍵設計技術、單元測試方法和靜態(tài)分析工具，同時收集各項指標數據來支持未來的需求。如果盡早啟動，軟件開發(fā)團隊就可以將這些方法無縫應用到現有流程中。同時也應盡早采用具有可擴展性的正確方法，避免在開發(fā)、測試和部署軟件時花費更大的力氣使代碼合規(guī)。