MISRA C++和AUTOSAR C++的合并：軟件開發(fā)行業(yè)專家的圓桌討論

---

汽車工業(yè)軟件可靠性協(xié)會（MISRA）宣布了MISRA C++和AUTOSAR C++的未來合并，這兩種領先的安全性至關重要的C++編碼標準。這對標準用戶意味著什么，這將對組織實現(xiàn)合規(guī)性產(chǎn)生什么影響？

我們在Parasoft召集了一組行業(yè)專家，以圓桌會議的形式討論了MISRA C++的未來以及該新的合并標準帶來的預期影響和收益。

參加者是：

• Andrey Madan，Parasoft首席解決方案架構(gòu)師
• Piotr Pepek，Parasoft C/C++test的軟件開發(fā)經(jīng)理
• Michal Rozenau，Parasoft的項目主管軟件工程師，MISRA C和C++ WG成員
• Miroslaw Zielinski，Parasoft C/C++test產(chǎn)品經(jīng)理

圓桌討論

如今如何使用MISRA C++和AUTOSAR C++標準，以及您在汽車行業(yè)遇到的一些普遍問題是什么？

Mirek：盡管這兩個標準都起源于汽車，但我們經(jīng)常看到它們不僅用于汽車ISO 26262，而且還用于IEC 61508（工業(yè)自動化標準）、醫(yī)療設備和IEC62304。因此，當我們談論MISRA和AUTOSAR時，它不僅適用于汽車行業(yè)。

就問題而言，根據(jù)我與多個行業(yè)的不同客戶合作的經(jīng)驗，我想說，遵守編碼標準最困難的部分是：

• 在團隊的靜態(tài)分析工具中設置標準
• 第一次分析后的初始階段
• 處理大量違規(guī)

 成功肯定取決于將標準引入組織的方式，建立合規(guī)性流程對于成功采用任何功能安全標準（包括這兩個標準）至關重要。

Andrey：我絕對同意。對于MISRA C++和AUTOSAR C++規(guī)則使用靜態(tài)分析，我們看到的一個常見問題是報告的違規(guī)數(shù)量。如果打開所有規(guī)則，則將有很多違規(guī)行為，而且我的意思是很多，尤其是對于遺留代碼庫而言。

 因此，現(xiàn)在，我認為大多數(shù)客戶正在采用的方法試圖找到中間立場。并非所有規(guī)則都是強制性或必需的。因此，他們需要制定一個良好的流程。例如，他們運行一些檢查器，并對代碼進行一些分析，找出適用于其開發(fā)和記錄該子集的規(guī)則的子集。他們知道他們不需要遵守所有規(guī)則，他們只需要有理由說明為什么不使用該規(guī)則，將其記錄下來就可以了。

 一旦了解了流程，他們就進行了分析，甚至積壓了數(shù)千個警告，這些客戶在一些點上可以劃清界線，繼續(xù)積壓問題，以期與他們聯(lián)系并解決這些問題。

Michal：是的。我認為，在此奮斗的另一個原因是，對于那些試圖最終實現(xiàn)與MISRA之類的編碼標準的合規(guī)性的公司，即使他們開始開發(fā)新的代碼，他們也在尋找最終的合規(guī)性。而不是從頭開始。起步較晚是他們可能首先遇到大量違規(guī)行為的最大原因之一。

是什么導致組織無法在實踐中強制執(zhí)行這些編碼標準？

Andrey：許多組織實際上已經(jīng)在使用自己的內(nèi)部編碼標準，該標準已經(jīng)在內(nèi)部開發(fā)并使用了多年。這些公司都有內(nèi)部文件和遵循的政策，它們需要進行現(xiàn)代化以達到MISRA之類的標準，但是公司發(fā)展勢頭很大，需要很長時間進行更改。

這些組織的策略是解決違規(guī)問題，查看自己的編碼標準，然后將Parasoft靜態(tài)分析檢查器映射到他們自己的編碼標準，同時還要檢查需要針對MISRA更新C語言其自身編碼標準并更新其代碼的地方。

對于C++，由于較舊的編碼標準，當前情況實際上更糟。它們不支持新的語言結(jié)構(gòu)（例如自動指針）以及新的現(xiàn)代C++引入表中的其他內(nèi)容，因此該過程更加耗時。

