隨著國內(nèi)外汽車電子架構(gòu)日益復(fù)雜，面向服務(wù)的架構(gòu)（Service-Oriented Architecture，SOA）設(shè)計理念逐漸從IT行業(yè)走進了汽車人的視野，近年來國內(nèi)外的各OEM開始逐步推進基于SOA的整車架構(gòu)。在此推進與演化過程中，S2S（Services To Signal）作為面向信號和面向服務(wù)的系統(tǒng)之間的交互橋梁也逐漸成為了非常基礎(chǔ)和重要的功能。

最近，北匯信息在CSDN、視頻號、B站以及百家號賬戶上同步進行了一次直播（回放視頻已上線），一起探討S2S的功能和針對S2S的測試解決方案。鑒于直播的時間關(guān)系，有些問題沒能展開回復(fù)，此次發(fā)布文字版的問答精選，以饗讀者。

1. 延時的一般要求是多少？

這類的延時要求取決于各OEM的需求中對于延時的要求，與信號路由類似，此外還和總線類型有關(guān)，CAN、LIN、FlexRay由于通信機制存在差異，延時要求各不相同。一般是幾毫秒或10多毫秒這個量級。

2. 功能邏輯是基于信號還是基于Serviceinstance？

這兩種都存在。

3. 對于多個源端的情況（信號或者參數(shù)來自不同，DUT不能同時收到所有的源端信息），我們?nèi)绾闻渲胻ransmission triggers，是否每個源端都需要配置？

每個信號都可以將transmission triggers配置成true或者false。若配置成true，則在源端收到時就會在目標(biāo)端觸發(fā)發(fā)送，反之則不會觸發(fā)目標(biāo)端的發(fā)送。

4. E2E不正確時，S2S的轉(zhuǎn)發(fā)具體是什么行為？

對于Service轉(zhuǎn)Signal，若Service端的E2E不正確，那么改變Service端的參數(shù)值，對應(yīng)Signal端的信號值不會跟著Service端改變，而是維持Lastvalue。Signal轉(zhuǎn)Service端同理，若Signal端的E2E不正確，服務(wù)端的服務(wù)參數(shù)同樣不會隨信號變化。此外，E2E不正確時在另一端（目標(biāo)端）可以反饋E2E錯誤（目標(biāo)端信號或者服務(wù)參數(shù)指示源端E2E錯誤）。

5. TLS是否可以用CAPL實現(xiàn)？

TLS的仿真和測試工程都可以使用CANoe CAPL腳本編程開發(fā)實現(xiàn)。

6. 域控的外圍I/O資源的服務(wù)化測試和S2S測試有何區(qū)別？

域控外圍I/O資源的服務(wù)化測試，主要特點為：源端的信息來自于I/O資源（比如傳感器的硬線信號），測試服務(wù)中的所承載的參數(shù)或數(shù)據(jù)，是否和I/O資源所要表征的狀態(tài)一致（如開關(guān)的斷開和閉合時對應(yīng)的服務(wù)參數(shù)，是否分別與開關(guān)當(dāng)前狀態(tài)一致），此類測試屬于功能測試的范圍，比如原子服務(wù)/設(shè)備抽象服務(wù)的功能測試。S2S和上述基于域控外圍I/O資源的服務(wù)化測試的區(qū)別是，S2S的源端信息來自于Service和Signal，這里的Service和Signal來源于以太網(wǎng)或者其他總線，而非域控本身的I/O資源。

7. 北匯信息提供的解決方案是用工具生成CANoe工程嗎？

CANoe工程的各類文件（如.cfg、.tes）都是有特定格式的文本文件，從技術(shù)角度生成CANoe工程是可行的。目前北匯已經(jīng)完成的S2S測試，暫時沒有采用生成整個CANoe工程的方案。目前的方案是依據(jù)測試規(guī)范，通過CAPL及其它編程語言完成標(biāo)準(zhǔn)測試工程開發(fā)，而是通過定制開發(fā)的工具來解析S2S轉(zhuǎn)發(fā)關(guān)系表，提取標(biāo)準(zhǔn)測試工程運行所需要的參數(shù)，從而完成測試工程的自動化配置。此方案可以減少由于S2S轉(zhuǎn)發(fā)表變化而導(dǎo)致需要重新手動配置CANoe測試工程的工作量。

