ICS65.060.01;35.240.99GB/T38874.3—2020/ISO25119-3:2018農(nóng)林拖拉機(jī)和機(jī)械控制系統(tǒng)安全相關(guān)部件第3部分：軟硬件系列開發(fā)(ISO25119-3:2018,IDT)國(guó)家市場(chǎng)監(jiān)督管理總局國(guó)家標(biāo)準(zhǔn)化管理委員會(huì)GB/T38874.3—2020/ISO25119-3:2018關(guān)北京市朝陽區(qū)和平里西街甲2號(hào)(100029)北京市西城區(qū)三里河北街16號(hào)(100045)服務(wù)熱線：400-168-00102020年6月第一版關(guān)書號(hào)：155066·1-64927GB/T38874.3—2020/ISO25119-3:2018GB/T38874《農(nóng)林拖拉機(jī)和機(jī)械控制系統(tǒng)安全相關(guān)部件》分為以下4個(gè)部分：——第1部分：設(shè)計(jì)與開發(fā)通則；——第2部分：概念階段；-—第3部分：軟硬件系列開發(fā)；本部分為GB/T38874的第3部分。本部分按照GB/T1.1—2009給出的規(guī)則起草。本部分使用翻譯法等同采用ISO25119-3:2018《農(nóng)林拖拉機(jī)和機(jī)械控制系統(tǒng)安全相關(guān)部件第本部分由中國(guó)機(jī)械工業(yè)聯(lián)合會(huì)提出。本部分由全國(guó)農(nóng)業(yè)機(jī)械標(biāo)準(zhǔn)化技術(shù)委員會(huì)(SAC/TC201)歸口。I1GB/T38874.3—2020/ISO25119-3:2018農(nóng)林拖拉機(jī)和機(jī)械控制系統(tǒng)安全相關(guān)部件GB/T38874的本部分規(guī)定了控制系統(tǒng)安全相關(guān)部件(SRP/CS)軟硬件設(shè)計(jì)與開發(fā)通則。本部分路清掃機(jī))。 本部分規(guī)定了SRP/CS執(zhí)行安全相關(guān)功能所要求的特性及類別，本部分未規(guī)定用于特定場(chǎng)合的性能等級(jí)。注1:機(jī)械特定C類標(biāo)準(zhǔn)可為其范圍內(nèi)的機(jī)械安全相關(guān)功能指定農(nóng)業(yè)性能等級(jí)(AgPL)。否則，AgPL的規(guī)范由制本部分適用于與機(jī)電系統(tǒng)有關(guān)的電氣/電子/可編程電子系統(tǒng)(E/E/PES)的安全部件。本部分涵蓋了E/E/PES安全相關(guān)系統(tǒng)(包括這些系統(tǒng)間的交互)的故障行為可能造成的危險(xiǎn)。本部分不涉及觸安全系統(tǒng)故障引起。本部分還涵蓋了在非E/E/PES危險(xiǎn)下E/E/PES安全相關(guān)系統(tǒng)的故障行為，涉及本部分包含以下范圍內(nèi)的示例：——SRP/CS的電磁干擾；——SRP/CS的防火設(shè)計(jì)?！Σ翆?dǎo)致電擊危險(xiǎn)產(chǎn)生的絕緣失效；——腐蝕導(dǎo)致的電纜過熱。注2:參見ISO12100中機(jī)械安全的設(shè)計(jì)通則。本部分不適用于實(shí)施日期之前制造的控制系統(tǒng)安全相關(guān)部件。2規(guī)范性引用文件下列文件對(duì)于本文件的應(yīng)用是必不可少的。凡是注日期的引用文件，僅注日期的版本適用于本文GB/T38874.1—2020農(nóng)林拖拉機(jī)和機(jī)械控制系統(tǒng)安全相關(guān)部件第1部分：設(shè)計(jì)與開發(fā)通則(ISO25119-1:2018,IDT)GB/T38874.2—2020農(nóng)林拖拉機(jī)和機(jī)械控制系統(tǒng)安全相關(guān)部件第2部分：概念階段2GB/T38874.3—2020/ISO25119-3:2018(ISO25119-2:2018,IDT)GB/T38874.4—2020農(nóng)林拖拉機(jī)和機(jī)械控制系統(tǒng)安全相關(guān)部件第4部分：生產(chǎn)、運(yùn)行、修改與支持規(guī)程(ISO25119-4:2018,IDT)GB/T38874.1界定的術(shù)語和定義適用于本文件。ISO和IEC標(biāo)準(zhǔn)術(shù)語數(shù)據(jù)庫的地址為：4縮略語下列縮略語適用于本文件。AgPL:農(nóng)業(yè)性能等級(jí)(agriculturalperformancelevel)AgPL,:農(nóng)業(yè)性能等級(jí)要求(requiredagriculturalperformancelevel)CAD:計(jì)算機(jī)輔助設(shè)計(jì)(computer-aideddesign)Cat:硬件類別(hardwarecategory)CCF:共因失效(common-causefailure)DC:診斷覆蓋率(diagnosticcoverage)ECU:電子控制單元(electroniccontrolunit)ETA:事件樹分析(eventtreeanalysis)E/E/PES:電氣/電子/可編程電子系統(tǒng)(electrical/electronic/programmableelectronicsystems)EMC:電磁兼容(electromagneticcompatibility)FMEA:失效模式及影響分析(failuremodeandeffectsanalysis)FSM:功能安全管理(functionalsafetymanagement)FTA:故障樹分析(faulttreeanalysis)HARA:危險(xiǎn)分析及風(fēng)險(xiǎn)評(píng)估(hazardanalysisandriskassessment)HIL:硬件在環(huán)(hardwareintheloop)MTTF:平均失效前時(shí)間(meantimetofailure)MTTFp:平均危險(xiǎn)失效前時(shí)間(meantimetodangerousfailure)MTTFpc:單通道平均危險(xiǎn)失效前時(shí)間(meantimetodangerousfailureforeachchannel)PES:可編程電子系統(tǒng)(programmableelectronicsystem)QM:質(zhì)量度量(qualitymeasures)RAM:隨機(jī)存取存儲(chǔ)器(random-accessmemory)SOP:開始生產(chǎn)(startofproduction)SRL:軟件需求等級(jí)(softwarerequirementlevel)SRP:安全相關(guān)部件(safety-relatedparts)SRP/CS:控制系統(tǒng)安全相關(guān)部件(safety-relatedpartsofcontrolsystems)UML:統(tǒng)一建模語言(unifiedmodelinglanguage)3定義系統(tǒng)的詳細(xì)設(shè)計(jì)，以滿足整個(gè)安全相關(guān)系統(tǒng)的安全需求。5.2概述安全需求包括實(shí)現(xiàn)和確保功能安全的所有需求。在安全壽命周期內(nèi)，在各層次級(jí)別上對(duì)安全需求進(jìn)行詳細(xì)的闡述和規(guī)定。圖1列出了安全需求的不同層次。安全需求開發(fā)過程的完整表述見5.4。為了對(duì)安全需求進(jìn)行管理，建議使用恰當(dāng)?shù)男枨蠊芾砉ぞ?。附錄A給出了AgPL=e時(shí)的功能安全評(píng)估示例。2/6°2/6°風(fēng)險(xiǎn)分析規(guī)范(功能安全概念)系統(tǒng)設(shè)計(jì)(技術(shù)安全概念)軟件安全需求(設(shè)計(jì)與實(shí)現(xiàn))硬件安全需求(設(shè)計(jì)與實(shí)現(xiàn))安全確認(rèn)4/64/6用斜線隔開的2個(gè)數(shù)字中第1個(gè)數(shù)字代表GB/T38874的相應(yīng)部分，第2個(gè)數(shù)字代表章條號(hào)。例如，2/6指GB/T38874.2—2020的第6章，3/5指GB/T38874.3—2020的第5章等。5.3前提條件前提條件是功能安全概念(見GB/T38874.2—2020的第7章)。4GB/T38874.3—2020/ISO25119-3:2018全概念規(guī)范以技術(shù)安全需求的形式規(guī)定了功能安全需求在系統(tǒng)架構(gòu)中的基本配置。系統(tǒng)架構(gòu)由軟件和硬件安全需求完善并固化了技術(shù)安全需求。第6章詳細(xì)描述了硬件需求。軟件安全需求從技術(shù)安全概念需求和底層硬件需求中導(dǎo)出。第7章定義了軟件需求。本條規(guī)定了系統(tǒng)設(shè)計(jì)過程中技術(shù)安全概念需求規(guī)范中所采用的方法，奠定了無差錯(cuò)系統(tǒng)設(shè)計(jì)的基礎(chǔ)。技術(shù)安全概念文檔包括系統(tǒng)技術(shù)安全需求?！渌夹g(shù)安全需求；——功能安全需求。技術(shù)安全概念應(yīng)考慮以下因素：a)所有安全目標(biāo)和功能安全需求；c)安全分析工具(FMEA、FTA等)的分析結(jié)果。系統(tǒng)開發(fā)過程中，安全分析為技術(shù)安全概念提a)應(yīng)指定技術(shù)安全概念的版本及有關(guān)基礎(chǔ)來源的版本。b)應(yīng)符合變更管理的要求(見GB/T38874.4—2020的第11章)。因此，技術(shù)安全需求應(yīng)結(jié)構(gòu)化c)應(yīng)對(duì)技術(shù)安全需求(見GB/T38874.4—2020的第6章)進(jìn)行復(fù)查。技術(shù)安全概念應(yīng)包括滿足SRP/CS設(shè)計(jì)要求的軟硬件安全需求，并應(yīng)符合規(guī)定?！獑?dòng)；——正常運(yùn)行；——復(fù)位后重啟；5GB/T38874.3—2020/ISO25119-3:2018規(guī)定關(guān)閉SRP/CS是否立即進(jìn)入安全狀態(tài)，或者僅通過可控停機(jī)操作才能進(jìn)入安全狀態(tài)。技術(shù)安全概念應(yīng)規(guī)定每個(gè)功能安全需求從出現(xiàn)錯(cuò)誤至進(jìn)入安全狀態(tài)的最大持續(xù)時(shí)間(響應(yīng)時(shí)間)。技術(shù)安全概念中應(yīng)規(guī)定每個(gè)子系統(tǒng)和子功能的響應(yīng)時(shí)間。應(yīng)對(duì)安全架構(gòu)及其子組件進(jìn)行描述。應(yīng)特別規(guī)定所采取的技術(shù)性措施。技術(shù)安全概念應(yīng)描述以下組件(如適用):——混合數(shù)字和模擬輸入輸出單元；-—各種機(jī)電組件；——組件間的信號(hào)傳輸；——系統(tǒng)外部與SRP/CS間的信號(hào)傳輸；——電源。應(yīng)規(guī)定SRP/CS組件間的接口、機(jī)器中與其他系統(tǒng)和功能間的接口以應(yīng)規(guī)定SRP/CS的限定條件及邊界條件，這特別適合壽命周期各階段所有環(huán)境條件的極值。5.5工作產(chǎn)品a)技術(shù)安全概念規(guī)范。定義適用的SRP/CS的硬件架構(gòu)。6.2概述通過對(duì)SRP/CS硬件結(jié)構(gòu)的改進(jìn)，可提供避免故障、檢測(cè)故障或容錯(cuò)的方法。實(shí)際方法包括冗余、通常應(yīng)采用以下故障判據(jù)：——由一個(gè)共同原因而導(dǎo)致的兩個(gè)或多個(gè)單獨(dú)故障，視為單一故障(即共因失效);6GB/T38874.3—2020/ISO25119-3:20186.3前提條件由硬件實(shí)現(xiàn)的部分功能安全概念(見GB/T38874.2—2020的第7章)。硬件開發(fā)過程應(yīng)從系統(tǒng)級(jí)開始，其安全功能及相關(guān)需求已標(biāo)識(shí)(見圖2)。應(yīng)使用功能安全概念標(biāo)識(shí)每個(gè)系統(tǒng)安全功能的性能等級(jí)(AgPL)(見GB/T38874.2)。配的所有功能安全需求的AgPL。應(yīng)對(duì)開發(fā)周期的每個(gè)階段進(jìn)行驗(yàn)證。圖1所示的系統(tǒng)硬件/軟件集成測(cè)試應(yīng)使用已經(jīng)測(cè)試的軟硬件組件。a)選擇硬件類別，應(yīng)考慮可用的MTTFpc、SRL和DC(見GB/T38874.2—2020的圖2);b)確定組件的工作環(huán)境和應(yīng)力等級(jí)；c)選擇組件；d)計(jì)算和驗(yàn)證MTTFpc是否達(dá)到要求的等級(jí)(見GB/T38874.2—2020的7.3.3);e)確定和驗(yàn)證DC是否達(dá)到要求的等級(jí)(見GB/T38874.2—2020的7.3.4);f)考慮CCF(見GB/T38874.2—2020的附錄D);g)考慮系統(tǒng)性失效(見GB/T38874.2—2020的附錄E);h)考慮其他安全相關(guān)功能(見GB/T38874.2—2020的附錄F)。以上步驟可迭代進(jìn)行。7GB/T38874.3—2020/ISO25119-3:2018來自圖1:來自圖1:V模式系統(tǒng)設(shè)計(jì)硬件硬件系統(tǒng)架構(gòu)與設(shè)計(jì)硬件子系統(tǒng)設(shè)計(jì)至圖1:集成測(cè)試硬件/軟件硬件安全確認(rèn)硬件系統(tǒng)集成硬件子系統(tǒng)測(cè)試硬件子系統(tǒng)測(cè)試概念硬件系統(tǒng)集成概念硬件確認(rèn)概念 斜線隔開的2個(gè)數(shù)字第1個(gè)數(shù)字代表本部分，第2個(gè)數(shù)字代表第6章。圖2V模式硬件開發(fā)6.5硬件類別控制系統(tǒng)安全相關(guān)部件的設(shè)計(jì)應(yīng)符合GB/T38874.2—2020中5個(gè)類別中的一種或多種要求，并將GB/T38874.2—2020中的附錄A、附錄H、附錄I和附錄J考慮在內(nèi)。當(dāng)安全相關(guān)功能由多個(gè)硬件類別集成組合實(shí)現(xiàn)時(shí)，最終總體硬件類別由整個(gè)系統(tǒng)特性確定(見圖3)。8GB/T38874.3—2020/ISO25119-3:2018CatCatB/1mCat2(整個(gè)系統(tǒng))CatB/1OTESL0II—輸入裝置(例如：傳感器);L——邏輯模塊；TE——測(cè)試設(shè)備(附加到邏輯模塊上);OTE——測(cè)試設(shè)備的輸出；S?——互連信號(hào)輸出；Cat--—硬件類別。圖3硬件類別集成系統(tǒng)示例6.6工作產(chǎn)品硬件設(shè)計(jì)的工作產(chǎn)品為：a)硬件安全確認(rèn)測(cè)試計(jì)劃；b)硬件安全確認(rèn)測(cè)試規(guī)范；c)硬件安全確認(rèn)測(cè)試結(jié)果；d)硬件系統(tǒng)集成測(cè)試計(jì)劃/硬件子系統(tǒng)測(cè)試計(jì)劃；e)硬件系統(tǒng)集成測(cè)試規(guī)范；f)硬件系統(tǒng)集成測(cè)試結(jié)果/硬件子系統(tǒng)測(cè)試結(jié)果；g)滿足要求的類別與AgPL的硬件架構(gòu)設(shè)計(jì)；h)硬件安全需求。7軟件7.1軟件開發(fā)計(jì)劃確定并計(jì)劃軟件開發(fā)的各階段，包括本章描述的軟件開發(fā)過程以及GB/T38874.4—2020的第11章9GB/T38874.3—2020/ISO25119-3:2018中必要的支持過程。圖4說明了軟件開發(fā)過程。在以下各條和表格中解釋了圖中方框內(nèi)容。應(yīng)根據(jù)要求的SRL選擇適當(dāng)?shù)募夹g(shù)或方法。影響軟件安全完整性的因素很多，不存在對(duì)任意系統(tǒng)均適用的(各種技術(shù)和方法的)組合通用算法。對(duì)于特定系統(tǒng)，在安全計(jì)劃制定時(shí)應(yīng)提出合適的安全性——要求的SRL,由功能安全概念階段的AgPL、MTTFpc、DC及類別確定； ——功能安全需求和安全目標(biāo)。對(duì)于軟件開發(fā)過程，應(yīng)確定如何完成軟件開發(fā)的各階段(見圖4),還應(yīng)考慮項(xiàng)目的范圍和復(fù)雜性。可完全參照?qǐng)D4進(jìn)行各階段的軟件開發(fā)，或者如果生成的所有工作產(chǎn)品涵蓋了多個(gè)階段，則可將這些階段合并。注：如果使用的方法不能清晰地區(qū)分各階段，通常將這些階段合并。例如：基于模型的開發(fā)過程、軟件架構(gòu)設(shè)計(jì)和軟件實(shí)現(xiàn)可由同一計(jì)算機(jī)輔助開發(fā)工具自動(dòng)生成?？赏ㄟ^分配活動(dòng)和任務(wù)來添加其他階段。示例：在電子控制單元的安全確認(rèn)之前，可增加數(shù)據(jù)集成作為單獨(dú)的階段。根據(jù)其功能分布，ECU的安全確認(rèn)可采用不同方式，作為特定的ECU測(cè)試或組合來控制網(wǎng)絡(luò)測(cè)試，可在組件系統(tǒng)的測(cè)試位置或在試驗(yàn)車輛上進(jìn)行測(cè)試。GB/T38874.3—2020/ISO25119-3:2018來自圖1:V模式系統(tǒng)計(jì)劃至圖1:來自圖1:V模式系統(tǒng)計(jì)劃集成測(cè)試軟件/硬件軟件安全需求和分析軟件安全需求和分析軟件安全軟件安全測(cè)試概念軟件系統(tǒng)軟件組件測(cè)試概念軟件架構(gòu)和設(shè)計(jì)軟件架構(gòu)和設(shè)計(jì)軟件軟件 斜線隔開的2個(gè)數(shù)字中第1個(gè)數(shù)字代表本部分，第2個(gè)數(shù)字代表第7章。圖4V模型軟件開發(fā)活動(dòng)和任務(wù)可從一個(gè)階段轉(zhuǎn)移到另一階段。參照表1完成軟件安全需求規(guī)格說明后，應(yīng)將軟件安全需求分配到相應(yīng)的過程活動(dòng)中。a)工作產(chǎn)品應(yīng)按照GB/T38874.4—2020的第13章進(jìn)行歸檔；b)應(yīng)按照GB/T38874.4—2020的第11章進(jìn)行軟件變更管理；c)工作產(chǎn)品的配置管理。GB/T38874.3—2020/ISO25119-3:2018在軟件開發(fā)的每個(gè)階段，應(yīng)根據(jù)SRL(例如：圈復(fù)雜度、測(cè)試覆蓋率和缺陷率)選擇適當(dāng)?shù)拈_發(fā)方表1～表6列出了每個(gè)技術(shù)或方法與4種SRL——十方法適用。如不適用，在計(jì)劃階段應(yīng)記錄這些理由?！猳不推薦或不建議使用?！獂不適用。選擇的方法應(yīng)與各個(gè)SRL相對(duì)應(yīng)。替代或等效的技術(shù)或方法用數(shù)字后的字母來標(biāo)識(shí)。但應(yīng)至少也可使用表中未列出的特定技術(shù)或方法。如果替換表中的技術(shù)或方法，則該技術(shù)或方法應(yīng)具有相等或更高的SRL值。本階段的工作產(chǎn)品為7.1.1～的軟件項(xiàng)目計(jì)劃(見GB/T38874.4—2020的第6章)。第一個(gè)目的是從技術(shù)安全需求中導(dǎo)出包括SRL在內(nèi)的軟件安全需求。第二個(gè)目的是驗(yàn)證軟件安全需求是否與技術(shù)安全概念相一致。軟件安全需求規(guī)格說明應(yīng)從系統(tǒng)技術(shù)安全概念需求中導(dǎo)出，并標(biāo)識(shí)為軟件安全需求。至少應(yīng)考慮a)在軟件中充分實(shí)現(xiàn)技術(shù)安全概念；b)系統(tǒng)配置和架構(gòu)；c)E/E/PES系統(tǒng)硬件設(shè)計(jì)；d)安全相關(guān)功能的響應(yīng)時(shí)間；f)影響軟件性能的物理要求和環(huán)境條件；g)安全軟件的修改需求。系統(tǒng)軟硬件開發(fā)應(yīng)迭代進(jìn)行。在進(jìn)一步指定和細(xì)化軟件安全需求和軟件架構(gòu)的過程中，對(duì)硬件架軟件安全需求規(guī)格說明的前提條件為：GB/T38874.3—2020/ISO25119-3:2018——符合5.4.2的技術(shù)安全概念；-—符合6.5的硬件類別。軟件安全需求規(guī)格說明應(yīng)與表1相一致。章條號(hào)SRL=BSRL=1SRL=2SRL=.1十十十十.2十十XX.3十十十十.4十十十十.500十十十十十十十十XX應(yīng)采用自然語言(即口語和書面語)描述需求規(guī)格說明。軟件安全需求規(guī)格說明應(yīng)包括用自然語言對(duì)問題進(jìn)行描述。(如必要)也可用非形式化方法(例如：GB/T38874.3—2020/ISO25119-3:2018方面進(jìn)行描述。足需求的可信度。描述結(jié)果進(jìn)行分析，其嚴(yán)格程度類似于編譯器對(duì)源程序的語法檢查；或模型演示系統(tǒng)行為的各個(gè)方面。形式化方法通常應(yīng)提供一種形式化語言(通常采用離散數(shù)學(xué)的表示形式)、語言推理技術(shù)以及各種該技術(shù)應(yīng)生成電子格式的規(guī)格說明，以便審查評(píng)估的一致性和完整性。通常這種技術(shù)不僅支持規(guī)如果E/E/PES執(zhí)行安全功能以外的功能，則應(yīng)描述這些功能或引用相關(guān)的規(guī)格說明。應(yīng)實(shí)現(xiàn)軟件安全需求與技術(shù)安全需求之間的雙向可追溯性。GB/T38874.3—2020/ISO25119-3:2018軟件安全需求規(guī)格說明應(yīng)描述軟硬件之間安全相關(guān)的依存性(如相關(guān))。軟件安全需求規(guī)格說明應(yīng)涵蓋以下方面(如相關(guān)):——使系統(tǒng)達(dá)到或保持安全狀態(tài)的功能；——與軟件自身故障檢測(cè)、指示和處理相關(guān)的功能(軟件自檢功能);注1:既包括操作系統(tǒng)中軟件自檢，也包括特定應(yīng)用程——與安全功能在線和離線測(cè)試有關(guān)的功能；注2:在車輛啟動(dòng)和運(yùn)行期間，需要進(jìn)行自檢?！试S對(duì)軟件進(jìn)行安全修改的功能；——非安全相關(guān)功能的接口；——性能和反應(yīng)時(shí)間；——電子控制單元軟硬件之間的接口。注4:接口也包括程序調(diào)試和配置。軟件安全需求規(guī)格說明應(yīng)包括：a)上述所列各功能的SRL;b)對(duì)軟件安全需求的進(jìn)行軟件安全確認(rèn)的驗(yàn)收準(zhǔn)則。術(shù)安全概念是否一致。還應(yīng)評(píng)審表6中定義的測(cè)試規(guī)范和測(cè)試報(bào)告，驗(yàn)證其是否符合軟件安全需求。軟件開發(fā)人員也應(yīng)參加驗(yàn)證工作。驗(yàn)證方法可為審查或遍歷(定義見GB/T38874.1)。b)依據(jù)的非安全相關(guān)軟件需求規(guī)格說明；c)來自的軟件安全需求規(guī)格說明的驗(yàn)證報(bào)告。7.3軟件架構(gòu)設(shè)計(jì)軟件架構(gòu)設(shè)計(jì)的目的是利用軟件組件使所有軟件需求結(jié)構(gòu)化，確定實(shí)現(xiàn)軟件的方法。軟件架構(gòu)應(yīng)確保所分配的軟件組件滿足所有軟件安全需求。軟件架構(gòu)是以層次結(jié)構(gòu)的形式表示軟件組件及其調(diào)用關(guān)系。應(yīng)從靜態(tài)(例如：所有軟件組件的接口GB/T38874.3—2020/ISO25119-3:2018軟件架構(gòu)開發(fā)的前提條件是軟件安全需求規(guī)格說明非常成熟。應(yīng)根據(jù)表2進(jìn)行軟件架構(gòu)開發(fā)。技術(shù)/方法“章條號(hào)SRL=BSRL=1SRL=2SRL=.2十十XX.3十十十十.4十十十十.500十十十十十十十十XX表1～表6的使用說明見。所選的設(shè)計(jì)方法應(yīng)支持下列特性：b)描述：——功能性；——時(shí)間約束；-—并發(fā)過程(如相關(guān));-—數(shù)據(jù)結(jié)構(gòu)及其特性；——設(shè)計(jì)中的假設(shè)及其依存性。c)開發(fā)人員及相關(guān)人員對(duì)設(shè)計(jì)方法非常了解。d)具備軟件修改能力。GB/T38874.3—2020/ISO25119-3:2018軟件架構(gòu)分層結(jié)構(gòu)的最底層應(yīng)為軟件單元。應(yīng)實(shí)現(xiàn)軟件架構(gòu)和軟件安全需求之間的雙向可追溯性。應(yīng)驗(yàn)證軟件架構(gòu)。應(yīng)檢查設(shè)計(jì)的軟件架構(gòu)是否滿足軟件安全需求。還應(yīng)審查表5中定義的測(cè)試規(guī)范和測(cè)試報(bào)告，以驗(yàn)證是否與軟件安全架構(gòu)檢查或遍歷(定義見GB/T38874.1),可酌情處理(見表2)。如果嵌入式軟件包含不同SRL的安全相關(guān)和非安全相關(guān)軟件組件，那么總體SRL取決于SRL最低的軟件組件。除非根據(jù)控制系統(tǒng)需要，能夠證明軟件組件之間充分獨(dú)立。SRL2或S錄B的要求。本階段的工作產(chǎn)品為：b)從得到的軟件架構(gòu)驗(yàn)證報(bào)告。軟件組件設(shè)計(jì)與實(shí)現(xiàn)的前提條件為：-軟件項(xiàng)目計(jì)劃(見7.1.1～); 軟件的設(shè)計(jì)和開發(fā)應(yīng)符合表3的規(guī)定。GB/T38874.3—2020/ISO25119-3:2018表3軟件設(shè)計(jì)和開發(fā)——支持工具和編程語言章條號(hào)1.1合適的編程語言.1十十十十1.2強(qiáng)類型編程語言.20十十十1.3語言子集.30十十十1.4工具和編譯器：增加使用的可信度.40十十十1.5使用可信/經(jīng)驗(yàn)證的軟件組件(如可用).500十十.2十十XX2.1b半形式化方法.3十十十十2.1c形式化方法.4十十十十2.2防御性編程.6000十2.3結(jié)構(gòu)化編程.70十十十2.4模塊化方法2.4.1軟件組件尺寸限制.80十十十2.4.2軟件復(fù)雜度控制.9000十2.4.3信息隱藏/封裝.1000十十2.4.4子程序和函數(shù)中僅一個(gè)入口/一個(gè)出口.80十十十2.4.5完全定義的接口.80十十十2.5可信/經(jīng)驗(yàn)證的軟件組件庫.11十十十十2.6計(jì)算機(jī)輔助設(shè)計(jì)工具.12000十3.1使用編碼規(guī)范.130十十十3.2a不使用動(dòng)態(tài)變量或?qū)ο?14000十3.2b在線檢查動(dòng)態(tài)變量的創(chuàng)建.15000十3.3限制使用中斷.16000十.17000十.18000十4a軟件設(shè)計(jì)和/或源代碼審查十十十十4b軟件設(shè)計(jì)和/或源代碼遍歷十十XX表1～表6的使用說明見。方法。GB/T38874.3—2020/ISO25119-3:2018可選擇支持GB/T38874的編程語言，特別是防御性編程、結(jié)構(gòu)化編程和斷言。所選擇的編程語言編程語言的定義應(yīng)無歧義。語言應(yīng)是面向用戶或面向問題、而不是面向機(jī)器的處理器/平臺(tái)。應(yīng)使——塊結(jié)構(gòu)；——編譯時(shí)進(jìn)行類型檢查。編程語言應(yīng)支持：——限制訪問特定軟件組件中的數(shù)據(jù)；——其他類型的防差錯(cuò)結(jié)構(gòu)。程序語言應(yīng)避免以下不利于驗(yàn)證的特性：a)無條件跳轉(zhuǎn)(子程序調(diào)用除外);b)遞歸；d)應(yīng)用層的中斷處理；f)隱式變量初始化或聲明；g)變體記錄和等價(jià)類；h)過程參數(shù)。注：低級(jí)語言(尤其是匯編語言)出現(xiàn)問題往往是由于處理器/平臺(tái)的面向機(jī)器的性質(zhì)。理想語言的屬性是，在程序設(shè)計(jì)和使用時(shí)其執(zhí)行結(jié)果是可預(yù)見的。給定一種適當(dāng)定義的編程語言，存在一個(gè)子集確保程序執(zhí)行結(jié)果可預(yù)見。盡管許多靜態(tài)約束有利于確保執(zhí)行結(jié)果可預(yù)見，但該子集通常不能被靜態(tài)確定。例如，通常需要證明數(shù)組索引在邊界內(nèi)且不引起數(shù)值溢出。應(yīng)采用強(qiáng)類型語言或編程實(shí)踐降低故障率，強(qiáng)類型語言或編程實(shí)踐允許使用編譯器或靜態(tài)分析工具進(jìn)行高級(jí)檢查。GB/T38874.3—2020/ISO25119-3:2018的用法可與基本類型完全相同。強(qiáng)制對(duì)數(shù)據(jù)類型進(jìn)行嚴(yán)格檢查確保其正確使用。即使程序由單獨(dú)編譯的單元語言子集的使用應(yīng)降低編程錯(cuò)誤率并提高錯(cuò)誤檢測(cè)率。在軟件包的開發(fā)、驗(yàn)證及維護(hù)過程中，為避免編譯器失效造成的問題，應(yīng)采用經(jīng)驗(yàn)證的工具和編譯器。應(yīng)使用在多數(shù)項(xiàng)目中經(jīng)驗(yàn)證的編譯器。避免使用未經(jīng)驗(yàn)證或有嚴(yán)重問題的編譯器，除非能保證編譯器可正確運(yùn)行。如果編譯器存在輕微問題，則應(yīng)標(biāo)識(shí)相關(guān)的語言，并在安全相關(guān)項(xiàng)目中盡量避免使用。對(duì)于每個(gè)新應(yīng)用，為避免軟硬件組件的重新驗(yàn)證和設(shè)計(jì)，應(yīng)使用可信/經(jīng)驗(yàn)證的軟件組件。允許開該方法應(yīng)驗(yàn)證軟件組件不存在系統(tǒng)性設(shè)計(jì)故障和/或操作失效。僅在極少數(shù)情況下，使用可信的軟件組件(即經(jīng)使用驗(yàn)證的)可作為達(dá)到所要求的SRL的唯一保證措施。對(duì)于多功能復(fù)雜組件(例如：操如果經(jīng)驗(yàn)證已達(dá)到要求的SRL或者符合下列準(zhǔn)則，則軟件組件是充——不改變影響安全相關(guān)功能的需求規(guī)范(例如：如果經(jīng)驗(yàn)證判定點(diǎn)和查找表的變更不影響安全相——至少有一年的運(yùn)行歷史；——軟件組件的使用經(jīng)驗(yàn)應(yīng)符合系統(tǒng)要求，并在使用中增加軟件組件的使用經(jīng)驗(yàn)(例如：在不同的應(yīng)用系統(tǒng)中):——無安全相關(guān)功能失效。20GB/T38874.3—2020/ISO25119-3:2018a)每個(gè)系統(tǒng)及其組件的準(zhǔn)確標(biāo)識(shí)，包括驗(yàn)證過程中使用的版本號(hào)(軟件和硬件版本);b)標(biāo)識(shí)有統(tǒng)計(jì)意義的用戶樣本和使用時(shí)間(例如：服務(wù)年限);d)檢測(cè)并記錄失效以及排除故障的過程。注2:如果經(jīng)驗(yàn)證滿足所要求的準(zhǔn)則(形成文檔記錄),則這種方法可用于整個(gè)軟件系統(tǒng)(也可由供應(yīng)商提供)?？山邮艿拇_定方式進(jìn)行響應(yīng)。以減少數(shù)據(jù)流錯(cuò)誤的可能性。軟件應(yīng)設(shè)計(jì)內(nèi)在的容錯(cuò)機(jī)制適應(yīng)設(shè)計(jì)本身的缺陷，這些缺陷由設(shè)計(jì)或編——數(shù)值合理性檢查；第一組防御技術(shù)有助于確保程序控制的輸入數(shù)據(jù)的合理性，輸入數(shù)據(jù)的合理性包括程序函數(shù)與變量的物理意義兩方面。應(yīng)將只讀參數(shù)和可讀寫參數(shù)分開，并對(duì)其訪問進(jìn)行檢查。函數(shù)應(yīng)將所有參數(shù)視作只讀參數(shù)。字面第二組防御性技術(shù)包括：——利用物理意義檢查輸入變量和中間變量的合理性；是軟件維護(hù)過程后保持其完整性。a)將程序劃分為較小的軟件組件，確保其功能盡可能隔離且所有的交互是顯式的。c)使通過軟件組件的路徑數(shù)量少，并使輸入和輸出參數(shù)之間的關(guān)系盡量簡(jiǎn)單。d)避免復(fù)雜分支。尤其要避免高級(jí)語言中的無條件跳轉(zhuǎn)(go-to)語句。GB/T38874.3—2020/ISO25119-3:2018f)避免使用復(fù)雜的計(jì)算作為分支和循環(huán)判斷的條件。優(yōu)先使用上述方法，而不是其他更有效率模塊化方法(模塊化)預(yù)先設(shè)定了軟件項(xiàng)目設(shè)計(jì)、編碼和維護(hù)階段的多個(gè)規(guī)則。根據(jù)所采用的設(shè)計(jì)—-—軟件組件應(yīng)有明確定義的單個(gè)任務(wù)或功能(適用于表3第2.4.1項(xiàng)和第2.4.4項(xiàng))?！浖M件之間的連接應(yīng)受到限制并嚴(yán)格定義；單個(gè)軟件組件應(yīng)有很強(qiáng)的一致性(適用于表3第2.4.5項(xiàng))?！獞?yīng)建立子程序庫，提供軟件組件的多個(gè)等級(jí)(適用于表3第2.4.5項(xiàng))?！浖M件大小應(yīng)以編碼規(guī)范中的指定值為限(適用于表3第2.4.1項(xiàng))?！浖M件應(yīng)僅有一個(gè)入口和一個(gè)出口(適用于表3第2.4.4項(xiàng))?！浖M件應(yīng)通過其接口與其他軟件組件進(jìn)行通信。使用全局變量或公共變量時(shí)，應(yīng)結(jié)構(gòu)良好、訪問受控，并在每個(gè)實(shí)例中合理使用(適用于表3第2.4.5項(xiàng))?！熊浖M件接口應(yīng)充分文檔化(適用于表3第2.4.5項(xiàng))?！浖M件接口應(yīng)僅包含其功能所需的參數(shù)(適用于表3第2.4.5項(xiàng))。這些模型可用于評(píng)估軟件的某些結(jié)構(gòu)屬性，并將其與期望的屬性(如可靠性或復(fù)雜度)相聯(lián)系。需要軟件工具來評(píng)估大多數(shù)度量。下面給出一些可應(yīng)用的度量標(biāo)準(zhǔn)：——圈復(fù)雜度。用于在壽命周期早期對(duì)軟件進(jìn)行評(píng)估均衡。圈復(fù)雜度取決于程序控制圖的復(fù)雜——激活軟件組件的路徑數(shù)(路徑可達(dá)性檢驗(yàn))。軟件組件被訪問次數(shù)越多，越有可能暴露錯(cuò)誤。--—Halstead度量。該度量通過對(duì)運(yùn)算符和操作數(shù)計(jì)數(shù)計(jì)算程序長(zhǎng)度，提供了一種復(fù)雜度和規(guī)模——每個(gè)軟件組件的扇入扇出數(shù)。最小化入口/出口點(diǎn)的數(shù)量是結(jié)構(gòu)化設(shè)計(jì)和編程技術(shù)的關(guān)鍵22GB/T38874.3—2020/ISO25119-3:2018因此，應(yīng)使用抽象數(shù)據(jù)類型的概念。如果不直接支持，可能需要檢查抽象數(shù)據(jù)類型是否被意外注1:不同應(yīng)用背景的E/E/PES有時(shí)包含一些相同或非常相似的軟件組件。構(gòu)建通用軟件組件庫，確認(rèn)設(shè)計(jì)所需GB/T38874.3—2020/ISO25119-3:2018——代碼布局(列表)?！槐匾幕蛭礄z測(cè)到的內(nèi)存覆蓋；——運(yùn)行時(shí)的資源瓶頸(與安全相關(guān)的)。動(dòng)態(tài)變量和動(dòng)態(tài)對(duì)象在運(yùn)行時(shí)分配內(nèi)存并確定絕對(duì)地址。內(nèi)存分配值及地址取決于分配時(shí)系統(tǒng)的動(dòng)態(tài)變量和對(duì)象的數(shù)量、用于分配新動(dòng)態(tài)變量或?qū)ο蟮默F(xiàn)有可用內(nèi)存取決于分配時(shí)系統(tǒng)的狀態(tài)。在創(chuàng)建動(dòng)態(tài)變量或動(dòng)態(tài)對(duì)象期間應(yīng)進(jìn)行在線檢查，檢查動(dòng)態(tài)變量或?qū)ο笏峙涞膬?nèi)存在分配前是動(dòng)態(tài)變量在程序運(yùn)行時(shí)分配內(nèi)存并確定絕對(duì)地址(變量也具有對(duì)象實(shí)例的屬性)。在向動(dòng)態(tài)變量或出子程序),應(yīng)釋放內(nèi)存。時(shí)間。應(yīng)完整記錄中斷的使用和禁用。測(cè)試和驗(yàn)證并限制失效造成的后果。24GB/T38874.3—2020/ISO25119-3:2018才允許在源代碼級(jí)使用指針運(yùn)算。應(yīng)對(duì)軟件組件的設(shè)計(jì)及其代碼進(jìn)行驗(yàn)證。應(yīng)檢查設(shè)計(jì)和代碼是否滿足軟件安全需求。還應(yīng)審查表6中定義的測(cè)試規(guī)格說明和測(cè)試報(bào)告，驗(yàn)證是否與軟件組件設(shè)計(jì)及其代碼一致。軟件開發(fā)者應(yīng)參與本階段的工作產(chǎn)品為：b)依據(jù)的軟件；c)依據(jù)的軟件組件設(shè)計(jì)和代碼驗(yàn)證報(bào)告。7.5軟件組件測(cè)試驗(yàn)證已設(shè)計(jì)和編碼的軟件組件是否正確實(shí)現(xiàn)了軟件需求?！浖?yàn)證計(jì)劃(見GB/T38874.4—2020的第6章);——符合要求的軟件組件。應(yīng)依據(jù)表4進(jìn)行軟件組件測(cè)試。軟件組件測(cè)試計(jì)劃應(yīng)包含驗(yàn)證目標(biāo)SRL所選擇的技術(shù)/方法。軟GB/T38874.3—2020/ISO25119-3:2018件組件測(cè)試規(guī)范應(yīng)說明這些技術(shù)/方法的使用規(guī)程。軟件組件測(cè)試報(bào)告應(yīng)記錄所進(jìn)行的測(cè)試及測(cè)試結(jié)果。表4軟件組件測(cè)試技術(shù)/方法“章條號(hào)SRL=BSRL=1SRL=2SRL=31靜態(tài)分析1.1邊界值分析.1十十十十1.2檢查單.200001.3控制流分析.300十十1.4數(shù)據(jù)流分析.400十十2動(dòng)態(tài)分析和測(cè)試.52.1邊界值分析的測(cè)試用例7.5,4.1.6000十2.2a結(jié)構(gòu)測(cè)試覆蓋(入口點(diǎn)).700十X2.2b結(jié)構(gòu)測(cè)試覆蓋(語句).700十十2.2c結(jié)構(gòu)測(cè)試覆蓋(分支).700十十3單元測(cè)試3.1等價(jià)類和輸入分區(qū)測(cè)試.800十十3.2邊界值分析.100十十3.3測(cè)試用例執(zhí)行(測(cè)試用例由模型生成).9000十4性能測(cè)試.104.1響應(yīng)時(shí)間和內(nèi)存約束.110十十十4.2性能需求測(cè)試.120十十十4.3雪崩/壓力測(cè)試.13000十7.5.4,1.14000十表1～表6使用說明見。應(yīng)依照SRL選擇適當(dāng)?shù)募夹g(shù)/方法。替代或等效的技術(shù)/方法用數(shù)字后的字母表示，僅需滿足其中一種技術(shù)方法。通過邊界值分析檢測(cè)在參數(shù)極限或邊界發(fā)生的軟件錯(cuò)誤。按照等價(jià)關(guān)系將程序的輸入域劃分為多個(gè)輸入類(見.5)。測(cè)試應(yīng)涵蓋類的邊界和極限。測(cè)試應(yīng)檢查規(guī)格說明中輸入域的邊界是否與程序中的邊界一致。在直接或間接的轉(zhuǎn)換中，零值的使用經(jīng)——零除數(shù)；26GB/T38874.3—2020/ISO25119-3:2018——空堆?；蚩樟斜碓?；--—全0矩陣；——空表格。測(cè)試用例使輸出超過規(guī)格說明的邊界值。單個(gè)元素和兩個(gè)元素等。檢查單適用于E/E/PES整個(gè)軟件安全壽命周期的所有階段，并且特別有助于功能安全評(píng)估。.3靜態(tài)分析——控制流分析法通過控制流分析檢測(cè)不良和有潛在錯(cuò)誤的程序結(jié)構(gòu)?？刂屏鞣治龇ㄊ且环N靜態(tài)測(cè)試技術(shù)，用于查找不符合良好編程實(shí)踐的可疑代碼區(qū)域。通過程序分-—打結(jié)的代碼。結(jié)構(gòu)良好的代碼可通過連續(xù)圖縮減至單個(gè)節(jié)點(diǎn)，而結(jié)構(gòu)不良的代碼僅能縮減為多個(gè)節(jié)點(diǎn)。.4靜態(tài)分析——數(shù)據(jù)流分析數(shù)據(jù)流分析用于檢測(cè)有潛在錯(cuò)誤的風(fēng)格不良的程序結(jié)構(gòu)。數(shù)據(jù)流分析是一種靜態(tài)測(cè)試技術(shù)，將控制流分析中獲得的信息與在代碼不同部分讀取或?qū)懭胱兞縂B/T38874.3—2020/ISO25119-3:2018的信息相結(jié)合。數(shù)據(jù)流分析可檢查以下變量類型：將預(yù)定工作環(huán)境下的典型數(shù)據(jù)輸入到安全相關(guān)系統(tǒng)原型中，完成安全相關(guān)系統(tǒng)的動(dòng)態(tài)分析。如果新的運(yùn)行版本。結(jié)構(gòu)化測(cè)試用于對(duì)程序結(jié)構(gòu)中的某些子集進(jìn)行測(cè)試。在程序分析的基礎(chǔ)上選擇一組輸入數(shù)據(jù)，運(yùn)行程序達(dá)到程序代碼的目標(biāo)覆蓋率。目標(biāo)覆蓋率應(yīng)盡可能大，應(yīng)預(yù)先指定并進(jìn)行記錄。代碼覆蓋度量方法如下，與測(cè)試的嚴(yán)格程度有關(guān)。此測(cè)試與表4中的——入口點(diǎn)(調(diào)用)覆蓋確保每個(gè)子程序(子程序或函數(shù))至少被調(diào)用一次(這是最不嚴(yán)格的結(jié)構(gòu)覆蓋度量)?！Z句覆蓋這是最不嚴(yán)格的測(cè)試方法。在未運(yùn)行條件語句兩個(gè)分支的情況下，有可能執(zhí)行所有的代碼——分支覆蓋等價(jià)類和輸入分區(qū)測(cè)試應(yīng)利用最少的測(cè)試數(shù)據(jù)充分測(cè)試軟件。應(yīng)對(duì)運(yùn)行軟件所需的輸入域進(jìn)行分28GB/T38874.3—2020/ISO25119-3:2018測(cè)試策略應(yīng)基于輸入的等價(jià)關(guān)系確定輸入域的分區(qū)。有兩種基本的輸入分區(qū)方法：——源于規(guī)格說明的等價(jià)類——可面向輸入(例如：選擇的值以相同方式處理)或面向輸出(例如：功能結(jié)果相同的一組輸入值);-—源于程序結(jié)構(gòu)的等價(jià)類——等價(jià)類由程序的靜態(tài)分析確定(例如：執(zhí)行相同路徑的一組值)。為進(jìn)行建模。此外，基于模型的測(cè)試可與源代碼級(jí)的測(cè)試覆蓋度量相結(jié)合，功能模型可基于現(xiàn)有的源代碼。試用例從這個(gè)抽象測(cè)試套件中導(dǎo)出并對(duì)系統(tǒng)進(jìn)行測(cè)試，也可對(duì)系統(tǒng)通常具體活動(dòng)為：——建模(來自系統(tǒng)需求);——生成期望的輸入值；——生成期望的輸出值；——運(yùn)行測(cè)試；——比較實(shí)際輸出和期望輸出值；——使用判決表；——使用語法；——使用狀態(tài)圖；——理論證明；——約束邏輯程序設(shè)計(jì)；——符號(hào)執(zhí)行技術(shù)；——使用事件流模型；GB/T38874.3—2020/ISO25119-3:2018注2:基于模型的測(cè)試專門針對(duì)安全關(guān)鍵領(lǐng)域。允許在早期暴露規(guī)格說明和設(shè)計(jì)中的歧義，提供自動(dòng)生成許多不重復(fù)高效測(cè)試的能力，評(píng)價(jià)回歸測(cè)試套件以評(píng)估軟件的可靠性和質(zhì)量，并簡(jiǎn)化測(cè)試套件的更新。性能測(cè)試用于確保系統(tǒng)的工作能力充分滿足特定需求。組件級(jí)的性能測(cè)試可與軟件集成性能測(cè)試相結(jié)合。響應(yīng)時(shí)間和內(nèi)存約束應(yīng)確保系統(tǒng)滿足時(shí)間需求和內(nèi)存需求。應(yīng)分析確定平均和最壞情況下的分配需求。需要分析估計(jì)每個(gè)系統(tǒng)功能的資源使用情況和運(yùn)行時(shí)間。注：對(duì)于SRL1,可在組件級(jí)或集成級(jí)進(jìn)行響應(yīng)時(shí)間和內(nèi)存約束測(cè)試。應(yīng)建立測(cè)試驗(yàn)證軟件系統(tǒng)的性能需求。應(yīng)對(duì)每個(gè)性能需求進(jìn)行檢查以確定：——是否達(dá)到通過準(zhǔn)則；——潛在的測(cè)量精度；——可獲得性能測(cè)量估計(jì)值的項(xiàng)目階段；——可完成該性能需求驗(yàn)證的項(xiàng)目階段。應(yīng)分析每個(gè)性能需求的可行性，以獲取性能需求列表、通過準(zhǔn)則和潛在測(cè)量方法列表。主要目a)每個(gè)性能需求至少與一種測(cè)量方法關(guān)聯(lián)；GB/T38874.3—2020/ISO25119-3:2018d)在不降低測(cè)量有效性的情況下，應(yīng)優(yōu)先考慮使用單個(gè)測(cè)量方法對(duì)應(yīng)多個(gè)性能需求?！杏绊懙脑O(shè)備分別調(diào)至最高速度或最低速度；接口測(cè)試用于檢測(cè)子程序中的接口錯(cuò)誤?？蛇M(jìn)行多級(jí)測(cè)試或完整性測(cè)試。最重要級(jí)別的測(cè)試為：——所有變量的任意值組合(僅限于接口數(shù)較少時(shí));——與子程序調(diào)用相關(guān)的指定測(cè)試條件。應(yīng)消除在本階段檢測(cè)到的錯(cuò)誤。應(yīng)對(duì)每項(xiàng)修改進(jìn)行影響分析。如果修改影響前面任意階段的工作產(chǎn)品，則應(yīng)返回軟件安全壽命周期的相應(yīng)階段。按照GB/T38874的相關(guān)部分重新執(zhí)行后續(xù)階段。本階段的工作產(chǎn)品為：a)符合的軟件組件測(cè)試計(jì)劃；b)與一致的軟件組件測(cè)試規(guī)范；c)性能測(cè)試所產(chǎn)生的軟件組件測(cè)試報(bào)告。GB/T38874.3—2020/ISO25119-3:2018軟件集成和測(cè)試的第一個(gè)目的是將軟件單元逐步集成到軟件組件，直至集成為ECU嵌入式軟件。第二個(gè)目的是驗(yàn)證嵌入式軟件集成部件已正確地實(shí)現(xiàn)了軟件需求。和測(cè)試的步驟應(yīng)直接對(duì)應(yīng)分級(jí)的軟件架構(gòu)。軟件集成和測(cè)試的前提條件為： ——軟件驗(yàn)證計(jì)劃(見GB/T38874.4—2020的第6章);——符合已測(cè)試的軟件組件。軟件集成和測(cè)試計(jì)劃應(yīng)至少包括以下內(nèi)容：b)軟件集成測(cè)試計(jì)劃。軟件集成策略應(yīng)至少包含以下內(nèi)容：a)分級(jí)集成軟件組件的步驟；b)與軟件集成相關(guān)的功能依賴性。軟件組件集成測(cè)試和軟件安全測(cè)試可合并到一個(gè)階段。在軟件集成測(cè)試計(jì)劃中應(yīng)制定適當(dāng)?shù)募蓽y(cè)試過程。GB/T38874.3—2020/ISO25119-3:2018表5軟件集成測(cè)試(組件)技術(shù)/方法章條號(hào)SRL=BSRL=1SRL=2SRL=31功能測(cè)試或黑盒測(cè)試.1十十十十2等價(jià)類和輸入劃分測(cè)試.800十十3性能測(cè)試3.1a資源約束分析.100十XX3,1b響應(yīng)時(shí)間和內(nèi)存約束7.5,4.1.110十十十3.2性能需求測(cè)試.1200十十3.3雪崩/壓力測(cè)試.13000十表1～表6的使用說明見。“應(yīng)依照SRL選擇適當(dāng)?shù)募夹g(shù)/方法。替代或等效的技術(shù)/方法用數(shù)字后的字母表示，僅需滿足其中一種技術(shù)方法。功能測(cè)試用于揭示規(guī)格說明和設(shè)計(jì)階段中的失效，并發(fā)現(xiàn)在軟件實(shí)現(xiàn)及軟硬件集成時(shí)引入的失效。在進(jìn)行功能測(cè)試時(shí)，應(yīng)對(duì)測(cè)試結(jié)果進(jìn)行評(píng)審，確定是否達(dá)到系統(tǒng)規(guī)定的特性以及系統(tǒng)輸入數(shù)據(jù)是否充分反映系統(tǒng)正常的預(yù)期。同時(shí)，應(yīng)確定系統(tǒng)輸出與規(guī)格說明的一致性。如果與規(guī)格說明有偏離和不針對(duì)多通道架構(gòu)電子組件的功能測(cè)試，通常使用經(jīng)驗(yàn)證的廠商元件對(duì)制造的組件進(jìn)行試驗(yàn)。此外，(可行時(shí))制造的組件應(yīng)與同批次的其他廠商的元件一起測(cè)試，以揭示可能被掩蓋的共模故障。應(yīng)消除在本階段檢測(cè)到的錯(cuò)誤。應(yīng)對(duì)每項(xiàng)修改進(jìn)行影響分析。如果修改影響前面任意階段的工作產(chǎn)品，則應(yīng)返回軟件安全壽命周期的相應(yīng)階段。按照GB/T38874的相關(guān)部分重新執(zhí)行后續(xù)階段。本階段的工作產(chǎn)品為：a)軟件集成測(cè)試計(jì)劃，包含符合～的軟件集成策略；b)要求的軟件集成測(cè)試規(guī)格說明；c)符合的軟件集成測(cè)試報(bào)告。7.7軟件安全測(cè)試軟件安全測(cè)試用于驗(yàn)證嵌入式軟件是否正確滿足了軟件需求。GB/T38874.3—2020/ISO25119-3:2018軟件安全測(cè)試是E/E/PES系統(tǒng)安全確認(rèn)的一部分(見GB/T38874.4—2020的第6章)。在整個(gè)E/E/PES系統(tǒng)的安全確認(rèn)計(jì)劃期間，應(yīng)確定在E/E/PES系統(tǒng)級(jí)測(cè)試的安全目標(biāo)以及軟件級(jí)測(cè)試的安全目標(biāo)。在最簡(jiǎn)單的情況下，E/E/PES系統(tǒng)的安全確認(rèn)應(yīng)覆蓋包括軟件在內(nèi)的所有安全目標(biāo)。因此，無需單獨(dú)進(jìn)行軟件安全確認(rèn)。軟件安全測(cè)試的前提條件為： ——軟件需求(見7.2.5a)和b]];——軟件驗(yàn)證計(jì)劃(見GB/T38874.4—2020的第6章);——ECU。測(cè)試應(yīng)是軟件驗(yàn)證的主要方法，模型演示和模型驗(yàn)證可作為補(bǔ)充驗(yàn)證活動(dòng)。應(yīng)參照表6選擇適當(dāng)?shù)募夹g(shù)/方法。表6軟件安全測(cè)試技術(shù)/方法“章條號(hào)1軟件安全需求測(cè)試1.1aECU網(wǎng)絡(luò)內(nèi)的測(cè)試0十十X1.1b硬件在環(huán)測(cè)試0十十十1.1c機(jī)器內(nèi)測(cè)試0十十十表1～表6的使用說明見7,1.4.7。注：1.la、1.1b、1.1c中的測(cè)試代表測(cè)試環(huán)境。應(yīng)依照SRL選擇適當(dāng)?shù)募夹g(shù)/方法。替代或等效的技術(shù)/方法用數(shù)字后的字母表示，僅需滿足其中一種技術(shù)軟件應(yīng)與其相關(guān)的ECU中的主機(jī)微處理器集成。當(dāng)通過專用測(cè)試接口訪問/監(jiān)測(cè)軟件狀態(tài)和結(jié)果時(shí)，系統(tǒng)其余部分的輸入可為仿真信號(hào)。圖5給出了接口測(cè)試示例。GB/T38874.3—2020/ISO25119-3:20181——整個(gè)E/E/PES系統(tǒng)；4——未接入的ECU和軟件；圖5E/E/PES系統(tǒng)的ECU測(cè)試接口軟件應(yīng)與其相關(guān)的ECU中的主機(jī)微處理器相集成，該ECU應(yīng)與整個(gè)E/E/PES系統(tǒng)中的其余333342442154251——整個(gè)E/E/PES系統(tǒng)；2——含實(shí)際待測(cè)試軟件的實(shí)際ECU;4——待監(jiān)測(cè)的實(shí)際信號(hào)；5——仿真信號(hào)。GB/T38874.3—2020/ISO25119-3:2018軟件應(yīng)與其相關(guān)的ECU主機(jī)微處理器相集成，而E/E/PES系統(tǒng)的其余部分及環(huán)境應(yīng)以仿真或物2——含實(shí)際待測(cè)試軟件的實(shí)際ECU;圖7E/E/PES系統(tǒng)的ECU硬件在環(huán)測(cè)試軟件及相關(guān)的E/E/PES系統(tǒng)應(yīng)集成到相關(guān)的機(jī)器架構(gòu)中。然后，在機(jī)器上對(duì)系統(tǒng)進(jìn)行測(cè)試，以驗(yàn)證軟件行為符合規(guī)格說明，見圖8。在系統(tǒng)硬件/軟件集成測(cè)試期間可進(jìn)行這種測(cè)試(見圖1)。2——含實(shí)際待測(cè)試軟件的實(shí)際ECU; 圖8E/E/PES系統(tǒng)的機(jī)器內(nèi)測(cè)試GB/T38874.3—2020/ISO25119-3:2018軟件應(yīng)對(duì)以下信號(hào)進(jìn)行仿真：——正常運(yùn)行時(shí)的輸入信號(hào)；——可預(yù)期事件；——要求系統(tǒng)動(dòng)作的非理想條件。供應(yīng)商和/或開發(fā)人員應(yīng)將軟件安全確認(rèn)的文檔化結(jié)果和相關(guān)文件提供給系統(tǒng)開發(fā)人員，使其能夠符合GB/T38874.4的要求。應(yīng)消除本階段檢測(cè)到的錯(cuò)誤或缺陷。應(yīng)對(duì)每個(gè)修改項(xiàng)進(jìn)行影響分析。影響前一階段工作產(chǎn)品的任何修改，都應(yīng)啟動(dòng)返回到軟件安全壽命周期的相應(yīng)階段。后續(xù)階段應(yīng)參照GB/T38874的相關(guān)部分執(zhí)行。本階段的工作產(chǎn)品為：c)依據(jù)的軟件安全測(cè)試報(bào)告?；谲浖膮?shù)化是指在開發(fā)完成后通過改變參數(shù)修改軟其目的是導(dǎo)出安全相關(guān)參數(shù)的需求。安全相關(guān)參數(shù)的參數(shù)化應(yīng)視為SRP/CS設(shè)計(jì)的安全相關(guān)方面，在軟件安全需求規(guī)格說明中描述?；谲浖膮?shù)包括：基于軟件的參數(shù)化的前提條件為： GB/T38874.3—2020/ISO25119-3:2018——軟件驗(yàn)證計(jì)劃(見GB/T38874.4—2020的第6章);a)有效的輸入范圍?！獙?duì)配置數(shù)據(jù)進(jìn)行合理性檢查；——使用冗余數(shù)據(jù)存儲(chǔ)；c)參數(shù)傳輸過程中的錯(cuò)誤。d)參數(shù)不完整傳輸?shù)挠绊?。e)參數(shù)化工具的軟硬件故障及失效影響。參數(shù)數(shù)據(jù)不應(yīng)包含可執(zhí)行代碼。基于軟件的參數(shù)化應(yīng)為配置管理的一部分(見GB/T38874.4—2020的第7章)?！?yàn)證每個(gè)安全相關(guān)參數(shù)的正確設(shè)置(最小值、最大值和典型值);——驗(yàn)證可防止安全相關(guān)參數(shù)未經(jīng)授權(quán)的修改；本階段的工作產(chǎn)品為：a)經(jīng)驗(yàn)證的安全軟件參數(shù)配置；c)依據(jù)和的軟件確認(rèn)測(cè)試規(guī)格說明；d)依據(jù)的軟件確認(rèn)測(cè)試報(bào)告。GB/T38874.3—2020/ISO25119-3:2018(資料性附錄)AgPL=e時(shí)功能安全評(píng)估的議程示例A.1系統(tǒng)功能A.1.1系統(tǒng)、組件和功能屬性的詳細(xì)描述。A.1.2電氣組件的概述。A.1.3功能的危險(xiǎn)和風(fēng)險(xiǎn)分析。A.2硬件A.2.1功能框圖。A.2.2布局和走線圖。A.2.3環(huán)境連接(接口)。A.3安全概念A(yù).3.1安全概念的基本原則。A.3.3安全概念的功能。A.3.4故障條件(容錯(cuò))下的安全相關(guān)功能的驗(yàn)證。A.3.5安全概念與其他系統(tǒng)/功能的交互。A.4安全分析和安全數(shù)據(jù)A.4.1失效分析(FMEA、FTA等)。A.4.2內(nèi)部監(jiān)控功能。A.4.4發(fā)現(xiàn)的內(nèi)部故障數(shù)據(jù)(例如：組件失效的診斷發(fā)現(xiàn)、失效識(shí)別次數(shù)等)。A.5壽命周期各階段的安全設(shè)計(jì)過程A.5.1項(xiàng)目管理。A.5.2文檔。A.5.3規(guī)格說明階段。A.5.4計(jì)劃和開發(fā)階段。A.5.5集成階段。A.5.6通用確認(rèn)/安全確認(rèn)計(jì)劃。A.5.7通用確認(rèn)/安全確認(rèn)的結(jié)果。GB/T38874.3—2020/ISO25119-3:2018A.6軟件開發(fā)A.6.1軟件安全概念。A.6.2軟件結(jié)構(gòu)。A.6.3軟件測(cè)試及文檔。A.6.4使用的開發(fā)工具。A.6.6保護(hù)已實(shí)現(xiàn)的軟件免受未經(jīng)授權(quán)的修改。A.7驗(yàn)證和測(cè)試A.7.1在無失效條件下的系統(tǒng)功能驗(yàn)證。A.7.2在失效情況下的系統(tǒng)功能驗(yàn)證。A.8文檔和安全文檔A.8.1完整性。A.8.2一致性。A.9匯總和評(píng)估40GB/T38874.3—2020/ISO25119-3:2018(規(guī)范性附錄)軟件分區(qū)的獨(dú)立性B.1概述本附錄提供了一種方法(軟件分區(qū)及其相關(guān)方法),幫助設(shè)計(jì)者證明軟件組件的獨(dú)立性(見7.3.4軟件組件違反獨(dú)立性會(huì)引起故障。應(yīng)排除這種故障影響，確保軟件組件的充分獨(dú)立性。采取的方法應(yīng)至少具有中等效果。對(duì)本附錄中的每種方法，給出了推薦的有效性等級(jí)(見表B.1和表B.2)。B.2術(shù)語和定義、縮略語B.2.1術(shù)語和定義下列術(shù)語和定義適用于本附錄。B.2.1.1注：只要對(duì)象處于活動(dòng)狀態(tài)，計(jì)數(shù)器就從時(shí)間1-1遞增至?xí)r間t。最后，活動(dòng)計(jì)數(shù)器給出網(wǎng)絡(luò)中的對(duì)象處于活動(dòng)狀B.2.1.2B.2.1.3B.2.1.4(進(jìn)程間/內(nèi)部任務(wù)通信)用于在異步進(jìn)程或任務(wù)間傳遞和交換數(shù)據(jù)(消息)的過程，包括FIFO緩沖。B.2.1.5微時(shí)隙minislottingB.2.1.6保護(hù)語句順序獨(dú)占式執(zhí)行的同步機(jī)制。41GB/T38874.3—2020/ISO25119-3:2018B.2.1.7注1:分區(qū)通過靜態(tài)指定，并在系統(tǒng)啟動(dòng)時(shí)創(chuàng)建。注2:分區(qū)內(nèi)的程序運(yùn)行總是受限于系統(tǒng)啟動(dòng)時(shí)系統(tǒng)向分區(qū)分配的資源。B.2.1.8B.2.1.9B.2.1.10注1:軟件分區(qū)的目的是：當(dāng)軟件分區(qū)與其他分區(qū)共享資源或部分資源時(shí)(例如：處理器和/或外圍設(shè)備),控制額外風(fēng)險(xiǎn)的產(chǎn)生。軟件分區(qū)不是要防止單個(gè)軟件分區(qū)內(nèi)的失效，而是要防止此類失效的傳播。注2:軟件分區(qū)包含兩方面。一方面是空間分區(qū)，空間分區(qū)處理未經(jīng)授權(quán)的數(shù)據(jù)訪問和對(duì)其他分區(qū)外圍設(shè)備的非法命令。另一方面是時(shí)間分區(qū)，時(shí)間分區(qū)處理對(duì)其他分區(qū)的事件定時(shí)的干擾(調(diào)度、執(zhí)行順序等)。B.2.1.11注：管道建立消息隊(duì)列的上層并使用類似標(biāo)準(zhǔn)I/O接口，即一個(gè)進(jìn)程/任務(wù)的輸出作為另一管道的輸入。B.2.1.12注：見相對(duì)尋址(B.2.1.14)。B.2.1.13注：通常在需要備份或故障安全的情況下采取此措施。B.2.1.14注：見實(shí)際尋址(B.2.12)。B.2.1.15注：共享內(nèi)存是多個(gè)任務(wù)可直接訪問的內(nèi)存區(qū)域。信號(hào)量用于避免干擾并確保內(nèi)存完整性。這種進(jìn)程間/任務(wù)間通信的方法比通過操作系統(tǒng)業(yè)務(wù)交換數(shù)據(jù)更快。GB/T38874.3—2020/ISO25119-3:2018B.2.1.16B.2.1.17軟件的一個(gè)或多個(gè)功能的實(shí)現(xiàn)。和任務(wù)來實(shí)現(xiàn)的。B.2.1.18軟件單元softwareunitB.2.1.19配置單獨(dú)系統(tǒng)資源運(yùn)行時(shí)的環(huán)境。B.2.1.20軟件運(yùn)行所需的所有資源。B.2.1.21任務(wù)taskB.2.1.22排除軟件組件之間的意外交互以及避免軟件組件的設(shè)計(jì)和/或?qū)崿F(xiàn)錯(cuò)誤影響另一軟件組件的正確運(yùn)行。B.2.1.23B.2.1.24下列縮略語適用于本附錄。CRC:循環(huán)冗余校驗(yàn)(CyclicRedundancyCheck)CPU:中央處理單元(CentralProcessingUnit)43GB/T38874.3—2020/ISO25119-3:2018MMU:內(nèi)存管理單元(MemoryManagementUnit)MPU:內(nèi)存保護(hù)單元(MemoryProtectionUnit)第一個(gè)目的是控制子系統(tǒng)內(nèi)部發(fā)生的危險(xiǎn)，使其不影響其他子系統(tǒng)。第二個(gè)目的是通過軟件分區(qū)指定軟件組件充分獨(dú)立性的驗(yàn)證方法。B.4概述為了實(shí)現(xiàn)軟件組件的充分獨(dú)立性，(可行時(shí))系統(tǒng)資源應(yīng)分配給獨(dú)立子系統(tǒng)或分區(qū)。每個(gè)子系統(tǒng)或句柄)等。軟件分區(qū)的使用不受相同運(yùn)行環(huán)境下不同SRL的軟件共存性的限制。也可支持：理時(shí)間和I/O訪問(可行時(shí))。a)單微控制器的多個(gè)分區(qū)；b)ECU網(wǎng)絡(luò)內(nèi)的多個(gè)分區(qū)。B.5要求B.5.1一般要求支持分區(qū)實(shí)現(xiàn)的軟件部分的SRL應(yīng)大于或等于與軟件分區(qū)相關(guān)的最高SRL。B.5.1.2軟件架構(gòu)在規(guī)定軟件架構(gòu)時(shí)，應(yīng)考慮軟件分區(qū)的概念。B.5.2單微控制器的多個(gè)分區(qū)B.5.2.1概述見圖B.1。44GB/T38874.3—2020/ISO25119-3:2018分區(qū)B分區(qū)A操作系統(tǒng)硬件——內(nèi)存損壞(意外寫入其他分區(qū)的內(nèi)存空間);——分區(qū)阻塞(由于通信鎖死);——處理器執(zhí)行時(shí)間配置錯(cuò)誤；——錯(cuò)誤的通信對(duì)等體(發(fā)送方發(fā)送消息給錯(cuò)誤的接受方，或偽裝發(fā)送方發(fā)送消息);——由于意外寫入到其他分區(qū)I/O接口而造成I/O接口損壞。應(yīng)采用表B.1所列的方法和措施，中等以上效果處理對(duì)所有的故障影響，確保軟件組件的充分獨(dú)立性。表B.1微控制器內(nèi)的方法和措施方法/措施故障影響內(nèi)存損壞分區(qū)阻塞處理器執(zhí)行時(shí)間錯(cuò)誤通信對(duì)等體錯(cuò)誤I/O接口損壞通信驗(yàn)證1.無歧義雙向通信對(duì)象無無無中無2.兩個(gè)嚴(yán)格單向通信對(duì)象無無無中無3.對(duì)標(biāo)識(shí)的識(shí)別和/或確認(rèn)無無無高無4.異步數(shù)據(jù)通信無高無無無處理器執(zhí)行時(shí)間的分配5.非優(yōu)先級(jí)的調(diào)度無無中無無6.時(shí)間分片法無無高無無45GB/T38874.3—2020/ISO25119-3:2018表B.1(續(xù))方法/措施故障影響內(nèi)存損壞分區(qū)阻塞處理器執(zhí)行時(shí)間錯(cuò)誤通信對(duì)等體錯(cuò)誤I/O接口損壞系統(tǒng)資源配置7.內(nèi)存保護(hù)機(jī)制高無無無無高/中無無無無9.靜態(tài)分析中無無無無10.靜態(tài)配置中中中中中第1、2條分區(qū)之間的通信對(duì)象為管道、消息隊(duì)列及共享內(nèi)存等資源。這些不應(yīng)用于同步分區(qū)。共享內(nèi)存的兩個(gè)分區(qū)之間的通信訪問應(yīng)是同步的。例如，使用信號(hào)量。當(dāng)使用消息隊(duì)列時(shí)，應(yīng)禁止阻塞讀寫的訪問。內(nèi)存管理單元MMU允許使用虛擬地址空間。這可防止一個(gè)分區(qū)的任務(wù)通過意外寫入此地址空間而損壞另一任務(wù)的內(nèi)存空間，因?yàn)槊總€(gè)分區(qū)都有自己的內(nèi)存空間。使用MMU要求操作系統(tǒng)支持該特性。應(yīng)做出規(guī)定，使MMU不能忽略。因此，任務(wù)以所謂的用戶模式運(yùn)行，不使用實(shí)際尋址模式。兩個(gè)分區(qū)間分別使用一個(gè)雙向通信對(duì)象進(jìn)行數(shù)據(jù)交換。兩個(gè)分區(qū)間分別使用兩個(gè)單向通信對(duì)象進(jìn)行數(shù)據(jù)交換。使用唯一數(shù)字識(shí)別通信對(duì)等體或由通信對(duì)等體確認(rèn)收到消息。本條使用所述的異步數(shù)據(jù)通信，且已完成的通信本身無等待狀態(tài)。在處理器執(zhí)行時(shí)間分配時(shí)，各分區(qū)是同等的，并