Mirek：我提到我們看到AUTOSAR C++和MISRA C++經(jīng)常被用作功能安全標準（例如ISO 26262和IEC 61508）的合規(guī)過程的一部分。要遵守這些功能安全標準，需要有紀律的開發(fā)過程，其中包括準備文檔。客戶需要一種方式來正式證明他們符合功能安全標準以及編碼標準，這是功能安全符合性過程的一部分。

借助MISRA C++和AUTOSAR C++，Parasoft工具為合規(guī)性過程的這一正式方面提供了專門的支持。我們的報告框架會生成符合MISRA Compliance:2016“實現(xiàn)MISRA編碼準則的遵從性”文檔中定義的要求的特殊文檔。最終變得非常重要。試圖達到標準要求的客戶可以通過使用Parasoft工具來自動執(zhí)行遵從過程的這一部分。

Piotr：從采用和執(zhí)行標準的角度來看，還有一件事是，標準本身也為規(guī)則提供了一些分類機制，這極大地幫助組織引入了標準。例如，對于MISRA C++，準則有不同的類別（強制性、必需和建議性）。AUTOSAR C++集合也是如此，并且還有一些其他分類框架。從最關鍵的類別開始，清理代碼，然后再進一步，該機制還可以用于簡化整個實現(xiàn)過程，并基本上幫助人們分階段進行。

從這些標準開始的組織是否了解分類和優(yōu)先級的重要性？

Andrey：組織并不一定要考慮這一點。作為解決方案架構(gòu)師，我得到的最大要求是：“好吧，Parasoft，我們看到您有成千上萬的規(guī)則，并且我們擁有龐大的代碼庫。幫助我們選擇規(guī)則，以幫助我們發(fā)現(xiàn)真正的錯誤，實際上找到有趣的東西，有價值的東西以及值得修復的東西。”

 在這一點上，我們要退后一步來確定其具體目標是什么。但是，我們經(jīng)常看到客戶開始時的選擇更為廣泛，因為盡管需要遵守編碼標準，但他們沒有時間仔細研究所有規(guī)則并進行分析。這就是分類和一般優(yōu)先級的來源。

我們還可以詢問團隊管理人員，例如，是否遵循所有必需和強制性規(guī)則，他們是否需要強硬方法來遵守法規(guī)。在大多數(shù)情況下，管理層不會劃清界限，而是將決定權(quán)交給工程師，他們的工程師“足夠聰明”以找出需要遵守哪些規(guī)則。期望開發(fā)團隊將記錄他們?yōu)槭裁创蜷_或關閉規(guī)則的理由。

因此，從這個角度來看，我還沒有看到人們實際上在“強制執(zhí)行”。這更多是一種教育方法。例如，當我解釋有必需和強制性規(guī)則時，您可以偏離規(guī)則（但必須按照MISRA 2016合規(guī)性文檔中的說明進行記錄），實際上，這對于很多人來說是大開眼界的人。根據(jù)我的經(jīng)驗，在這個領域中肯定有學習曲線，需要咨詢。

Mirek：我同意。我們不僅在汽車行業(yè)，而且在其他對安全性要求較高的組織中也都迫切需要獲得咨詢服務，以更實際地執(zhí)行該標準并確定實現(xiàn)目標的優(yōu)先級。我們有幾個合作伙伴可以在這個領域為我們的客戶提供服務，但是顯然需要獲得更多的教育和執(zhí)法機會。

您認為整合AUTOSAR C++和MISRA C++準則的動力是什么？是否存在某個標準或其他標準缺少的重要內(nèi)容？

Piotr：合并這些標準的主要原因僅僅是為C++制定一個單一標準。從歷史上看，MISRA C++ 2008是基于C++ 2003的，而MISRA C++已有近10年的歷史。AUTOSAR C++最初以MISRA C++ 2008為基礎，但隨后在頂部添加了許多與現(xiàn)代C++更相關的新規(guī)則，包括C++ 11和C++ 14的功能。因此，集成這兩個標準的主要動力是采取AUTOSAR C++小組所做的工作并將其轉(zhuǎn)換為下一個MISRA C++標準。

MISRA C++是否已將AUTOSAR C++編碼標準替換為標準？

Michal：是的，這是計劃。當前版本的AUTOSAR C++中的注釋將將來的增量參考由MISRA驅(qū)動的編碼指南。因此，正如Piotr所說，我們可以考慮將AUTOSAR C++作為基于MISRA C++的MISRA C++標準的更新版本，并從MISRA中直接提取了許多規(guī)則。其中一些規(guī)則已更新，并且添加了規(guī)則。因此，計劃是采用這些更新的規(guī)則，并將其帶回MISRA C++。

