在引入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系统上。
阅读原文，关注作者知乎
