6月4日，“2020首届软件定义汽车云论坛”以网络视频直播的形式顺利召开。本次论坛主要围绕“软件定义汽车”趋势下企业的思考与战略选择展开探讨，为业界搭建一个沟通、学习的平台。下面是普华基础软件股份有限公司张晓先在本次论坛上的发言：
给大家介绍一下，我是普华基础软件股份有限公司张晓先，我今天最主要讲的是软件定义汽车和AUTOSAR之间的关系，这里面也会讲到功能安全的内容。下面我就开始我的报告。
我想，软件定义汽车是一个很大的题目，很多专家、同行朋友已经介绍了有关这些方面的技术和产品。
第一页是汽车发展的历史，我想表达软件定义汽车不是哪一天突然开始的，它是一个过程。如果从最初开始，实际上软件定义汽车很多的内容已经在实践了，甚至已经实践很多年了。
世界上第一辆汽车于1886年面市。134年前，第一辆机械控制的奔驰1号，这是世界上我们所知道的第一辆汽车。它是完全机械控制的，谈不上软件。
这张图把整个汽车发展历史分成四个阶段，可以有很多分法，但是我分成四个阶段，第二个阶段就是70年代，通用汽车第一款采用微处理器的汽车。我认为可能就是软件定义汽车的起点，为什么这么说？因为软件定义汽车，我认为可以有很多的维度去讲这件事情，不是一个定义所能涵盖的，软件定义汽车有一个从局部到范围越来越广的过程，从深度来讲，有一个逐步深入的过程；从模式来讲，也有模式逐步创新的过程。
70年代通用的第一款采用微处理器的汽车，里面采用的微处理器以及对应的软件，去实现汽车上至少一个点的功能，我认为就是软件定义汽车的起点，它所实现的是局部的功能，采用电子信息技术去实现。
接下来我们看到2002年奔驰的e-class基于网络电控系统车型，这个车型跟传统汽车上的电子电气架构有联系。在这个架构上面，不是一个功能，而是有很多功能都是用电控去实现，软件已经在每一个控制器上发挥了很重要的作用，去实现每个控制器上的特定功能。
我认为这是软件汽车的发展，从最初实现单个功能，到实现汽车上普遍的很多的控制功能。
我们看到最新的，可能很多朋友认为软件定义汽车重要的标志，或者说我们认为所谓软件定义汽车应该是这样的，它就是2016年的Waymo，源于谷歌无人驾驶项目，可能更早就已经开始了，但是2016年可以作为标记，Waymo的成立，无人驾驶汽车采用人工智能的技术，去实现汽车的感知决策和控制，完全和以前的电控技术、软件技术是不同的。
关于“软件定义汽车”的定义，我前几天在百度上面看了一下，当然用百度查出来，是百度最先提出来的软件定义汽车，不是由于机械的原因或者是功能上决定一个汽车的状态，而是由于软件定义汽车的状态，特别是人工智能的、AI的软件，这才是软件定义汽车源于百度的解释。
这是有不同的解释和不同的阶段，我认为这都没有关系，软件定义汽车是一个过程，未来是什么样，可能没人知道。我试着做一些预测，或者说我看到一些可能发展的未来，我下面会继续讲。
第二页我还是说一下过去，有一点点未来，但是大部分都是过去。
汽车上面软件实现了控制器上的功能，过程是逐步的从一个单点的功能到车上越来越多的功能，范围的扩大，也从一个单点功能的深入，软件会越来越复杂，这是一个深入，这两个维度都是在不断发展的。
1980年我认为和第一辆采用微控制器的汽车的时间点是有契合的，也就是说一开始软件发动机喷油点火的控制，这是最初汽车电子的功能。
大概到1990年，慢慢扩充到车上的信息系统、舒适系统实现电子控制，进一步发展到车身控制，就是安全，例如防盗的设计，车身的门锁设计。也有被动安全，例如汽车的气囊这样一些系统，都采用了电子技术，这里面很重要的就是软件算法对功能的实现。
在2000年，安全系统又有了一个更新的要求，就是从被动安全向主动安全去发展，主动安全由于我们需要在没有发生事故的情况下去避免事故，这样的需求出来之后，对软件就提出了一些更新的要求，特别是更高端的传感器技术，我要预测路上会有一些什么问题，然后去避免这些问题，在没有发生事故之前，就去防范这些危险，这是一个软件功能的增强。
在2010年，我们会看到有更多的功能引入进来，包括用户体验，这是很多公司提升驾驶员体验方面的电子系统。我认为在中国的汽车市场上面，特别注重这个，包括互联网技术，互联性技术，都会在汽车里面用。这是一个更新的发展，汽车上面的网络越来越重要，网络不仅包括车内网络，也包括车和车之间以及车和路之间，以及车和外界云端互联性。
2020年看到的未来，我们现在已经是现实，所谓高级驾驶辅助系统，在很多车型上面已经出来了，至少在新车型的发展方向上是一个非常非常重要的系统，高级驾驶辅助系统就是说我能够在路上面去做一定的规划，去感知路上的情况，去协助驾驶员，协助车辆主动的或者说自动驾驶，或者说智能驾驶，实现这样的功能。将来会发展到无人驾驶，这是非常重要的技术。
这样的功能出来之后，对软件和电子系统提出了一个更新的要求，主要在什么地方？主要在过去我们所讲的功能，都是在单片机上实现的，不需要太多的计算资源，既使是互联技术，也是一部分相对来说深嵌入实施的系统。
当高级辅助驾驶系统出来，未来到自动驾驶、无人驾驶系统出来之后，对计算平台的要求就会越来越高，计算能力单片机或者NCU是能够满足的要求，不仅对芯片，而且对软件的架构提出更新的要求，这是一个巨大的变化。这是汽车电子的功能在过去若干年以及以后会发生的变化，这里体现的就是软件定义汽车的范围在车上面不断的扩大，以及深度在单个系统里的功能性越来越复杂。
下面再看一张图，这张图反映了汽车电子成本占比的发展趋势，前面是从技术的角度看这个问题，现在从商业的角度看这个问题，在一辆车上面，汽车电子成本占到多少。在1950年，早期汽车电子成本占整辆车的成本是微不足道的，非常小。后来呈现了一个上升的趋势，一直到2010年，我记得普华是在2009年成立的，在那个时候我们看到的数据是一个车上没有到30%的比例，大概在20%多的比例，当然已经是相当高的比例，买一辆车或者一辆车制造出来成本，电子部分所占有的成本已经要占到1/3的数字。到2020年-2030年比例会继续增加，这反映了我前面讲的功能的不断深入，范围的不断扩大，复杂性不断增加，必然导致汽车电子的比例越来越大，这是必然的趋势。
我们再回过头来看技术，从技术看到商业，再看一下技术。这张图已经有朋友用过，这张图是麦肯锡的调研报告，它归纳了很多其他方面的研究，综合这些方面，不是自己提出来的，但是我觉得综合的还是蛮好的。
汽车电子电气架构方面，功能在汽车上的分布，归根到底是这样的定义，在整个历史上面是分成五个阶段，目前可能处在第三个阶段。从大的概念来讲，到目前为止，我们看到很多车辆都是以分布式的电子电气架构为主，所谓分布式就是没有中心的，一辆车上没有中心的，每个功能有每个功能的电控系统，这些电控系统形成一个网络，这个网络是CAN总线的网络，上面会有很多报文传递，这样的结构。
第一阶段、第二阶段、第三阶段无非是这个网络会越来越复杂，综合来说还是一个分布式的结构，会从单个系统变成一些子系统，这些子系统之间的连接，会越来越多，会有一些交叉性的功能互联，这是目前电子电气架构的状态。
大家已经谈了很多电子电气架构，中心化的电子电气架构会出来，每一个域代表不同的功能，一个车上跟动力有关的会有一个域，跟车身舒适型有关的会有一个单独的域，每个域里面的控制器会有一个共同的特点，会对一些传感器的资源有一些共享，实时性要求、安全性要求有一些共性，在每个域上面。这时候有一些公共的软件，我们看到蓝色的部分，就是域控制器上面实现，域控制器可以规划下面具体的控制器的功能分布，这是第四个阶段。
再往下整车会有一个中心的结构，这个结构是计算平台，智能驾驶的大脑，现在还不能确定，有很多方案会往这上面去设计，但是我们知道很可能的一个架构特征就是域会融合，不是截然分开不同的域，而是说每一个域和每一个域之间功能会互相融合，这种结构上，很多资源可以共享，比如传感器，很多控制器可能会共用一个前端的传感器，传感器会把数据先做域处理，处理之后后面控制器里拿到处理过的数据，然后去做功能。
另外一方面，过去讲的域控制器，相互之间可以做融合。第二个是功能可以互为共享，或者说互为冗余等等，这些方面的新设计都可以基于这样的架构出来，我们现在可能看不到新的设计，因为我们的架构限制了我们的眼光，这个架构变化之后，很多新的设计，很多新的思路可以根据这个架构生发出来。这是电子电气架构的发展趋势。软件定义汽车可以在新的架构里面生发出新的思想，有新的功能出来。
我们再看另外一个维度，这个表大家比较熟悉，我们的历史还可以这样来讲，用自动驾驶的分级讲历史。在这个过程中，完全人工驾驶的汽车是L0级的，汽车完全听从人类驾驶者的指令去工作。在这个之后L1级，就是所谓的辅助驾驶，辅助驾驶就是对加减速以及转向其中一项来提供车辆的辅助，驾驶员来负责区域的驾驶动作，这是辅助驾驶概念，比如说我在行驶的时候，可以跟随前面的车辆，自动巡航的功能，在道路上跟随前面的车辆，当你在高速公路上的时候，可以大大减缓驾驶的辛苦。这是L1级的辅助驾驶。
到L2级，我们就可以对多项操作提供辅助，包括方向盘的转向和加减速，多项操作来提供车辆的辅助，典型的就像自动泊车，自动泊车就是一个L2级的典型应用。
L0-L2阶段，行驶的责任，法规要求一旦出事故之后，责任是人类驾驶员，人类驾驶员一定要负责所有的驾驶动作。现在很有争议的一点就是最近大家一直在讨论的L3级，有很多汽车企业说L3级不做，跳过L3级。为什么？L3级在责任上是不清楚的，L3级因为是有条件自动驾驶，就是由车辆完成绝大部分的驾驶操作，人类驾驶员不需要做驾驶操作，但是需要保持注意力集中，以备不时之需。这个讲法就很麻烦，我不确定像特斯拉，在行驶的时候，人类是可以放弃控制的，但是需要随时准备接管，这种情况下一旦出事故的时候，责任到底是车还是人的，这是会有争议。
这是L3级所谓的有条件自动驾驶，当然有一些事故发生，某些车型有条件自动驾驶的情况下，出了事故会造成一些争议，甚至一些诉讼，都会有。
往下就是L4和L5，L4就是车辆完成所有驾驶动作，人类驾驶员无须保持注意力，但是在限定的道路和环境条件下，也就是说路是限定的道路，不是全部的路况，在一个封闭的环境下面，或者说在一个开放的环境下，某个城市或者某一个区域特定的道路状况下面，在这种情况下L4级的高度自动驾驶，责任很清楚，是由车辆来负责，人类不需要接管车辆。
目前很多研究都是围绕着L4级驾驶来进行的。最终级的状态就是L5，在所有场景下，对路况，对范围都没有限制的情况下，由车辆完成所有的驾驶动作，这是一个自动驾驶的分级对历史的阐述。
对于软件定义汽车这样的概念，有各种各样的角度去看，从汽车历史的角度看，可以从汽车电子系统功能的角度看，可以从电子电气架构的角度看，也可以从自动驾驶等级角度去看。我这里有一个我个人的想法，我们怎么去定义它，从各个角度是有不同的定义，但是我认为从软件的角度有一个我的想法。
第一个软件定义汽车我认为到目前为止可以把它分成三个阶段，这三个阶段都可以看到，都不是未来。
第一个阶段，预装系统，在汽车电子的控制器上面去设计软件，去实现特定的功能，传统的汽车出来之后，它的发动机控制系统，变速器控制系统，车身控制系统，主动安全和被动安全系统，我认为是一个预装系统，长久以来当车厂推出一个车型之后，如果这个车型在世界上卖了一千万辆车，一千万辆车都是一模一样的，我们的预装系统确保了上面的软件实现特定的功能，这些软件和这些功能都是固化在这辆汽车上的，不管在哪里买到这辆车，这辆车世界上都是一样的，这就是软件定义汽车第一个阶段，预装系统。
第二个阶段，这些预装系统可以在行驶的过程中，在车主使用的过程中，让它升级、更新、改写，这是第二个阶段。第二个阶段像蔚来汽车或者特斯拉，用OTA把软件版本升级到新的版本上去，不断升级形成新的功能，同样一辆车可能会具备更强大的功能。
第二个阶段的状态下，如果一个车厂一个车型在世界上卖了一千万辆车，可能会有500万辆车，车主没有动力去升级，我不关心，我不需要升级，可能还有300万辆车是升级了一次，变成了2.0，还有200万辆车升级了两次，变成了3.0。这个世界上可能会有同一个车型，会有不同的版本，不同版本的车在不同的软件版本实现不同的功能。
第三个阶段，我认为基于环境的学习、迭代、优化和个性化，特别关键的就是个性化的软件。我们现在是不是有，我觉得应该或许会有一些，就是在驾驶员的个人体验上面，可以做一些初步的个性化。个性化的含义是什么？打个比方。如果我出差到一个外地的城市，我要租一辆车开，我租到一辆不熟悉的车，当我开的时候，车的响应和我的预期是不一样的，我经常会碰到这种情况，有的车敏感性会强一点，有的车敏感性会弱一点，或者说动力会弱一点，这种情况下一开始开会不舒服，慢慢的时间长了，或者一天两天，你会变成驾驶员适应这辆车的特性。
这是一个不太好的选择，就是驾驶员适应不同的车。第三个阶段的软件定义汽车意思是什么？就是说车应该来适应驾驶员，而不是驾驶员去适应车。车应该在行驶的过程中，学到驾驶员的期望，对他的期望，然后不断迭代优化，这辆车可能知道驾驶员开车的时候，是一个比较喜欢开快一点的，响应快一点的，或者说我是一个想开的稳一点的，每个人的想法不一样，车的算法应该是慢慢的去适应驾驶员。在安全的环境下去适应它，变成一辆最适合于驾驶员的车。
在第三个阶段如果实现，我相信世界上如果车厂生产了一千万辆车在世界上，就变成一千万辆完全不一样的车，每辆车跟车主的个性和性格习惯是有匹配的，这是我的想法，三个阶段是软件定义汽车的，我们现在看得到的过程，第一、第二阶段都已经有了，第三个阶段或许有一点点可以看到，但是大批量的我认为还没有，这可能是未来一条路线。
如果做到这样的方向，我认为有一个前提条件，前提条件是什么？就是车上的硬件变成标准化，软件的优化、升级导致车辆功能的变化。跟我们在很多行业里所看到的一样，标准化的硬件加上变化的软件才会实现各种不同的功能，或许汽车行业的朋友会说，标准化的硬件意味着什么？标准化的硬件，比如一个控制器硬件可以去适应很多很多软件的要求，必然要求硬件的资源会更大，更冗余。
标准化的硬件还有一个是什么情况？就是说我们硬件的连接可以有一个更柔性的做法，现在整个车的电子电气架构是固化的，一辆车量产之后，100%是固化的。在未来如果说我们需要做软件定义汽车，标准化的硬件可能会增加一个柔性组合的连接，才可以实现。
所有这些前提条件意味着什么？意味着成本，大家知道成本会增加。成本增加，这是汽车厂不希望的，成本是非常重要的因素。
我觉得解决方法是什么？标准化的硬件，一个硬件适用于不同场景，就硬件本身而言肯定会增加。但是我们想所有的车型都可以共享一些硬件，硬件的量可能也会帮助成本逐步下降，从预算已经看到，硬件在整个车上的成本是在不断下降的，未来可能会继续这样的趋势。所以标准化的硬件不是不可能实现的梦想。
另外，在标准化硬件上面软件要进行迭代和优化，软件有一个必须的要求，就是它必须有高内聚、低耦合的特性，软件不可以是一个黑盒，必须有体系架构，体系架构具备高内聚、低耦合、模块化的特性，同时要有一个很好的方法论，软件在不同的功能、不同的硬件上快速做开发。
这是我对汽车上软件定义汽车方面的想法。它会带来一些挑战，有三个方面的挑战，第一个是架构设计的挑战，我刚才讲到的软件的架构，如果要做成高内聚、低耦合以及可以快速的有效率的开发，这是一个新的架构挑战。第二个功能安全的挑战，本来我这个题目就是讲功能安全的，我可能会讲一点，但是我会把功能安全大部分留在后面另外一个话题去说。功能安全挑战是什么？当我们说软件是可以不断迭代升级优化甚至个性化的时候，软件的验证如何来做，我们在生产之前必须要做验证，必须要确保可靠性，这对传统的功能安全概念会是一种挑战，新的挑战。
信息安全的挑战，信息安全意味着数据是不是得到有效的保护，因为数据会在不同的电子系统里面去共享，甚至会通信，会重复使用，信息安全如何保障，下面对三个方面分别做一个阐述。
第一个方面，架构的挑战。架构的挑战就是我今天题目上讲的软件定义汽车和AUTOSAR的关系。AUTOSAR是这样一种结构，AUTOSAR提供一个标准化的接口和层次化的隔离，有利于应用基础软件、驱动、算法单独的开发，这是一个低耦合达到的效果。它可以大幅提高汽车电子的研发效率和研发质量。下面这个图显示的是过去软件和硬件耦合性非常强，AUTOSAR低耦合区分的内容远远比这个图示意的更多，下面我会在合适的地方讲隔离和效果。
功能安全的挑战会是什么样的？左边这张图是功能安全的标准，就是主流标准IOS 26262，在功能安全里常常听到功能安全等级，右边是方法，我们会把一个系统从三个角度去看，比如要做一个发动机的控制系统，我们看发动机控制系统一旦发生故障严重度是什么，最左边这一类就是第一个维度，严重会导致轻度或者中度的伤害，还会危及生命，还是会造成必然的致命的伤害，发动机控制系统在严重等级上处于哪个位置。
暴露度，故障发生可能性比较低，还是中度，还是高。
可控性，当故障发生的时候，我们能不能有效的控制它，或者说很容易的控制它，还是它是不容易控制的，如果这三个角度，严重度、暴露率和可控性都是非常高，那个时候我们就会把它定义到右下角等级最高的安全等级，SOD等级红色的，SOD等级意味着控制器一旦发生故障，一定会造成人命的伤害，开发的时候一定要用最高的安全等级，最高的强有力的功能安全方法去开发它，避免造成风险。这是功能安全对挑战所提出的解决方法。
当然，软件定义汽车，最近也听到一些讨论，传统的功能安全架构是不是能适应未来软件定义汽车的要求，因为软件定义汽车，软件是一个动态的，而不是固化的，你能不能用同样的功能安全的流程去验证这个软件，这是未来提出来的问题，但是我觉得至少我们现在的ISO26262这个流程对我们解决这个问题提供了很好的借鉴，在现有的系统上非常的有效保证功能安全的手段。
汽车软件的信息安全的挑战，现在的车已经跟外部有非常多的连接了，虽然这些连接还没有到我们想象中那么多，我们现在的连接主要是用于车辆的导航、信息娱乐，一些信息的监控监管，把一些数据上传，还没有到通过互联网技术去影响驾驶的程度，但是已经有非常多的数据在车和车之间，车和车外部的通信。
我们需要有对信息技术保护，进行控制的技术手段，这里主要是一些数据的通信安全机制，我们要有一个完整的车内通信和车外通信安全机制。我们要有一些验证，对数据来源的验证和数据本身认证正确性和时效性。
我们还要对加密解密算法，做一些轻量级以及高效的优化，使它适用于车内的环境。除了具体技术之外，我们需要一个信息安全体系。跟功能安全相比，信息安全体系可能还比较滞后，对功能安全来说，我们很清楚的流程标准ISO26262已经定义了，我们首先要做危险危害分析和风险评估，对这个系统，我们要去设计这个系统的功能安全技术概念，如果是一个系统需求，如果是一个软件，就是软件需求规格。
我们要做系统设计，以及硬件和软件的设计和开发实现，最后做验证和确认，这些步骤是一个方法论，有很多具体的要求、手段在这个方面来实施，这是功能安全方面比较成熟的流程。在信息安全方面还没有这样的标准化流程，目前还没有公认的标准化流程出来，这是需要我们根据车辆的发展和信息安全的要求，再去设计和建立起来的体系。
整体安全就只有功能安全和信息安全都完善的情况下，才是真正的安全。
下面我介绍一下AUTOSAR的解决方案，前面讲了一部分AUTOSAR怎么提供低耦合、高内聚的架构。AUTOSAR结构，目前来说AUTOSAR组织在汽车里面得到普遍应用的主流的结构。在这个结构里面，是一个模块化的，我们看到不同的颜色，从下面开始，硬件上面会有一层驱动以及IO驱动，隔离软件和硬件的差异性。
驱动之上会有抽象层，软件访问驱动也是统一的接口，包括板级的，存储硬件的，通信的，还有IO硬件的抽象层。再往上是服务层，服务层就是提供一些底层的软件功能，包括通信服务，包括存储服务，包括系统服务，系统服务里面就包括操作系统。
三层叫做基础软件，基础软件之上会有一个运行环境，是虚拟软件总线的意思，就是说隔离掉应用软件和基础软件，使得应用软件和基础软件是低耦合的状态。这样的结构是可以保证我们在基础软件设计的时候，随着模块关联性是低耦合的。假如说最典型的是芯片，如果换了一种芯片，A芯片厂商换成B芯片厂商，底层的驱动层是需要变化的，但是除此之外，上面的抽象层保证了所有的软件，包括基础软件和之上的应用软件，都是不需要做改变的。
下面一张图更细的，也是AUTOSAR典型的图。这张图显示的是AUTOSAR里面所有模块之间的接口，刚才讲了底层的隔离性，可以改变芯片，不影响基础软件。往上看，RTE起的作用是隔离应用软件和基础软件，有什么好处？直接的好处是做应用软件的朋友，可以不用依赖于某一个供应商的基础软件，如果按照AUTOSAR方法论，从A公司，从普华公司的基础软件或者从另外一家国外公司的基础软件，对上层应用的影响是不大的，因为你是直接通过RTE接口，来和基础软件做交互。这是一个基本的好处，它可以有更深入的好处，AUTOSAR本身的思想是要求应用软件，也是一个组件化的开发，这个例子上就有三个组件，这是典型的AUTOSAR设计方法，你在设计一个应用系统的时候，你有算法的部分是一个组件，执行器的部分，让执行器动作的那部分软件组件，还有一部分跟传感器相关的。
这三个软件组件通信都是通过AUTOSAR进行的，组件之间的数据通信是通过抽象程度非常高的接口，这个接口对一个软件组件来说，需要往总线上发数据的时候，只是发送一条消息。至于说总线到底是在一条总线还是在其他的以太网总线上，对应用软件是不关心的。至于这三个组件，我们是在同一个ECU上，还是在不同的ECU上，对于软件组件的开发者也是不关心的。
大家或许会觉得奇怪，为什么一个算法执行器和传感器在不同ECU上，将来设计的时候，按照AUTOSAR方法论，可以共享的。如果有两个ECU，或者三个ECU，用同一种方法拿数据，只需要有一个设计出来就可以了。
RTE软件总线实现的功能，一方面是隔离了应用软件和基础软件，另一方面是隔离了底层RTE以及互相连接的逻辑拓扑。对于上层的组件来说，只要发送和接收数据就可以，至于数据在哪个ECU上面，以及通过哪条总线弄的，取决于RTE的配置。对AUTOSAR的思想来说，软件+配置才是最终软件的实现。
基础软件会有配置文件，RTE也会有配置文件，配置文件里描述了哪个ECU上面有哪个软件组件，哪个ECU用什么的组件。修改软件布局的时候需要修改的基本上就是配置部分，方法论对于未来软件开发工程化和实现的低耦合，复用，以及软件模块的跨平台思想设计，这是AUTOSAR解决方法。
AUTOSAR具体来说功能有哪些，这是普华产品，但是对所有的AUTOSAR供应商来说，都是一样的，因为标准制定是同样的情况。我们有操作系统，这是一个核心的部分，有诊断，有标定，有网络管理，有通信，存储管理，底层驱动，有复杂驱动，大致有这么多模块。除了RTE，RTE是非常重要的部分，但是功能已经描述清楚了。操作系统这些大家都知道了，不细讲，因为AUTOSAR操作系统都是需要有精简、性能强特点，功能隔离保护，内存保护，都在标准里面有定义。要讲的就是说有一个非常重要的特点，我这里没有写进去，实际上是非常重要的，终端响应和任务切换快，这是不准确的，对于实时系统来说，当然要性能高，这是必然的，要快，这是必然的。更重要的要求是确定性，多任务的系统里面，A任务如果是定义的10毫秒的周期，必然在任何情况下都是10毫秒的周期能完成，不可以说在某一种负载情况下面，某一种比较困难的情况下面，或者某种异常的情况下，达不到时间周期，10毫秒并不是很短的周期，但是我定义10毫秒就是切实的10毫秒。发生中断的时候，发生任务调度的时候，不可以有预料不到的东西，确定性是比性能更重要的特征，任何情况下，性能是不能低于时间的，这是操作系统的要求。
诊断协议栈包括UDS、J1939，这是行业里一直在用的，我们可以灵活的配置诊断协议，可以配置传输层的时间参数，可以用诊断规范，把诊断规范对应到配置上面去，可以实现多帧传输。标红部分就是跟诊断协议相关的部分。
通讯组件，过去汽车上面大部分用的都是CAN总线，现在包括以太网，标准通信组件里面，有很多报文需要配置，可以用文件导入的方式，降低用户使用的工作量，既然已经有通讯矩阵了，直接可以拿来生成配置。中间需要的时候再具体做一些修改，这是通讯实现的特点。以太网实现基于AUTOSAR DR的接口，用于封装以太网的数据。
还有很重要的一部分就是标定，做标定的时候基础软件必须支持标定协议，标定工具是在外面，但是标定协议是在控制器的里面，我们提供的标定模块是实现CCP和XCP两种标定协议，可以跟外面的主流标定工具匹配使用。
网络管理跟整车级的能耗，网络的状态都是有非常密切的关系，网络管理是具备了静态配置，动态监控的功能，我们可以支持两种标准，一种是AUTOSAR，也可以支持NM 2.5.3。很多情况下整车厂有自己的规范，可以根据整车厂自己的规范配置到相应的区域里面去。还有存储管理模块，可以支持flash存储介质等方面的内容。
MCAL驱动在AUTOSAR处在最底层的基础软件，也是基础软件一部分，提供的主要是屏蔽芯片上面的差异，向上提供标准的微控制器驱动接口。通过MCAL基础软件和芯片的适配性非常强。
我介绍一下普华，普华现在跟其他国外的AUTOSAR供应商是一样的模式，基本上在MCAL方面会跟芯片原厂合作，由芯片厂提供标准MCAL软件我们做集成，由于提供标准接口之后，这个集成工作会非常高效，包括MCAL和基础软件的集成，包括和底层的芯片在运行上的问题技术支持，这些方面都会有。
很重要的一点，我刚才讲的AUTOSAR开发思想是软件+配置实现的，用户通过配置适用于不同的汽车电子产品的需求，每一种产品的需求反映出配置是不一样的，我们需要有一个集成开发环境，对产品来说必须有一个集成开发环境的界面，通过这个界面对操作系统，对通信网络管理诊断驱动等等进行数据配置，为了减轻配置，我们也提供一些数据文件导入，降低配置的工作量。配置项是非常多的，其实这个是一个矛盾点，要做到高效率的适用于不同的场景，配置项必须多，配置项一多，往往在使用的时候会觉得对使用的工程师的要求比较高，就要知道所有配置项的概念，怎么样配置会更好，我们会提供辅助的手段，包括预定的默认数据放置，包括标准数据的导入，还包括冲突的检测，不同模块里面配置如果发生错误，我们也会报警和提供建议
这是集成开发环境的界面，实质上我们可以把软件模块和接口定义好，每种软件的数据配置上来，这是AUTOSAR基础软件工具的架构。
通常在工程项目里会有一些刷写的工作，BOOTLOADER需要和硬件做适配，需要一些更高性能或者更精简的驱动。因为刷写对不同的产品和厂商有不同流程，我们要根据流程去设计刷写过程，厂商规范的适应性。
中间有一些内容，比如安全模块，加解密方面的数据模块，包括监控，数据通信因为刷写的时候也有刷写效率，刷写的性能跟设计也是有关的。上位机刷写的时候要做定义，支持总线的参数，去定义收发地址和协议的时间参数，定义厂商给到的流程，设计一些或者说让客户加进来一些安全的认证算法和教研算法，这是上位机的特点。
前面讲的是AUTOSAR本身对于软件定义汽车低耦合、高内聚方式的实现，也就是架构挑战的实现方式，从安全角度来说，有三个挑战，架构挑战、功能安全挑战、信息安全挑战。对功能安全来说，AUTOSAR并不等于功能安全，普华做了十年的AUTOSAR，AUTOSAR本身是有一些跟功能安全相关的模块，但是本身并不代表功能安全。
在AUTOSAR里面去实现功能安全最重要的模块是操作系统，因为操作系统实现的任务调度，资源管理，时序，所有的系统必须要用底层的核心关键功能，操作系统是AUTOSAR实现功能安全的关键，如果操作系统没有过功能安全，而是过一些其他模块的功能安全，那是本末倒置的做法，做AUTOSAR产品，如果达到功能安全，首要的工作就是要操作系统去实现功能安全。
操作系统如何实现功能安全，操作系统是采用功能安全的机制去实现功能安全。功能安全机制起什么作用？我这里只是一个引导或者开端，我们在6月16号举办功能安全日，我会介绍功能安全实际的工作流程，对操作系统实现功能安全来说，方法论是很类似的，可以作为软件功能安全的借鉴。
功能安全会有很多相关安全模块，大部分的模块都会有功能安全要求，不仅仅标出来的模块，真正实现的时候，需要跟应用，由应用选择哪些模块会在具体场景上使用，我们在这些场景上面去实现功能安全。这是功能安全选模块时候的必要条件，当然有两者，OS是必须要选择的，如果说我前面已经讲过，OS没有达到功能安全，在其他的模块实现功能安全是远远不够的，这里面很重要的公共安全密切相关的模块。
接下来讲一下信息安全，AUTOSAR解决方法里面有几个方面，第一个信息安全是有E/E的通信架构，通信安全是信息安全很重要的内容，AUTOSAR里面提供了端对端的数据保护机制，这张图可以看出来，当发送端发送一个数据之后，需要做验证，加安全的报文头，收的时候从这里做验证，我们知道发送端和接收端保持一致，有一些时间戳的信息，这样保证信息的完整性。
第二个信息安全的方法是SecOC，这个安全机制为PDU做的，前面是为信号做的。对PDU来说，我们在发送的时候，需要对PDU实现认证机制，PDU的数据，会增加SecOC的模块，进行加密和解密，然后做通信，数据就是加密过的数据了。
第三个Crypto，主要提供加密和解密的机制，比如说Hash、Mac、对称加密、非对称加密和数字签名算法，对这些算法来说，AUTOSAR本身的架构里面会定义的两种实现方法，一种是纯软件的实现方法，还有一种外部的芯片上的机制，一般来说我们会通过SPI访问芯片上的安全模块，SM或者SHE不同架构的安全模块，取密钥存储，算法也是在芯片上面实现。后一种通过硬件做的，性能比较高，安全性更高一点，成本也会相对高一点，这是AUTOSAR对加解密方面的实现方法。
最后花一点点时间介绍一下普华，普华软件是中国电子科技集团的下属企业， 2008年注册成立，2009年开始正式运营，到现在差不多12年的时间，公司员工有600多人，普华作为国家的基础软件战略平台，通过国家的支持以及跟车厂的合作，产生了产品，并且这个产品是不断的通过业务创新，通过市场推进，目前在国内汽车电子AUTOSAR市场上，还是普遍得到了应用。
普华汽车电子事业部是我们公司核心业务部门，我们负责汽车电子AUTOSAR产品的开发，以及产品销售和技术服务。公司的总部在上海，汽车电子事业部在上海、西安、成都，三个地方，这是我们国内的布局。
普华是2010年加入AUTOSAR组织，2018年成为中国软件企业里面唯一一家高级合作伙伴，AUTOSAR高级合作伙伴世界上应该有58家，是有变化的，会多一点，少一点，每年都会有变化。中国企业在高级合作伙伴里面，有4家，普华是唯一一家作为软件AUTOSAR供应商的，我们作为标准软件的供应商，其他的中国企业还有长城、华为、百度，就四家在高级合作伙伴里，高级合作伙伴做什么事情？我简单介绍一下AUTOSAR组织架构，合作伙伴的分类。
AUTOSAR是一个汽车开放系统组织，标准是开放，大家都可以拿技术标准来开发产品，如果说你是商业化用AUTOSAR开发产品，用标准开发产品，需要成为合作伙伴才可以，至少有一个灰色的部分，就是关联合作伙伴，加入关联合作伙伴就可以合法用标准开发软件，就可以用它的体系架构。
在AUTOSAR组织里面参与标准制定工作，普华一直做AUTOSAR，我们必须要做参与的工作，比如做新版本开发的时候，最近在R20-11版本，今年下半年要发布的版本里面的模块，会跟所有高级合作伙伴讨论这个模块标准的设计以及做一些概念性的开发，这些工作都是在高级合作伙伴里面做的，付出会比较多一点，因为我们做这个业务的，我们也必须去做这些工作，在这些做AUTOSAR组织安排的工作。
我们在这个月，差不多一个星期前，我们获得了德国莱茵TUV功能安全产品认证，普华灵智ORIENTAIS操作系统是国内第一个通过功能安全产品认证达到最高安全等级ASIL D的AUTOSAR操作系统，这是认证证书。我们会在6月16号，12天以后会办一个活动，叫功能安全技术日，在国内大家推动倡议软件的功能安全怎么做更好，我们也会分享，我会把功能安全普华实战的过程，在那个活动上跟大家做分享，希望大家可以关注这个活动。
我们的合作伙伴，有国际主流的芯片厂商，有AUTOSAR组织，有国内整车厂，都是我们的合作伙伴。
我今天的报告就到这里。