這個新的集成標準將以何種方式幫助用戶？

Mirek：我認為在市場上擁有一種標準非常有價值。我們已經(jīng)與許多不愿意采用合規(guī)性標準的組織進行了交談，因為他們不確定MISRA是否會提供更新，并正在考慮采用AUTOSAR C++。因此，他們推遲了這一決定。因此，合并可以澄清這種情況，明顯的好處是市場上只有一種標準，而且基本上毫無疑問可以走哪條路——新的MISRA C++標準成為合規(guī)性的主要選擇。

MISRA C++和AUTOSAR C++集成會影響現(xiàn)有用戶嗎？

Mirek：肯定會有影響。例如，如果依賴于MISRA C++ 2008的組織要遷移到AUTOSAR C++，則他們必須處理大約200條新規(guī)則（因為在當前的AUTOSAR C++版本18.10中，大約45％的規(guī)則直接繼承自MISRA C++ 2008） ）。

因此，如果組織依賴MISRA C++ 2008，則對他們而言，遷移到AUTOSAR C++是一項巨大的工作。但是，這樣做還有很大的價值，因為MISRA C++ 2008和AUTOSAR C++之間的差異解決了自2003年以來C++語言的變化。因此AUTOSAR C++中包含了C++ 11和C++ 14的所有新穎性。是的，這是有影響的，但是更新到新標準也有很多價值。

Andrey：如果客戶從MISRA C++更改而他們已經(jīng)符合其既定的編碼標準，并且更改了標準（例如AUTOSAR C++），那么所產(chǎn)生的影響有時也會更加后勤。

這些客戶已經(jīng)在內(nèi)部進行了正當化，記錄在案并抑制了警告，甚至有可能通過審核。例如，假設違反了MISRA C++規(guī)則11.5，但已記錄并記錄了偏差。那是壓制的例子，或者在這種情況下是偏差，它需要報告和文書工作。現(xiàn)在，如果我轉(zhuǎn)到AUTOSAR C++，那么來自MISRA C++的規(guī)則可能是相同的規(guī)則，但是工具供應商將其報告為AUTOSAR C++規(guī)則17.6。這是一個不同的名稱，但這是唯一的區(qū)別——僅是標簽。靜態(tài)分析工具將其再次標記為錯誤，并且忽略了抑制。禁止標記有不同的規(guī)則編號，現(xiàn)在它們有大量違規(guī)行為。

那么安全性呢？AUTOSAR C++以及大概新的MISRA C++是否涵蓋安全性？

Mirek：好吧，主要是功能安全標準，但是安全性和安全性是相關的。兩者都是關于創(chuàng)建沒有導致無法預料的行為的構(gòu)造的軟件的，這意味著遵循AUTOSAR C++或MISRA C++進行功能安全的組織通常在安全性方面被很好地涵蓋。安全是為了消除程序的不可預測性，當然，安全性也可以提高安全性。

但是像CERT這樣的安全性準則更為詳盡，并且包含了更多與安全性相關的準則。當前，我們在許多組織（尤其是成熟的汽車組織）中看到的是，他們選擇功能安全標準作為主要來源，然后通過包括來自諸如CERT C++的安全標準的其他選定準則來增強規(guī)則集。

是否有任何動力將更高的安全性納入這些安全關鍵標準中，例如合并諸如CERT C++之類的安全性標準？還是您認為公司會自己繼續(xù)合并規(guī)則集？

Mirek：我個人不會很快將CERT與MISRA或AUTOSAR集成或合并。由于安全性的范圍更廣，而在語言子集方面則不那么嚴格，因此始終需要與安全性標準分開的面向安全性的標準。

因此，例如，在MISRA C++ 2008中，您有一條規(guī)則可以阻止您使用動態(tài)內(nèi)存分配。如果要與MISRA C++ 2008兼容，則不能使用它。但是，對于CERT C++，這是完全可以的。您可以使用動態(tài)內(nèi)存分配，并且有關于如何以安全方式進行分配的規(guī)則。

Piotr：是的，您可以在MISRA網(wǎng)站上找到官方文件，這些文件提供有關MISRA C 2012和CERT C之間映射的信息，例如，這些映射清楚地告訴您所缺少內(nèi)容的區(qū)別。因此，開發(fā)人員可以了解有關在選擇規(guī)則時要從CERT C/C++中包括哪些指南的信息。并且在AUTOSAR C++和CERT C++之間也存在可追溯性映射。我認為所有CERT C++指南中約有50％在AUTOSAR C++本身中也有類似的規(guī)則。

