日本无码免费高清在线|成人日本在线观看高清|A级片免费视频操逼欧美|全裸美女搞黄色大片网站|免费成人a片视频|久久无码福利成人激情久久|国产视频一二国产在线v|av女主播在线观看|五月激情影音先锋|亚洲一区天堂av

  • 手機站
  • 小程序

    汽車測試網(wǎng)

  • 公眾號

    • 汽車測試網(wǎng)

    • 在線課堂

    • 電車測試

功能安全系統(tǒng)需求的良好實踐

2021-12-17 20:49:02·  來源：薄說安全  
　
需求性文件對于產(chǎn)品開發(fā)的重要性不用多說，研發(fā)中的許多問題都是由于不完整的、不成熟的、不正確的、模糊有歧義的、糟糕的系統(tǒng)需求而引發(fā)的。對于功能安全領(lǐng)域，
需求性文件對于產(chǎn)品開發(fā)的重要性不用多說，研發(fā)中的許多問題都是由于不完整的、不成熟的、不正確的、模糊有歧義的、糟糕的系統(tǒng)需求而引發(fā)的。對于功能安全領(lǐng)域，如何開發(fā)出安全、可靠的產(chǎn)品，良好的系統(tǒng)需求性文件是關(guān)鍵的一個環(huán)節(jié)，筆者將結(jié)合功能安全標準以及實踐經(jīng)驗，來講講如何寫好功能安全產(chǎn)品系統(tǒng)需求的一些良好實踐方法。
需求的結(jié)構(gòu)化
系統(tǒng)需求應(yīng)采用結(jié)構(gòu)化的方法，根據(jù)需求類型進行分類，逐級細化，拆分到最簡單直觀的層次，常見的結(jié)構(gòu)化分類方式包括：
  1. 系統(tǒng)應(yīng)用場景及任務(wù)概要；
  2. 輸入文件；
  3. 參考標準；
  4. 功能需求（包括安全功能及對應(yīng)的安全目標，和非安全功能）；
  5. 性能需求；
  6. 接口需求；
  7. 環(huán)境適應(yīng)性需求；
  8. 可信性需求（可靠性、可用性、可維護性、維修保障）；
  9. 系統(tǒng)約束和假設(shè)；
  10. 其它。
其中1，2，3，9，10為系統(tǒng)需求的描述性內(nèi)容（information），為4，5，6，7，8提供支撐，而4，5，6，7，8則為系統(tǒng)需求的正式內(nèi)容（specification）。
需求的基本屬性
EN50126、DO-178C、ISO26262都有對需求屬性的基本要求，包括：
完整性（complete）：每個需求項應(yīng)包括對應(yīng)此項的全部必要信息，不需要進一步擴展；
正確性（precise）：需求描述的內(nèi)容如功能定義、性能要求等是正確的；
無歧義（unambiguous）：不能模棱兩可，需求只能有一個解釋，設(shè)計實現(xiàn)者可以無歧義地理解；
可驗證（verifiable）：需求是可驗證的，通過評審、分析或測試的驗證方法，以確定需求被正確的實現(xiàn)，對于可測性需求能夠?qū)φ招枨笸瓿蓽y試用例；
可追蹤（traceable）：需求的可追蹤性以便其可以追蹤到更底層的需求，縱向追蹤如軟件到代碼級，硬件到板級，橫向追蹤如需求與測試用例之間的對應(yīng)關(guān)系；
可維護（maintainable）：需求條目的修改、刪除、增加是清晰可見的，項目內(nèi)部對于需求的更新有著一致的認識。
為什么需求有著以上的屬性，有些人認為我是這么想的，寫這么復雜干什么。系統(tǒng)需求在產(chǎn)品開發(fā)生命周期中作為頂層文件，不同的參與方都將利用系統(tǒng)需求開展開發(fā)、安全分析、驗證確認等工作，因此需求必須明確、清晰、簡潔，以易于理解。
下面舉一些示例來說明下什么是良好的需求。
良好需求的示例
1.系統(tǒng)功能需求
系統(tǒng)功能應(yīng)逐級分解，以致到最低層不可再分解的條目。如圖，以制動系統(tǒng)的緊急制動功能為例，從頂層功能向下分解，包括EB1（制動指令獲取）、EB2（制動指令傳遞）、EB3（列車載荷計算）、EB4（緊急制動力計算）、EB5（部分制動力喪失后再分配）、……。每個子功能再按照輸入-處理-輸出的邏輯關(guān)系進行描述。


