feifei.xu/autosar_standard_spec_v4.4
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0d470d1f1750b515b51be218bb3897436579ec0e
autosar_standard_spec_v4.4/General/AUTOSAR_TR_AIMeasurementCalibrationDiagnostics.md
T

82 KiB
Raw Blame History

AUTOSAR 文档、测量与标定的唯一名称：建模与命名方面（包括自动生成）

AUTOSAR CP Release 4.4.0

原文：Unique Names for Documentation, Measurement and Calibration: Modeling and Naming Aspects including Automatic Generation（文档 ID 537）

翻译状态：已完成 v1（封面+前言+目录+章节 1-17 完整翻译）

对应原文 PDF：General/AUTOSAR_TR_AIMeasurementCalibrationDiagnostics.pdf

翻译日期：Step 3 - P0 批量翻译

文档标识

字段 值
文档标题（Document Title） 文档、测量与标定的唯一名称：建模与命名方面（包括自动生成）
文档所有者（Document Owner） AUTOSAR
文档责任人（Document Responsibility） AUTOSAR
文档标识号（Document Identification No） 537
文档状态（Document Status） 正式版（Final）
所属 AUTOSAR 标准 Classic Platform（经典平台）
所属标准版本 4.4.0

原文版权：© AUTOSAR — 机密文件 本中文译文仅供学习参考。

免责声明（Disclaimer）

本作品（规范和/或软件实现）及其包含的材料由 AUTOSAR 发布，仅供信息参考。AUTOSAR 及为其做出贡献的公司不对作品的任何使用承担责任。

本作品中包含的材料受版权及其他类型知识产权保护。对本作品所含材料的商业利用需要获得这些知识产权的许可。

本作品可在不作任何修改的情况下、以任何形式或任何手段用于纯信息性目的。任何其他目的，未经出版者书面许可，作品的任何部分不得被利用或复制。

本作品仅为汽车应用而开发。它既未为非汽车应用而开发，也未为非汽车应用而进行测试。

"AUTOSAR" 一词和 AUTOSAR 标志是注册商标。

文档变更历史（Document Change History）

日期 版本 变更人 变更说明
2018-10-31 4.4.0 AUTOSAR Release Management • 编辑性修订（Editorial changes）
2017-12-08 4.3.1 AUTOSAR Release Management • 编辑性修订（Editorial changes）
2016-11-30 4.3.0 AUTOSAR Release Management • 编辑性修订（Editorial changes）
2015-07-31 4.2.2 AUTOSAR Release Management • 次要变更（Minor changes）
2014-10-31 4.2.1 AUTOSAR Release Management • P/L-List 现在也作为 .arxml 作为 MOD_AISpecification 的一部分提供
2014-03-31 4.1.3 AUTOSAR Release Management • 次要变更（Minor changes）
2013-03-15 4.1.1 AUTOSAR Administration • 包含文档问题
• 除了端口和参数接口中的数据外，还考虑其他数据原型
• 添加了带有数组的 FlatMap 示例
• 根据元模型细化命名空间概念（例如使用符号名称）
2011-12-22 4.0.3 AUTOSAR Administration • 初始发布（Initial Release）

目录（Table of Contents）

  1. 参考文献（References）
  2. 范围（Scope）
  3. 如何阅读本文档（How to read this document）
  4. 需求（Requirements）
  5. 需求可追溯性（Requirements Traceability）
  6. 方法论背景（Methodological Background）
  7. 整体建模和生成规则（Overall Modeling and Generation Rules）
  8. 数据原型（Data Prototypes）
  9. 数据接口中的数据原型（Data Prototypes in DataInterfaces）
  10. ClientServerInterfaces 中的数据原型（Data Prototypes in ClientServerInterfaces）
  11. 命名空间（Name Space）
  12. SwSystemconsts
  13. PortPrototypeBlueprints
  14. 组件层次结构（ComponentHierarchy）
  15. SwComponentPrototypes
  16. 唯一 SW-Signal 显示名称（Unique SW-Signal Display Names）
  17. 附录：Powertrain 域的 Phys/Log（P/L-List）关键字

1 参考文献（References）

编号 名称 文档
[1] SW-C and System Modeling Guide AUTOSAR_TR_SWCModelingGuide.pdf
[2] Table of Application Interfaces AUTOSAR_MOD_AITable.zip
[3] XML Specification of Application Interfaces AUTOSAR_MOD_AISpecification.zip
[4] System Template AUTOSAR_TPS_SystemTemplate.pdf
[5] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[6] Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf
[7] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate.pdf
[8] Specification of BSW Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[9] Specification of RTE AUTOSAR_SWS_RTE.pdf
[10] ASAM MCD-2 MC (ASAP2) www.asam.net
[11] Explanation of Application Interfaces of the Powertrain Domain AUTOSAR_EXP_AIPowertrain.pdf
[12] AUTOSAR Predefined Names AUTOSAR_TR_PredefinedNames.pdf

2 范围（Scope）

本文档特定于 Powertrain 域。对于 Powertrain 域，高效处理标定和测量非常重要。

本文档提供了有关 AUTOSAR 标定相关问题的方法论背景，独立于任何应用域。

提供了示例。尽管它们可能类似于标准化的应用接口，但仅作为示例¹。

然而，本文档的主要重点是提出一个建议，即如何为测量、标定和诊断工具（MCD）自动生成显示名称²。如果满足某些假设和特定建模规则，则自动生成会导致适当的显示名称。当然，仍然可以手动定义显示名称，并且在生成名称不合适的情况下甚至是必要的。

本文档未描述到 MCD-2 MC（A2L，[10]）的完整映射。它当前的重点是 sender receiver 和 parameter 接口以及系统常数的变量和参数原型。尚未考虑本地可测量值、标定参数以及其他接口类型。

本文档不包含 AUTOSAR 元素的通用建模和命名规则。这已由 AUTOSAR_TR_SWCModelingGuide [1] 涵盖。

文档中显示的 XML 代码符合 Release 4.0 的 AUTOSAR xsd。

本文档中描述的算法已应用于 [11] 的显示名称部分。

¹ 例如，路径不正确：正常情况下是 /AUTOSAR/AISpecification/Units（[3]）等，但为了更好的可读性，本文中的路径被缩短为 /AUTOSAR/Units 等。 ² 请注意使用 A2L [10] 时：本文档中使用的显示名称与 A2L 的 DISPLAY_IDENTIFIER 不相同，但与属性 Name 本身相同。

3 如何阅读本文档（How to read this document）

3.1 使用的约定（Conventions used）

在需求中，使用以下特定语义（取自 Internet Engineering Task Force IETF 的请求评论 RFC 2119）：

本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 RFC 2119 中的描述进行解释。请注意，使用这些词的文档的需求级别会修改这些词的强制力。

  • MUST / REQUIRED / SHALL：该词或术语意味着该定义是规范的绝对要求。
  • MUST NOT / SHALL NOT：该短语意味着该定义是规范的绝对禁止。
  • SHOULD / RECOMMENDED：该词或形容词意味着在特定情况下可能存在合理的理由去忽略某一项，但在选择不同做法之前必须充分理解并仔细权衡其全部影响。
  • SHOULD NOT / NOT RECOMMENDED：该短语意味着在特定情况下某些行为可能是可以接受的或甚至有用的，但在实现任何带有此标签描述的行为之前，应充分理解其全部影响并仔细权衡。
  • MAY / OPTIONAL：该词或形容词意味着某项是真正可选的。

3.2 规则编号（Numbering of Rules）

所有规则或建议都由一个 ID 标识。有关此类标识符的名称模式，请参见 [6]；有关包括本文档中使用的预定义名称，请参见 [12]。

  • 该 ID 以 "TR_MCM" 开头用于测量和标定的建模规则，后跟四位数字（TR_MCM_xxxx）。
  • 该 ID 以 "TR_MCG" 开头用于测量和标定的生成规则，后跟四位数字（TR_MCG_xxxx）。
  • 该 ID 以 "TR_MCA" 开头用于能够使用特定生成规则所做的假设（TR_MCA_xxxx）。它们被引入是为了更容易地说明哪些假设对于您的项目（产品线）是正确的，然后确定哪些规则（TR_MCR）是适用的。
  • 该 ID 以 "TR_MCR" 开头用于测量和标定的需求，后跟四位数字（RS_MCR_xxxx）。

从元模型中获取的术语（例如 AutosarDataPrototype）以斜体书写。

下表给出了重新编号或删除的规则的概述：

新编号 旧编号 注释
[RS_MCR_9{0}0..n<number>] [MCR<number>] 避免需求和规则等的编号相同 [6]
[TR_MCM_7{0}0..n<number>] [MCM<number>] 避免建模规则的编号与生成规则等的编号相同 [6]
[TR_MCA_8{0}0..n<number>] [MCA<number>] 避免假设和规则等的编号相同 [6]
[TR_MCA_80789] [MCA030b] 根据 [6] 中的 [TPS_STDT_00042] 重新编号
[TR_MCG_00788] [MCG005b] 根据 [6] 中的 [TPS_STDT_00042] 重新编号
[RS_MCR_90781] [MCR010a] 根据 [6] 中的 [TPS_STDT_00042] 重新编号
[RS_MCR_90782] [MCR010b] 根据 [6] 中的 [TPS_STDT_00042] 重新编号
[RS_MCR_90783] [MCR013a] 根据 [6] 中的 [TPS_STDT_00042] 重新编号
[RS_MCR_90784] [MCR013b] 根据 [6] 中的 [TPS_STDT_00042] 重新编号
[TR_MCG_00787] [MCG710] 因为与 [TR_MCA_80710] 中的编号相同
changed [TR_MCM_70030] —
changed [TR_MCG_00035] —
changed [TR_MCM_70022] —
changed [TR_MCG_00770] —
-- [TR_MCG_00712] 隐含在其他规则中
-- [TR_MCG_00715] 隐含在其他规则中
-- [TR_MCG_00400] 隐含在规则 [TR_MCG_00021] 中

为了表述规则，使用的语法遵循 [6] 中的语法。但是，"发明"了一些额外的占位符以能够表达预期的规则。

额外使用的占位符列出如下：

  • componentDescriptor
  • componentHierarchy
  • data
  • dataInfo
  • element
  • operationInfo
  • port
  • portBlueprint
  • portBlueprintDescriptor
  • systemDescriptor
  • swSignal

具体可标识对象的名称表示为 (identifiable).name，例如 PortPrototype.name。

3.3 缩略语与缩写（Acronyms and Abbreviations）

缩写 含义
AI Application interfaces（应用接口）
component 组件是 CompositionSwComponentType 的 SwComponentPrototypes
cp-path SwComponentPrototype-Path，参见第 6.3 节
dataElement / Element 端口接口的元素，类型为 AutosarDataPrototype。dataElements 是 PortInterface 的 VariableDataPrototypes
data element dataElements 是 PortInterface 的 VariableDataPrototypes
data prototype 一个 AutosarDataPrototype，如 VariableDataPrototype 或 ParameterDataPrototype 等
Descriptor <X>Descriptor：FlatMap 中目标元素 x 的 FlatInstanceDesriptor.shortName 的缩写形式（元素类型为 X）
Element Element 可能是原型元素，如 SwComponentPrototype、AutosarDataPrototype 等，也可能是 ARElement
MCD Measurement, Calibration and Diagnostic（测量、标定和诊断）
name 用作 ShortName 的缩写（除非另有说明）
parameter ParameterInterface 的元素，类型为 ParameterDataPrototype。parameters 是 PortInterface 的 ParameterDataPrototypes
pb-path PortPrototypeBlueprint-Path，参见第 6.3 节
P/L-list 物理和逻辑类型的缩写列表。参见第 17 章
port port prototype 或 port prototype blueprint —— 取决于上下文
SW Software（软件）
SW-C Software Component（软件组件）
virtual name space 本文档中我们使用术语"针对 {element} 或 {prototype} 的虚拟命名空间"来表示相应元素的名称在相应的 ARPackage 中是唯一的（递归地）。参见第 6.6 节