Mirek：另外，我認為采用這些標準在地區(qū)方面。正如我們隨著MISRA的逐步采用所看到的那樣，現(xiàn)在CERT C和C++看到了類似的模式。例如，我們在日本的客戶很快就采用了最新的標準，他們似乎領先于世界其他地區(qū)。我們的日本客戶是第一個比其他地區(qū)至少提前一年要求MISRA C 2012支持的客戶，現(xiàn)在我們看到CERT C和C++的情況類似，日本汽車市場上有更多需要CERT C/C++支持的請求。

AUTOSAR C++是非常動態(tài)的標準，每年發(fā)布兩個版本。頻繁更新對試圖實現(xiàn)合規(guī)性的組織有什么影響？您預見到新的MISRA C++標準會遵守此時間表嗎？

重點：請記住，AUTOSAR C++準則是AUTOSAR自適應平臺的一部分，因此每年的兩個發(fā)行版是整個平臺的發(fā)行周期。如果他們想使C++準則與平臺保持同步，那么可以，這的確需要長期管理。但是不一定每個版本都會改變很多事情。

Mirek：正如我們已經(jīng)討論的那樣，標準的變更存在一些問題。隨著標準的頻繁更改，您會遇到Andrey討論的與物流有關的所有問題。準則更改后，客戶需要更新其合規(guī)性框架，因為他們將面臨所有重新報告的違規(guī)問題，而現(xiàn)在這些問題突然不再受到抑制。這是一個巨大的挑戰(zhàn)，需要花費大量金錢。如果您有50、70或100個開發(fā)人員，并且在開發(fā)過程中已經(jīng)引入了合規(guī)性流程，但是您對產(chǎn)品必須符合最新版本的標準有業(yè)務要求，那么您將面臨挑戰(zhàn)。

如果標準隨著標準的重大變化而迅速發(fā)展，則客戶必須以某種方式解決這一問題。通常這意味著從計劃和預算中抽出額外的時間。這是一個問題，但是正如Piotr所說，我認為從長遠來看，該標準將趨于穩(wěn)定，并且每個版本之間的更改都不會那么重要，例如我們在AUTOSAR C++版本17.32和18.10之間的過渡中已經(jīng)看到的那樣。

在過去的兩年中，C++語言的發(fā)展加速了。AUTOSAR C++當前基于C++ 14。對于MISRA C++相對于C++語言的發(fā)展，有什么期望？

Michal：目前，MISRA C++的下一個版本的計劃是合并AUTOSAR C++ 14，并涵蓋C++ 17（該語言的當前版本）。但是，我不能說它將來會發(fā)展多快，或者這些新版本將如何發(fā)布。就個人而言，我希望會為該語言的每個新版本創(chuàng)建一個新版本的標準，其基本思想是在標準足夠成熟時對其進行更新。這樣可以避免遇到基于C++ 14的AUTOSAR C++的情況，但每年仍需更改兩次。

您預見到MISRA C++標準正在更新與ISO C++委員會發(fā)布該語言之間會有多長時間？

Michal：很難說，因為就AUTOSAR C++而言，標準化是在C++ 14發(fā)行之后開始的。AUTSAR C++的發(fā)布與該語言版本的發(fā)布或該語言的出現(xiàn)無關。

 AUTOSAR C++從一開始就基于C++ 14。當AUTOSAR發(fā)布自適應平臺時，他們發(fā)現(xiàn)沒有涵蓋C++ 14的編碼標準，因此他們決定將該標準基于MISRA C++ 2008，并使用新的規(guī)則和對C++ 14的支持進行更新。

AUTOSAR C++更新是否由Adaptive Platform的發(fā)布時間表而非語言驅(qū)動？

Piotr：是的，我會這樣說。

Mirek：需要指出的是，新合并的MISRA C++標準將在AUTOSAR C++之外進行更新。已經(jīng)宣布將對新的集成標準進行更新，以包括在C++語言的新版本中引入的所有創(chuàng)新，包括C++ 17和C++ 20。對于許多組織而言，這是至關重要的。例如，現(xiàn)代C++功能在使用AI的系統(tǒng)中非常重要，這些系統(tǒng)依賴于最新版本的C++中經(jīng)常開發(fā)的現(xiàn)代體系結(jié)構(gòu)、現(xiàn)代平臺和現(xiàn)代庫。因此，聲明標準將遵循語言的發(fā)展這點非常重要。