8. 用于測試開發(fā)的輸入文件應(yīng)該包含哪些信息？

主要包括如下三類輸入信息：

1）S2S需求規(guī)范；

2）Service、Signal、E2E相關(guān)的信息（ARXML中包含，或者提供同樣包含相關(guān)信息的其它類型的數(shù)據(jù)庫文件）

3）S2S轉(zhuǎn)發(fā)關(guān)系表

4）其他輸入（需求規(guī)范中涉及的如SecOC等需求對應(yīng)的輸入物）

9. 基于服務(wù)的通信除了AUTOSAR的AP外還有其他的類型（如ROS2），這種AUTOSAR架構(gòu)以外的S2S實現(xiàn)能否大致介紹下嗎？

基于服務(wù)的通信用AUTOSAR的AP以外的方式實現(xiàn)（如ROS2或其他），這類的S2S的實現(xiàn)方式和基于AP的實現(xiàn)方案比較類似。同時直播中提到的轉(zhuǎn)發(fā)過程存在邏輯轉(zhuǎn)換的S2S轉(zhuǎn)發(fā)大多都是基于此類方案。

10. 可以基于ARXML文件替換轉(zhuǎn)發(fā)關(guān)系表，實現(xiàn)測試嗎？

我們知道ARXML中可以包含service和signal的相關(guān)信息，以及E2E相關(guān)信息，若ARXML中定義了且完整體現(xiàn)了S2S轉(zhuǎn)發(fā)關(guān)系信息，則也可以通過解析ARXML（替換轉(zhuǎn)發(fā)關(guān)系表）的方式來實現(xiàn)S2S的測試。當(dāng)前我們所遇到的情況，S2S轉(zhuǎn)發(fā)關(guān)系表大都只是單獨的文件來體現(xiàn)，而service、signal和E2E信息在ARXML中體現(xiàn)。

11. 直播中提到的S2S有兩種部署方案，一個是在CP，一個是在AP，這兩種應(yīng)該怎么選？

直播中提到的兩種部署方案是基于AUTOSAR提供的兩種方案，實際上S2S的實現(xiàn)方案還有這兩種方案以外的方案。具體需要根據(jù)整車E/E架構(gòu)和控制器的軟件架構(gòu)去綜合評估選用哪種方案，這兩種方案并沒有優(yōu)劣之分，適用的情況和場景不同，但基于AP的方案靈活性要高一些。下圖體現(xiàn)的是CP上部署S2S時的架構(gòu)。

12. 服務(wù)測試和信號測試是否采用同一種測試方案？

S2S中信號轉(zhuǎn)服務(wù)的測試和服務(wù)轉(zhuǎn)信號的測試是有所不同的。首先從仿真來說前者仿真信號，后者仿真服務(wù)；其次我們對信號的監(jiān)控和采集與對服務(wù)的監(jiān)控和采集方法也是不同的，信號發(fā)送類型大致有周期型、事件型、事件周期型，服務(wù)接口類型有Event、Method、Field，針對不同的信號發(fā)送類型和服務(wù)接口類型，測試邏輯也會存在差異，不過總體框架都是在源端仿真，在目標(biāo)端監(jiān)控。

13. SOME/IP有類似CAN的那種DBC嗎？

目前SOME/IP主要的數(shù)據(jù)庫格式是XML或者ARXML的，我們可以通過CANoe導(dǎo)入XML或ARXML文件來進行SOME/IP的service的仿真。

14. 若服務(wù)端采用DDS方案，當(dāng)前北匯信息的仿真方案是什么樣的？

從22年第四季度新發(fā)布的CANoe16.0 SP3開始，CANoe支持相對通用的DDS的仿真，在這之前，我們使用開源或者DDS 廠商提供的庫，如 pydds，RTI Connector 等，來快速搭建 DDS應(yīng)用程序，并在CANoe 中編寫接口來控制仿真節(jié)點，詳情可以參考我們往期直播中DDS相關(guān)的內(nèi)容。目前來看，由于對DDS標(biāo)準(zhǔn)理解及實現(xiàn)存在差異，所以DDS仿真往往需要分析所選擇DDS協(xié)議棧的特點，進行一定的定制或適配的工作。