2024年7月18-19日，龍智攜汽車軟件開發(fā)及管理解決方案創(chuàng)新亮相2024 ATC汽車軟件與安全技術周。龍智技術支持部負責人&Atlassian認證專家葉燕秀、龍智功能安全高級工程師景玉鑫在活動主會場聯合發(fā)表了精彩演講，分享推動汽車軟件開發(fā)與功能安全的創(chuàng)新實踐。

本期，龍智技術支持部負責人&Atlassian認證專家葉燕秀，將分享如何應對汽車行業(yè)的功能安全挑戰(zhàn)，以及如何借助先進的項目管理平臺Jira，實現精細化需求管理等方面的經驗與見解。

以下為演講實錄（內容有精簡潤色）。

大家好，我是葉燕秀，我與我的同事景玉鑫一同來自上海龍智數碼科技股份有限公司。龍智已深耕DevSecOps領域超過十年，我們與眾多產品生命周期管理解決方案的國際知名公司保持著深度的合作關系，提供從產品規(guī)劃與需求管理、開發(fā)，到測試、部署以及運維全生命周期的解決方案與管理工具。迄今為止，我們已經為包括汽車行業(yè)在內的多個行業(yè)的上千家客戶，提供了專業(yè)的咨詢、實施、培訓、運維以及二次開發(fā)等全方位服務。

功能安全挑戰(zhàn)

首先，我們來探討一下當前汽車行業(yè)所面臨的功能安全挑戰(zhàn)。

為什么要強調功能安全？

隨著汽車信息化，特別是智能化與電動化趨勢的加速，汽車正逐漸從傳統的機械產品轉變?yōu)楦叨入娮踊漠a品。為了滿足并不斷提升用戶對汽車功能和用戶體驗的需求，車輛上安裝的控制器數量日益增多。目前，中高檔車輛上的控制器數量已高達40至50多個，車輛出廠時就配備了數千萬行的代碼，來負責管理發(fā)動機、變速器控制、制動轉向以及各子系統的大量診斷信息。對于有人駕駛的車輛而言，這已是龐大的系統。而針對自動駕駛車輛，其代碼量更是有可能突破數十億行。

汽車電子部件的數量與復雜度的增加，更是會大大提升電子失效的風險，特別是底盤、動力等關鍵部件一旦失效，比如剎車、轉向失靈，都將會造成極其嚴重的后果。

這也是為什么現在僅僅針對汽車的物理部件，來滿足各項標準已經遠遠不夠了。在汽車設計的系統、軟硬件層面，我們同樣需要解決安全問題，確保功能安全，以應對日益復雜的汽車電子化趨勢。

功能安全標準

鑒于汽車對軟件的依賴性日益增加，國際標準化組織（ISO）于2011年發(fā)布了ISO 26262標準，并在2018年發(fā)布了更新版本，來作為汽車行業(yè)系統及設備所有軟件的詳細的行業(yè)指南。

那么，我們?yōu)槭裁葱枰槍ζ囆袠I(yè)制定一份專門的標準呢？

這是由汽車工業(yè)的獨特特點決定的。汽車是大眾消費市場中單價最高的大規(guī)模量產產品，其所有的確認工作都必須在量產之前，即所謂的SOP（Start of Production）之前完成。這意味著汽車的開發(fā)和驗證過程必須做到完整且充分，以確保產品的安全性和可靠性。這一要求與工業(yè)產品以及其他消費類電子產品存在著顯著差異。

因此，針對汽車行業(yè)專門制定一份標準尤為重要。ISO 26262標準的出臺，為汽車行業(yè)提供了明確的指導，幫助汽車制造商在設計和開發(fā)過程中充分考慮功能安全要求，降低電子失效風險，確保汽車產品的安全性和可靠性。

那么如何降低風險呢？

我們需要認識到，風險與安全是相對的概念，我們是無法完全消除風險的，但可以通過一系列措施將其降低至合理的范圍內。在功能安全領域，為了評估風險并確定其合理度，我們引入了“Automotive Safety Integrity Level”（ASIL）這一標準。

在功能安全的概念階段，最重要的工作就是危害分析與風險評估。只有通過深入分析，我們識別出潛在的危險，才能為后續(xù)的功能安全開發(fā)工作奠定基礎。危害分析與風險評估的過程需要結合整車的功能，在不同應用場景下假設失效情況，以評估可能存在的危險。

為了全面評估風險，我們通常會結合整車功能的失效模式、運行場景等因素，構建出可能的危險場景。然后從嚴重度、暴露率和可控性三個維度對風險進行量化評估。其中，嚴重度越高、暴露率越高、可控性越小，意味著風險越高，ASIL等級也會更高，后續(xù)的安全開發(fā)工作也需要更加嚴格。

那么我們如何實現功能安全呢？

下面這張圖總結了功能安全的實現原理。

首先，我們會去識別失效的模式及其潛在影響，然后采取一定的糾正措施以避免失效，最終通過驗證與確認來評估措施的有效性。若效果未達預期，就需要進行多次的完善與迭代?；谶@樣的思路，功能安全標準整理確立了一套完整的功能安全開發(fā)流程，為了保障流程被正確實施，我們同時還需要在管理流程、需求設計和工具層面上輔以支持。

功能安全開發(fā)過程

