This is a direct reference to a system constant
/OEM1/SwSystemconsts/DIESEL
.
```
这将例如被打印为：
> "This is a direct reference to a system constant 'DIESEL'."
由于段落中不支持实例引用，一种可能性是首先定义 `FlatInstanceDescriptor` 并引用此元素。
**示例**：
```xml
This is a reference to a sw signal
/AUTOSAR/AISpecification/Flatmaps/PowertrainFlatmap/Eng_n
.
```
这将例如被打印为：
> "This is a reference to a sw signal 'Eng_n'."
如果没有 flat map，则也可以使用 `DocumentContext` 信息作为唯一名称。`DocumentContext` 与 `FlatInstanceDescriptor` 非常相似。
**示例**：
```xml
AR_Eng_n
/OEM1/Systems/System/TopLvl
/AUTOSAR_AISpecification/SwComponentTypes/TopLvl/Pt
/AUTOSAR_AISpecification/SwComponentTypes/Pt/Eng
/AUTOSAR_AISpecification/SwComponentTypes/Eng/EngN
```
```xml
This is a reference to a sw signal
/OEM1/Documentations/Eng_Docu/AR_Eng_n
.
```
这将例如被打印为：
> "This is a reference to a sw signal 'AR_Eng_n'."
在某些情况下，使用**技术术语**（即 `Tt`）也很有趣。如果满足一些先决条件，这甚至可以替代 `XREF`。
**示例**：
```xml
This is a reference to system constant
DIESEL
via a technical term.
```
这将例如被打印为：
> "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 规范，可以自动派生此表：
```xml
DisplayName w/o Name Space.
With Name Space add AR_ before name, e.g. AR_Abs_flgActv
ShortName of Port
/ additional information if needed
LongName of
DisplayName (= name
extended in case of multiple data prototypes or arrays)
/AUTOSAR/AISpecification/Flatmaps/PowertrainFlatmap/Pt_nClu
/AUTOSAR/AISpecification/PortPrototypeBlueprints/PtNClu
/AUTOSAR/AISpecification/Flatmaps/PowertrainFlatmap/Pt_nClu
...（其他 row 类似）...
```
### 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 定义名称：
```xml
ARMap
I1
/OEM1/Systems/System/TopLvl
/OEM1/SwComponentTypes/TopLvl/ExtrLiAdprFrntRi
```
代替 `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 代码块已翻译注释（``、``、``、`` 等），但保留所有 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 批量翻译*