汽车行业正在向集中式的汽车电子电气架构发展，最终的目标要达到软件定义汽车。这也反映了全球消费者对汽车未来的期望在发生变化，汽车的使用在发生变化，OEM的角色、商业模式等等都在发生着变化。如今出现了很多新的名词，如SOA、OTA、HPC、应用商店的功能部署、云服务、云连接等等名词。汽车功能愈像智能手机，但是汽车要比智能手机要复杂很多。因此在系统中开发者要考虑系统安全、实时通信、自动驾驶从故障静默、验证、认证等一系列问题，以及需要考虑到全生命周期的不确定性。
此外，平台还要不断的优化，时需要复用硬件的资源，并且希望能够结合硬件和应用的关系，这样的话应用能够更好的升级、维护，包括应用的算法也会变得更加标准化。从电子电气架构的演进过程，包括对于整个功能的要求，决定着开发者需要一个安全的、整车平台平台。
MotionWise作为安全的整车软件平台，可以看到在OEM的CarOS里面包含了OS的第一级，以及OS的第二级，然后再到OS的第三级。在不同OS的层级上，我们可以看到在第一级的时候，它更多是只需要管理自己本地的或者说单个的芯片，不管是MCU也好还是SOC也好，由这个芯片上的操作系统去负责管理这个芯片以及其外设。
MotionWise是安全的整车软件平台，它这里面主要包含一些核心的能力，一个是Global Scheduling，我们叫作全局的调度。因为每一个操作系统不管是OSEK或者POSIX，它都会提供自己的调度机制，如何基于应用去有效合理的使用这些调度机制，并且让操作系统能够知道如何去正确的对应用程序进行调度，并且如何能完成在不同的MCU和SOC上任务的调度，满足系统的需求，这些都是由平台全局的调度完成的。 第二部分它会提供Time Synchronization，在这样异构的系统里，或者在未来整个的E/E架构里面需要有一个时间同步，时间同步的标准定义了如何来实现这些同步，但是如何使用同步的时间，并且如何有效的保证APP和网络之间的同步，安全有效的运用这些时间，都会在这里面实现。
还有一个功能是Communication Middleware，在单个MCU或者SOC上，它能直接通过IPC的方式就可以实现APP和APP之间的数据交换。但是比如说需要MCU和SOC进行通信，或者说我们的一个域控和另外一个域控进行通信，这个时候就会需要用到一些除了IPC之外的DDS也好，或者TSN也好，保证Communication Middleware的确定性。
还有Safety Supervision和Platform Health Management，这个更多和功能安全相关，如何保证应用，保证任务，保证给每个任务分配和保证时间在运行过程中，在整个ECU或者整个域控制器之间是完整的，安全的，这部分都会通过我们的Safety Supervision和健康管理模块来去完成。
还有一些功能包括System Design，以及资源的管理，当我的硬件还没有完全实现的时候，如何在PC端，如何在虚拟机这一侧做应用程序的开发，保证开发的应用程序能够无缝的移植到环境里面，这个都能在Emulation和RE-Simulation去呈现。
Global Scheduling全局调度
在AD或者在ADAS领域里面的一个典型的场景。可以在系统的需求里面有很多的要求，如何保证任务和任务之间的确定性关系，如何保证把任务合理的分配，分配到不同的核上去。在示意图里面可以看到AD和ADAS域里面我们从前端的感知到融合，以及最后的控制。在这个里面我们有不同的数据类型，在这样的数据类型里面可以看到，在感知的时候更多是基于事件驱动的，或者数据驱动的一些应用，同时在融合和规划以及控制更多是一些基于时间驱动的一些应用。同时在这里面也有一些比如摄像头的数据，这些数据为了演示，或者为了监控，但是这些数据内容不是关键的，这些数据对于整个系统来说，它的丢失不会影响到系统的安全性和可靠性，在这个底下可以看到基于以太网，或者基于PCE传输的场景，在这样的AD或者ADAS的场景下，我们有多个SOC，在SOC上有不同的核。在这个全链路里面又有各种各样不同的应用，从传感器到执行器会有很多不同的计算链路，我们对于这个链路又有不同的要求。从这张图可以看出我们从功能的角度来说，我们希望的是感知完了之后就是融合和规划，最后到控制的单元或者控制应用里面去驱动不管刹车也好，或者油门也好，从功能域的角度更多是这样的方式。
如何把所有的应用要求放到硬件里面，可能有10的5000次方的方案，如果加上一些系统的需求，比如说我会需要加上一些每条计算链有一些端到端延时的要求，每个任务会有自己的周期，每个任务有自己释放的时间，同时考虑抖动，以及任务之间的相互依赖关系，这个时候解决方案只有10的5次方的范围。
在这样系统的配置之下，如何能够去找到在10的5次方的范围内找到符合系统需求的一个整体的调度方式其实是非常难的情况。TTTech Auto能够提供自己的一套工具链，让用户合理有效的构建自己的任务模型，包括计算链的模型，基于这样的内容作为工具的输出，有效合理的找到解决方案，基本上在200秒的情况不同系统的配置下都能够找到解决的方案。
在工具链里面对于系统的定义，包括任务的数量，任务的周期以及有多少核，以及CPU上的资源是什么样的能做为工具链的输入，就可以产生整个应用的调度表。
从任务的角度或者从系统需求的角度能够直接离线规划出来我们的任务在实际的硬件当中为了满足系统需求应该怎么被调度，并且在基于这样任务的需求，或者基于系统的需求我们可以导出来通信部分的调度方式。
在全局的调度方面，因为全局的调度一定会涉及到通信，这个通信会包含IPC，会包含SOC到SOC之间，ECU和ECU之间，包括域和域之间的通信。TTTech Auto在IPC的方向上用的是一个形态，在确定性网络，我们用TSN的时候会有全局性网络的Stack，同时还有DDS，以及基于SOME/IP的通信，最后到传输层，所以MotionWise能够支持市面各种传输的协议栈。今天我会主要介绍一下跟TSN相关的部分，TSN在汽车里面，它被用在不管是域类的通信，包括整车的通信，它的需求越来越明确，TSN的特点相对来说是比较清晰。
在ADAS或者AD场景中提到过会有各种各样类型的APP，在不同的确定方式下，对数据本身来说，比如说我们会周期性的数据，在TSN里面会有TT的数据，同时还会有一些流媒体的数据，以及我们还有诊断的数据，还有无关紧要的一些数据。相当于我们本身的场景里面会有三类不同的数据类型，TTTech Auto现在对于MotionWise而言，其支持TSN的特点，主要包含了，第一是802.1AS，以及802.1的Qbv，同时TTTech Auto现在正在开发的一部分，更多是和系统的可靠性相关，802.1CB以及802.1Qci的这两个跟可靠性相关的协议支持。
TSN的802.1AS，它本身是很重要的，在时间触发的系统里面，有两点是最基本的因素，第一点是需要有一个全局的时钟，系统内的各设备需要有一个统一的时间认知，这部分就是802.1AS，通过它能得到一个全局的时钟。第二部分比较关键的就是，需要有一个调度表。基于全局的时钟，需要有这样一个调动表，这部分更多是Qbv来完成。
当MotionWise和TSN去进行结合，MotionWise能够支持TSN的时候，会看到这样一个场景，使用全局调度，它其实是融合了任务或者应用的调度，以及和网络的调度，把它整合起来。
TTTech Auto提供全栈方案
在之前提到过，我们对于TSN网络本身，除了在MotionWise里面做支持之外，同样还会提供独立的TSN服务，TTTech是全球第一家具有TSN IP的公司，包括SJA1105和1110里面用到的TSN IP就是来自于TTTech。我们也是全球第一家有TSN配置工具的，这个工具现在被集成在MotionWise里面，当然这个工具也是可以单独被采购的。
TTTech Auto的TSN网络配置工具，对用户来说，他不需要配置很多参数，不需要按照流去配置整个门控，用户只需要定义网络有多少个节点，哪些是Talker，哪些是listener，在网络里面有多少个交换机，以及整个网络的拓扑结构是什么样的，同时会定义不同的流，对于流的定义，给到他一些属性，比如它VLAN的ID，VLAN的优先级，它的发送端是哪个，接收端是哪个，同时给流加上具体的网络需求，比如多少延迟，这个端到端更多是网络的情况，所有这些东西都作为输入给到TTTech Auto一个工具，这个工具会直接给产生出来这样一个Qbv调度的门控列表。