4 需求（Requirements）

以下是需求列表及其简短描述。

[RS_MCR_90000]

⌈ 对于显示名称，有时测量和标定工具或标定数据交换格式（例如 A2L）需要单个 ECU 内的全局命名空间。因此应支持这一点。⌋ ()

[RS_MCR_90001]

⌈ 对于 OEM 或供应商的单个标定团队：软件信号的显示名称应在由该团队标定的所有系统中稳定且相同，与项目、项目配置或基础产品或产品线软件架构无关。⌋ ()

[RS_MCR_90002]

⌈ 应有一个默认可派生的显示名称。⌋ ()

[RS_MCR_90003]

⌈ 应可能自动生成显示名称。⌋ ()

[RS_MCR_90004]

⌈ 应可能从显示名称自动生成/派生模型元素名称。⌋ ()

[RS_MCR_90005]

⌈ 应可以但实际上例外地为数据原型手动定义显示名称。另请参阅自动生成和默认显示名称的需求。⌋ ()

[RS_MCR_90006]

⌈ 显示名称应尽可能短。它不应超过 31 个字符。在最佳情况下，显示名称不超过 16 个字符。 在多个实例的情况下，名称长度可以延长以确保唯一性。 应考虑 MCD 工具的当前限制。⌋ ()

[RS_MCR_90008]

⌈ 在多个实例化的情况下，应确保在具有不同实例数量的项目中，具有相同语义的实例具有相同的显示名称。⌋ ()

[RS_MCR_90009]

⌈ 如果 MCD 工具不提供易于使用的机制来识别 maps、curves 等，则相应信息应作为显示名称本身的一部分。⌋ ()

[RS_MCR_90781]

⌈ 如果元素属于一起，应可能按字母顺序排序。⌋ ()

[RS_MCR_90782]

⌈ 对于属于一起的元素，应可能根据物理或逻辑意义对子组进行排序。⌋ ()

[RS_MCR_90011]

⌈ 命名约定应考虑每个项目约 20000 个与标定相关的名称。因此，可读性是重要的需求。⌋ ()

[RS_MCR_90783]

⌈ 测量和标定的建模规则或建议不应违反元模型中定义的通用 "shall" 命名规则。⌋ ()

[RS_MCR_90784]

⌈ 测量和标定的建模规则或建议不应违反 AUTOSAR_TR_SWCModelingGuide 中定义的通用 "shall" 命名规则。⌋ ()

[RS_MCR_90014]

⌈ 显示名称也应可用于遗留系统以实现全局变量。⌋ ()

[RS_MCR_90015]

⌈ 不同的数据应具有不同的显示名称。例如 A2L 不明确禁止对不同的数据使用相同的显示标识符。但是，使用此机制可能会导致混乱，似乎没有任何优势。⌋ ()

[RS_MCR_90016]

⌈ 在一个标定项目中，同一个软件信号应仅具有一个显示名称。⌋ ()

5 需求可追溯性（Requirements Traceability）

下表引用了第 4 章中指定的需求，并将其与这些需求的实现联系起来。

需求 描述 由以下规范项满足
RS_MCR_90000 - TR_MCG_00790、TR_MCG_00791、TR_MCM_70002
RS_MCR_90001 - TR_MCM_70040
RS_MCR_90002 - TR_MCG_00005、TR_MCG_00010、TR_MCG_00015、TR_MCG_00020、TR_MCG_00021、TR_MCG_00030、TR_MCG_00033、TR_MCG_00035、TR_MCG_00040、TR_MCG_00045、TR_MCG_00070、TR_MCG_00080、TR_MCG_00090、TR_MCG_00120、TR_MCG_00310、TR_MCG_00320、TR_MCG_00330、TR_MCG_00340、TR_MCG_00350、TR_MCG_00360、TR_MCG_00510、TR_MCG_00512、TR_MCG_00520、TR_MCG_00610、TR_MCG_00705、TR_MCG_00706、TR_MCG_00713、TR_MCG_00716、TR_MCG_00740、TR_MCG_00750、TR_MCG_00752、TR_MCG_00760、TR_MCG_00770、TR_MCG_00780、TR_MCG_00785、TR_MCG_00786、TR_MCG_00787、TR_MCG_00788、TR_MCG_00790、TR_MCG_00791
RS_MCR_90003 - （与 RS_MCR_90002 相同的规范项）
RS_MCR_90004 - TR_MCG_00785、TR_MCG_00786
RS_MCR_90005 - TR_MCG_00004
RS_MCR_90006 - TR_MCA_80020、TR_MCA_80030、TR_MCA_80530、TR_MCA_80710、TR_MCA_80715、TR_MCA_80720、TR_MCA_80730、TR_MCA_80789、TR_MCG_00010、TR_MCG_00015、TR_MCG_00020、TR_MCG_00030、TR_MCG_00045、TR_MCG_00120、TR_MCG_00713、TR_MCG_00740、TR_MCG_00750、TR_MCG_00752、TR_MCG_00790、TR_MCG_00791、TR_MCM_70020、TR_MCM_70022、TR_MCM_70030、TR_MCM_70040、TR_MCM_70390
RS_MCR_90008 - TR_MCA_80720、TR_MCA_80730、TR_MCG_00004
RS_MCR_90009 - TR_MCG_00090、TR_MCG_00310、TR_MCG_00320、TR_MCG_00330、TR_MCG_00340、TR_MCG_00350、TR_MCG_00510、TR_MCG_00520、TR_MCG_00790、TR_MCG_00791
RS_MCR_90011 - TR_MCG_00010、TR_MCG_00015、TR_MCG_00020、TR_MCG_00030、TR_MCG_00045、TR_MCG_00070、TR_MCG_00090、TR_MCG_00120、TR_MCG_00310、TR_MCG_00320、TR_MCG_00330、TR_MCG_00340、TR_MCG_00350、TR_MCG_00713、TR_MCG_00740、TR_MCG_00750、TR_MCG_00752、TR_MCM_70060
RS_MCR_90014 - TR_MCG_00001、TR_MCG_00790、TR_MCG_00791
RS_MCR_90015 - TR_MCA_80034、TR_MCG_00005、TR_MCG_00785、TR_MCG_00786、TR_MCG_00787、TR_MCG_00788、TR_MCG_00790、TR_MCG_00791
RS_MCR_90016 - TR_MCG_00785、TR_MCG_00786、TR_MCG_00787、TR_MCG_00790、TR_MCG_00791
RS_MCR_90781 - TR_MCM_70070
RS_MCR_90782 - TR_MCM_70050、TR_MCM_70065
RS_MCR_90783 - TR_MCM_70005
RS_MCR_90784 - TR_MCM_70010、TR_MCM_70060

6 方法论背景（Methodological Background）

以下各章提供了有关 AUTOSAR 元模型和方法论某些方面的背景信息。除第 6.6 和 6.7 章介绍了一些对于理解本文档以下主题很重要的新方面外，可以跳过这些章节。

6.1 SwCalibrationAccess

必须为 AutosarDataPrototypes 的所有实例提供显示名称，这些实例的属性 SwCalibrationAccess 通过其 SwDataDefProps 设置为 "readOnly" 或 "readWrite"。

信息 SwCalibrationAccess 对于 ApplicationDataTypes 是强制性的，但可以被覆盖。例如，SwCalibrationAccess 可以在 AutosarDataPrototypes 或 FlatInstanceDescriptor.swDataDefProps 等中被覆盖（参见 [5] 中的 [constr_1015]，[9] 中的 [SWS_Rte_07196]）。

在应用接口的当前标准化中（[3]），ApplicationDataTypes 的信息 SwCalibrationAccess 设置为 ReadOnly。

示例：

…
   <VARIABLE-DATA-PROTOTYPE>
      <SHORT-NAME>EngN</SHORT-NAME>
      <TYPE-TREF
            DEST="APPLICATION-DATA-TYPE">
                 /OEM1/ApplicationDataTypes/N1</TYPE-TREF>
      <SW-DATA-DEF-PROPS>…
          <SW-CALIBRATION-ACCESS>NOT-ACCESSIBLE</SW-CALIBRATION-ACCESS>
      …</SW-DATA-DEF-PROPS>
   </VARIABLE-DATA-PROTOTYPE>
…

覆盖了：

…
      <APPLICATION-PRIMITIVE-DATA-TYPE>
         <SHORT-NAME>N1</SHORT-NAME>
         <CATEGORY>VALUE</CATEGORY>
         <SW-DATA-DEF-PROPS>
           <SW-DATA-DEF-PROPS-VARIANTS>
             <SW-DATA-DEF-PROPS-CONDITIONAL> …
               <SW-CALIBRATION-ACCESS>READ-ONLY</SW-CALIBRATION-ACCESS>
             …</SW-DATA-DEF-PROPS-CONDITIONAL>
           </SW-DATA-DEF-PROPS-VARIANTS></SW-DATA-DEF-PROPS>
           …
      </APPLICATION-PRIMITIVE-DATA-TYPE>

6.2 FlatMap 用于测量和标定数据

SystemSignals 用于 ECU 间通信，而软件信号隐式用于 ECU 内部通信。没有称为软件信号的模型元素，因为它们由对 AutosarDataPrototype 的实例引用（InstanceRef）表示。然而，对于标定工程师来说，需要为软件信号提供唯一名称，类似于需要为 ECU 间通信提供唯一名称。这些软件信号的唯一名称与本文档中讨论的显示名称相同。

图 1：FlatMap [4]

AUTOSAR 方法论提供了指定唯一名称的方法，例如用于从中生成 A2L 文件 [10]。这是通过所谓的 FlatMaps 完成的（参见图 1）。FlatMap 由几个 FlatInstanceDescriptors 组成。在我们的上下文中，FlatInstanceDescriptor 恰好表示一个 VariableDataPrototype 或一个 ParameterDataPrototype，并为其附加一个唯一名称（shortName）。此 shortName 稍后可用作软件信号的显示名称。在 [4] 中，以下映射推荐用于 A2L：

FlatInstanceDescriptor.shortName ->
   MEASUREMENT Name for VariableDataPrototypes
   CHARACTERISTIC Name for ParameterDataPrototypes

在 [9] 第 4.2.8 章中，描述了 RTE 如何处理测量和标定。

[TR_MCM_70002]

⌈ 对于显示名称，单个 ECU 内的全局命名空间被建模为 FlatMap。 ⌋ (RS_MCR_90000)

包含一组软件信号显示名称定义的 FlatMap 实例是一个 XML 工件，可以由单个文件表示。根据其范围，它通过引用附加到系统描述的顶级组合或 ECU 提取的顶级组合（RootSwCompositionPrototype）。

映射表（FlatMap）可以手动维护，也可以自动生成显示名称。当然，也可以混合使用这两种方法。这种混合由 <<atpSplitable>> 支持。

图 2：AUTOSAR System EngN 示例

示例：

