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

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

1. 延時(shí)的一般要求是多少？

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

2. 功能邏輯是基于信號(hào)還是基于Serviceinstance？

這兩種都存在。

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

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

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

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

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

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

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

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

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

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

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

主要包括如下三類(lèi)輸入信息：

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

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

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

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

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

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

10. 可以基于A(yíng)RXML文件替換轉(zhuǎn)發(fā)關(guān)系表，實(shí)現(xiàn)測(cè)試嗎？

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

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

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

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

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

13. SOME/IP有類(lèi)似CAN的那種DBC嗎？

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

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

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