这两天变天，这两年加班熬夜导致的劳损对于这样的天气特别敏感。结果，一个周末基本结束了，整个人的状态才稍稍好转。这样，继续之前的学习，我已经落后于自己的计划太多。接下来，继续看《AUTOSAR_TR_Methodology》。
创建 ECU 系统描述
目的
基于系统提取，本活动创建在子系统设计期间细化的 ECU 系统描述。
创建 ECU 系统描述活动
基于交付的系统提取，接收组织创建一个或多个 ECU 描述。 ECU 描述用于设计子系统工件（请参阅活动设计子系统）。
从方法论的角度来看，创建 ECU 系统描述有两种选择。
使用 System Extract 作为 ECU 开发的结构基础
System Extract 作为 ECU 开发的结构基础。 在这种情况下，系统提取成为 ECU 系统描述。
为 ECU 开发创建新结构
创建一个新结构作为 ECU 开发的基础。 新创建的 ECU 系统描述映射到初始系统提取。 为此，定义系统视图映射任务创建了在子系统设计期间细化的初始系统视图映射工件。
创建ECU系统描述
表格基本是对前面的描述概括，正好再做一次总结。
在开发子系统活动期间，供应商改进接收到的系统提取，以便可以生成有效的 ECU 提取。
系统提取的细化是使用 ECU 系统描述完成的。 因此，此活动基于系统提取创建一个或多个 ECU 系统描述。 子系统工件是在“设计子系统”活动期间在 ECU 系统描述中设计的。
从方法论的角度来看，创建 ECU 系统描述有两种选择。
1) System Extract 作为 ECU 开发的结构基础。 在这种情况下，系统提取成为 ECU 系统描述。
2) 创建一个新的结构作为 ECU 开发的基础。 新创建的 ECU 系统描述映射到初始系统提取。 为此，执行“定义系统视图映射”任务。
设计子系统的目的
本活动详细介绍了给定的 ECU 系统描述（之前从交付的系统提取中创建）以及其他 ECU 和网络。
设计子系统活动
基于 ECU 系统描述，定义了子系统的描述。
不同组织之间的协作
此外，由主要组织交付的系统提取的软件组件结构可以由接收组织（ECU 系统描述）转换为不同的结构。 在这种情况下，主要组织的系统摘录可以被视为需求，而接收组织的子系统可以被视为必须满足已交付需求的解决方案。
因此，这里再次定义映射活动，该活动将新引入的解决方案子系统映射到来自主要组织的提供的需求子系统。
设计子系统活动期间的转换更改
在这个转换过程中，分层 SWC 结构可以改变，一些 SWC 可以被其他 SWC 替换，一些可以保留在结果视图中。
不同视图的映射
不同的视图由系统“视图映射”映射。
转换步骤典型的用例如下：
用例：将需求映射到解决方案
次级组织为不同的初级组织开发一个 ECU，因此必须将不同初级组织的需求映射到其解决方案上。
用例：软件结构重组
主要组织提供定义一个 ECU 的子系统描述。 二级组织决定使用两个 ECU。 因此，软件结构必须由第二个组织重新组织。
用例：不同版本系统描述之间变化的描述
此外，映射可用于正式描述不同版本的系统描述之间的变化。
最终子系统范围内的所有原子软件组件都包含在此子系统描述中。
需要注意的是ECU 系统描述显示为该活动的输入和输出，因为它是经过改善的。
由于本活动的详细工作流程使用方法库中的元素与 2.5.2.3 中描述的元素相同，因此这里没有对任务分解进行建模。
这是设计子系统的描述表。
根据之前从交付的 ECU Extract 创建的 ECU 系统描述设计子系统工件。 它由与活动设计系统相同的任务组成。
描述必须完成到 ECU 级别，以便可以生成有效的 ECU 提取。
这次小结暂且到此结束，内容多少还是有一些抽象，可能能够带给我大突破的部分还是与实践相关的部分。