图 2 显示了 AUTOSAR 系统的示例。下面描述了显示名称为 "Eng_n" 的软件信号的 FlatMap：

<AR-PACKAGE>
 <SHORT-NAME>OEM1</SHORT-NAME>
 <AR-PACKAGES><AR-PACKAGE>
  <SHORT-NAME>FlatMaps</SHORT-NAME><ELEMENTS>
   <FLAT-MAP>
      <SHORT-NAME>OEMMap</SHORT-NAME>
      <INSTANCES>
         <FLAT-INSTANCE-DESCRIPTOR>
           <SHORT-NAME>Eng_n</SHORT-NAME>
              <UPSTREAM-REFERENCE-IREF>
                <CONTEXT-ELEMENT-REF DEST="ROOT-SW-COMPOSITION-PROTOTYPE">
                           /OEM1/Systems/System/TopLvl
                </CONTEXT-ELEMENT-REF>
                <CONTEXT-ELEMENT-REF DEST="SW-COMPONENT-PROTOTYPE">
                           /OEM1/SwComponentTypes/TopLvl/Eng
                </CONTEXT-ELEMENT-REF>
                <CONTEXT-ELEMENT-REF DEST="PORT-PROTOTYPE">
                          /OEM1/SwComponentTypes/Eng/EngN
                </CONTEXT-ELEMENT-REF>
                <TARGET-REF DEST="VARIABLE-DATA-PROTOTYPE">
                          /OEM1/PortInterfaces/EngN1/EngN
                </TARGET-REF>
             </UPSTREAM-REFERENCE-IREF>
         </FLAT-INSTANCE-DESCRIPTOR>
    </INSTANCES>
   </FLAT-MAP></ELEMENTS>
 </ELEMENTS>
</AR-PACKAGE>…

对于数组类型，如果只打算引用数组中的单个元素，则必须添加索引。数组第一个元素（INDEX: "0"）的示例（无图）：

<FLAT-INSTANCE-DESCRIPTOR>
  <SHORT-NAME>Esc_vWhlInd_0</SHORT-NAME>
    <UPSTREAM-REFERENCE-IREF>
      <CONTEXT-ELEMENT-REF DEST="ROOT-SW-COMPOSITION-PROTOTYPE">
                   /OEM1/Systems/System/TopLvl
      </CONTEXT-ELEMENT-REF>
      <CONTEXT-ELEMENT-REF DEST="SW-COMPONENT-PROTOTYPE">
                   /OEM1/SwComponentTypes/TopLvl/Pt
      </CONTEXT-ELEMENT-REF>
      <CONTEXT-ELEMENT-REF DEST="PORT-PROTOTYPE">
                   /OEM1/SwComponentTypes/Pt/EscVWhlInd
      </CONTEXT-ELEMENT-REF>
      <CONTEXT-ELEMENT-REF DEST="VARIABLE-DATA-PROTOTYPE">
         /OEM1/PortInterfaces/WhlSpdCircuml1/WhlSpdCircuml
      </CONTEXT-ELEMENT-REF>
      <TARGET-REF DEST="APPLICATION-ARRAY-ELEMENT" INDEX="0">
                   /OEM1/ApplicationDataTypes/WhlSpdCircumlPerWhl1
      </TARGET-REF>
      </UPSTREAM-REFERENCE-IREF>
   </FLAT-INSTANCE-DESCRIPTOR>

当只标准化 PortPrototypeBlueprints 而不标准化软件组件本身时，显示名称只能通过对 PortPrototypeBlueprint 的引用来标准化。在这种情况下，显示名称本身就是 blueprints，并用作从端口原型 blueprint 派生的端口原型的显示名称的基础。

图 3：AUTOSAR Blueprints EngN 示例

对于多实例化组件，显示名称不能完全标准化，因为通常既不知道实例的数量，也不知道实例的名称，而只知道在 ECU 级别。

由于 [6] 中的 [constr_2528]，引用 blueprints 的元素必须是 blueprint 本身或 BlueprintMap。定义 blueprints 显示名称的 FlatMap 也是 blueprint（即它必须是类别 Blueprint 的 ARPackage 的元素）。

示例，参见图 3：

假设端口原型 blueprint "EngN" 引用端口接口 "EngN1"。"EngN1" 本身可能就是 blueprint。对于 blueprint，必须添加 NamePattern。这适用于完整的 FlatMap 以及其单个 FlatInstanceDescriptors。在本例中，我们知道此 blueprint 没有多个实例化。因此，NamePattern 等于描述符的 ShortName（{blueprintName}）。

此外，引入了 BlueprintCondition 以表示例如并非所有标准化应用接口都存在于每个系统中。因此，允许派生一个包含比 blueprint FlatMap 更少元素加上其他元素的 FlatMap。

<AR-PACKAGE>
 <SHORT-NAME>AUTOSAR</SHORT-NAME>
 <AR-PACKAGES><AR-PACKAGE>
  <SHORT-NAME>FlatMaps_Blueprint</SHORT-NAME>
  <CATEGORY>BLUEPRINT></CATEGORY>
  <ELEMENTS>
    <FLAT-MAP>
       <SHORT-NAME NAME-PATTERN="{anyName}">ARMap</SHORT-NAME>
       <INSTANCES>
         <FLAT-INSTANCE-DESCRIPTOR>
         <SHORT-NAME NAME-PATTERN="{blueprintName}">
              AR_Eng_n
         </SHORT-NAME>
         <LONG-NAME><L-4 L="EN">Actual Engine Speed</L-4></LONG-NAME>
         <UPSTREAM-REFERENCE-IREF>
             <CONTEXT-ELEMENT-REF DEST="PORT-PROTOTYPE-BLUEPRINT">
                /AUTOSAR/PortPrototypeBlueprints_Blueprint/EngN
             </CONTEXT-ELEMENT-REF>
             <TARGET-REF DEST="VARIABLE-DATA-PROTOTYPE">
                /AUTOSAR/PortInterfaces_Blueprint/EngN1/EngN
             </TARGET-REF>
        </UPSTREAM-REFERENCE-IREF>
        <VARIATION-POINT>
          <SHORT-LABEL NAME-PATTERN="{blueprintName}">VP1</SHORT-LABEL>
          <BLUEPRINT-CONDITION>
            <P><L-1 L="EN">used only if port prototypes are derived from
                 this blueprint</L-1></P>
            <P><L-1 L="EN">The condition swSyscond has to be implemented
                 in the derived element (Upcoming)</L-1></P>
          </BLUEPRINT-CONDITION>
          <SW-SYSCOND>undefined</SW-SYSCOND></VARIATION-POINT>
     </FLAT-INSTANCE-DESCRIPTOR>
    </INSTANCES>
    </FLAT-MAP>
  </ELEMENTS>
 </AR-PACKAGE>…

之前呈现的 FlatMap 可能由此 blueprint FlatMap 派生，正式描述为：

<AR-PACKAGE>
  <SHORT-NAME>BlueprintMappingSets</SHORT-NAME>
  <ELEMENTS>
    <BLUEPRINT-MAPPING-SET>
      <SHORT-NAME>OEM1BlueprintMapSet</SHORT-NAME>
      <BLUEPRINT-MAPS>
        <BLUEPRINT-MAPPING>
          <BLUEPRINT-REF DEST="FLATMAP">
                /AUTOSAR/Flatmaps_Blueprint/ARMap
          </BLUEPRINT-REF>
          <DERIVED-OBJECT-REF DEST="FLAT-MAP">
                 /OEM1/Flatmaps/OEMMap
          </DERIVED-OBJECT-REF>
        </BLUEPRINT-MAPPING>
        <BLUEPRINT-MAPPING>
          <BLUEPRINT-REF
                DEST="PORT-PROTOTYPE-BLUEPRINT">
                 /AUTOSAR/PortPrototypeBlueprints_Blueprint/EngN
          </BLUEPRINT-REF>
          <DERIVED-OBJECT-REF DEST="P-PORT-PROTOTYPE">
              /OEM1/SwComponentTypes/Eng/EngN
          </DERIVED-OBJECT-REF>
        </BLUEPRINT-MAPPING>
        <BLUEPRINT-MAPPING>
          <BLUEPRINT-REF
                  DEST="SENDER-RECEIVER-INTERFACE">
                    /AUTOSAR/PortInterfaces_Blueprint/EngN1
          </BLUEPRINT-REF>
          <DERIVED-OBJECT-REF
                  DEST="SENDER-RECEIVER-INTERFACE">
                    /OEM1/PortInterfaces/EngN1
          </DERIVED-OBJECT-REF>
        </BLUEPRINT-MAPPING>
       </BLUEPRINT-MAPPING-SET>
    </ELEMENTS>
</AR-PACKAGE>

6.3 AliasNameSet 用于显示名称

AliasNameAssignment（参见图 4）可用于将替代名称关联到 flat instance descriptor 或 Identifiable [4]。

图 4：AliasNameAssignment [4]

在 [4] 中，以下映射推荐用于 A2L [10]：

AliasNameAssignment.shortLabel ->
   MEASUREMENT -> DISPLAY_IDENTIFIER for VariableDataPrototypes
   CHARACTERISTIC -> DISPLAY_IDENTIFIER for ParameterDataPrototypes
但
   SYSTEM_CONSTANT -> Name for SwSystemconsts

系统常数的示例：

<ALIAS-NAME-ASSIGNMENT>
  <SHORT-LABEL>ENGNRCYL_SC</SHORT-LABEL>
  <IDENTIFIABLE-REF DEST="SW-SYSTEMCONST">
      /OEM1/SwSystemconsts/EngNrCyl
  </IDENTIFIABLE-REF>
</ALIAS-NAME-ASSIGNMENT>

由于 FlatMaps 不允许引用 SwSystemconsts，因此使用别名机制为 SwSystemconsts 指定唯一的显示名称。

在 AUTOSAR 和 ASAM MCD-2MC [10] 中都不支持 SwSystemconsts 的别名或 DISPLAY_IDENTIFIER。

如果 r-ports 和 p-ports 都在 FlatMap 中有条目但在生成的 A2L 文件中应具有相同的名称，则也需要 AliasNameAssignments。在 FlatMap 中，r-ports 和 p-ports 的名称必须不同，因为 FlatMap 定义的命名空间。通常，p-port 的 FlatInstanceDescriptor 的 ShortName 用作 p-port 所连接的 r-ports 的别名名称。

此外，如果无法生成唯一的显示名称而只能生成要扩展以确保唯一性的显示名称的一部分，则使用此机制。这可能是 PortPrototypeBlueprints 的情况。

蓝图的别名的示例（例如已自动生成并现在打算"覆盖"的现有 flat instance descriptor）：

<ALIAS-NAME-ASSIGNMENT>
  <SHORT-LABEL NAME-PATTERN="{blueprintName}">Esc_vWhlIndFrntLe
  </SHORT-LABEL>
  <FLAT-INSTANCE-REF DEST="FLAT-INSTANCE-DESCRIPTOR">
      /AUTOSAR/Flatmaps/ARMap/Esc_vWhlInd_0
  </FLAT-INSTANCE-REF>…
</ALIAS-NAME-ASSIGNMENT>

本文档不包含 Units 的显示名称规则。尽管如此，这里有一些关于 units 的提示。units 在 [2] 或 [3] 中标准化。对于 Units，元模型提供了显式的 DisplayName 标记 [5]。我们有以下内容（[4] 和 [5]）：

AliasNameAssignment.shortLabel ->
   UNIT -> Name for Units
Unit.DisplayName ->
   UNIT -> Display for Units

