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

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

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

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

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

措施1：清楚了解自己的技術(shù)負債

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·集成到自動打包系統(tǒng)中

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

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

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

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

措施3：隔離關(guān)鍵功能

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

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

·空間域：

文件

模塊

目錄

庫

·執(zhí)行域：

線程、RTOS任務(wù)、管理程序

CPU內(nèi)核、獨立CPU

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

結(jié)語

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