系統(tǒng)需求結(jié)構(gòu)化示例
2.安全相關(guān)功能需求
對于安全相關(guān)功能，不僅應(yīng)標記出從風險分析分配的安全目標（SIL等級），而且在需求的通用屬性要求外，還應(yīng)規(guī)定：
  • 安全側(cè)（safe state）定義；
  • 定義從故障發(fā)生、系統(tǒng)檢測到故障到進入到安全側(cè)的最大允許時間，軌道交通叫做SDT（safe down time），汽車叫做FTTI（fault tolerant time inteval）


FTTI時間指標定義
  • 故障診斷安全措施，常見的故障診斷措施如
  • 輸入數(shù)據(jù)的非預期性，是否超限、數(shù)據(jù)凍結(jié)不更新、短路、開路等；
  • 通信鏈路的七類典型失效模式及防護措施；
  • 冗余數(shù)據(jù)的比較，輸入數(shù)據(jù)、輸出指令的比較；
  • CPU、內(nèi)存中內(nèi)部錯誤，各類自檢機制。
采用哪些故障診斷措施，依賴于系統(tǒng)的危害分析以及選定的安全完整性等級。
安全功能的目標在于防范風險，系統(tǒng)完整性在于系統(tǒng)的健壯性，因此更多考量的是各種故障場景下，系統(tǒng)是否有監(jiān)控、差異化的故障診斷和響應(yīng)機制，保障系統(tǒng)發(fā)生導向危險失效后能夠在規(guī)定的時間內(nèi)導向安全側(cè)。因此對于安全功能要求，以上三點要求缺一不可。
3.可信性需求
軌道交通常稱為RAM需求，包括可靠性、可用性、可維護性和維修保障，常用MTBF、MTTR、可用性A等定量指標進行規(guī)定，但在規(guī)定定量指標前，確定系統(tǒng)的下述屬性非常重要：
  • 系統(tǒng)的應(yīng)用場景和任務(wù)概要——以確定可信性指標對應(yīng)的系統(tǒng)是在何種應(yīng)用場景下，執(zhí)行哪些任務(wù)；
  • 系統(tǒng)失效判據(jù)——根據(jù)系統(tǒng)失效的影響范圍，可以將指標進行有區(qū)分度的定義，比如影響列車安全的故障、影響列車服務(wù)的故障、未對服務(wù)質(zhì)量產(chǎn)生影響但需要維修保障的故障，對應(yīng)的可信性指標是不同的；
  • 系統(tǒng)的工作條件和環(huán)境條件；
  • 用于驗證指標符合預期的方法。