上圖是對于功能安全開發(fā)過程的整理，涵蓋了需求、設計、驗證與確認三個層面，每個層面在不同的階段均有不同的實施活動。在概念階段，就是從用戶需求出發(fā)，我們產生一個想法，提出一個功能定義，這個通常是整車功能層面的一個應用設計，對于功能安全來說就是定義一個研究對象和功能，進行風險分析，定義安全目標、功能安全概念等。要實現這些想法，就需要工程人員進行產品的開發(fā)，包括系統開發(fā)、軟硬件開發(fā)，以及驗證和測試等。

對于生產維護，主要是實施在開發(fā)階段識別出的可能影響功能安全的特性及保障措施，比如制定生產保障的計劃、流程，提供相應保障的證據等等。

需求管理貫穿功能安全流程

貫穿整個功能安全開發(fā)流程的主線，就是需求。

隨著產品的開發(fā)，需求從概念階段一直傳遞到系統階段和軟硬件階段。概念階段即是安全目標、功能安全需求；系統階段即是技術安全需求；軟件階段即是軟件安全需求；硬件階段也就是硬件安全需求。

功能安全需求是針對安全目標，并結合整車的系統架構所制定的需求。我們所有的開發(fā)工作都是圍繞滿足這些需求展開，最終通過驗證與確認來實現功能安全。

精細化需求管理

對于這樣一個功能安全的過程與流程，我們無法完全依賴傳統的Office辦公軟件或Checklist檢查項清單來進行有效的管理和跟蹤。而是需要更加專業(yè)、靈活的工具平臺，來幫助有效地管理相關需求，例如Jira Software這一數據驅動的產品開發(fā)平臺。

以數據驅動的產品開發(fā)平臺

以往，我們通常將需求記錄在Word文檔中，這些文檔可能包含成百上千條的需求。而“以數據驅動的管理方式”則是將每一條需求、每一個相關聯的測試用例、風險項、缺陷項都獨立拆分出來，作為單獨的條目進行管理。通過這種條目式的管理，我們能夠針對具體需求進行版本控制，跟蹤其變更歷史，并收集針對該條需求的反饋信息。同時，我們還可以通過需求中定義的關鍵屬性（如ASIL等級），來快速過濾和檢索需求，以及生成對應的需求風險分析報告。

有了這樣的工具平臺，我們也無需手動在文檔中維護大量的需求ID，或者追溯上下游的需求鏈接，而是可以更方便地在平臺上實現追溯。在評審效率方面，我們可以專注在少量的迭代式的需求評審，而無需在等待整個需求文檔提交后，才能提供相關的反饋信息。

整個V模型的端到端可追溯性

不管是ASPICE還是ISO 26262，都強調了V模型。

我們可以借助Jira平臺來建立端到端的可追溯性，快速識別系統、子系統及其具體需求，并分析需求如何被拆分為更詳細的規(guī)格：例如用戶需求包含了哪些系統需求？系統需求又拆分為哪些軟硬件需求？相關的架構設計是什么？若需要驗證需求，關聯的測試用例有哪些？測試結果是什么？等等。

當需求發(fā)生變更時，Jira平臺也能方便地進行影響分析，了解識別該項變更對上下游需求和測試的連鎖反應，通過完整的追溯關系來保障我們的產品質量，改進變更管理流程。此外，借助V模型端到端的完整追溯鏈，我們也可以通過追溯報表，快速識別未被覆蓋的需求或設計，及時進行調整和修正。

集成風險管理，簡化合規(guī)流程

同時，我們可以通過Jira平臺集成風險管理，簡化合規(guī)流程。

Jira平臺支持多種風險評估方法。對于前面提到的一些關鍵風險值，比如ASIL等級，它可以根據該項需求的嚴重度、暴露率、可控性等參數，自動進行計算和呈現風險。通過將風險管理集成至統一平臺，我們可以在整個產品開發(fā)過程中，定期執(zhí)行風險分析，并生成對應的分析報表。

將需求與測試用例及其結果鏈接來提高質量

正如我們前面介紹到的，在汽車行業(yè)中，量產前一定要進行完整、充分的功能驗證。通過Jira平臺，我們可以將驗證用例與需求直接關聯，記錄執(zhí)行結果，以確保產品質量。若在測試過程中發(fā)現缺陷，也可以一鍵提交缺陷，并與相關的用例、步驟、需求相關聯，實現缺陷的統一分配、處理和進度跟蹤。

與傳統管理方式不同，通過采用一套專業(yè)的管理平臺Jira，我們能夠實現內部垂直團隊之間的緊密合作，同時加強與客戶及供應鏈的外部協作。這種合作機制有助于我們消除開發(fā)過程中的沖突，確保項目的順利進行。此外，Jira平臺還能幫助我們收集合規(guī)所需的大量細節(jié)，如團隊遵循流程的證據，從而助力順利通過ASPICE評估認證，或滿足ISO 26262提出的功能安全要求。

當前正處于AI時代，Jira管理平臺也集成了多種AI智能化和自動化功能，幫助提升工作效率。借助這一專業(yè)平臺，我們能夠實現精細化的需求管理，通過將重復性、低效的工作交給AI工具處理，而擁有更多的時間專注于創(chuàng)新和優(yōu)化產品。

審核編輯 黃宇