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

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

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

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

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

這兩種都存在。

3. 對于多個源端的情況（信號或者參數來自不同，DUT不能同時收到所有的源端信息），我們如何配置transmission triggers，是否每個源端都需要配置？

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

4. E2E不正確時，S2S的轉發具體是什么行為？

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

5. TLS是否可以用CAPL實現？

TLS的仿真和測試工程都可以使用CANoe CAPL腳本編程開發實現。

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

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

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

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

8. 用于測試開發的輸入文件應該包含哪些信息？

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

1）S2S需求規范；

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

3）S2S轉發關系表

4）其他輸入（需求規范中涉及的如SecOC等需求對應的輸入物）

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

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

10. 可以基于ARXML文件替換轉發關系表，實現測試嗎？

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

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

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

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

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

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

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

14. 若服務端采用DDS方案，當前北匯信息的仿真方案是什么樣的？

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