4.性能需求
可以劃分為時間性需求和空間性需求，時間性需求有系統(tǒng)運行周期、響應(yīng)延時、上電啟動時間、重啟時間等；
空間性需求有內(nèi)存容量、處理器容量、通信緩存容量、帶寬容量，考慮未來的可擴展性和靈活性。
5.文字和圖形化的結(jié)合
采用圖文結(jié)合的方法用于需求編寫，如
系統(tǒng)接口圖——用于描述系統(tǒng)內(nèi)外部接口，并在接口需求再詳細描述接口規(guī)格；
狀態(tài)轉(zhuǎn)移圖——用于描述系統(tǒng)不同模式之間的轉(zhuǎn)換關(guān)系，每個狀態(tài)用文字描述；
數(shù)據(jù)流圖——用于描述不同系統(tǒng)之間的數(shù)據(jù)流和時序關(guān)系。
但應(yīng)注意圖形并不能完全替代文字，而是作為文字的輔助，幫助閱讀者的理解。
其它還有一些通用性的需求，如可測試性、可制造性等，不再贅述。另外，現(xiàn)代安全關(guān)鍵系統(tǒng)的需求編寫，還常采用形式化/半形式化、基于模型的設(shè)計方法，下面講講這些方面。
首先應(yīng)該了解需求的一些特性要求，需求的要求分為單個需求項要求和一組需求的整體要求。
單個需求項應(yīng)符合以下要求：
  • 單一的：一條需求是一個明確的，不可分割的元素，它表達的是唯一的一個要求；
  • 簡潔的：一條需求必須以單個句子的形式來寫，長度不要超過兩到三行，大段的文字需要斷句分開；
  • 清晰的：句子結(jié)構(gòu)簡單，不拖泥帶水，沒有額外的修飾，閱讀者可以完全理解需求；
  • 精確的：需求中使用的所有元素都是可識別的，并有充分的特征；
  • 抽象的：一條需求只是描述需求，不應(yīng)該是一個具體的技術(shù)實現(xiàn)方案；
  • 無二義性的：對該需求的解讀應(yīng)有助于對該需求的理解，并只有一種可能的解釋，要用簡潔的語言表達，不要用太復雜的句子；
  • 可驗證的：必須有一種可行的驗證需求的方法，常用的方法有走讀、建模、分析、測試；
  • 可實現(xiàn)的：從成本和進度上考慮，需求是可實現(xiàn)的。
由單個需求項構(gòu)成的一組需求，應(yīng)符合以下要求：
  • 完整的：沒有遺漏的需求，需求集的內(nèi)容是完整的。完整性比較難以判斷，它與需求分析的詳盡程度有關(guān)。在項目中的需求編寫過程，容易忘記定義軟件需求在不希望發(fā)生的事件中的行為（比如硬件故障，用戶輸入的數(shù)據(jù)錯誤等等）。在確定需求的過程中，有必要檢查這些需求是否包括在內(nèi)，不要讓軟件實現(xiàn)人員去考慮這些問題；
  • 一致的：需求之間不能有不一致的地方，并在文件中有唯一的標識，需求中使用的專用詞匯在每條需求中的表達要一致；
  • 非冗余的：在一組要求中，相同的信息和需求不應(yīng)多次出現(xiàn)，只表達一次；
  • 充分的：需求的內(nèi)容是充分的，不需要為了理解需求，去回顧需求之外的其它文件；
  • 結(jié)構(gòu)化的：需求集有清晰的結(jié)構(gòu)，如軟件需求按照類別分為功能、接口、性能、硬件約束、安全性、可維護性、可靠性、可用性、可移植性、健壯性等；
  • 模塊化的：同一類型的需求應(yīng)放在一個明確的結(jié)構(gòu)內(nèi)進行分組；
  • 可擴展的：有靈活的結(jié)構(gòu)，適應(yīng)需求的變更；
  • 可追溯的：需求與其它項目文件（上下層集）建立追溯關(guān)系。
每條需求除了它的內(nèi)容外，還具備以下這些屬性：
屬性
描述
ID
需求的唯一標識符
類型
功能、接口、RAM、性能、……
TEXT
需求的內(nèi)容
SOURCE
需求的來源
STATE
開發(fā)中、掛起、已實現(xiàn)、已測試、……
PRIORITY
Key, mandatory, optional, desirable
Verifiable
是/否
type of Verification
走讀、分析、建模、測試
Testable
是/否
Version
版本
在了解以上需求的要求和各類屬性后，如何編寫需求以符合以上的要求。需求表達可以采用自然語言和模型語言兩種方法或它們的組合，現(xiàn)在有一種認識，認為模型語言要比自然語言更高級，但是模型的建立并不能替代自然語言表達的需求，如果需求編寫者用自然語言表達出來的需求是模棱兩可的，那也不能奢望他用模型語言能夠表達清楚。
從實踐來說，推薦兩種方法相結(jié)合，在高層次的需求，用自然語言表達更恰當，可以結(jié)合一些半形式化方法（公式、圖形、表格、流程圖、時序圖或其它UML和SysML）作為補充；
在低層次的需求，定義了精確的硬件和軟件行為，采用形式化或半形式化方法更合適，但也沒有必要每條需求都用。


