在引入SOA架構之后，汽車軟件工程師不得不面臨的一個問題是，基于以太網的服務（service）的域控制器，區域控制器等，如何能和只有基于信號(signal)工作的ECU相互兼容并工作。
這個問題之前并沒有被AUTOSAR規范所定義，所以也沒有類似于其他BSW模塊的基礎模塊，或者參考解決方案以使用，基本上OEM或者Tier1需要新建一個SWC/APP來做這個轉換，至于是部署在CP端還是AP端，這個不同的團隊都會根據實際硬件性能或者軟件架構進行思考。
在AUTOSAR組織發布20-11版本規范之后，我們可以在AUTOSAR_TPS_System Template文檔的6.16章節閱讀到對于Signal to Service(下稱S2S)的實現參考。當然，這里也只是一個參考，并沒有相應的SWS文檔進行詳細規范定義，所以仍舊需要各供應商或者軟件團隊自己進行實現。
今天，我們一起來解讀一下規范中是如何說明S2S的功能的。
部署在使用了服務的ECU中，各自轉換各自需要的Signal/Service
部署S2S的時候，團隊可以根據實際需求決定是部署在CP或者AP上，同時，也要考慮是否加上E2E或者SecOC的功能。
上圖展示了S2S功能以SWC的方式部署在CP端的形式。
無論是基于信號還是基于服務的通信部分，CP端的COM協議棧都可以提供完整支持，再配合E2E Transformer，SecOC等模塊功能，可以實現功能安全以及信息安全的保護。
S2S可以完成Event，Field的轉換，由于Method只能基于以太網而且Method本身必須做序列化，通信雙方必定能夠互相識別，所以沒有必要再對Method做轉換。
S2S的數據映射需要定義在Arxml文件當中，以SignalServiceTranslationProps表示，例如：
（由于是20-11規范定義的屬性，筆者未找到合適SWC設計軟件以圖形化界面查看，如果有小伙伴知道有哪個工具可以，歡迎留言）
和S2S功能相關的屬性如上圖。
Props就是一組數據映射，所有的Props都在PropsSet下。
而對于SignalServiceTranslationEventProps：
我們先來看一個信號和服務一對一映射的一個簡單示例，R1收到signal以后進行信號服務轉換，然后P1發出。
對于SignalServiceTranslationElementProps:
從S2S的角度來看，它需要能夠控制對應服務的提供和訂閱，大體框架如下圖：
當然，這里涉及到一個問題，S2S在何時可以開始轉換功能呢？
如果有注意到的話，上文已經提到過一個屬性——serviceControl，它對應有三個值，代表了服務可用的時間節點：
ECU啟動時，也可以理解為自啟動，服務實例會自動進行offer，SWC也不需要通過BswM控制服務狀態。
網絡上線（激活）時，也即在網絡可用時，轉換過的服務實例才會提供offer/subscribe的功能。
有的場景下，基于信號的PDU是由SD控制的，所以需要在服務生效時，開啟轉換功能。
當引入了E2E頭部信息或者加密通信特性時，需要先完成對應的封包/解包等，再進行信號服務轉換。
上圖是和E2E相關的示意圖，當safeTranslation設置為True時，這個流程就起效了。
對于加密通信來說，需要設置secureTranslation為True，至于是使用SecOC還是TLS進行底層加解密，就看各團隊自己的需求了。
在AP端，可以將S2S作為一個進程部署，至于具體實現，可以沿用CP的協議棧，部署在對應的POSIX系統上。
閱讀原文，關注作者知乎