请注意，AliasNameSet 的使用未在 AUTOSAR 中定义。它旨在由 AUTOSAR 未标准化的 A2L 生成器使用。尽管如此，[4] 给出了一些关于如何进行映射的建议。

6.4 SW Component Types 等的唯一符号名称

在某些情况下，RTE 要求唯一名称，即使元素包含在不同的命名空间中，以避免 c 代码中的名称冲突。对于这些情况，引入了**符号属性（SymbolProps）**的概念作为 ImplementationProps 的特殊情况 [5]。

符号属性仅适用于原子软件组件类型，因为组合被扁平化，在 c 代码中不可见。

<APPLICATION-SW-COMPONENT-TYPE>
   <SHORT-NAME>TMdl</SHORT-NAME>
   <SYMBOL-PROPS>
     <SHORT-NAME>AR_TMdl</SHORT-NAME>
     <SYMBOL>AR_TMdl</SYMBOL>
<SYMBOL-PROPS>
</APPLICATION-SW-COMPONENT-TYPE>

符号属性也适用于其他元素，例如 RunnableEntity 和 ImplementationDataType。

6.5 FlatMap 用于 SW Component Prototypes 的唯一名称

在系统的 ECU 提取中，需要 FlatMap 条目来为组件原型指定唯一名称 [4]。

示例：

该示例为组件原型 "Eng" 指定唯一名称。请注意，图 2 中的示例已通过附加组件层次结构 "Pt" 进行了扩展，以使示例更真实。

<FLAT-MAP>
   <SHORT-NAME>ARMap</SHORT-NAME>
   <INSTANCES>
         <FLAT-INSTANCE-DESCRIPTOR>
           <SHORT-NAME>Eng</SHORT-NAME>
           <UPSTREAM-REFERENCE-IREF>
             <CONTEXT-ELEMENT-REF DEST="ROOT-SW-COMPOSITION-PROTOTYPE">
                      /OEM1/Systems/System/TopLvl
             </CONTEXT-ELEMENT-REF>
              <CONTEXT-ELEMENT-REF DEST="SW-COMPONENT-PROTOTYPE">
                       /OEM1/SwComponentTypes/TopLvl/Pt
              </CONTEXT-ELEMENT-REF>
              <TARGET-REF DEST="SW-COMPONENT-PROTOTYPE">
                       /OEM1/SwComponentTypes/Pt/Eng
              </TARGET-REF>
           </UPSTREAM-REFERENCE-IREF>
        </FLAT-INSTANCE-DESCRIPTOR>
      </INSTANCES>
</FLAT-MAP>

6.6 虚拟命名空间（Virtual Name Spaces）

在本文档中，我们使用术语"针对 {element} 的虚拟命名空间"来表示某类 {element} 的所有元素的名称在特定 ARPackage 内是唯一的。这意味着对于作为此包子包的所有 ARPackage 以及根据元模型定义自己的命名空间的其他元模型元素（如 SwComponentTypes），将忽略此定义自己命名空间的属性。

还应考虑到 RTE [9] 对 AUTOSAR 元模型存在限制，即元模型允许定义比 RTE 的实际实现支持的更多的命名空间。例如 [SWS_Rte_07190] 要求 SwComponentTypes 的名称唯一，而不管 ARPackage 层次结构如何。但是，可以通过 SymbolProps（参见 6.4 节）在开发的后期阶段添加符号名称。

AUTOSAR 允许定义所谓的全局元素 [7]。全局元素可以通过使用此引用基来引用。这意味着这些元素的 ShortNames 在当前包内是唯一的（如果基是当前包），或者假定在引用的 ARPackage 中是唯一的。但是，它们的使用受到限制（[constr_2538]），不应被滥用于定义虚拟命名空间。

因此，AUTOSAR 不提供显式指定虚拟命名空间的可能性。

然而，正如我们稍后将看到的，我们需要包路径的缩写。这可以通过 AliasNameAssignments 实现。

示例：

<ALIAS-NAME-SET>
  <SHORT-NAME>NameSpaceAbbr</SHORT-NAME>
  <ALIAS-NAMES>
    <ALIAS-NAME-ASSIGNMENT>
      <SHORT-LABEL>AR_Types</SHORT-LABEL>
      <IDENTIFIABLE-REF DEST="AR-PACKAGE”>
            /AUTOSAR/SwComponentTypes</IDENTIFIABLE-REF>
    </ALIAS-NAME-ASSIGNMENT>
  </ALIAS-NAMES>
</ALIAS-NAME-SET>

6.7 文档中的引用（References in Documentation）

在文本文档中引用有几种可能性。在此上下文中，最重要的两种是：

  • 使用 Xref
  • 使用 Tt

两者都在段落（<P>）中使用。

示例：

<P>
  <L-1 L="EN">
     This is a direct reference to a system constant
     <XREF SHOW-RESOURCE-SHORT-NAME="SHOW-SHORT-NAME">
       <REFERRABLE-REF DEST="SW-SYSTEMCONST">
         /OEM1/SwSystemconsts/DIESEL
       </REFERRABLE-REF>
     </XREF>.
  </L-1>
</P>

这将例如被打印为：

"This is a direct reference to a system constant 'DIESEL'."

由于段落中不支持实例引用，一种可能性是首先定义 FlatInstanceDescriptor 并引用此元素。

示例：

<P>
  <L-1 L="EN">
     This is a reference to a sw signal
     <XREF SHOW-RESOURCE-SHORT-NAME="SHOW-SHORT-NAME">
       <REFERRABLE-REF DEST="FLAT-INSTANCE-DESCRIPTOR">
         /AUTOSAR/AISpecification/Flatmaps/PowertrainFlatmap/Eng_n
       </REFERRABLE-REF>
     </XREF>.
  </L-1>
</P>

这将例如被打印为：

"This is a reference to a sw signal 'Eng_n'."

如果没有 flat map，则也可以使用 DocumentContext 信息作为唯一名称。DocumentContext 与 FlatInstanceDescriptor 非常相似。

示例：

<DOCUMENTATION-CONTEXT>
  <SHORT-NAME>AR_Eng_n</SHORT-NAME>
  <FEATURE-IREF>
     <CONTEXT-ELEMENT-REF DEST="ROOT-SW-COMPOSITION-PROTOTYPE">
       /OEM1/Systems/System/TopLvl
     </CONTEXT-ELEMENT-REF>
     <CONTEXT-ELEMENT-REF DEST="SW-COMPONENT-PROTOTYPE">
       /AUTOSAR_AISpecification/SwComponentTypes/TopLvl/Pt
     </CONTEXT-ELEMENT-REF>
     <CONTEXT-ELEMENT-REF DEST="SW-COMPONENT-PROTOTYPE">
       /AUTOSAR_AISpecification/SwComponentTypes/Pt/Eng
     </CONTEXT-ELEMENT-REF>
     <CONTEXT-ELEMENT-REF DEST="PORT-PROTOTYPE">
       /AUTOSAR_AISpecification/SwComponentTypes/Eng/EngN
     </CONTEXT-ELEMENT-REF>
   </FEATURE-IREF>
</DOCUMENTATION-CONTEXT>

<P>
  <L-1 L="EN">
     This is a reference to a sw signal
     <XREF SHOW-RESOURCE-SHORT-NAME="SHOW-SHORT-NAME">
       <REFERRABLE-REF DEST="DOCUMENTATION-CONTEXT">
         /OEM1/Documentations/Eng_Docu/AR_Eng_n
       </REFERRABLE-REF>
     </XREF>.
  </L-1>
</P>

这将例如被打印为：

"This is a reference to a sw signal 'AR_Eng_n'."

在某些情况下，使用技术术语（即 Tt）也很有趣。如果满足一些先决条件，这甚至可以替代 XREF。

示例：

<P>
  <L-1 L="EN">
     This is a reference to system constant
     <TT TYPE="SwSystemconsts">DIESEL</TT>
     via a technical term.
  </L-1>
</P>

这将例如被打印为：

"This is a reference to system constant DIESEL via a technical term."

在技术术语概述章节中，将有一个标题 "SwSystemconsts"，以及一个条目 "DIESEL"，其中包含对此技术术语使用页面的引用：

"Technical Terms - SwSystemconsts DIESEL 23, 50, 90 "

Powertrain Explanation Document [11] 中的具体示例：给定相应的 xml 规范，可以自动派生此表：

<DOCUMENTATION-CONTENT>
  <TABLE>
    <TGROUP COLS="3">
      <COLSPEC COLNUM="1" COLNAME="col1" COLWIDTH="1.00*" />
      <COLSPEC COLNUM="2" COLNAME="col2" COLWIDTH="1.00*" />
      <COLSPEC COLNUM="3" COLNAME="col3" COLWIDTH="1.00*" />

      <THEAD>
        <ROW>
          <ENTRY COLNAME="col1">
            <P>
              <L-1 L="EN">
                 <TT TYPE="ARGlossary">DisplayName</TT> w/o Name Space.
                With Name Space add AR_ before name, e.g. AR_Abs_flgActv
              </L-1></P></ENTRY>
          <ENTRY COLNAME="col2">
            <P>
              <L-1 L="EN">
                 <TT TYPE="ARMetaModelElement">ShortName</TT> of Port
                 / additional information if needed</L-1></P></ENTRY>
          <ENTRY COLNAME="col3">
            <P>
              <L-1 L="EN">
                 <TT TYPE="ARMetaModelElement">LongName</TT> of
                 <TT TYPE="ARGlossary">DisplayName</TT> (= name
                 extended in case of multiple data prototypes or arrays)
              </L-1></P></ENTRY>
        </ROW></THEAD>

      <TBODY>
        <ROW>
          <ENTRY COLNAME="col1">
            <P>
              <L-1 L="EN">
                <XREF SHOW-RESOURCE-SHORT-NAME="SHOW-SHORT-NAME">
                  <REFERRABLE-REF DEST="FLAT-INSTANCE-DESCRIPTOR">
 /AUTOSAR/AISpecification/Flatmaps/PowertrainFlatmap/Pt_nClu
                  </REFERRABLE-REF></XREF></L-1></P></ENTRY>
          <ENTRY COLNAME="col2">
            <P>
              <L-1 L="EN">
                <XREF SHOW-RESOURCE-SHORT-NAME="SHOW-SHORT-NAME">
                  <REFERRABLE-REF DEST="PORT-PROTOTYPE-BLUERPRINT">
 /AUTOSAR/AISpecification/PortPrototypeBlueprints/PtNClu
                   </REFERRABLE-REF></XREF></L-1></P></ENTRY>
          <ENTRY COLNAME="col3">
            <P>
              <L-1 L="EN">
                <XREF SHOW-RESOURCE-LONG-NAME="SHOW-LONG-NAME">
                  <REFERRABLE-REF DEST="FLAT-INSTANCE-DESCRIPTOR">
  /AUTOSAR/AISpecification/Flatmaps/PowertrainFlatmap/Pt_nClu
                  </REFERRABLE-REF></XREF></L-1></P></ENTRY></ROW>
        <ROW>
          ...（其他 row 类似）...
      </TBODY>
    </TGROUP>
  </TABLE>
</DOCUMENTATION-CONTENT>

6.8 实例 cp-path 和 pb-path

在本章中，引入了一些新术语，允许对 flat instance descriptors 进行简短描述。在测量和标定的上下文中，数据原型是相关的。

定义。实例 cp-path（SwComponentPrototype-Path）是到软件组件原型的实例路径 + 其端口原型之一 + 端口原型的端口接口的数据原型之一（递归）：