EN50128 軟件需求推薦的技術(shù)方法


ISO26262 安全需求推薦的技術(shù)方法
自然語言（文本語言）作為需求表達的基本方法，人們在日常表達經(jīng)常存在歧義，在需求管理中，經(jīng)常會舉下面這個例子。


以上這個例子雖然有些夸張，但實際項目中不同的人由于知識背景、社會背景和經(jīng)驗?zāi)芰Φ牟顒e，對同一需求的理解確實千差萬別，需求和設(shè)計實現(xiàn)出現(xiàn)這么大的差異也就不足為怪了。
在需求的表達上有基本的規(guī)則可以遵循，建立一個需求模板是很有必要的，使得需求簡單且易于理解，減少自然語言對語義表達的影響。
在Klaus Pohl. Chris Rupp的《Requirements Engineering Fundamentals》一書中，推薦了一類描述功能需求的自然語言模板如下：


在這個模板框架中，采用"主語+動詞+賓語+補語 "的結(jié)構(gòu)，要求的強烈程度分為SHALL/SHOULD/WILL/MAY，需求的過程表達了三種行為：
  • 系統(tǒng)自動執(zhí)行該過程；
THE SYSTEM SHALL/SHOULD/WILL/MAY <process verb>
  • 系統(tǒng)提供該過程作為給用戶的服務(wù)；
THE SYSTEM SHALL/SHOULD/WILL/MAY provide <whom?> with the ability to<process verb>
  • 系統(tǒng)根據(jù)另一個系統(tǒng)的輸入執(zhí)行流程，系統(tǒng)等待外部觸發(fā)事件執(zhí)行；
THE SYSTEM SHALL/SHOULD/WILL/MAY be able to <process verb>
最后additional details中，用于確定系統(tǒng)在什么條件下執(zhí)行該流程，常見的條件有邏輯條件和時間條件。
第二個減少需求理解的沖突和誤解的方法是，盡早地建立一份項目組共享的術(shù)語、縮寫和縮略語清單，它包括：
  • 與系統(tǒng)特定相關(guān)的技術(shù)類術(shù)語；
  • 縮寫和首字母縮略詞；
  • 日常語義在給定的場景中特殊含義；
  • 具有相同含義的不同詞；
  • 具有不同含義的相同詞。
通過定義術(shù)語列表，可以大大提高需求的可理解性，從一開始就避免對可能導致沖突的術(shù)語的誤解和不同的解釋。

以上是對需求的要求、屬性和編寫規(guī)則的一些方法，良好的需求文本對于項目組的每一個成員而言，能夠使項目的目標更明確可達，提高協(xié)作的工作效率，對于有外部審核要求的項目，簡潔清晰的需求對于外方審核也會減少不必要的溝通成本。對需求編寫者個人來說，寫出一份賞心悅目的需求文檔，如同做出一道色香味俱全的美味佳肴，工作的心情自然舒暢。
參考文件：
EN50126-1 2017 Railway Applications - The Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS) Part 1: Generic RAMS Process
EN50129 2018 Railway applications – Communication, signalling and processing systems – Safety related electronic systems for signalling
ISO26262-4 2011 Road vehicles - Functional safety -Part 4: Product development at the system level
分享到：
 
反對 0 舉報 0 收藏 0 評論 0
滬ICP備11026917號-25