本文共 1548 字，大约阅读时间需要 5 分钟。

         对AUTOSAR的了解确实不多，一直觉得AUTOSAR不应该是买买买，更不该是各种工具来一统天下。我觉得任何软件架构都应该升华为一种哲学，但是在掌握的过程中我们可能得从支离破碎的零星判断中逐渐还原哲学的内核本质。

         今天尝试理解一份我自己从网上找的几页PPT资料，整理出这份学习笔记。

第1点，

截图中已经做了很多解释，不过这种解释我一般只会保留性的吸收。我自己再整理一遍：

RET的主要功能分为如下4点：

1. VFB的接口实现；
2. 一共基础设施服务，支持如下功能：
   1. AUTOSAR模块（我理解应该是应用层模块）之间的通信；
   2. AUTOSAR模块（依然是ASW）访问基础软件，比如OS以及各种服务；
3. 实现软件模块（应该是ASW）与ECU的映射以让RTE服务标准化；
4. 针对专门的ECU生成而不是通用的，从而保证最优。

个人思考：

1. 从上面的描述看，直接的变量赋值或者传递的方式肯定是不行的；
2. 2.a中可以看得出，ASW不同模块之间的通信应该是通过RTE，这样ASW模块之间似乎模块不该用全局变量合理一点；
3. 变量与ECU的映射以及标准化，需要再进一步了解；
4. 一个疑问：这个东西是否会导致软件执行效率的降低？

         关于这个图，先提出自己的几个疑问点：

1. 这是整个RTE的描述还是RTE可以拆分为若干个这样的小单元？
2. 端口是怎样一个概念？如何使用？是哪一个英文描述的翻译？
3. ECU中的并发是一个什么样的概念？
4. RTE的事件是一个什么概念？
5. 通信收发中，明确与不明确又是一个什么概念？
6. 运行提应该是ASW的软件逻辑？

         这个图应该可以理解清楚，其实比较好的方式就是看箭头的走向。可能呢分为几种路线，如果把两个构件（ASW模块）左边叫做A，右边叫做B。路线如下：

         路线1： A经过端口到通信的收发器，再从收发器出去到B的端口，传递给B。可以理解为A的修改通知给B，或者B有时候需要查询A的信息。这个路线比较简单，因为是单向的。

         路线2：A经过端口到客户端，客户端再到BSW端口，之后访问底层。这种可以理解为底层的输出驱动类操作。

         路线3,：其实主要是路线2的双向箭头反过来，BSW的信息通过端口到客户端，之后再传递到A的端口，之后被A读取。这样的场景可以理解为对底层状态的读取，诸如AD采集。

         我个人理解上，上面的图应该是错误的或者是个例，不然的话构件Call右边的箭头应该还是一个双向的箭头，不然没法解释通信与BSW之间的Call的箭头的双向。

         先按照我自己的理解方式顺着箭头理顺一遍：

         路线1：这一个理解方式不一定对，就是ASW直接到通信，之后访问BSW。或许，上面图中没有这个意思。

         路线2：ASW调用端口通信的时候需要等待RTE事件的发生。或者描述为：RTE事件的发生会出发ASW调用端口产生通信，从而访问BSW。或许，这是它想表达的意思。

1. ASW不能够直接访问OS，所以没有task的概念与ASW关联到一块。这样，前后台程序模式下，我会考虑，没有task，ASW会如何运行？
2. 针对我在1中的问题，AUTOSAR的回答或许是，通过Runnable来执行。可是，Runable又是通过什么来激活？
3. AUTOSAR或许回答我2中问题的方式：Runable由RTE统一管理，通过RTE的事件来触发。RTE可以被OS调度，这样的话要满足不同的调度顺序，RTE应该执行的十分高频？RTE的事件又是一个什么概念呢？这个资料中看不到问题的答案。
4. 另外，我自己疑问之外的基础性知识有一部分。
   1. Runable有几种，以满足不同的设备。
   2. RTE的事件可能会尝试把所有的触发任务的事件都包含进来，这样理解的话，应该是各种执行条件的判断？
   3. Runable是可以由RTE调用管理的一段指令序列。

文档剩下的部分是一个卖工具的介绍，暂且不去理解了。

转载地址：http://rrgjf.baihongyu.com/