簡介UL 1998:2018《軟件在可編程組件中的安全標(biāo)準(zhǔn)》完整英文版PDF由UL美國保險商實(shí)驗室發(fā)布面向嵌入式軟件、功能安全及安規(guī)認(rèn)證領(lǐng)域開發(fā)者與測試人員用于指導(dǎo)可編程組件中軟件的安全設(shè)計、風(fēng)險評估和驗證實(shí)施。標(biāo)準(zhǔn)重點(diǎn)涵蓋范圍界定、過程定義與風(fēng)險分析、變量初始化、易失性內(nèi)存使用、用戶取消機(jī)制、唯一標(biāo)識符以及附錄A適用性等關(guān)鍵要求可幫助讀者理解UL認(rèn)證中對軟件部分的審查依據(jù)。資源為1個PDF文件壓縮包大小約859KB共42頁內(nèi)容為清晰英文原文便于檢索與標(biāo)注學(xué)習(xí)。已有1112人學(xué)習(xí)瀏覽適合正在開展UL 1998合規(guī)工作或希望建立可編程軟件安全設(shè)計思路的工程師參考。下載后可直接獲得標(biāo)準(zhǔn)正文、修訂說明及標(biāo)題頁等內(nèi)容可用于內(nèi)部培訓(xùn)、設(shè)計評審或認(rèn)證準(zhǔn)備。 那天下午我收到一個做嵌入式控制器開發(fā)的哥們兒發(fā)來的消息配著一張PDF文件的截圖標(biāo)題是“UL 19982018 Standard For Safety - Software in Programmable Components - 完整英文版42頁.pdf”。他問得很直接“UL審核開了個不符合項讓我們按UL 1998補(bǔ)軟件安全評估材料這標(biāo)準(zhǔn)到底講什么42頁我全英文啃起來太費(fèi)勁了有沒有什么精簡閱讀路線”這不是我第一次遇到這種情況。很多人第一次接觸UL 1998都不是因為想研究而是被認(rèn)證項目追著跑。UL 1998全稱是《Standard for Safety - Software in Programmable Components》翻譯過來就是“可編程組件中軟件的安全標(biāo)準(zhǔn)”它要解決的核心問題很樸素當(dāng)你產(chǎn)品里的軟件出現(xiàn)故障時怎么保證不會把人弄傷、不會把設(shè)備弄壞、不會引發(fā)安全事故。它不教你怎么寫代碼而是告訴你怎么證明這套軟件在異常情況下仍然安全。這篇文章就是給那些被UL 1998“趕鴨子上架”的朋友準(zhǔn)備的。不管你是安全工程師、嵌入式開發(fā)、認(rèn)證協(xié)調(diào)員還是純粹想提高嵌入式軟件可靠性的開發(fā)者我都建議把這份標(biāo)準(zhǔn)的邏輯框架搞清楚。我會從標(biāo)準(zhǔn)定位、閱讀順序、落地思路、審核常見問題這幾個角度展開盡量用干過項目的人說話方式把這份42頁英文文檔拆成能直接用的東西。1. 為什么UL 1998只盯“軟件”這一個環(huán)節(jié)1.1 它在功能安全標(biāo)準(zhǔn)版圖里的位置很多人第一反應(yīng)是問UL 1998和IEC 61508、UL 991這些標(biāo)準(zhǔn)到底是什么關(guān)系我通常打個比方IEC 61508是功能安全的“憲法”講通用框架UL 991是專門針對固態(tài)器件安全相關(guān)控制電路的測試標(biāo)準(zhǔn)偏硬件而UL 1998就是UL體系里給“可編程組件中的軟件”單獨(dú)開的一本“實(shí)施細(xì)則”。早期做UL認(rèn)證時硬件安全還可以靠繼電器、熔斷器、分立保護(hù)電路來兜底但到了微控制器時代安全功能越來越多地跑在軟件里。軟件有個硬傷——看不見摸不著故障模式不像電阻燒毀那樣直觀。你沒法靠一顆保險絲攔住一段崩潰的代碼。UL 1998的誕生本質(zhì)上就是要把“軟件如何做到安全”這個問題從“出事了再修”變成“開發(fā)前就必須證明”。再具體一點(diǎn)UL 1998關(guān)注的是軟件本身的安全表現(xiàn)比如邏輯是否正確、能否正確處理異常輸入、發(fā)生故障時是否會進(jìn)入安全狀態(tài)。它不會替你做功能設(shè)計但會要求你有一套完整的開發(fā)、驗證和變更流程來支持你的安全聲明。放在認(rèn)證場景里如果產(chǎn)品使用了嵌入式軟件作為安全功能的一部分UL審核員大概率會以UL 1998作為評估依據(jù)。1.2 哪些產(chǎn)品會真正碰上它以我接觸過的項目看最常踩到UL 1998的產(chǎn)品有幾類家用電器控制板比如洗衣機(jī)、洗碗機(jī)、燃?xì)饪鞠涞目刂撇糠?。暖通空調(diào)設(shè)備里的控制器涉及風(fēng)機(jī)、閥門、加熱器邏輯。商業(yè)食品設(shè)備例如果汁機(jī)、咖啡機(jī)、保溫柜。工業(yè)控制器和可編程邏輯控制器外圍模塊比如安全繼電器邏輯、電機(jī)驅(qū)動器里的控制軟件。帶有通信功能的傳感器、執(zhí)行器、智能開關(guān)等物聯(lián)網(wǎng)終端。這些產(chǎn)品共同點(diǎn)是一旦軟件邏輯錯亂可能造成過熱、機(jī)械傷害、火災(zāi)、觸電等危險。UL審核員并不指望產(chǎn)品永遠(yuǎn)不壞他們希望看到的是壞得對、壞得可控。比如單片機(jī)跑飛了軟件能觸發(fā)看門狗復(fù)位輸出端進(jìn)入安全狀態(tài)而不是隨機(jī)亂動作。這套邏輯正是UL 1998的考核重點(diǎn)。2. 42頁文檔的閱讀路線跳過哪些頁會讓你少走彎路2.1 先啃定義和范圍別直接翻要求拿到一份標(biāo)準(zhǔn)我最反對的就是從中間開始看。UL 1998雖然只有42頁但結(jié)構(gòu)很緊湊。開頭部分的范圍和定義看似枯燥實(shí)際決定了你后面讀到的每一條要求適用不適用。核心先搞懂“可編程組件”到底指什么。按標(biāo)準(zhǔn)的語境它通常指包含硬件和軟件、能夠執(zhí)行一個或多個功能的組件典型就是微控制器加上嵌入式軟件。里面還會區(qū)分“安全相關(guān)軟件”和“非安全相關(guān)軟件”這是后續(xù)所有隔離要求的基石。假如你把安全邏輯和界面顯示邏輯寫成你中有我、我中有你后面審核會非常痛苦。另外要注意范圍里列出的不適用范圍。很多標(biāo)準(zhǔn)都會明確自己不管什么UL 1998同樣如此。如果你產(chǎn)品的軟件部分不屬于它的適用對象但審核員又說要按這個標(biāo)準(zhǔn)查那就不是標(biāo)準(zhǔn)的問題而是技術(shù)溝通的問題了。這時候回到范圍條款去據(jù)理力爭比悶頭補(bǔ)材料更有效。2.2 核心要求章節(jié)到底按什么邏輯展開UL 1998的主體邏輯和功能安全領(lǐng)域常用的V模型非常像從軟件安全需求開始往下走到架構(gòu)設(shè)計、詳細(xì)設(shè)計、編碼實(shí)現(xiàn)再往上走經(jīng)過單元測試、集成測試、系統(tǒng)驗證形成一個閉環(huán)。中間還穿插著配置管理、驗證活動、變更控制等橫向支撐。我建議第一次讀的時候不要逐字死磕而是先拿一張A4紙把標(biāo)準(zhǔn)里“軟件安全需求”“軟件架構(gòu)”“軟件設(shè)計”“軟件實(shí)現(xiàn)和測試”這幾個章節(jié)畫成一條流水線在旁邊標(biāo)注標(biāo)準(zhǔn)到底要求每個階段留下什么證據(jù)。讀完之后你會發(fā)現(xiàn)整份標(biāo)準(zhǔn)的核心訴求用一句話就能概括你說是安全的得拿出全過程證據(jù)鏈來。很多嵌入式團(tuán)隊的文檔只有“需求規(guī)格說明書”和“用戶手冊”中間的架構(gòu)設(shè)計、詳細(xì)設(shè)計、測試記錄一片空白。放到UL 1998的框架下這不叫開發(fā)了個產(chǎn)品這叫只蓋了一半的樓。2.3 別忽略驗證、確認(rèn)和測試方法這部分才決定工作量標(biāo)準(zhǔn)的驗證與確認(rèn)部分是審核員檢查的重點(diǎn)也是項目組工作量最大的地方。這里通常會提到評審、靜態(tài)分析、單元測試、集成測試、邊界值分析、故障注入、模擬運(yùn)行等驗證手段。我看很多人讀到這里會慌覺得每種方法都要用一遍。其實(shí)標(biāo)準(zhǔn)通常允許你根據(jù)風(fēng)險評估和使用場景來裁剪。比如一個安全功能本身很簡單只有三段邏輯你非得上全套形式化驗證那是殺雞用牛刀。反過來一個控制燃?xì)忾y門的軟件對時序要求極高你只做功能測試不做異常時序測試審核員一眼就能看出風(fēng)險盲區(qū)。實(shí)操建議是先列一個驗證活動矩陣左邊是每條軟件安全需求右邊是對應(yīng)的驗證方法、驗證級別和交付物。這樣既能控制工作量也能在審核時快速回應(yīng)“這條需求你們怎么證明”的追問。3. 把標(biāo)準(zhǔn)條款翻譯成開發(fā)任務(wù)一份可落地的軟件安全清單3.1 需求階段就要扎可追溯性很多團(tuán)隊做需求只寫“系統(tǒng)應(yīng)具有防干燒功能”這種籠統(tǒng)描述然后就直接寫代碼了。UL 1998的視角下這種需求根本沒法驗證。你需要做的是把安全需求逐層細(xì)化直到每個子需求都能對應(yīng)到具體代碼模塊和測試用例。拿防干燒舉例安全目標(biāo)可能是檢測到溫度超過閾值后必須在500毫秒內(nèi)切斷加熱器電源。圍繞這個目標(biāo)要拆出溫度采集的有效性判斷、閾值比較邏輯、輸出切斷的控制函數(shù)、異常時進(jìn)入安全狀態(tài)的策略等。每一條都要編號并和架構(gòu)設(shè)計、測試用例關(guān)聯(lián)起來。這是后面所有證據(jù)鏈的起點(diǎn)。另外需求階段還要考慮輸入異常的應(yīng)對方式。UL 1998審核很在意軟件對非法輸入、超范圍輸入的處理。最簡單的辦法就是要求每個輸入接口必須有邊界檢查并且定義好越界時是拒絕執(zhí)行還是進(jìn)入安全狀態(tài)。別讓一個飄過來的隨機(jī)錯誤值直接驅(qū)動執(zhí)行器。3.2 架構(gòu)和設(shè)計階段最容易被忽略的隔離與自診斷架構(gòu)階段的標(biāo)準(zhǔn)要求核心是“隔離”二字。安全相關(guān)功能和非安全相關(guān)功能盡量分模塊、分任務(wù)、分內(nèi)存區(qū)域。哪怕不能完全物理隔離也要在邏輯上做到安全功能不受其他功能故障干擾。比如全局變量不能任由通信任務(wù)隨意修改安全邏輯用的緩沖區(qū)不能被普通應(yīng)用代碼越界覆蓋。軟件自診斷也不能漏。很多家用電器控制器里外部有硬件看門狗內(nèi)部還有軟件定時器檢查任務(wù)調(diào)度是否正常。UL 1998對這類自診斷能力的態(tài)度是很積極的。你在設(shè)計文檔里主動記錄內(nèi)存校驗策略、堆棧溢出檢測、時鐘故障檢測、錯誤處理與恢復(fù)機(jī)制審核員看了會省心很多。我自己做評審時最喜歡問一個問題如果內(nèi)存里的關(guān)鍵變量被改成一個非法值你的軟件下一步會做什么能答出“進(jìn)入安全狀態(tài)并產(chǎn)生錯誤代碼”的團(tuán)隊通常已經(jīng)理解了UL 1998的設(shè)計精髓。3.3 編碼、測試和變更管理要形成習(xí)慣到了編碼階段UL 1998不會規(guī)定你必須用哪種語言但它會要求代碼可讀、可審、可測。工程上的做法包括采用編程規(guī)范比如嵌入式領(lǐng)域常見的MISRA C、做靜態(tài)分析、代碼走查、單元測試覆蓋關(guān)鍵分支、對邊界值做額外測試。變更管理也要提前立項。很多項目前期文檔做得漂漂亮亮后來發(fā)現(xiàn)一個bug改了十行代碼重新編譯出個新版但沒同步更新架構(gòu)文檔和測試記錄。這在審核時屬于致命傷。建議每個軟件版本都帶上一個變更記錄至少寫清楚改了什么、為什么改、影響哪些模塊、做了哪些回歸測試。這個習(xí)慣一旦養(yǎng)成后續(xù)認(rèn)證審核會輕松得多。下面給一份我常用的自查清單參考階段關(guān)鍵交付物常見缺失問題需求軟件安全需求規(guī)格、需求追溯矩陣需求粒度太粗無法測試架構(gòu)軟件架構(gòu)說明、安全隔離方案沒有畫出安全相關(guān)/非安全相關(guān)模塊邊界設(shè)計模塊詳細(xì)設(shè)計、接口定義關(guān)鍵算法和異常處理缺少描述編碼代碼規(guī)范記錄、靜態(tài)分析報告第三方庫來源和版本未記錄測試單元測試、集成測試、故障注入報告測試結(jié)果沒有和需求關(guān)聯(lián)變更變更申請、回歸測試記錄文檔和代碼版本不匹配4. 審核現(xiàn)場最常見的不符合項以及我踩過的坑4.1 安全功能和非安全功能沒有隔離這是我見過頻率最高的不符合項。一個看起來不大的項目控制界面用同幾個全局變量傳參數(shù)某天通信邏輯出故障把安全判斷用的溫度值覆蓋成了一個超大數(shù)加熱器關(guān)閉邏輯被跳過產(chǎn)品進(jìn)入到潛在危險狀態(tài)。審核員不會接受“這個概率很小”的說法。UL 1998關(guān)注的是安全功能必須有足夠的魯棒性去應(yīng)對軟件內(nèi)部故障。正確做法是要么在數(shù)據(jù)訪問層加防護(hù)機(jī)制要么在架構(gòu)上徹底分離讓非安全功能的故障邊界不會跨到安全區(qū)域。哪怕只能做到邏輯隔離也要在代碼評審里讀出風(fēng)險點(diǎn)并記錄緩解措施。4.2 第三方庫變成了“內(nèi)部控制點(diǎn)”嵌入式項目不寫第三方庫幾乎不可能至少一個啟動文件、一個通信協(xié)議棧都算。問題在于很多團(tuán)隊把第三方庫當(dāng)黑盒既不評估它的故障影響也不鎖定版本。某次審核工程師用的協(xié)議棧從舊版本換成了新版本只因為下載時點(diǎn)了最新版但沒人記錄這件事結(jié)果整個測試證據(jù)鏈?zhǔn)?。UL 1998視角下第三方軟件也是可編程組件的組成部分必須納入配置管理和安全評估。至少要知道這個庫從哪里來當(dāng)前版本是什么有沒有已知的安全缺陷它是否會訪問安全相關(guān)資源如果它崩潰了會有什么后果。把這些寫進(jìn)軟件物料清單比事后解釋“這是開源的應(yīng)該沒問題”有效得多。4.3 測試記錄和代碼版本對不上還有一個高頻坑是測試報告里沒寫被測版本。審核員拿到一份測試記錄問“測的是哪個固件版本”你們回答不上來這說明整個過程失控。我后來要求團(tuán)隊在固件構(gòu)建產(chǎn)物里嵌入版本號和構(gòu)建時間每次測試記錄都帶上這個信息并且把原始構(gòu)建產(chǎn)物歸檔到服務(wù)器上。別小看這一步它能幫你省掉無數(shù)來往提問。更嚴(yán)重的是有些團(tuán)隊反復(fù)修改代碼但測試報告只有最終版。中間幾輪改了什么影響哪些需求沒有任何記錄。UL 1998對軟件變更活動是有要求的它在意的不是“你沒有bug”而是“你對bug的處理方式是否受控”。所以每次修復(fù)后至少得有一個回歸記錄哪怕只是手工測試打勾也比沒有強(qiáng)。4.4 根因是團(tuán)隊把標(biāo)準(zhǔn)當(dāng)成了“交材料”我反思下來這些不符合項背后其實(shí)是同一個問題整個團(tuán)隊對UL 1998的態(tài)度是給審核員打工而不是把它當(dāng)作產(chǎn)品可靠性的一部分。等到被開不符合項了緊急去補(bǔ)文檔、補(bǔ)測試記錄時間花了不少效果卻很差。真正合適的做法是在項目開發(fā)流程里提前把標(biāo)準(zhǔn)的證據(jù)要求內(nèi)化進(jìn)去讓寫架構(gòu)文檔、寫測試記錄成為日常工作的一部分而不是送審前一個月突然集中產(chǎn)出。這就像健身平時不鍛煉臨時突擊一周去拍腹肌照拍出來也不像那么回事。5. 拿到PDF之后標(biāo)準(zhǔn)文檔的版本管理和團(tuán)隊落地5.1 正規(guī)渠道獲取并做好內(nèi)部受控先說一個原則標(biāo)準(zhǔn)文檔本身有版權(quán)建議從UL官網(wǎng)或正規(guī)標(biāo)準(zhǔn)服務(wù)商處采購正式授權(quán)版本。公司內(nèi)部分發(fā)時建議在文件名里統(tǒng)一標(biāo)注標(biāo)準(zhǔn)號、版本年號、文件標(biāo)題和內(nèi)部受控編號比如“UL 1998-2018_Software_in_Programmable_Components_受控A版.pdf”。然后放到共享文檔庫設(shè)成只讀由專人維護(hù)。為什么不建議直接用個人下載的路徑分發(fā)給所有人一方面涉及合規(guī)風(fēng)險另一方面是版本管理問題。標(biāo)準(zhǔn)會更新如果你內(nèi)部同時存在好幾個版本的PDF不同人引用的條款不一樣送審材料就會自相矛盾。統(tǒng)一受控后一旦有新版本發(fā)布由管理員統(tǒng)一替換并郵件通知所有相關(guān)人員這樣內(nèi)部引用才不會亂。5.2 做一次“標(biāo)準(zhǔn)導(dǎo)讀”比讓所有人硬啃更高效拿到42頁P(yáng)DF直接扔給團(tuán)隊讓大家“有空看看”大概率是沒人看。更好的做法是找半天時間拉一個多學(xué)科小會把標(biāo)準(zhǔn)和公司實(shí)際產(chǎn)品做一次映射。我當(dāng)時是拿自己項目的一條安全功能從需求、設(shè)計、編碼到測試完整過了一遍每一步都指出UL 1998對應(yīng)要求在哪一段。這樣一聽大家才明白原來這個標(biāo)準(zhǔn)不是在搞文字游戲而是希望開發(fā)者對每一行關(guān)鍵邏輯都負(fù)責(zé)。邊講邊把標(biāo)準(zhǔn)里的抽象要求轉(zhuǎn)化為內(nèi)部模板、檢查單和評審入口。5.3 融入項目管理而不是另起爐灶很多團(tuán)隊以為做UL 1998就是多了一堆額外的質(zhì)量文件其實(shí)它的很多理念和優(yōu)質(zhì)軟件開發(fā)實(shí)踐本來就一致。比如代碼評審、靜態(tài)分析、自動測試、持續(xù)集成這套東西做扎實(shí)了UL 1998的大部分證據(jù)自然就有。建議在每個項目啟動階段做一次“UL 1998適用性評估”明確產(chǎn)品是否涉及安全相關(guān)軟件涉及哪些風(fēng)險需要做到什么深度。項目結(jié)項時把審核發(fā)現(xiàn)的問題反饋到流程改進(jìn)清單里讓下一個項目少踩同樣的坑。長期下來你會發(fā)現(xiàn)自己團(tuán)隊的軟件意外地比同行穩(wěn)健得多這時候標(biāo)準(zhǔn)就不再是負(fù)擔(dān)而是你最有力的背書。最后再分享一點(diǎn)個人體會。當(dāng)初被審核員開不符合項時我們也很郁悶覺得標(biāo)準(zhǔn)太苛刻。但后來認(rèn)認(rèn)真真把UL 1998讀了一遍把每個要求對應(yīng)到實(shí)際開發(fā)動作后團(tuán)隊的代碼評審明顯更嚴(yán)格了測試記錄也更完整了。一個很有意思的變化是評審時大家不再問“這樣寫行不行”而是問“如果這條路徑的變量被改壞了后面還會不會安全停止”。如果你能讓團(tuán)隊形成這種條件反射UL 1998的作用就真正落地了。后續(xù)還可以做一件事把這份標(biāo)準(zhǔn)的條款與IEC 61508做映射對照表這樣以后遇到海外客戶要求功能安全也能快速找到雙方溝通的共同語言。本文還有配套的精品資源點(diǎn)擊獲取