{instance path to sw component prototype}/{port prototype}/{data prototype})1..n

例如：

/OEM1/Systems/System/TopLvl/Pt/Eng/EngN/EngN

即以 Backus Naur 形式：

/({ARPackage of System}/)1..n
{System.name}/
{RootSwCompositionPrototype.name}/
({SwComponentPrototype
    - part of referenced SwComponentType of
                RootSwCompositionPrototype or
                parent SwComponentPrototype resp.}/)0..n
{PortPrototype of referenced SwComponentType}
(/{AutosarDataPrototype of referenced PortInterface or
 within parent data prototype})1..n

父 sw component prototype 是指引用 SwComponentPrototype 所属 SwComponentType 的 SwComponentPrototype。例如在 cp-path /OEM1/Systems/System/TopLvl/Pt/Eng/EngN/EngN 中，"Pt" 是 "Eng" 的父 sw component prototype（参见本文档后面的示例）。

定义。实例 pb-path（PortPrototypeBlueprint-Path）是到端口原型 blueprint 的实例路径 + 端口原型 blueprint 的端口接口的数据原型之一：

{instance path to port prototype blueprint)/({data prototype})1..n

例如：

/AUTOSAR/PortPrototypeBlueprints_Blueprint/EngN/EngN

即以 Backus Naur 形式：

/({ARPackage of PortPrototypeBlueprint}/)1..n
{PortPrototypeBlueprint}
(/{AutosarDataPrototype of referenced PortInterface or
 within parent data prototype})1..n

7 整体建模和生成规则（Overall Modeling and Generation Rules）

[TR_MCM_70005]

⌈ 模型和生成的模型元素应符合元模型。 ⌋ (RS_MCR_90783)

本文档相关的元模型部分记录在 [4]、[5]、[6] 和 [7] 中。

[TR_MCM_70010]

⌈ 模型应符合 AUTOSAR_TR_SWCModelingGuide [1] 中定义的 Shall 规则。然而，可以违反建议和可选规则。 ⌋ (RS_MCR_90784)

[TR_MCG_00001]

⌈ 生成的显示名称应符合 C 编程语言。 ⌋ (RS_MCR_90014)

[TR_MCG_00004]

⌈ 如果手动定义的显示名称可用，则不应被生成的名称覆盖。 ⌋ (RS_MCR_90005、RS_MCR_90008)

有关 "shall" 和 "recommendation/should" 的解释，请参见第 3.1 节。

有两套单独的显示名称模式，一个用于原型，一个用于 ARElements。

[TR_MCG_00785]

⌈ 对于 ARElements，我们有以下名称部分：

element : {nameSpace}_{data}

其中

nameSpace : {ARPackage.name}(_{ARPackage.name})0..n
data : {ARElement.name}(_{typeId})

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90004、RS_MCR_90015、RS_MCR_90016)

{nameSpace} 对应于包层次结构，因为 ARPackages 定义了命名空间。{typeId} 对应于附加信息，例如标定参数。

下面讨论的元素是 PortPrototypeBlueprints、SwSystemconsts、Units 和 Systems。

[TR_MCG_00790]

⌈ 对于具有符号名称（SymbolProps）的 ARElements，我们有以下名称部分：

element : {ARElement.symbol}(_{typeId})

⌋ (RS_MCR_90000、RS_MCR_90002、RS_MCR_90003、RS_MCR_90006、RS_MCR_90009、RS_MCR_90014、RS_MCR_90015、RS_MCR_90016)

现在介绍原型的显示名称模式：

[TR_MCG_00786]

⌈ 对于原型，我们有以下名称部分：

prototype : {nameSpace}_{componentHierarchy}_{data}

其中

nameSpace : ({ARPackage.name}_)1..n{System.name}
componentHierarchy : ({SwComponentPrototype.name}_)0..n
或
componentHierarchy : {RootSwCompositionPrototype.name}

{data} 根据原型的种类而有所不同。

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90004、RS_MCR_90015、RS_MCR_90016)

{nameSpace} 对应于相关系统的路径。{componentHierarchy} 考虑 SwComponentPrototypes 层次结构，包括多个实例化。RootSwCompositionPrototype 通常可以在 {componentHierarchy} 中忽略，因为一个系统内恰好有一个。仅当端口直接属于根组件时，其名称才是相关的。

{data} 指的是端口及其端口接口的数据原型之一加上可选后缀。有关 {data} 的详细信息，请参见下一章。

[TR_MCG_00791]

⌈ 对于具有符号名称（SymbolProps）的原型，我们有以下名称部分：

prototype : {Prototype.symbol}

⌋ (RS_MCR_90000、RS_MCR_90002、RS_MCR_90003、RS_MCR_90006、RS_MCR_90009、RS_MCR_90014、RS_MCR_90015、RS_MCR_90016)

下面讨论的原型是 SwComponentPrototypes 和 PortInterface 的 AutosarDataPrototypes（例如数组等复杂数据类型）。注意：PortPrototypeBlueprints 是元素而不是原型。PortPrototype 名称本身仅作为显示名称的一部分相关，但在测量和标定上下文中本身并不相关。

下面我们将仔细查看每个名称部分，并讨论如何缩短它或在哪些情况下可以完全省略该名称部分。

7.1 名称部分长度（Name Part Length）

软件信号的显示名称不应超过 31 个字符。因此我们建议遵循以下规则。我们意识到这并不总是可能的。

[TR_MCM_70022]

⌈ 软件信号的 {nameSpace} 不应超过 3 个字符。 ⌋ (RS_MCR_90006)

[TR_MCM_70020]

⌈ 建议进一步限制与生成显示名称相关的模型元素名称的长度。AutosarDataPrototype 名称和 PortPrototype 名称不应超过 23 个字符。 ⌋ (RS_MCR_90006)

[TR_MCM_70390]

⌈ 用于区分 AutosarDataPrototypes 的不同类型标识符（{typeId}）的后缀不应超过 3 个字符。 ⌋ (RS_MCR_90006)

8 数据原型（Data Prototypes）

在本章中，我们处理 {data} 所需的 {dataInfo} 名称部分。

[TR_MCG_00021]

⌈

{dataInfo} 指一个 AutosarDataPrototype。
对于原始类型，我们有：
  dataInfo : {AutosarDataPrototype.name}
对于复杂类型，我们有：
  dataInfo :
  {AutosarDataPrototype.name}
  (_{parentData})0..n_{AutosarDataPrototype.name}
其中
  parentData : ({AutosarDataPrototype.name}|{index})

{index} 在 ArrayElements 的情况下是必需的。

⌋ (RS_MCR_90002、RS_MCR_90003)

Records 的示例：

假设我们有端口原型 LockgCenSts 引用 PortInterface LockgCenSts，其中包含数据元素 LockgCenSts 和以下 ApplicationRecordDataType：

ShortName: LockgCenSts1
   recordElement 1: LockgSt
   recordElement 2: TrigSrc

那么我们将有：

dataInfo : LockgCenSts_LockgSt
或
dataInfo : LockgCenSts_TrigSrc

取决于您感兴趣的两个软件信号中的哪一个。

由于 ArrayElements 没有名称，因此只能使用索引号进行自动生成。因此，在这种情况下，手动定义显示名称通常更好。

数组在第 6.2 章中处理；它们将需要 {index} 名称部分。请注意，上面的 {parentData} 可能是 ArrayElement。

Arrays 的示例：

4 元素数组 EscVWhlInd 的单个元素的显示名称可以使用 [TR_MCG_00021] 生成：

Esc_vWhlInd_0, Esc_vWhlInd_1, Esc_vWhlInd_2 and Esc_vWhlInd_3

或者 - 手动扩展数组本身的生成显示名称：

Esc_vWhlIndFrntLe, Esc_vWhlIndFrntRi,
Esc_vWhlIndReLe and Esc_vWhlIndReRi

分别用于左前轮等。

9 数据接口中的数据原型（Data Prototypes in DataInterfaces）

在本章中，我们处理数据接口的 {data} 名称部分。通用模式是（参见 [TR_MCG_00786]）：

data : {port}_{dataInfo}_{typeId}

[TR_MCG_00005]

⌈ 对于数据接口内数据原型的 {data}，我们有以下名称部分：

data : {port}_{dataInfo}(_{typeId})0..1

{port} 可以指 PortPrototype 或 PortPrototypeBlueprint，即

port : (PortPrototype.name)
或
port : {PortPrototypeBlueprint.name}

{dataInfo} 指端口的数据接口中扮演 dataElement、parameter 或 nvData 角色的一个数据原型。

{typeId} 取决于最终数据原型的类型。

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90015)

示例：

假设我们有端口原型 LockgCenSts 引用 PortInterface LockgCenSts，其中包含数据元素 LockgCenSts 和以下 ApplicationRecordDataType：

ShortName: LockgCenSts1
   recordElement 1: LockgSt
   recordElement 2: TrigSrc

那么我们将有：

data : LockgCenSts_LockgCenSts_LockgSt
或
data : LockgCenSts_LockgCenSts_TrigSrc

取决于您感兴趣的两个软件信号中的哪一个。

{data} 名称部分通常相当长，包含大量冗余，并且并不总是满足所有需求。根据特定的附加规则和假设，此名称可以缩短。

这些规则和假设记录在下面。

只有以下四条规则 [TR_MCG_00010]、[TR_MCG_00015]、[TR_MCG_00020] 和 [TR_MCG_00030] 中的一条可以应用。

[TR_MCG_00010]

⌈ 如果数据元素名称与端口名称相同，则可以忽略元素的显示名称中的端口原型或端口原型 blueprint 名称。我们有：

data : {dataInfo}(_{typeId})0..1

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90006、RS_MCR_90011)

[TR_MCG_00015]

⌈ 如果数据元素名称与 "Val"（表示 "Value"）相同，则可以忽略显示名称中的数据原型名称。

对于原始类型，我们有：

data : {port}(_{typeId})0..1

对于复杂类型，我们有：

data : {port}_{dataInfo}(_{typeId})0..1

其中

dataInfo :
 ({parentData}_)0..n{AutosarDataPrototype.name}

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90006、RS_MCR_90011)

[TR_MCG_00020]

⌈ 如果 PortInterface 恰好包含一个数据元素，则可以忽略显示名称中的数据元素名称。

对于原始类型，我们有：

data : {port}(_{typeId})0..1

对于复杂类型，我们有：

data : {port}_{dataInfo}(_{typeId})0..1

其中

dataInfo :
({parentData}_)0..n{AutosarDataPrototype.name}

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90006、RS_MCR_90011)

[TR_MCG_00030]

⌈ 如果

  1. PortInterface 包含多个数据元素，并且
  2. PortPrototype 或 PortPrototypeBlueprint 名称是数据元素名称的子字符串

则可以忽略显示名称中的端口名称。我们有：

data : {dataInfo}(_{typeId})0..1

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90006、RS_MCR_90011)

示例 1：

从第 6.2 章图 2 中取 {port}_{data} 的以下示例（具有原始数据类型）：

EngN_EngN
EngNMax_EngN

以及以下示例：

EngN_Val

最后，以下示例假设端口接口有两个数据原型 EngNMax 和 EngNMin：

EngN_EngNMax

规则 [TR_MCG_00010]、[TR_MCG_00015]、[TR_MCG_00020] 和 [TR_MCG_00030] 将分别导致：

EngN 或 EngN
EngNMax
EngN
EngNMax

示例 2：

