全部学习汇总: GitHub - GreyZhang/hack_autosar: learning autosar documents, aha, very hard!

       继续学习AUTOSAR的文档,看一下《AUTOSAR_RS_StandardizationTemplate》。这次看一下这里面的需求相关部分。

781_AUTOSAR_RS_StandardizationTemplate3_需求1_建模

       3 要求

       本章描述了推动定义标准化模板规范 [2] 工作的所有要求。

       本文档中的每个需求都有其以前缀“RS_STDT_”开头的唯一标识符(表示标准化模板的需求规范)。

       应支持和解释一般的蓝图

       标准化模板应支持蓝图。 蓝图是一种“不完整”的模​​型,在后期被复制和细化。蓝图的原则应该定义:

       • “实例化”是通过复制而不是引用来完成的。下游处理不包括蓝图的使用。

       • 为蓝图和蓝图模型元素定义适当的术语。

       • 从蓝图创建的元素是如何命名的?

       • 应明确定义元模型的哪些部分有资格进行蓝图。元模型的蓝图不合格部分应计为“验证错误”。

       • 定义如何从蓝图中派生对象的规则,特别是策略,可以添加/删除/重新定义哪些属性。 这些规则应为每个符合蓝图条件的元类单独定义。

       应定义元模型的必要设施:

       • 特定蓝图

       • 映射蓝图和派生对象

781_AUTOSAR_RS_StandardizationTemplate3_需求1_元模型_02

       BSW SWS 的形式化描述

       标准化模板应能够发布 SWS 的正式部分,然后作为指定模块的蓝图。

       标准化模板应提供描述标准化接口 (C-API) 的方法。

       标准化模板应允许描述标准化的 AUTOSAR 接口。

       标准化模板必须支持接口变体的规范。

       特别是“标准 AUTOSAR 接口”是每个提供此接口的 SWS 的一部分(通常包含在第 7 或第 8 章的单独章节中)。

       描述大多是纯文本,带有一些伪语言来展示接口的用法(包括常量等)。 此外,服务的描述经常使用元模型中的“元素”,这些元素不是最新的或者它们的含义已经改变。 当 RTE 在 BSW 和 SWC 之间“路由”呼叫时,当前状态会导致几个问题。 伪语言必须手动转换为某种“SWC-Description”。 如果人们尝试混合来自不同供应商的模块,则不清楚这是如何工作的。 在我们的理解中,格式需要标准化。 我们建议对 SWS 的这一部分进行标准化,例如通过自己的模型(然后生成的描述可以像第 8 章一样导入到 SWS 中)或通过标准化语言来阐明对界面的理解并允许出于 RTE 目的进行自动对话。

781_AUTOSAR_RS_StandardizationTemplate3_需求1_autosar_03

       应允许表示端口蓝图

       AUTOSAR 标准化了所谓的“应用程序接口”。 这些接口实际上用于指点端口蓝图。

       AUTOSAR 将标准化模型发布为 ARXML。

781_AUTOSAR_RS_StandardizationTemplate3_需求1_建模_04

       应允许表示 shortName 模式

       AUTOSAR 发布应用程序接口建模指南。

781_AUTOSAR_RS_StandardizationTemplate3_需求1_元模型_05

       应支持关键字和关键字缩写

       在 [7] AUTOSAR 中,将 ShortName 的构建规则发布为关键字序列。 这些关键字需要通过标准化模板来表达。现有的可识别关键字应使用 ShortLabel 进行扩展。SHORT-LABEL 的语义:用于代替 ShortName。 如果有几个 nampe 部分要由相同的关键字缩写缩写,则是必要的。

       由于关键字是可识别的,这会导致冲突。

781_AUTOSAR_RS_StandardizationTemplate3_需求1_应用程序接口_06

       应在不存在与现有模板兼容问题的情况下实施

781_AUTOSAR_RS_StandardizationTemplate3_需求1_应用程序接口_07

       应基于 AUTOSAR 模式

       为所有模板使用一个元模型的一般方法。

781_AUTOSAR_RS_StandardizationTemplate3_需求1_autosar_08

       应提供支持分析实现与 AUTOSAR 标准的一致性的方法

       标准化模板应使实施者能够检查其描述(例如 BSWM)是否符合 M1 级别(SWS)指定的 AUTOSAR 标准。

     这在 AUTOSAR 实现和定义的标准之间建立了可追溯性。 并且也是检查不同版本之间的应用程序兼容性的前提。

781_AUTOSAR_RS_StandardizationTemplate3_需求1_建模_09

       应能够代表 SWS 中规定的要求

       为了提高需求的可追溯性,SWS 的正式描述应包含相应 SWS 文档(SWS 的规范项目)中包含的每个需求的文本代表。

       声明应归类为{要求、规范、实现、约束}之一。

       此功能支持自动跟踪需求更改,这是改进更改管理和兼容性评估的基础。

781_AUTOSAR_RS_StandardizationTemplate3_需求1_元模型_10

       应参考ECUC参数定义

       AUTOSAR 也标准化了ECUC 参数定义。 因此它在标准化模板的范围内。 严格来说,这些标准化的ECUC 参数定义充当供应商特定参数的蓝图,即使这些参数未使用BluePrintMappingSet 进行映射。

       至少对于 AUTOSAR 4.0,标准化模板不应更改方法,但应反映关系。

       这保持了整体范围和应用的模式。

781_AUTOSAR_RS_StandardizationTemplate3_需求1_建模_11

       应能够标准化组件

       STDT 应该能够表达组件的标准化,即使 AUTOSAR 不标准化组件。

       此要求涵盖一组单独的组件。

       STDT 中不考虑硬连线兼容性的任何规则。提供支持的是它只允许将 SwComponentType 指定为符合蓝图的条件。

       这允许在公司内部利用 AUTOSAR 标准化原则。

781_AUTOSAR_RS_StandardizationTemplate3_需求1_元模型_12

       应能够标准化架构

       这允许在公司内部利用 AUTOSAR 标准化原则。

781_AUTOSAR_RS_StandardizationTemplate3_需求1_应用程序接口_13

       应能够表达参考路径诸如包层次结构的部分

       这允许在公司内部利用 AUTOSAR 标准化原则。

781_AUTOSAR_RS_StandardizationTemplate3_需求1_建模_14

       应能够表达义务水平

       这允许使用标准化模型来评估实施的一致性。

781_AUTOSAR_RS_StandardizationTemplate3_需求1_元模型_15

       应支持从蓝图派生的不同方法

       这允许使用标准化模型来评估实施的一致性。一致性取决于派生对象的方法。

       大部分内容还是关于建模或者工具的,大概了解一下,不做进一步的总结了。