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

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

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

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

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

這兩種都存在。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基于服務的通信用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ā)關系表，實現(xiàn)測試嗎？

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

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

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

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

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

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

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

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

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