参见上文，我们的记录示例 LockgCenSts 将导致（[TR_MCG_00010]）：

data : LockgCenSts_LockgSt
或
data : LockgCenSts_TrigSrc

取决于您感兴趣的两个软件信号中的哪一个。

可以为复杂数据类型内的数据原型添加类似的规则。

9.1 提高显示名称的可读性（Increase Readability of Display Names）

为了进一步提高显示名称的可读性，建议采用以下建模规则。

我们上一章的示例非常短，例如：

EngN

但是，生成的名称也可能看起来像这样：

TrsmCluStTar

甚至可能更长。在这种情况下，指出 AutosarDataPrototype 的 mean/source 以及物理或逻辑含义并在其前面加上下划线将提高可读性：

TrsmClu_StTar

为了进一步提高可读性，物理或逻辑类型应以小写字母书写：

TrsmClu_stTar

为了能够做到这一点，需要额外的生成和建模规则：

[TR_MCM_70050]

⌈ 应有一个小而可管理的物理和逻辑类型列表，用于生成显示名称。此列表称为 P/L-list。 ⌋ (RS_MCR_90782)

在第 17 章中，介绍了 Powertrain 域的这种 P/L-List 的建议。

[TR_MCM_70060]

⌈ P/L-List 是 AUTOSAR_MOD_AISpecification [3] 中关键字缩略语的子集。 ⌋ (RS_MCR_90011、RS_MCR_90784)

然而，AUTOSAR_MOD_AISpecification [3] 的所有物理类型或操作并非 P/L-list 的元素；它会太大。属于 "Physical Type/Action" 语义字段之外的其他关键字也可能属于 P/L-list。例如，建模指南中的字段 "Physical type/Action" 不包含逻辑类型，但这些类型对于区分控制流和功能软件信号非常有用。

[TR_MCM_70065]

⌈ 假设 P/L-list 不为空，则每个 AutosarDataPrototype 名称应至少包含一个来自 P/L-list 的关键字。 ⌋ (RS_MCR_90782)

P/L-list 可以为空。然后对显示名称生成和建模没有影响。

[TR_MCG_00070]

⌈ 对于生成显示名称，只有 P/L-list 中关键字在端口或数据元素名称中的第一次出现是相关的：在关键字之前添加下划线并以小写字母书写关键字。如果既有端口原型名称又有数据原型名称，则它们之间的下划线被删除。 ⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90011)

示例：

假设我们有 {port}_{AutosarDataPrototype.name} : EngN_Max。然后规则 [TR_MCG_00070] 导致：

Eng_nMax

[TR_MCG_00080]

⌈ 如果名称以 P/L-list 中的关键字开头，则不在 P/L-list 中的关键字之前添加 "_"。 ⌋ (RS_MCR_90002、RS_MCG_00003)

原因：在 FlatMap 中，Identifiables 用作显示名称。对于 Identifiables，不允许以下划线 "_" 开头或包含 "__" [7]。

[TR_MCM_70070]

⌈ PortPrototype 或 PortPrototypeBlueprint 名称不应以 P/L-list 中的关键字开头。即，建议首先向其添加分类为 "Mean-Environment-Device" 的关键字或其他语义信息。 ⌋ (RS_MCR_90781)

上述规则导致 [6] 中名称模式语言语法的以下模式：

displayName : ({part1)_}0..1 ({physLog})0..1 {part2}(_{typeId})0..1
其中
part1 : ( ({keyword}) 1..n ({index}) 0..n)1..n
physLog : {keyword from P/L-List, written in small letters}
part2 : ({keyword} | {index} | '_')0..n
typeId : { 'MP' | 'SC' | 'C' | 'T' | 'M' | 'CA' | 'Ax' }

下面描述了允许的后缀种类。

9.2 SenderReceiverInterfaces 中的 VariableDataPrototypes

为了区分可运行间交换所需的变量和仅为测量目的定义的变量，定义以下规则：

[TR_MCG_00090]

⌈ 对于仅用作测量点的 VariableDataPrototypes 的显示名称，添加后缀 "_MP"。我们有：

data : {port}_{dataInfo}_MP

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90009、RS_MCR_90011)

数据原型是否为测量点在 SwDataDefProps 的 SwImplPolicy 中指定。

示例：

假设以下软件信号仅用于测量目的：TrsmClu_stTar。使用规则 [TR_MCG_00090]，我们得到 TrsmClu_stTar_MP。

9.3 ParameterInterface 中的 ParameterDataPrototypes

参数的类型由其数据类型的类别表征，例如 MAP、CURVE [5]。如果 AutosarDataPrototype 是作为 ApplicationCompositeElementDataPrototype 的一部分的 ParameterDataPrototype 的参数，或者它本身是 ParameterDataPrototype，则它充当参数的角色。

如果可以一眼看出它是变量还是参数，可读性会提高。因此，添加了以下规则以将参数与变量区分开：

[TR_MCG_00310]

⌈ 对于作为单个数据点（ApplicationDataType 的类别等于 VALUE、STRING 或 BOOLEAN）的参数的 AutosarDataPrototype 的显示名称，添加后缀 "_C"（表示 "constant"）。我们有：

data : {port}_{dataInfo}_C

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90009、RS_MCR_90011)

[TR_MCG_00320]

⌈ 对于作为具有一个轴（依赖关系）的数据点集（ApplicationDataType 的类别等于 CURVE）的参数的 AutosarDataPrototype 的显示名称，添加后缀 "_T"（表示 "table" 或 "curve"）。我们有：

data : {port}_{dataInfo}_T

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90009、RS_MCR_90011)

[TR_MCG_00330]

⌈ 对于作为具有两个轴（依赖关系）的二维数据点集（ApplicationDataType 的类别等于 MAP）的参数的 AutosarDataPrototype 的显示名称，添加后缀 "_M"（表示 "map"）。我们有：

data : {port}_{dataInfo}_M

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90009、RS_MCR_90011)

[TR_MCG_00340]

⌈ 对于类型为 ApplicationArrayDataType 且 ApplicationArrayElements 的类型为 CURVE 或 VAL_BLK 的参数的 AutosarDataPrototype 的显示名称，添加后缀 "_CA"（表示 "array of calibration parameters"）。我们有：

data : {port}_{dataInfo}_CA

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90009、RS_MCR_90011)

[TR_MCG_00350]

⌈ 对于具有轴元素（类别 COM_AXIS 和 RES_AXIS）的参数的 AutosarDataPrototype 的显示名称，添加后缀 "_Ax"（表示 "axis"）。我们有：

data : {port}_{dataInfo}_Ax

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90009、RS_MCR_90011)

对于 ParameterDataPrototypes 的其他类别，应添加其他后缀。

示例：

CtryNrCod

将导致（假设 CtryNrCod 是 VALUE 类别的参数，"Nr" 是 P/L-list 的一部分，并应用规则 [TR_MCG_00310]）：

Ctry_nrCod_C

10 ClientServerInterfaces 中的数据原型（Data Prototypes in ClientServerInterfaces）

在本章中，我们处理 client server 接口的 {data} 名称部分。通用模式是：

data : {port}_{operationInfo}_{typeId}

[TR_MCG_00360]

⌈ 对于 client server 接口内数据原型的 {data}，我们有以下名称部分：

data : {port}_{operationInfo}(_{typeId})0..1

{port} 可以指 PortPrototype 或 PortPrototypeBlueprint，即

port : (PortPrototype.name)
或
port : {PortPrototypeBlueprint.name}

对于 {operationInfo}，我们有：

operationInfo: {ClientServerOperation.name}_{dataInfo}

其中 {dataInfo} 是操作的参数之一（ArgumentDataPrototype）的数据原型信息。

{typeId} 取决于最终数据原型的类型。

⌋ (RS_MCR_90002、RS_MCR_90003)

10.1 InternalBehavior 中的数据原型

在本章中，我们处理 InternalBehavior 中 AutosarDataPrototypes 的 {data} 名称部分。

对于 InterhalBehavior，我们有：

  • constantMemory
  • staticMemory

对于 SwcInternalBehavior，我们有：

  • arTypedPerInstanceMemory
  • explicitInterRunnableVariable
  • implicitInterRunnableVariable
  • perInstanceParameter
  • sharedParameter

对于 BswInternalBehavior，我们有：

  • perInstanceParameter

通用模式是：

data : {swcInternalBehavior}_{dataInfo}_{typeId}

假设 internal behavior 不会在不同的 SwComponentTypes 或 BswModuleDescriptions 中重用，即假设每个 SwcInternalBehavior 至多有一个 SwComponentType，每个 BswBehavior 至多有一个 BswModuleDescription。

SwcInternalBehavior 为内部数据原型定义命名空间，类似于请求或提供的数据原型的端口原型。因此它也必须被考虑。只有原子组件才具有 internal behavior。

[TR_MCG_00033]

⌈ 对于 InternalBehavior 内数据原型的 {data}，我们有以下名称部分：

data : {swcInternalBehavior}_{dataInfo}(_{typeId})0..1

其中

swcInternalBehavior : {{SwcInternalBehavior.name} | Int}

"Int" 是 "Internal" 的缩写。组件的任何 PortPrototype 都不得具有与 "Int" 相同的名称。否则应使用 SwcInternalBehavior 的名称以使名称唯一。

{dataInfo} 指充当 arTypedPerInstanceMemory、explicitInterRunnableVariable、implicitInterRunnableVariable、perInstanceParameter、sharedParameter、constantMemory 或 staticMemory 角色的 AutosarDataPrototype。

{typeId} 取决于最终数据原型的类型。

⌋ (RS_MCR_90002、RS_MCR_90003)

[TR_MCA_80034]

⌈ 组件的任何 PortPrototype 都不得具有与 "Int" 相同的名称。"Int" 保留为 internal behavior 的缩写。 ⌋ (RS_MCR_90015)

11 命名空间（Name Space）

在本章中，我们处理命名空间标识符 {nameSpace}。ARElements（{element}）的命名空间的通用模式是（参见 [TR_MCG_00785]）：

nameSpace : ({ARPackage.name}/)1..n

原型（{prototype}）的命名空间的通用模式是（参见 [TR_MCG_00786]）：

nameSpace : ({ARPackage.name}/)1..n_{System.name}

有关 AUTOSAR 命名空间概念的详细信息，请参见 [7]。虚拟命名空间在第 6.6 章中定义。

每个元素都是 ARPackage 的一部分。一些原型元素（如 SwComponentPrototypes）是不同命名空间的元素，对于 SwComponentPrototypes 它是 SwComponentType。对于这些，{componentHierarchy} 比组件类型所属的 ARPackage 更为重要。但对于 PortPrototypeBlueprints、Units、System 等 ARElements，{nameSpace} 非常重要。

下面给出了一些关于如何处理 {nameSpace} 的规则。

[TR_MCM_70030]

⌈ 可以为 ARPackage 内的元素定义 {nameSpace} 的任意缩写。 ⌋ (RS_MCR_90006)

[TR_MCM_70040]

⌈ 对于预定义 ARPackage "AUTOSAR" 内的元素，应使用缩写 "AR" 作为 {nameSpace} 的一部分。 ⌋ (RS_MCR_90001、RS_MCR_90006)

[TR_MCG_00035]

⌈ 生成的显示名称内的包路径应通过使用定义的缩写来缩短。 ⌋ (RS_MCR_90002、RS_MCR_90003)

如第 6.6 章所述，AliasNameAssignments 可用于正式指定此类路径的缩写。

