首先来看一下服务，我相信在座的很多工程师有时候拿dbc去收发一些信号，那什么是服务？服务的载体是什么？包括我们有通讯，那通过什么方式去实现通讯的应用呢？站在OEM的角度我们会去定义各种各样的服务，如孟总上午提到对每个传感器和信号都进行IP化，进行相应的编码，根据我们的应有去做相应的调用。我们能够让我们车里面对应的功能进行相应的升级，去满足我们相应的应用，SOA确保了我们车与外面互联部分能够衔接起来。同时我们也看到了沃尔沃讲到的有高性能的中央控制结点的出现。

在这张图中可以看到我们服务有提供服务的服务方和使用者，比较有趣的是我们的服务可以放在后台的，这是非常有趣的应用场景，我们在云端去实现相应的控制应用，但是这个里面我们去谈SOA和开发的时候，非常致命的一个点就是Security，涉及所有的开发验证工具链体系，每个OEM用的Security都是不一样的，这对于供应商来说是非常严重的挑战，OEM相对来说比较容易一点，因为他们是固定的一套体系，但是我们今天不会展开探讨Security这个话题，我们再回到SOA主线本身上。

我们传统所有这些车辆的设计，我们基本上都在设计的时候会定义数据库，由哪一个ECU发布哪些信号都是固定的，在执行的时候会按照预期设定的方式进行相应的运行，我们在设计的时候系统之间都是静态的通讯，开发通常通过C语言进行开发，在这个图中有相应的通讯应用，但是当我们出现了服务应用的时候，服务还是应用在我们的软件组建或者是ECU中的，我们在设计的时候是设计了一部分，但是在执行的时候其他部分也会占到相应的资源去做运算，而我们在执行的时候才会有对应的功能出现，所以整个是动态的方式去做处理，这个时候我们会通过C++去做这个事情，通常采用Adaptive AUTOSAR实现基于服务的通信，当然经典AUTOSAR平台也支持基于服务的通信。

这是一个简单的对比，相对来说最重要的一点，我们service-oriented这边是动态的，这边更多是在动态执行去做相应的实现，所以这边我们来看一下服务到底是怎么做这个事情的，什么是service？我们对应的不同软件组建或者ECU彼此之间相通讯我们提供的服务，服务有服务相应的接口和方法在里面，因为在座很多是工程师所以我们讲技术的东西会多一点。

然后我们会把定义的service跟具体的ECU去实现服务部署的应用，我们设计的服务非常灵活的根据我们的架构设计和应用部署的对应平台上，去实现服务之间彼此通讯的应用。所有这一切在序列化和反序列化来实现与底层通信，我们对应的是一种中间件的协议，但是跟后台对应的时候我们慢慢看到有一系列相应的协议，这些都是中间件协议，我们需要把这个服务通过中间件协议进行序列化和反序列化的应用，才能让服务在总线上进行相应的传递。我们再补充说明一点，并不是所有的服务都是通过以太网的，因为有些应用我们仍然考虑传统的系统，SOA的需求是：传输速率足够快、数据端有效数据大、支持动态通信。CAN FD这边是可以基于AUTOSAR 4.2中定义的动态PDU，所以动态PDU也是可以实现服务通讯的，而且已有供应商有样件证明可行。以及行业在做相应CAN下一代的总线技术CAN XL也支持基于服务通信，这是明年或者后年会发布的新的技术。也就是说车不可能所有的都用以太网，成本太贵肯定会用混合总线体系在车里面。但是我们的大基调是做服务，传统的部分也需要去做服务去满足我们的应用层面的需求。

我们会通过中间件实现具体服务的承载，我们会在这个里面去定义我们的service定义，我们也会去定义我们的软件和硬件，我们会把service部署到对应的硬件上以及配置我们相对硬件信号路由等等，包括以太网的IP去实现服务的承载。这边是我们要去根据实际车辆情况去把这样的一个服务文件设计出来，去用作我们后面的开发工作，所以这里会导出对应的格式文件去满足我们的应用。

另外我们这个里面要去定义相应的服务，并且也要把服务实力化，比如说服务接口、部署，包括一些状态机的设计，这些在不同层面都是有相应的文件导出，满足于我们后面服务的部署和设计实现。这是我们说的服务是可以去做定义实现的，维克多是一家工具供应商，我们提供PREEVision工具支持Adaptive数据库和以太网数据库的定义，当然也兼容传统总线的数据库定义。当正向开发做好数据库是满足我们在功能仿真、开发实现和测试验证服务功能的基本条件。