全部学习汇总：https://github.com/GreyZhang/hack_autosar

         我前面过高预估了我自己看文档的速度，看起来这部分文档读起来还是比较费时间的。但是一旦熟悉了，或许速度会快一些。继续吧！今天看看第一份文档中的另一个章节：方法论。

         需要提供整个系统接口的描述方法，这个是软件重用或者合作开发的一个重要前提。其实，我一直觉得POSIX的接口标准是这方面的典范。而在设计大型系统的时候，需要分而治之，这样，软件接口的标准化就十分重要了。

         提供知识产权的保护机制，其实这个或许是现在中国整个科技圈中最被忽视的一点。而对于一般的工程师来说，掌握知识应用本身其实更加重要。这一点，我也暂时跳过不看了，后面如果有更加精确的描述的时候是否会看届时再说。

         提供数据交换格式，用于支持大型公司团队的内外部开发合作。估计这个会是我现在接触到的arxml的文件？

         需要提供一种应用软件模块的描述方法。这部分的设计，主要的考量点也是软件的重用性。

         这个设计理念是很好的，也是应该如此的。这也是现在我所在的团队的一个问题所在。其实，AUTOSAR各种层级的划分就是为了能够让大家能够拆分不同的任务，在不同的层级上进行专注开发。而现在看到的做法是一个人从头做到底，或者是几个人各自把某一个层级切片从头做到底。这样，失去了分工合作设计本身的意义所在。

         需要提供集成应用软件的时候相关方面所有的描述需求格式。这个主要解决的问题是，保证能够获知每一个需要集成的应用软件所需要的的运行时环境。说起来，现在我在工作中看到的现象其实是缺少这样的体现的。

         支持计时的需求，可以支持计时需求的描述以及修改实施。这包括数据流以及控制流相关的需求。这个主要是要满足应用软件的特殊计时需求？

         支持汽车多样性的管理，这个主要是考虑应用软件的兼容性。在一定程度上，这个应该是对应用软件设计的一个要求。

         应该提供典型角色以及工作在共享工作模型中的一个预定义。典型的角色有车辆架构师、领域架构师、ECU集成商、功能设计师。角色也可以与不同的学科相关，如静态体系结构、动态体系结构、通信体系结构等。典型的活动可以是软件/软件分区、软件到ECU的映射、基本软件的配置。综合来说，就是应该定义好有什么人，要做什么样的事儿。

AUTOSAR流程应支持工作共享模型中的角色和权限。分布式开发需要明确的职责。

AUTOSAR应支持表达角色及其创建/访问/修改AUTOSAR描述的权利的通用方法。

这部分的描述，看上去有些类似项目管理的要求，对每一个人能够做的事情进行明确的权限界定。这样的话，可以减少不同人修改他人模块的风险。