示例：

假设我们为路径定义以下缩写：

AUTOSAR/SwComponentTypes → AR_Types

那么规则 [TR_MCG_00035] 将导致：

nameSpace : AR_Types

而不是 AUTOSAR_SwComponentTypes。

请注意，short label 选择为 "AR_Types" 而不是 "Types" 或 "hugo"：这是因为 [TR_MCM_70040] 仍应满足，即 AUTOSAR 显示名称应有命名空间。

[TR_MCG_00120]

⌈ 如果 ARPackage 属于元素类的虚拟命名空间，则可以忽略该元素的显示名称中的包名称。仅定义虚拟命名空间的 ARPackage 的名称和此 ARPackage 本身的 {nameSpace} 应被考虑。 ⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90006、RS_MCR_90011)

示例：

在 /AUTOSAR/AISpecification/PortPrototypesBlueprints_Blueprint/ 中，/AUTOSAR/ 当前为所有端口原型 blueprints 定义虚拟命名空间。因此使用 [TR_MCG_00120]，blueprint 的显示名称可以缩短为：

element : {portBlueprint} : AUTOSAR_{data}

使用 [TR_MCG_00035] 和 [TR_MCM_70040]，名称可以进一步缩短为 AR_{data}。

如果我们不能确保 /AUTOSAR/ 的唯一性，那么我们只能说 /AUTOSAR/AISpecification 为所有端口原型 blueprints 定义虚拟命名空间。因此使用 [TR_MCG_00120]，blueprint 的显示名称只能缩短为：

portBlueprint : AUTOSAR_AISpecification_{data}

AUTOSAR 是 ARPackage AISpecification 的 {nameSpace}。

[TR_MCA_80710]

⌈ 假设：与显示名称生成相关的只有一个 System。 ⌋ (RS_MCR_90006)

此假设通常满足，因为不需要在不同系统上保持显示名称一致：FlatMap 始终仅覆盖一个系统或一个 ECU，但以不同的变体形式。

[TR_MCG_00713]

⌈ 如果只有一个 system，则 {nameSpace}（即 ARPackages 的名称以及 system 名称）可以忽略原型元素的显示名称。我们有：

prototype : {componentHierarchy}_{data}

原因：起点是 System 的 RootSwCompositionPrototype。

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90006、RS_MCR_90011)

在规则 [TR_MCG_00713] 中，假设 [TR_MCA_80710] 假定已满足：只有一个 system。

如果有一个 FlatMap 为 System 定义唯一名称，则此名称也可用作 {nameSpace}。

[TR_MCG_00770]

⌈ 在 FlatMap 中为 System 指定的显示名称可用于指定软件信号的显示名称的 {nameSpace} 名称部分。

通用规则：

nameSpace : {systemDescriptor}

⌋ (RS_MCR_90002、RS_MCR_90003)

12 SwSystemconsts

在编译时已计算的常量值在 MCD 系统中也可以是可见的（"readOnly"）。对于系统常数（element : {systemconst}），通用模式定义如下（参见 [TR_MCG_00785]）：

systemconst : {nameSpace}_{SwSystemconst.name}_{typeId}

[TR_MCG_00510]

⌈ 对于 SwSystemconst 的显示名称，添加后缀 "_SC"（表示 "software configuration"）。我们有：

systemconst : {nameSpace}_{data}

其中

data : {SwSystemconst.name}_SC

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90009)

[TR_MCG_00520]

⌈ 对于 SwSystemconst 的显示名称，仅使用大写字母。 ⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90009)

请注意：[TR_MCG_00070] 不适用于系统常数。这是因为系统常数通常不包含物理或逻辑信息，而是表示功能或特性。

[TR_MCA_80530]

⌈ 假设：对于系统常数，恰好有一个虚拟命名空间 sw。 ⌋ (RS_MCR_90006)

[TR_MCG_00512]

⌈ 如果只有一个 system 且对于 SwSystemconsts 恰好有一个虚拟命名空间，我们有：

systemconst : {SwSystemconst.name}_SC

⌋ (RS_MCR_90002、RS_MCR_90003)

在规则 [TR_MCG_00512] 中，假设 [TR_MCA_80530] 和 [TR_MCA_80710] 假定已满足。

示例：

/OEM1/SwSystemconsts/EngNrCyl

将导致（应用 [TR_MCG_00510]、[TR_MCG_00520]；假设名称唯一性（[TR_MCA_80530]）；甚至假设 "Nr" 是 P/L-list 的一部分）：

ENGNRCYL_SC

13 PortPrototypeBlueprints

在本章中，我们处理 port prototype blueprints 的唯一名称。由于 PortPrototypeBlueprints 是 ARElements（{element} : {portBlueprint}），通用模式是（参见 [TR_MCG_00785]）：

portBlueprint : {nameSpace}_{data}

其中

nameSpace : ({ARPackage.name}_)1..n
data : {port}_{dataInfo}

{typeId} 与 port prototype blueprints 无关，因为它们本身不能被测量或标定，但可能仅用作软件信号的显示名称的一部分。

[TR_MCG_00788]

⌈ 对于 port prototype blueprints，以下基本显示名称模式

portBlueprint : {nameSpace}_ {data}

用于生成单个数据元素的显示名称。

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90015)

port prototype blueprint 的相应路径是：

({ARPackage.name}/)1..n{PortPrototypeBlueprint.name}

端口接口名称被忽略。

对于第 6.2 章图 3 中示例中的数据原型 EngN，完整的实例 pb-path 是：

AUTOSAR/PortPrototypeBlueprints_Blueprint/EngN/EngN

根据 [TR_MCG_00788] 没有任何缩短的生成显示名称将是：

AUTOSAR_PortPrototypeBlueprints_Blueprint_EngN_EngN

此名称相当长，包含大量冗余，并不满足所有需求。根据特定的附加规则和假设，此名称可以缩短。port 和 data 原型的规则可在第 8 章中找到。缩短命名空间标识符的规则可在第 11 章中找到。整体规则可在第 7 章中找到。

下面我们将就虚拟命名空间做一些假设。如果这些假设在系统中得到满足，则显示名称可以进一步缩短。虚拟命名空间在第 6.6 章中定义。

示例（继续第 6.2 章中的图 2 和图 3）：

假设 ARPackages "AUTOSAR" 和 "OEM1" 为 port prototype blueprints 定义虚拟命名空间。在此虚拟命名空间内，port prototype blueprint 名称是唯一的。鉴于此附加信息，数据原型 "EngN" 的生成显示名称将是（[TR_MCM_70040]、[TR_MCG_00120]）：

AR_EngN

如果只有一个虚拟命名空间（[TR_MCA_80030]）涵盖 "AUTOSAR" 和 "OEM1" 包，则名称甚至可以减少为：

EngN

下面我们将正式表达这些假设和规则：

Port prototype blueprint 名称在给定包内是唯一的，不需要关于给定 ARPackage 内 port prototype blueprint 名称唯一性的附加假设。

为了能够应用 [TR_MCG_00120]（参见第 11 章），应为 port prototype blueprints 满足以下假设：

[TR_MCA_80020]

⌈ 假设：每个 Top-Level ARPackage 为 port prototype blueprints 定义虚拟命名空间。 ⌋ (RS_MCR_90006)

以下规则包含在规则 [TR_MCG_00120] 中，因此不定义任何新内容。为了更好地理解，明确说明。

[TR_MCG_00040]

⌈ 只有在产品或产品系列内为 port prototype blueprints 显式定义虚拟命名空间的包才应在显示名称中考虑。 ⌋ (RS_MCR_90002、RS_MCR_90003)

示例：

使用规则 [TR_MCG_00040] 和 [TR_MCM_70040] 以及假设 [TR_MCA_80020]，AR_PortPrototypeBlueprints_Blueprint_EngNMax 可以缩短为 AR_EngNMax。

[TR_MCA_80030]

⌈ 假设：对于 port prototype blueprints 恰好有一个虚拟命名空间。 ⌋ (RS_MCR_90006)

[TR_MCG_00045]

⌈ 如果对于 port prototype blueprints 只有一个虚拟命名空间，则 {nameSpace}（即所有 ARPackage 名称）可以完全忽略在显示名称中。我们有：

portBlueprint : {data}

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90006、RS_MCR_90011)

在 [TR_MCG_00045] 中，假设 [TR_MCA_80030] 假定已满足。

示例：

使用规则 [TR_MCG_00045] 和假设 [TR_MCA_80030]，AR_EngNMax 可以进一步缩短为 EngNMax。

14 组件层次结构（ComponentHierarchy）

在本章中，我们处理组件层次结构 {componentHierarchy}。{componentHierarchy} 与原型（{prototype}）相关。通用模式是：

componentHierarchy : {RootSwCompositionPrototype.name}
                    (_{SwComponentPrototype.name})0..n

组件层次结构与软件信号相关，因为它们总是在 SwComponentPrototype 的上下文中实例化。它们与 port prototype blueprints 和 ARPackage 的其他第一类元素无关。

[TR_MCG_00705]

⌈ {componentHierarchy} 定义如下：

componentHierarchy : {RootSwCompositionPrototype.name}
                    (_{SwComponentPrototype.name})0..n

⌋ (RS_MCR_90002、RS_MCR_90003)

在规则 [TR_MCG_00706] 中，假设 [TR_MCA_80710]（参见第 11 章）假定已满足：只有一个 system。

[TR_MCG_00706]

⌈ 如果只有一个相关 System，则 {componentHierarchy} 定义如下：

componentHierarchy : {SwComponentPrototype.name}
                    (_{SwComponentPrototype.name})0..n
或
componentHierarchy : {RootSwCompositionPrototype.name}

⌋ (RS_MCR_90002、RS_MCR_90003)

为了能够应用 [TR_MCG_00120]（参见第 11 章），应为 sw component prototypes 满足以下假设之一：

类似于 [TR_MCA_80020]，我们有：

[TR_MCA_80715]

⌈ 假设：Sw component prototype 名称在给定 ARPackage 内是唯一的，即此 ARPackage 为 SwComponentPrototypes 定义虚拟命名空间。 ⌋ (RS_MCR_90006)

[TR_MCA_80720]

⌈ 假设：每个 Top-Level ARPackage 为 sw component prototypes 定义单独的虚拟命名空间。 ⌋ (RS_MCR_90006、RS_MCR_90008)

[TR_MCG_00740]

⌈ 如果 ARPackage 为 SwComponentPrototypes 定义虚拟命名空间，则此包内定义的 sw component prototypes 的父 sw component prototype 名称可以忽略在软件信号或 sw component prototype 的显示名称中 - 除了第一个以及具有相同 SwComponentType 的那些（即同一 SwComponentType 的多个实例）。 ⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90006、RS_MCR_90011)

在规则 [TR_MCG_00740] 中，假设 [TR_MCA_80715] 假定已满足。

第一个 sw component prototype 名称是必要的，因为不能排除在不同包中具有相同名称的 sw component prototypes。

[TR_MCA_80730]

⌈ 假设：对于 sw component prototypes 恰好有一个虚拟命名空间。 ⌋ (RS_MCR_90006、RS_MCR_90008)

[TR_MCG_00750]

⌈ 如果对于所有 sw component prototypes 只有一个虚拟命名空间，则父组件名称可以忽略在显示名称中，除了具有相同 SwComponentType 的那些（即同一 SwComponentType 的多个实例）。 ⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90006、RS_MCR_90011)

在 [TR_MCG_00750] 中，假设 [TR_MCA_80730] 假定已满足。

