开始一个新的文档梳理，《AUTOSAR_RS_Methodology_20190826_145121》。这个文件是一个比价特殊的文件，命名居然带了一个时间。
简介
本文档定义了指定 AUTOSAR 方法所需的要求。 即使 AUTOSAR 方法规范已经存在，本文档也将在需求与其实施方式之间建立联系。 该文档是测试规范的好工具，看看缺少什么，在计划和手段方面应该做哪些努力。从这个描述看，这个应该对整个系统设计是一个很好的理解性指点资料。
文档约定
AUTOSAR 文档中的需求表示遵循 [TPS_STDT_00078] 中指定的表格，请参阅标准化模板，支持可追溯性 ([1]) 一章。
[TPS_STDT_00053] 中规定的义务表达的口头形式应用于指示要求，参见标准化模板，支持可追溯性一章 ([1])。
我现在的工作中遇到了一个需求跟踪矩阵的概念，我感觉这个应该就是同一个概念。
缩写，直接过。
需求跟踪，看起来就是跟踪矩阵的意思。不需要每一条都过了，但是这种形式是很好模式，很值得学习。
方法论将解释 Autosar 系统是如何构建的。
方法论应解释如何使用指南支持的模板和活动来构建 Autosar 系统。 它应该像用户手册一样帮助组织有效地应用 Autosar。
要有效地管理大型系统的构建，需要强有力的方法论。
工程师想完成一项活动，并想知道需要哪些输入、应使用指导等。 构建 Autosar 系统所涉及的典型用例包括：
SWC 设计；
ECU 集成；
系统集成；
小结：感觉这个描述写的太空洞，按照这种模式，如何能够弄懂呢？
方法论应支持 VFB 概念
虚拟功能总线概念允许在 SW-C 与硬件的完整抽象之间进行早期检查。 方法论应该包括这个概念。
在 AUTOSAR 中，应用程序被建模为互连组件的组合。 “虚拟功能总线”是允许这些组件交互的通信机制。 即使这些组件使用的所有资源都不可用（硬件/网络），也可以进行一些基本检查，并且可以解决早期问题，从而简化以后的集成阶段。
小结：这个描述准确，但是实战的时候有什么实际的工具可参考呢？我觉得这个是我现在很需要或者很迫切了解的东西，在软件设计中应该如何实施呢？
方法论应支持自下而上的方法
方法论应支持自下而上 (B/U) 方法。 在这种方法中，应考虑来自 B/U 中硬件（ECU/传感器/执行器）的所有约束。
如果在给定的车辆架构中添加新的 ECU 或用新的 ECU 替换现有 ECU，则在集成期间需要将来自 ECU 的所有新的或修改的资源包含到系统配置中。
小结：这个自下而上的概念应该是从几个软件架构分层中最下面的一层往上开发，如果这样，现在我接触到的软件开发模式或许也是对的，只是有些实施过程中有一些细节上还是有不准确的地方。
方法论应支持构建 Autosar 和非 Autosar ECU 的系统
方法论需要展示如何构建一个与 AUTOSAR 兼容的 ECU 系统，这些 ECU 与非 AUTOSAR 兼容的 ECU 处于同一架构。
小结：这个主要是为了兼容非AUTOSAR的模块集成或者移植，如果是有这样的功能，那么还有啥兼容性问题呢？如果没有兼容性问题，我现在看到的各种不兼容又是如何出现的呢？如果出现了，又该如何解决呢？
方法论应明确界定什么是标准化的，什么是非标准化的
小结：具体的信息翻译小结的价值不大，不过后面的确得看看哪里能够找出标准化和非标准化的部分。只要是有标准化的功能，很多设计应该就可以处理了。
方法论应该是模块化的
小结：大概的意图应该容易明白，也无需去翻译阐述。这个主要的目的是能够完成一个独立的模块化测试。
方法论应该支持不同的抽象层
该方法应尊重软件组件、系统和抽象的 ECU 级别。
小结：这个应该就是MCAL、服务层、CDD、RTE等不同层级划分的一个要求。
方法论应支持迭代
小结：支持迭代，主要是考虑各种开发阶段，例如ABC样件等。这个，其实应该是对各种配置的可以修改的一个要求。不然的话，如果考虑软件开发的话，不可迭代升级的可能性应该不大。
方法论应支持不同绑定时间的参数配置
参数的配置可以在不同的过程步骤中执行：预编译、链接时间和后构建。 Autosar 方法必须支持使用这些配置类的不同组合进行系统开发。
小结：这部分看Main文件夹的时候可能已经看过了，应该是类似的说明。
这次的小结先到此为止，整个文件看了似乎不到一半，看起来，三次以内的梳理就能够把这部分梳理完。
