继续梳理《AUTOSAR_TR_Methodology》，感觉上这一次的小结应该可以实现的快一些。内容可能并不是很多，这一次主要去梳理如何开发一个抽象系统描述。
本活动提供了创建抽象系统描述的粗略概述。
抽象系统描述活动
由于车辆功能的整体视图可能与各个 ECU 软件架构的实际技术定义不同，因此可选活动“开发抽象系统描述”允许从抽象或功能角度定义整个系统的视图。 该视图描述了一个专用的抽象 VFB。在进一步的活动中，这个抽象视图被重构为软件架构的技术视图。
整体抽象系统的创建
在组件模型开发活动中，创建了一个组件模型，该模型从功能的角度表示整个系统，例如从车辆功能的客户相关角度出发，独立于具体的车辆平台设计。 在此过程中，可能会对组合进行建模，而不会将其进一步细化为原子软件组件。 然而，也可以在这个抽象 VFB 视图中定义原子软件组件。
出于此用例的目的，此活动分为子活动和任务（参见图 2.3），在第 2.3 和 2.5.2 章中进行了详细描述：
• 数据模型开发
• 组件模型开发
• VFB 时序开发
• 定义 VFB 顶层
• 定义 VFB 组件约束
• 设计系统
• 在 VFB 级别集成非 AUTOSAR 系统
在数据模型开发活动中，定义了在整个抽象 VFB 中使用的一组 VFB 接口、VFB 模式和 VFB 类型。 请注意，这些对象也可以在后续步骤中由 VFB 和子系统 VFB 使用。
在抽象系统的上下文中定义约束
在抽象 VFB 的上下文中，任务定义 VFB 组件约束定义了约束 w.r.t. 抽象 VFB 的软件组件。 在将抽象 VFB 转换为具体的技术 VFB 时，必须考虑这些约束。
在 AUTOSAR 过程中开发抽象系统描述的同时，可能有一些基于另一种方法开发的功能。 例如，车载信息娱乐系统的功能通常不包含在 AUTOSAR 开发过程中。 相反，使用诸如 GENIVI (http://www.genivi.org/) 之类的开发方法和平台来解决信息娱乐系统开发的特定需求和条件。 应尽早解决将这些功能集成到整个系统中的问题。 为此，首先需要非 AUTOSAR 功能的描述（非 AUTOSAR 系统的描述），它必须由非 AUTOSAR 方法提供。 在抽象系统描述的开发过程中，非 AUTOSAR 功能和 AUTOSAR 功能的功能交互必须基于两个部分的给定描述进行指定。 由于非 AUTOSAR 部分通常以非 AUTOSAR 格式指定，因此必须将其转换为相应的 AUTOSAR 格式（任务将非 Autosar 描述转换为 Autosar 描述）。 此外，必须合并有关功能交互的信息，以获得集成系统的一个共同视图。 “Franca IDL 软件组件描述的集成”文档 ([3]) 定义了 VFB 集成连接器的格式以及从 GENIVI 中使用的 Franca 接口定义到 AUTOSAR 的转换。 它可用于开发集成 AUTOSAR 和 GENIVI 系统的抽象描述。
在抽象系统的上下文中定义系统描述
除了抽象 VFB 的定义之外，系统描述的部分已经可以在设计系统活动中定义，例如 抽象 VFB 的 SWC 映射到的拓扑和 ECU。 这种从抽象 VFB 到 ECU 的 SW-C 映射可以用作定义具体 VFB 的方法步骤。 请注意，并非设计系统活动的所有任务都必须在抽象系统的上下文中执行。
这个功能流程相对来说简单，没有太多的回环。而这种流程图的查看方式跟上次看到的整体设计一样，都是从目标向前推进，这样会更好一些。
这是抽象系统描述涉及到的一个解析表。
看起来，每一个部分的开发应该都有类似的一个开发过程的梳理。这一份文件的确应该好好看看，最初还有冲动直接跳过，真是太武断了。