生成规则 [TR_MCG_00750] 缩短了显示名称。但是，结果可能是奇怪的名称。所以应该检查它们，如有必要手动更改。

图 5：多实例化示例 - Coordinator Wheels

示例（参见图 5）：

对于 SwComponentType Wheel，我们有两个实例：WheelLeft 和 WheelRight。对于 Coordinator，我们有以下路径：

/OEM1/Systems/System/TopLvl/Pt/Coordinator
和
/OEM1/Systems/System/TopLvl/Veh/Coordinator
/OEM1/Systems/System/TopLvl/Veh/Body/WheelLeft/Coordinator
/OEM1/Systems/System/TopLvl/Veh/Body/WheelRight/Coordinator

我们只有一个 system，因此 [TR_MCA_80710] 已满足，可以应用 [TR_MCG_00713]。每个顶级包为 SwComponentPrototypes 定义虚拟命名空间，即 [TR_MCA_80720] 已满足。但是，没有 sw component prototypes 的全局虚拟命名空间，即 [TR_MCA_80730] 未满足。

假设我们要为名称为 "Coordinator" 的所有 sw component prototypes 创建显示名称。使用规则 [TR_MCG_00706]，我们将为 sw component prototype 层次结构（{componentHierarchy}）提供以下显示名称：

Pt_Coordinator
Veh_Coordinator
Veh_Body_WheelLeft_Coordinator
和
Veh_Body_WheelRight_Coordinator

使用规则 [TR_MCG_00740]，我们有：

Pt_Coordinator
Veh_Coordinator
Veh_WheelLeft_Coordinator
和
Veh_WheelRight_Coordinator

15 SwComponentPrototypes

在本章中，我们处理单个 SwComponentPrototype 的显示名称。Sw component prototypes（prototype : {component}）的通用模式是：

component : {nameSpace}_{componentHierarchy}_{data}

{data} 对应于 sw component prototype 或 root composition 的名称。即，最后一个 component prototype 不是 {componentHierarchy} 的一部分。我们有：

component :
   {nameSpace}_{componentHierarchy}_{SwComponentPrototype.name}
或
component :
   {nameSpace}_{RootSwCompositionPrototype.name}

组件层次结构与软件信号相关，因为它们总是在 SwComponentPrototype 的上下文中实例化。它们与 port prototype blueprints 和 ARPackage 的其他第一类元素（{element}）无关。

[TR_MCG_00610]

⌈ 对于 sw component prototypes，以下基本显示名称模式

component :
   {nameSpace}_{componentHierarchy}_{SwComponentPrototype.name}

用于生成显示名称。

如果 SwComponentPrototype 对应于 RootSwCompositionPrototype，我们则有：

component : {nameSpace}_{RootSwCompositionPrototype.name}

⌋ (RS_MCR_90002、RS_MCR_90003)

组件的相应路径是：

({ARPackage.name}/)1..n{System.name}/{RootSwCompositionPrototype.name}/
({SwComponentPrototype.name}/)0..n({SwComponentPrototype.name})0..1

16 唯一 SW-Signal 显示名称（Unique SW-Signal Display Names）

软件信号的通用模式如下（(prototype) : {swSignal}）：

swSignal : {nameSpace}_{componentHierarchy}_{data}

其中

data : {port}_{dataInfo}_{typeId}

[TR_MCG_00787] 源自 [TR_MCG_00001]：

[TR_MCG_00787]

⌈ 对于多个实例化以及必须考虑多个 system 的情况，软件信号的以下显示名称模式

swSignal : {nameSpace}_{componentHierarchy}_{data}

用于生成软件信号的显示名称。

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90015、RS_MCR_90016)

软件信号的实例 cp-path 是：

({ARPackage.name}/)1..n{System.name}/
{RootSwCompositionPrototype.name}/({SwComponentPrototype.name}/)0..n
{PortPrototype.name}/({AutosarDataPrototype.name})1..n

示例：（参见图 6 ExtrLi）

考虑多个 system。

  • SwComponentType：ExtrLiAdpr
  • 引用类型 ExtrLiAdpr 的 SwComponentPrototypes：ExtrLiAdprFrntLe 和 ExtrLiAdprFrntRi

给定实例 cp-path：

OEM1/Systems/System/TopLvl/ExtrLiAdprFrntRi/ActvnOfIndcFrntRi/Cmd

这将使用规则 [TR_MCG_00787] 产生以下显示名称：

OEM1_Systems_System_ ExtrLiAdprFrntRi_ActvnOfIndcFrntRi_Cmd

以下规则源自 [TR_MCG_00713]。此外，假设 [TR_MCA_80710] 假定已满足：只有一个 system。

[TR_MCG_00716]

⌈ 对于单个 system 的多个实例化，软件信号的以下基本显示名称模式

swSignal : {componentHierarchy}_{data}

用于生成软件信号的显示名称。{nameSpace}、sw component type 名称、包名称和 port interface 名称被忽略。

⌋ (RS_MCR_90002、RS_MCR_90003)

在规则 [TR_MCG_00716] 中，假设（：只有一个 system）假定已满足。

示例：（参见图 6 ExtrLi）

假设：只有一个 System

  • SwComponentType：ExtrLiAdpr
  • 引用类型 ExtrLiAdpr 的 SwComponentPrototypes：ExtrLiAdprFrntLe 和 ExtrLiAdprFrntRi

给定实例 cp-path：

OEM1/Systems/System/TopLvl/ExtrLiAdprFrntRi/ActvnOfIndcFrntRi/Cmd

这将应用 [TR_MCG_00716] 产生以下显示名称：

ExtrLiAdprFrntRi_ActvnOfIndcFrntRi_Cmd

应用第 11 章的 [TR_MCG_00020] 后，我们将得到：

ExtrLiAdprFrntRi_ActvnOfIndcFrntRi

由于 ECU 提取必须有一个 FlatMap 来为组件原型指定唯一名称，因此可以应用第 16 章的规则来生成这些唯一组件原型名称。规则 [TR_MCG_00760] 可以替代规则 [TR_MCG_00787]。

[TR_MCG_00760]

⌈ 在 FlatMap 中指定的唯一组件原型名称可用于指定软件信号的显示名称的一部分。

通用规则：

swSignal : {componentDescriptor}_{data}

⌋ (RS_MCR_90002、RS_MCR_90003)

图 6：ExtrLi 多实例化示例

示例（图 6 ExtrLi）：

假设我们有以下 FlatMap 为 sw component prototypes 定义名称：

<FLAT-MAP>
   <SHORT-NAME>ARMap</SHORT-NAME>
   <INSTANCES>
         <FLAT-INSTANCE-DESCRIPTOR>
           <SHORT-NAME>I1</SHORT-NAME>
           <UPSTREAM-REFERENCE-IREF>
             <CONTEXT-ELEMENT-REF DEST="ROOT-SW-COMPOSITION-PROTOTYPE">
                     /OEM1/Systems/System/TopLvl
             </CONTEXT-ELEMENT-REF>
              <TARGET-REF DEST="SW-COMPONENT-PROTOTYPE">
                     /OEM1/SwComponentTypes/TopLvl/ExtrLiAdprFrntRi
              </TARGET-REF>
           </UPSTREAM-REFERENCE-IREF>
        </FLAT-INSTANCE-DESCRIPTOR>
      </INSTANCES>
</FLAT-MAP>

代替 TopLvl_ExtrLiAdprFrntRi_ActvnOfIndcFrntRi_Cmd，使用规则 [TR_MCG_00760] 和 [TR_MCG_00020] 以及 I1 作为 FlatMap 中为 TopLvl_ExtrLiAdprFrntRi 定义的唯一 short name，我们得到：

I1_ActvnOfIndcFrntRi

[TR_MCA_80789]

⌈ 假设：对于 port prototypes 恰好有一个虚拟命名空间。 ⌋ (RS_MCR_90006)

类似于 [TR_MCG_00045]，我们有以下规则：

[TR_MCG_00752]

⌈ 如果对于 port prototypes 只有一个虚拟命名空间，并且 sw component types 仅被实例化一次，则组件原型名称（{componentHierarchy}）和 {nameSpace} 可以忽略在软件信号的显示名称中。我们有：

swSignal : {data}

⌋ (RS_MCR_90002、RS_MCR_90003、RS_MCR_90006、RS_MCR_90011)

如果 port prototypes 基于 port prototype blueprints，则以下规则成立：

[TR_MCG_00780]

⌈ 在 FlatMap 中为 port prototype blueprints 内数据元素指定的显示名称可用于指定从此 blueprint 派生的软件信号的显示名称：

swSignal : {portBlueprintDescriptor}

必须确保未从 blueprints 派生的信号的显示名称或没有带显示名称的 flatmap 可用的信号与已在 blueprints 的 flatmap 中规范化的显示名称不同。

⌋ (RS_MCR_90002、RS_MCR_90003)

{componentHierarchy} 可以忽略，因为没有多个实例化。{nameSpace} 可以忽略，因为它已包含在 blueprint descriptor 名称中。

17 附录：Powertrain 域的 Phys/Log（P/L-List）关键字

下表定义了 Powertrain 域的 P/L-list，可用作第 9.1 章中描述的规则的输入。

关键字缩略语定义为 AUTOSAR 称为 "PL_List" 的标准化关键字集的视图。

包含 P/L-List 的相应 .arxml 文件作为 AUTOSAR_MOD_AISpecification [3] 的一部分提供，称为 "AUTOSAR_MOD_AISpecification_Collection_AIMC_Keyword_Blueprint.arxml"。

表 1：Powertrain 域的 Phys/Log（P/L-List）关键字

关键字缩写 描述
A acceleration（加速度）
Adr address（地址）
Ag angle（角度）
Ar area（面积）
Cntr counter（计数器）
Fac factor（因子）
Flg flag、bit、boolean、binary signal（标志、位、布尔值、二进制信号）
Frq frequency（频率）
I electric current（电流）
Idx index（索引）
N (rotational) speed（旋转速度）
Nr number（数量）
P pressure（压力）
Posn position（位置）
Pwr power（功率）
R resistance（电阻）
Rat ratio、duty cycle（比率、占空比）
St / Sts state、status（状态）
T temperature（温度）
Ti time、duration（时间、持续时间）
Tq torque（扭矩）
U voltage（电压）
V velocity（速度）
Vol volume（体积）
W work（功）

翻译说明

  • 本文档为测量/标定/诊断（MCD）唯一名称规范类，包含 100+ 项编号规则（TR_MCM_xxxx、TR_MCG_xxxx、TR_MCA_xxxx、RS_MCR_xxxx）
  • XML 代码块已翻译注释（<L-1>、<L-4>、<DESC>、<LONG-NAME> 等），但保留所有 XML 标签、属性、属性值
  • 元模型类名（如 FlatInstanceDescriptor、PortPrototypeBlueprint、SwComponentPrototype）保持英文不译
  • 所有需求/规则 ID（TR_MCM_xxxx、TR_MCG_xxxx、TR_MCA_xxxx、RS_MCR_xxxx）保持英文
  • 关键字缩略语（如 EngN、TrsmClu、EngNrCyl）和 P/L-List 缩略语保持英文
  • AUTOSAR 方框符 ⌈⌋ 已保留，用于标记需求/规则文本的开始与结束
  • 文档间交叉引用（如 [TPS_STDT_xxxxx]）已保留

翻译：opencode-translator / Step 3 P0 批量翻译

Reference in New Issue View Git Blame Copy Permalink