Specification of Manifest (`ManifestSpecification`)¶

属性	值
平台	AP
类别	TPS — 模板规范（Template Specification）
UID	713
规范版本	R25-11

本地文件¶

规范 PDF: F:\Work\Standards\01_Sources\AP_TPS_ManifestSpecification_713\AUTOSAR_AP_TPS_ManifestSpecification.pdf
ARXML 模型: F:\Work\Standards\01_Sources\AP_TPS_ManifestSpecification_713\AUTOSAR_AP_TPS_ManifestSpecification.arxml
纯文本全文: F:\Work\Standards\01_Sources\AP_TPS_ManifestSpecification_713\zzgen\AP_TPS_ManifestSpecification.complete.txt

文档简介¶

This document contains the specification of the so-called the Manifest on the AUTOSAR adaptive platform. A description of the overall modeling approach can be found in . A reference to the definition of the term service is given in .

The term Manifest is used in this specification in the meaning of a formal specification of configuration content. Please find a more detailed description of the term and the implications for the AUTOSAR adaptive platform in .

Over time, the manifest-related content in this document will be replaced step-by-step by a target configuration model based on the so-called APMC-Approach. Please find more details about the modeling approach implemented by APMC in the

Please note that the content of the document (despite the name) extends to the description of design elements necessary to develop software for the AUTOSAR adaptive platform.

The design-related modeling mainly is focused on the development of application software on the AUTOSAR adaptive platform as well as the connection between application and diagnostics and is described in detail in , and .

On the AUTOSAR adaptive platform, these chapters represent a counterpart/extension to the and the on the AUTOSAR classic platform. This means that certain parts of the mentioned documents on the AUTOSAR classic platform are also applicable to the AUTOSAR adaptive platform.

This relation is explicitly marked in the definition of imposition time of constraints defined in the mentioned documents.

contains a description of the concrete Machine Design, which represents a counterpart to some sections of the on the AUTOSAR classic platform.

, in particular, describes the big picture of AUTOSAR classic platform and AUTOSAR adaptive platform communicating via service-oriented communication.

supports the design-related section of this document with a description of how installable sub-systems are described on the design level.

concludes the design-related part by explaining how signal-based communication can be transformed into service-oriented communication and vice versa in order to participate in the communication between ECUs on the AUTOSAR classic platform.

starts the target-configuration part of the document. It represents that counterpart to on target-configuration level and describes the content of the so-called execution manifest.

describes the options for configuring a machine by means of a manifest.

contains a string of sub-sections that explain the manifest

模块依赖¶

The modeling of a dependency among SoftwareClusterDesigns is formulated by meta-class SoftwareClusterDependencyFormula.

Semantics of meta-class SoftwareClusterDependencyFormula ⌈ Meta-class SoftwareClusterDependencyFormula allows for the definition of a formal condition that can be taken to decide about the dependency to or the conflict with a SoftwareCluster.

The modeling of SoftwareClusterDependencyFormula allows for the definition of nested conditions. The attribute operator is applied on the results of the evaluation of the parts. ⌋

Class	SoftwareClusterDependencyFormula	<	<	<
Note	This meta-class represents the ability to define a dependency among SoftwareClusters.

This Class is only used by the AUTOSAR Adaptive Platform.	<	<	<
Base	ARObject, SoftwareClusterDependencyFormulaPart	<	<	<
Aggregated by	SoftwareClusterDependencyFormula.part, SoftwareClusterDesign.conflictsTo, SoftwareClusterDesign.dependsOn	<	<	<
Attribute	Type	Mult.	Kind	Note
operator	SoftwareClusterDependencyLogicalOperatorEnum	0..1	attr	This logical operator can be used to relate the results of different SoftwareClusterDependencyParts.
part (ordered)	SoftwareClusterDependencyFormulaPart	*	aggr	This aggregation represents the ordered collection of the parts of the SoftwareClusterDependencyFormula.

Enumeration	SoftwareClusterDependencyLogicalOperatorEnum
Note	This enumeration provides a set of operators to be used in a SoftwareClusterDependencyFormula.

This Enumeration is only used by the AUTOSAR Adaptive Platform. | Aggregated by | SoftwareClusterDependencyFormula.operator | |---|---| | Literal | Description | | logicalAnd | logical and |

Tags: atp.EnumerationLiteralIndex=0 | logicalOr | logical or | |---|---|

Tags: atp.EnumerationLiteralIndex=1

Semantics of meta-class SoftwareClusterDependencyFormulaPart ⌈ Meta-class SoftwareClusterDependencyFormulaPart represents a part of a SoftwareClusterDependencyFormula. The order of the parts of a SoftwareClusterDependencyFormula is s

章节详细内容¶

1. 简介¶

原文标题：Introduction

This document contains the specification of the so-called the Manifest on the AUTOSAR adaptive platform. A description of the overall modeling approach can be found in . A reference to the definition of the term service is given in .

The term Manifest is used in this specification in the meaning of a formal specification of configuration content. Please find a more detailed description of the term and the implications for the AUTOSAR adaptive platform in .

Over time, the manifest-related content in this document will be replaced step-by-step by a target configuration model based on the so-called APMC-Approach. Please find more details about the modeling approach implemented by APMC in the

Please note that the content of the document (despite the name) extends to the description of design elements necessary to develop software for the AUTOSAR adaptive platform.

The design-related modeling mainly is focused on the development of application software on the AUTOSAR adaptive platform as well as the connection between application and diagnostics and is described in detail in , and .

2. 建模 Approach¶

原文标题：Modeling Approach

3. 通用 Considerations¶

原文标题：General Considerations

The AUTOSAR adaptive platform has been introduced when the AUTOSAR classic platform was already a stable and well-established standard in the automotive domain.

And yet, the AUTOSAR adaptive platform is no successor of the AUTOSAR classic platform. Both platforms complement each other for specific use cases that can be better implemented by one or the other platform.

In this situation, two possible approaches for modeling on the AUTOSAR adaptive platform could have been taken:

The AUTOSAR adaptive platform is based on different principles than the AUTOSAR classic platform, and hence the modeling approach could also decouple from the canon of the AUTOSAR classic platform as much as possible to advertise the fact that the two platforms have different purposes.

Consequentially, even if specific model elements have clear counterparts in the respective other platform, use a different terminology to not confuse the users of both platforms.

4. 诊断配置的建模¶

原文标题：Modeling of Diagnostic Configuration

The configuration of the "external behavior" of the AUTOSAR diagnostic stack is done by means of the so-called Diagnostic Extract. The Diagnostic Extract in general extends to both the AUTOSAR classic platform and the AUTOSAR adaptive platform.

In particular, some parts of the Diagnostic Extract apply only for the AUTOSAR classic platform, some parts are shared between the AUTOSAR classic platform and the AUTOSAR adaptive platform, and some parts apply only for the AUTOSAR adaptive platform.

The parts that are specific to the AUTOSAR classic platform, and the parts that apply to both the AUTOSAR classic platform and the AUTOSAR adaptive platform are documented in the deliverable .

For technical reasons, the parts that apply to the AUTOSAR adaptive platform cannot be included in the document and are consequently documented in this document, "TPS Manifest Specification".

The parts about the configuration of Diagnostic Management, as described in this document, fit seamlessly into the same modeling framework that is used on the AUTOSAR classic platform. This means that the specific parts for the AUTOSAR adaptive platform utilize the shared parts that are described in the .

5. The Term 服务¶

原文标题：The Term Service

It is essential to keep in mind that the term service is frequently used within this document in particular and the AUTOSAR adaptive platform in general.

This usage has its reasons despite the fact that the meaning of the term service on the AUTOSAR adaptive platform collides with other meanings used within AUTOSAR.

In summary, the following meaning of the term service exist in the scope of AUTOSAR:

The Term service is used in the to denote the highest layer of the AUTOSAR software architecture that interacts with the application. In this context, model elements like ServiceSwComponentType, SwcServiceDependency, ServiceNeeds, or PortInterface.isService have been created on the AUTOSAR classic platform.
The term service is used to express that information is related or required in a workshop where a car is serviced. In this context, service-only diagnostic trouble codes (DTC) are defined.
The term service is used to describe the handling of diagnostic services, e.g. UDS service ReadDataByIdentifier, for the communication between a diagnostic tester and a diagnostic stack on an (AUTOSAR) ECU.

6. Document Conventions¶

Technical terms are typeset in mono spaced font, e.g. PortPrototype. As a general rule, plural forms of technical terms are created by adding "s" to the singular form, e.g. PortPrototypes. By this means the document resembles terminology used in the AUTOSAR XML Schema.

This document contains constraints in textual form that are distinguished from the rest of the text by a unique numerical constraint ID, a headline, and the actual constraint text starting after the \lceil character and terminated by the \rfloor character.

The purpose of these constraints is to literally constrain the interpretation of the AUTOSAR meta-model such that it is possible to detect violations of the standardized behavior implemented in an instance of the meta-model (i.e. on M1 level).

Makers of AUTOSAR tools are encouraged to add the numerical ID of a constraint that corresponds to an M1 modeling issue as part of the diagnostic message issued by the tool.

The attributes of the classes introduced in this document are listed in form of class tables. They have the form shown in the example of the top-level element AUTOSAR:

7. About Tables¶

There is a number of tables in this document that describe the applicability or multiplicity of model elements. These tables contain empty cells, which represent a "not applicable" meaning. Model elements that correspond to an empty cell shall not exist in the context described by the respective table cell.

If the value of a table cell shall indicate that that either the existence or multiplicity of the represented model element shall be ignored anyway, the table cell gets the content "d/c" for "don't care". This means that if the respective model element exists, it shall be ignored in the downstream processing of the model.

8. Big Picture of 清单定义¶

原文标题：Big Picture of Manifest Definition

9. 设计 vs. Target 配置¶

原文标题：Design vs. Target Configuration

10. Preface¶

This document underwent a change in terminology. Previously, the term "Deployment" was used to identify modeling or workflow steps that relate to the creation of model elements that are mostly local to a given compute node. Therefore, these elements are usually created during integration.

In other words, the purpose of all these "deployment-related" steps and modeling elements is to create a configuration of the target on which the code is executed at run-time.

In this context, the usage of the term "deployment" is considered to broad and lacking focus on the real task. In contrast, the usage of the term "target-configuration" is considered the better and more precise alternative. To provide a service to the reader, the text in this document has been updated to reflect the new terminology wherever reasonable.

Model elements, on the other hand, have not been renamed to achieve conformance with the updated terminology. The existing M2-based target-configuration model that is described in this document is subject to be replaced by an M1-based APMC-Model anyway and therefore a costly update of the M2 model is not considered worth the hassle.

11. 概述¶

原文标题：Overview

Despite the name, this document contains the description of model elements that are clearly bound to a design workflow and model elements that have a strong relation to the target configuration aspect.

Model elements discussed in this document are either related to design or target configuration, there is no overlap between the two groups, but it could happen that design model elements are required in a concrete model for target configuration mode elements to make sense.

As mentioned before, some target configuration model element may need one or more references to design model elements and the design model elements need to be uploaded to the target platform for the sake of completing the semantics of the target configuration model.

Please note that a design model element does not automatically become a target configuration model element just because it is required to be uploaded to a target platform.

12. Relation between 设计 and Target 配置 Models¶

原文标题：Relation between Design and Target Configuration Models

Please note that in many cases the part of the meta-model related to target configuration reflects a similar modeling in the design domain, e.g. the definition of E2E profile parameters.

There is currently no clearly defined preference about how the relation between design and target configuration may impact a concrete development project. The following scenarios for the example of E2E properties might occur:

Some model elements described in this document that are part of the content that gets uploaded to the target platform have direct counterparts on the design level.

One example for such a relation is the definition of ProcessDesign and Process. In these cases it would be easier to draw the line between design and target configuration aspects of the model.

There are cases where the mere existence of a reference into the design model is already representing valuable information. References that expose this capability are decorated with the stereotype atpUriDef>>.

Specifically, it is possible for the software on the platform to derive the value of an InstanceSpecifier from the content of an instanceRef decorated with atpUriDef>>.

13. 结构 of the document¶

原文标题：Structure of the document

The structure of the document maps to the division between design and target configuration such that the design aspect is mostly described in , , , , , and .

In contrast, , , , , , and focus on target configuration-related content.

14. About 清单¶

原文标题：About Manifest

This chapter shall clarify the definition of the term Manifest in the context of the AUTOSAR adaptive platform.

Definition of the term Manifest ⌈ A Manifest represents a piece of AUTOSAR model description that is created to support the configuration of an AUTOSAR adaptive platform product and which is uploaded to the AUTOSAR adaptive platform product, potentially in combination with other artifacts (like binary files) that contain executable code to which the Manifest applies. ⌋

It is important to stress the fact that the usage of a Manifest is indeed strictly limited to the AUTOSAR adaptive platform and that there is no use case to port the concept to the AUTOSAR classic platform.

15. Serialization Format¶

One aspect that the definition of a Manifest has in common with other AUTOSAR model content is the standardized serialization format.

Serialization format of the Manifest in AUTOSAR ⌈ The standardized serialization format of Manifest content in AUTOSAR is ARXML.

Consequently, Manifest model content can be validated against the AUTOSAR XML Schema. ⌋

An important consequence of is that there is no limitation to just one "manifest file" a.k.a. "the manifest".

Content may be distributed among several physical files according to the rules given in the specification of the .

Serialization format of Manifest content on a machine ⌈ The serialization format used to actually upload a manifest on a machine may be freely chosen by a platform supplier.

However, the content and semantics of the original ARXML Manifest needs to be fully preserved. ⌋

It can be expected that in many cases the best option for the upload of the Manifest will still be ARXML because a custom format obviously has to support the full complexity of the Manifest meta-model.

Please note that the meta-model foresees the existence of references from manifest-related meta-classes to design-related meta-classes.

16. 范围¶

原文标题：Scope

As mentioned before, the usage of a Manifest is limited to the AUTOSAR adaptive platform. This does not mean, however, that all ARXML produced in a development project that targets the AUTOSAR adaptive platform is automatically considered a Manifest.

In fact, the AUTOSAR adaptive platform is usually not exclusively used in a vehicle project.

A typical vehicle will most likely be also equipped with a number of ECUs developed on the AUTOSAR classic platform and the system design for the entire vehicle will therefore have to cover both ECUs built on top of the AUTOSAR classic platform and those created on top of the AUTOSAR adaptive platform.

17. Manifests described in this Document¶

In principle, the term Manifest could be defined such that there is conceptually just one "manifest" and every target configuration aspect would be handled in this context.

This does not seem appropriate because it became apparent that manifest-related model-elements exist that are relevant in entirely different phases of a typical development project.

This aspect is taken as the main motivation to subdivide the definition of the term Manifest in five different partitions:

This kind of Manifest is used to specify the target configuration-related information of applications running on the AUTOSAR adaptive platform.

An Execution Manifest is bundled with the actual executable code in order to support the integration of the executable code onto the machine.

Please find more information regarding this topic in . * This kind of Manifest is used to specify how service-oriented communication is configured in terms of the requirements of the underlying transport protocols.

A Service Instance Manifest is bundled with the actual executable code that implements the respective usage of service-oriented communication.

Please find more information regarding this topic in .

18. 应用设计¶

原文标题：Application Design

19. 概述¶

原文标题：Overview

This chapter describes all design-related modeling that applies to the creation of application software on the AUTOSAR adaptive platform.

There are also some extensions of existing modeling used on the AUTOSAR classic platform specifically for the usage on the AUTOSAR adaptive platform, e.g. the introduction of new values of the attribute category.

In particular, this section of the document focuses on the following aspects:

Definition of application structure, consisting of SwComponentType for the AUTOSAR adaptive platform (), Executable as the design-level representation of the smallest executable unit (), as well as Description of how to front-load the configuration of a Process by means of ProcessDesign, see .
Definition of data types specifically for the AUTOSAR adaptive platform (), including the handling of optional elements in data structures, see .
Configuration of transformation properties ().
Description of the design-level IAM configuration by means of the GrantDesign, see .
Description of the support for intrusion detection ().
Description of the design of cryptographic solutions ().

20. Application 结构¶

原文标题：Application Structure

21. 软件组件¶

原文标题：Software Component

In principle, it would be possible to directly take over the definition of e.g. ApplicationSwComponentType for the usage on the AUTOSAR adaptive platform.

However, this would complicate the formulation of constraints regarding the existence of model elements (for example: data types, as explained in ) that are exclusive to the AUTOSAR adaptive platform.

Therefore, the AdaptiveApplicationSwComponentType is defined as a representation of software-components on the AUTOSAR adaptive platform.

The Existence of the AdaptiveApplicationSwComponentType allows for a convenient way (see ) to lock out most kinds of software-component defined for the AUTOSAR classic platform from the usage on the AUTOSAR adaptive platform.

The clarification of the opposite direction (i.e. an erroneous use of an AdaptiveApplicationSwComponentType) is less obvious.

In other words, it may be possible to use an AdaptiveApplicationSwComponentType within a System as some sort of overall design model for software on both the AUTOSAR classic platform and the AUTOSAR adaptive platform.

22. Executable¶

23. 概述¶

原文标题：Overview

An Executable represents an executable program in the AUTOSAR meta-model. An explanation of the semantics of the attributes of Executable can be found in the following sub-sections.

Class	Executable	<	<	<
Note	This meta-class represents an executable program.

Tags: atp.recommendedPackage=Executables

This Class is only used by the AUTOSAR Adaptive Platform.	<	<	<
Base	ARElement, ARObject, AtpClassifier, CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable, UploadableDesignElement, UploadablePackageElement	<	<	<
Aggregated by	ARPackage.element	<	<	<
Attribute	Type	Mult.	Kind	Note
implementationProps	ExecutableImplementationProps	*	aggr	This aggregation contains the collection of implementation-specific properties necessary to properly build the enclosing Executable.
minimumTimerGranularity	TimeValue	0..1	attr	This attribute describes the minimum timer resolution (TimeValue of one tick) that is required by the Executable.
reportingBehavior	ExecutionStateReportingBehaviorEnum	0..1	attr	this attribute controls the execution state reporting behavior of the enclosing Executable.

24. Category¶

Standardized values of attribute Executable.category Imposition time: IT_BefAraApiGen ⌈ The following values for attribute Executable.category are standardized by AUTOSAR:

PLATFORM_LEVEL: the Executable represents software on the platform level (i.e. conceptually located on the level of the middleware).
APPLICATION_LEVEL: the Executable represents software on the application level (i.e. conceptually located above the middleware). ⌋

25. Root 软件组件 Prototype¶

原文标题：Root Software Component Prototype

Root element for a hierarchical software-component ⌈ Executable aggregates meta-class RootSwComponentPrototype in the role rootSwComponentPrototype to provide a root element for an arbitrarily nested hierarchy of software-components represented by the reference RootSwComponentPrototype.applicationType. ⌋

Please note that the aggregation of RootSwComponentPrototype by Executable is the basis for the applicability of an instanceRef>> reference into the hierarchy of software-components that represent the functionality of the Executable.

This modeling approach is similar to the modeling of a System on the AUTOSAR classic platform.

Optionality of Executable.rootSwComponentPrototype ⌈ The aggregation Executable.rootSwComponentPrototype has been made optional in order to support the implementation of platform modules that do not utilize any service oriented communication and don't require any further formalization. ⌋

26. Reporting 行为¶

原文标题：Reporting Behavior

Semantics of Executable.reportingBehavior ⌈ Attribute Executable.reportingBehavior shall be used to control the reporting of the execution state of the enclosing Executable to the Execution Management. If the attribute does not exist, the Executable shall report its execution state to the Execution Management. ⌋

Enumeration	ExecutionStateReportingBehaviorEnum
Note	This enumeration provides options for controlling of how an Executable reports its execution state to the Execution Management

This Enumeration is only used by the AUTOSAR Adaptive Platform. | Aggregated by | Executable.reportingBehavior | |---|---| | Literal | Description | | doesNotReportExecutionState | The Executable shall not report its execution state to the Execution Management. |

Tags: atp.EnumerationLiteralIndex=1 | reportsExecutionState | The Executable shall report its execution state to the Execution Management. | |---|---|

Tags: atp.EnumerationLiteralIndex=0

27. Implementation Props¶

Semantics of ExecutableImplementationProps ⌈ If an Executable is built for a specific purpose inside the AUTOSAR adaptive platform, i.e. the implementation of a functional cluster, then it may be necessary to add configurations that need to be considered at compile time, e.g. whether the implementation of the logging functional cluster needs access to resources provided by the synchronized time base functional cluster.

The configuration of such implementation-specific properties can be done by means of the Executable.implementationProps, specifically by a sub-class of ExecutableImplementationProps. ⌋

Class	ExecutableImplementationProps (abstract)	<	<	<
Note	This abstract class has the ability to act as a base class for classes that detail out the implementation-specific properties of an Executable.

This Class is only used by the AUTOSAR Adaptive Platform.	<	<	<
Base	ARObject, Describable	<	<	<
Subclasses	ExecutableLoggingImplementationProps	<	<	<
Aggregated by	Executable.implementationProps	<	<	<
Attribute	Type	Mult.	Kind	Note
-	-	-	-	-

28. Logging¶

Semantics of ExecutableLoggingImplementationProps ⌈ The implementation properties of an Executable that is implementing (a part of) the logging functional cluster can be configured using the ExecutableLoggingImplementationProps. ⌋

Restriction for the existence of ExecutableLoggingImplementationProps Imposition time: IT_BefAraApiGen ⌈ The aggregation of ExecutableLoggingImplementationProps in the role Executable.implementationProps is only allowed for an Executable where attribute category is set to the value PLATFORM_LEVEL. ⌋

Class	ExecutableLoggingImplementationProps	<	<	<
Note	This meta-class contains configuration relevant for the implementation of an Executable used in the context of the LogAndTraceInstantiation.

This Class is only used by the AUTOSAR Adaptive Platform.	<	<	<
Base	ARObject, Describable, ExecutableImplementationProps	<	<	<
Aggregated by	Executable.implementationProps	<	<	<
Attribute	Type	Mult.	Kind	Note
usesTimeBaseResource	Boolean	0..1	attr	This attribute indicates that the implementation of the enclosing Executable is required to access resources provided by the synchronized time base functional cluster.

29. TraceSwitchConfig¶

Semantics of TraceSwitchConfig ⌈ The TraceSwitchConfig element maps a DltMessage that is referenced in the role traceMessage in the context of an Executable to a trace switch type defined by the TraceSwitchConfig.traceSwitch attribute that in turn decides how the DltMessage is routed. ⌋

Please note that the TraceSwitchConfig is used by the compile time configuration of ARTI trace. The TraceSwitchConfig is not required for normal logging. If TraceSwitchConfig does not exist for a dedicated DltMessage, then the DltMessage is forwarded to the logger.

Class	TraceSwitchConfig	<	<	<
Note	This class maps a DltMessage to a trace switch type.

Tags: atp.recommendedPackage=TraceSwitchConfigs

This Class is only used by the AUTOSAR Adaptive Platform.	<	<	<
Base	ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable	<	<	<
Aggregated by	ARPackage.element	<	<	<
Attribute	Type	Mult.	Kind	Note
executable	Executable	0..1	ref	Executable that defines the context of the trace switch.

30. Interaction Endpoint for Application¶

The interaction of software-components with the outside world can take several forms, e.g. service-oriented communication or the interaction with a persistent data storage.

A formal representation of the interaction needs to be described as an anchor point for adding various additional configuration attributes that make sense in this context but would not make sense in the context of a PortInterface.

There is a model element that already has a long-standing tradition in the AUTOSAR meta-model for exactly the described purpose: the PortPrototype.

The following sub-chapters discuss the interaction by means of PortPrototypes with software "outside" a given software-component with the focus on different kinds of interaction that require different ways to further contribute model elements for configuration.

31. Service-oriented Communication¶

The service-oriented communication by means of PortPrototypes does not support the concept of a communication endpoint that is both required and provided at the same time. This motivates the existence of .

No support for PRPortPrototype Imposition time: IT_BefAraApiGen ⌈ A ServiceInterface shall not be referenced by a PRPortPrototype in the role providedRequiredInterface. ⌋

Representation of provided service ⌈ A provided service shall be modeled by means of a PPortPrototype that is typed by a ServiceInterface. ⌋

Representation of required service ⌈ A required service shall be modeled by means of an RPortPrototype that is typed by a ServiceInterface. ⌋

For more background regarding the rationale of , please refer to .

Please note that the utilization of service discovery on the AUTOSAR adaptive platform means that opposite communication ends are by design not known upfront.

As a consequence, it is in general not possible to use AssemblySwConnectors to model a pre-defined relation between two communication endpoints modeled as PortPrototypes.

32. Port Prototype Props¶

As mentioned before, in some cases a qualification of the semantics of PortPrototypes is necessary. For this purpose, AUTOSAR typically defines a props class of some kind. The same approach applies in this situation as well.

In particular, PortPrototype aggregates the abstract meta-class PortPrototypeProps, that in turn starts an inheritance tree of derived meta-classes that have the ability to qualify sub-classes of PortPrototype accordingly.

Class	PortPrototypeProps (abstract)	<	<	<
Note	This meta-class represents the ability to define a further qualification of semantics of sub-classes of PortPrototype.

This Class is only used by the AUTOSAR Adaptive Platform.	<	<	<
Base	ARObject	<	<	<
Subclasses	RPortPrototypeProps	<	<	<
Aggregated by	PortPrototype.portPrototypeProps	<	<	<
Attribute	Type	Mult.	Kind	Note
-	-	-	-	-

Restriction of aggregation of PortPrototypeProps to the Adaptive Platform Imposition time: IT_BefAraApiGen ⌈ The aggregation of PortPrototypeProps is only supported in the context of a SwComponentType that is (transitively) referenced by rootSwComponentPrototype. ⌋

其余 721 章（内容从略，见纯文本全文）¶

Port Prototype ComSpec
Port Prototypes typed by 服务接口
Receiver ComSpec
Sender ComSpec
Client ComSpec
Server ComSpec
Communication 行为 to be implemented by the Application 软件
Transmission ComSpec Props
Transmission triggered by Element of composite 数据类型
Port Prototypes typed by 持久化数据接口
Port Prototypes typed by 持久化文件接口
Process 设计
数据类型
概述
ApplicationDataType
String 数据类型
Associative 映射数据类型
Attributes of SwDataDefProps
CppImplementationDataType
概述
Attributes of SwDataDefProps
Primitive 数据类型
String 数据类型
Array 数据类型
Vector 数据类型
Struct 数据类型
Enumeration 数据类型
映射数据类型
Variant 数据类型
Bitfield 数据类型
Compatibility of ApplicationDataType and CppImplementationDataType
Optional Members in complex 数据 Structures
Background
定义 of Optionality
Usage of constant Values
Serialization Of 数据
Default Values for Serialization Properties
Individual 定义 of Serialization Properties
Assignment of TLV properties
Assignment of TLV 数据 IDs
Assignment of Wire 类型 Selection
Identity and Access 管理
Com Grant 设计
Remote access 控制
Remote Subject in the Case of TLS
Remote Subject in the Case of IPsec
Remote Subject in the Case of IP Communication
Remote Subject in the Case of SecOC Communication
Intrusion 检测设计
Relation to Crypto 系统设计
Application Port 接口设计
概述
服务接口
概述
Event
Trigger
Field
Method
Fire and Forget Method
Versioning of ServiceInterfaces
Versioning driven by 传输 layer
Namespace
错误处理
服务接口数据类型映射
服务接口映射
服务接口 Element 映射
概述
服务接口 Event 映射
服务接口 Trigger 映射
服务接口 Field 映射
服务接口 Method 映射
状态管理接口
概述
状态管理接口 for 通知
状态管理接口 for Triggers
状态管理接口 for 错误
Execution 管理接口
状态 Client 接口
持久化接口
概述
The big Picture
持久化接口的建模
Redundancy 处理
Update 处理
持久化 Key Value Storage 接口
持久化文件 Storage 接口
Time 同步接口
Platform Health 管理接口
概述
Supervised Entities and Checkpoints
Recovery 通知 to 状态管理
诊断接口
概述
诊断接口 for UDS
诊断 Routine 接口
数据 Identifier的接口 to 数据 Identifier and Element
Security Level 接口
服务校验接口
Generic UDS 接口
诊断接口 for Upload and Download
接口 to 支持 managing the EcuReset
诊断 Authentication 接口
诊断 External Authentication 接口
诊断 Communication 控制接口
诊断 Request 文件 Transfer 接口
诊断接口 for Fault 存储
接口 for providing 数据 to Extended 数据 Record
接口 to 诊断 Events
接口 to 诊断 Condition
接口 for 多诊断 Resources
接口 for 多诊断 Events
接口 for 多诊断 Conditions
Indicator 接口
Operation Cycle 接口
诊断接口 for SOVD
概述
Port 接口 for SOVD Client Authorization
Port 接口 for SOVD Proximity Challenge
Port 接口 for SOVD Bulk 数据
Port 接口 for SOVD 服务校验
Port 接口 for SOVD Update
Port 接口 for SOVD 配置
Port 接口 for SOVD Operation
Port 接口 for SOVD Content Access
诊断接口 for DoIP
Crypto 接口
Interaction with Crypto 软件
Crypto Key Slot 接口
Crypto Certificate 接口
Crypto Certificate Group 接口
Crypto Provider 接口
Raw 数据 Stream 接口
Intrusion 检测接口
Security Event Report 接口
Intrusion 检测 Timestamp Provider 接口
Intrusion 检测 Context Provider 接口
Intrusion 检测 Reporting 模式 Provider 接口
Intrusion 检测 Qualified Events Receiver 接口
Log And Trace 接口
Firewall 接口
网络管理接口
Suspend to RAM 接口
诊断设计
Extensions to the 诊断 Common Props
诊断 SOVD Props
诊断 Address
诊断 Authentication 配置
诊断映射
概述
多诊断 Resources to a PortPrototype的映射
Fault-Memory-related 诊断映射
诊断 Monitor to Port 映射
多诊断 Monitor to Port 映射
诊断 Event to Port 映射
多诊断 Event to Port 映射
诊断 Operation Cycle to Port 映射
诊断 Enable Condition to Port 映射
诊断 Clear Condition to Port 映射
多诊断 Condition to Port 映射
诊断 Indicator to Port 映射
诊断存储 Destination to Port 映射
诊断 Extended 数据 Record Port 映射
UDS-related 诊断映射
诊断 Security to Port 映射
诊断数据 Identifier to Port 映射
诊断 Generic UDS 服务 Handler to Port 映射
诊断 Generic 映射
诊断服务校验映射
诊断 Authentication 映射
诊断 External Authentication 映射
SOVD-related 诊断映射
诊断 SOVD Proximity Challenge 映射
诊断 SOVD Authorization Port 映射
诊断 SOVD Bulk 数据 Port 映射
诊断 SOVD Update Port 映射
诊断 SOVD 服务校验 Port 映射
诊断 SOVD 配置 Port 映射
诊断 SOVD 数据 Port 映射
诊断 SOVD Operation Port 映射
诊断 SOVD 配置 to SOVD Content 映射
DoIP-related 诊断映射
诊断 DoIP 映射
诊断 DoIP Group Identification 映射
诊断 DoIP Activation Line 映射
诊断 DoIP Entity Identification 映射
诊断 DoIP Power 模式映射
诊断 DoIP custom Payload 映射
诊断 DoIP custom Payload Rx 映射
诊断 DoIP custom Payload Tx 映射
诊断 Clear Condition
Security Access
诊断 Provided 数据映射
Usage of 诊断 Environmental 数据 Element Condition
SOVD 配置 Elements
SOVD 服务 Instance
概述
SOVD Log
SOVD Update
SOVD Fault 存储 Access
诊断 SOVD 数据
SOVD Operation
SOVD Method
SOVD Lock
SOVD Content
概述
SOVD Composite Content
SOVD Primitive Content
Environmental 数据 Condition to SOVD Content Element
SOVD Snapshots
诊断 Miscellanea
Machine 设计
概述
Processor
概述
核 Affinity
功能性 Cluster 设计
DoIp 功能性 Cluster 设计
Machine 设计的网络设计 aspects
服务 Discovery 配置
SOME/IP 服务 Discovery 配置
TcpIp stack 配置 properties
系统设计
概述
Communication 系统结构的规范
网络 connection
支持 of 10BASE-T1S 网络 Topologies
支持 of Ethernet tunneling through CAN XL
IP 配置 properties
TCP and UDP 配置 properties
ICMP 配置 properties
Securing Communication with IPsec
MACsec
Partial 网络
Application 软件系统结构的规范
服务 oriented Communication between Classic and Adaptive platform的建模
Method 映射
Event 映射
FieldMapping
Fire And Forget Method 映射
Crypto 系统设计
Process 设计 to Machine 设计映射
Ethernet Synchronized Time 设计
Sub-System 设计
概述
软件 Cluster 设计
Relevance of 软件 Cluster 设计 for 诊断
软件 Cluster Dependency
概述
a 软件 Cluster Dependency的建模
软件 Cluster 设计的Provided and required 服务
服务 to Executables的映射
Signal-based Communication
概述
Signal-based Prerequisites
Message Header for IP based 传输
Message Identification for IEEE1722 ACF based 传输
Signal-based Deployment
Signal/服务 Translation 映射
处理 of ISignalGroups
Direction of Signal/服务 Translation 映射
SignalBasedEvent 映射
SignalBasedTrigger 映射
SignalBasedField 映射
SignalBased Fire and Forget Method 映射
服务 Discovery and Static Communication 配置
服务 discovery 控制
服务控制 right after translation start
related 服务 instance的服务控制 due to availability
Signal-service-translation
Service-signal-translation
Static Communication 配置
Static Communication 配置 for the Server
Static Communication 配置 for the Client
Translation 行为
ServiceInterface Representation of Translation 数据
Optional Elements in the Case signal-service-translation
Optional Elements in the Case service-signal-translation
Event and update-bit Semantics
数据过滤
Translation from one Source
Translation from several Sources
Signal-Service-Translation to several Targets
Translation pass-through Composition
Expected Features of Classic Platform
Processing Order
Reception 数据 Filter
Reception of Invalid Signal
Update Bit 处理
Transfer Properties and Transmission Modes for Service-Signal-Translation
Deadline Monitoring
Signal and IPdu Transmission
IPdu Multiplexing
End-to-End considerations
Safety
Signal-service-translation
Service-signal-translation
Security
Restrictions on Classic Platform SecOC
Link between Classic Platform SecOC and CryptoKeySlot
执行清单
概述
Process
Process relates to Executable
Process States
启动配置
State-dependent 启动配置
Process Attributes
调度
Process Arguments
Association with Resource Group
Execution Dependency
Assignment of Processes to 功能 Group states
Resource Consumption Boundaries
错误 and Termination 行为
功能 Groups
Semantics of 功能 Group
Reporting of Security Events
机器清单
Machine
Environment Variable
Process To Machine 映射
通用建模 Approach
核 Affinity
Default Start-up and Termination Timeout
Platform 模块 Development
OS 模块配置
持久化 Target-Configuration
概述
Redundancy 处理
Update 处理
Size 处理
Security 处理
Preference Rules
Target-Configuration of Persistent Key-Value Storage
Target-Configuration of 文件 Storage
Platform Health 管理 Target-Configuration
概述
Relation between 设计 and Target-Configuration
Supervision Target-Configuration
Global supervision
Supervision 模式
Supervision 模式 condition
NoSupervision 定义
AliveSupervision 定义
AliveSupervision of self-terminating processes
CheckpointTransition 定义
LogicalSupervision 定义
DeadlineSupervision 定义
NoCheckpointSupervision 定义
Supervision Recovery 通知 Target-Configuration
Recovery 通知
Time 同步 Target-Configuration
概述
Time 同步功能性 Cluster 配置
Time Base
Synchronized Time Base
Persistent Time Base Value Storage
Time Base to Port Prototype 映射
DoIP 配置
Log and Trace 模块配置
Log and Trace Target-Configuration
Relation between 设计 and Target-Configuration
网络管理配置
UDP 网络管理
Relation between Application 软件 and 网络句柄
Relation between 功能 Group states and 网络句柄
UdpNm 配置 constraints
CAN XL 网络管理
更新与配置管理
概述
Retry Strategy
UCM Master 模块 Instantiation
UCM Subordinate 模块 Instantiation
CM 配置
Com Grant Target-Configuration
Com Field Grant Target-Configuration
Com Method Grant Target-Configuration
Com Event Grant Target 配置
Com Trigger Grant Target-Configuration
Com Offer 服务 Grant Target-Configuration
Remote Access 控制
Crypto Target-Configuration
Crypto Provider
Crypto Key Slot
Crypto Key Slot to Port Prototype 映射
Crypto Key Slot to Client Port Prototype 映射
Crypto Certificate
Crypto Certificate Group
Relation to Crypto 系统设计
IdsM Target-Configuration
IdsM Instantiation
Time Stamps for Security Events via Time-Base Resource
映射 to Timestamp Provider
映射 to Context Provider
映射 to Reporting 模式 Provider
映射 to Qualified Event Receiver
Target-Configuration for Security Events
Service-oriented Vehicle 诊断
概述
SOVD Server
SOVD Gateway
Firewall Target-Configuration
Firewall Rules on Datalink Layer
Firewall Rules on 网络 Layer
Firewall Rules on 传输 Layer
Firewall Rules via Byte Pattern
Firewall Deep Packet Inspection of SOME/IP SD and SOME/IP Messages
Firewall Deep Packet Inspection of DoIP Messages
Firewall Deep Packet Inspection of DDS Messages
状态管理 Target-Configuration
概述
Requests to 状态管理
Trigger Requests to 状态管理
错误 Requests to 状态管理
通知 from 状态管理
Rules
概述
Trigger Rules
错误 Rules
Action Items
状态 Machine Action Item
Sync Action Item
功能 Group Action Item
网络管理 Action Item
休眠 Action Item
Suspend to RAM Action Item
状态 Client
错误处理 inside 状态管理
Request 功能 Group 状态
Suspend to RAM
Suspend to RAM 模块 Instantiation
Suspend to RAM 模块 Satellite 映射
Suspend to RAM 模块 Hub 映射
Generic 诊断 TransportInstantiation
Ethernet Endpoint 配置 for Platform 模块
服务实例清单
ApplicationEndpoint
VLAN Priority
服务接口 Deployment
SOME/IP 服务接口 Deployment
DDS 服务接口 Deployment
User Defined 服务接口 Deployment
服务 Instance Target-Configuration
SOME/IP 服务 Instance Deployment
Provided 服务 Instance
IP 配置
TP 配置
服务 Discovery Server 配置
Provided Event Group
ProvidedSomeipServiceInstance related event and method properties
Required 服务 Instance
IP 配置
TP 配置
服务 Discovery Client 配置
Required Event Group
RequiredSomeipServiceInstance related method call properties
Provided 服务 Instance with static remote peers
Required 服务 Instance with static remote peers
DDS 服务 Instance Deployment
Provided DDS 服务 Instance
Required DDS 服务 Instance
DDS 服务 Instance to Machine 映射
User Defined 服务 Instance Deployment
服务 Deployment Relations
End To EndProtection
Secure Communication
Secure Communication over TLS
Secure Communication over SecOC
Secure Communication over DDS
Raw 数据 Stream 清单
Raw 数据 Stream Deployment
Raw 数据 Stream 映射
Raw 数据 Streams over Ethernet using IP based 协议
Ethernet Raw 数据 Stream Client 映射
Ethernet Raw 数据 Stream Server 映射
Raw 数据 Streams over Ethernet using MAC Layer 协议
Raw 数据 Streams over Ethernet using IEEE1722 协议
Raw 数据 Streams for 控制 Messages over Ethernet using IEEE1722 ACF 协议
Cross-Functional Cluster interaction
Com Certificate To Crypto Certificate 映射
Com Key To Crypto Key Slot 映射
Com SecOc To Crypto Key Slot 映射
持久化 Deployment To Crypto Key Slot 映射
持久化 Deployment Element To Crypto Key Slot 映射
持久化 Deployment To Dlt Log Sink 映射
功能性 Cluster To Dlt Log Sink 映射
Ucm To Time Base Resource 映射
功能性 Cluster Interacts With 持久化 Deployment 映射
Adaptive 模块 Instantiation to Security Event 定义映射
状态管理 interacts with 网络管理 and vice versa
状态管理 interacts with 网络管理
网络管理 interacts with 状态管理
功能性 Cluster reports Production 错误
软件 Distribution
概述
Uploadable Package Element
软件 Cluster
软件 Cluster 通用建模
Relevance of 软件 Cluster for 诊断
诊断 Props
Relation to the 诊断 Contribution Set
诊断服务校验
Contract between 软件 Cluster and 软件 Cluster 设计
References between 软件 Clusters
软件 Cluster Artifact Checksum
软件 Cluster Artifact Locator
软件 Package
Vehicle Package
概述
VehicleRolloutStep
UcmStep
SoftwarePackageStep
Interoperability between Classic Platform and Adaptive Platform
Usage of major Version in the SOME/IP 网络 binding
附录
Reference Material
Terms and Abbreviations
Imposition Times of Constraints
示例
数据类型
映射数据类型的定义
String 数据类型的定义
String 数据类型的定义
Vector 数据类型的定义
Struct 数据类型的定义
Enumeration 数据类型的定义
映射数据类型的定义
Variant 数据类型的定义
Scenarios to define a Vector
Service-oriented Communication
Radar and Camera ServiceInterface 示例
服务接口映射
服务接口 Element 映射
服务接口 Event 映射
服务接口 Field 映射
服务接口 Method 映射
服务 Instance Deployment
服务 Instance Deployment by 服务接口映射
服务 Instance Deployment by 服务接口 Element 映射
服务 Instance 映射
SOME/IP 服务 Instance 映射
User-Defined 服务 Instance 映射
定义 of VLAN Priority
Static 配置 of remote Peers
Provided 服务 Instance with remote Peers
Required 服务 Instance with remote Peers
执行管理
启动配置的定义
持久化
Persistent 数据的定义
Persistent 文件的定义
Interaction with the PHM
Relation between Instance Specifier and Instance Ref
Phm Application 设计示例
Phm 配置示例
状态管理
Consideration of User Perspective
Scenario for Trigger
Scenario for 错误
Crypto
Relation between a Crypto Certificate and a Crypto Key Slot
机器清单
Distributed 定义 of Environment Variables
Ethernet Raw 数据 Stream 配置
Preamble
Fully formalized 建模示例
Only Client is formalized
Only Server is formalized
Signal/服务 Translation
Signal/服务映射
映射 Event to Signal
映射 Field to Signal
Signal/服务 Translation 行为
Optional 结构 Element in the context of Signal/服务 Translation
Optional 结构 Element in the context of 服务/Signal Translation
Translation from different Sources
Signal/服务 Translation from different Sources
ServiceSignalTranslation from different Sources
Translation to different Targets
软件 Cluster 设计
Dependencies among 软件 Cluster Designs
Usage of SoftwarePackageStep
Usage of transfer and process
Miscellaneous 示例
Relation of ApApplicationError and ApApplicationErrorDomain
Custom 建模 Extension
概述
Custom Attribute 定义
Custom Primitive Attribute 定义
Custom Complex Attribute 定义
Custom Foreign Reference 定义
Custom Subclass 配置
Custom Constraints
定义 of Reference from SdgClass to SdgClass
通用建模
Reference to a DataPrototype in a PortInterface
Reference to the inside of an ApplicationDataType
Reference to the inside of a CppImplementationDataType
Reference to a AutosarDataPrototype in an Executable
Reference to a Trigger in an Executable
Reference to a PortPrototype in an Executable
建模 of a Method in an Executable
建模 of Diagnostic-related InstanceRefs
建模 of PHM-related InstanceRefs
建模 of Time-related InstanceRefs
建模 of Persistency-related InstanceRefs
建模 of SoftwareClusterDesign-related InstanceRefs
建模 of State-Management-related InstanceRefs
建模 of Intrusion-Detection-related InstanceRefs
建模 of Crypto-related InstanceRefs
Firewall InstanceRef
Mentioned Class Tables
Change History of AUTOSAR Traceable Items
Traceable item history of this document according to AUTOSAR Release R17-03 (original version)
Created Constraints in R17-03
Created 规范 Items in R17-03
Traceable item history of this document according to AUTOSAR Release R17-10
Added 规范 Items in R17-10
Changed 规范 Items in R17-10
Deleted 规范 Items in R17-10
Added Constraints in R17-10
Changed Constraints in R17-10
Deleted Constraints in R17-10
Traceable item history of this document according to AUTOSAR Release R18-03
Added 规范 Items in R18-03
Changed 规范 Items in R18-03
Deleted 规范 Items in R18-03
Added Constraints in R18-03
Changed Constraints in R18-03
Deleted Constraints in R18-03
Traceable item history of this document according to AUTOSAR Release R18-10
Added 规范 Items in R18-10
Changed 规范 Items in R18-10
Deleted 规范 Items in R18-10
Added Constraints in R18-10
Changed Constraints in R18-10
Deleted Constraints in R18-10
Traceable item history of this document according to AUTOSAR Release R19-03
Added 规范 Items in R19-03
Changed 规范 Items in R19-03
Deleted 规范 Items in R19-03
Added Constraints in R19-03
Changed Constraints in R19-03
Deleted Constraints in R19-03
Traceable item history of this document according to AUTOSAR Release R19-11
Added 规范 Items in R19-11
Changed 规范 Items in R19-11
Deleted 规范 Items in R19-11
Added Constraints in R19-11
Changed Constraints in R19-11
Deleted Constraints in R19-11
Traceable item history of this document according to AUTOSAR Release R20-11
Added 规范 Items in R20-11
Changed 规范 Items in R20-11
Deleted 规范 Items in R20-11
Added Constraints in R20-11
Changed Constraints in R20-11
Deleted Constraints in R20-11
Traceable item history of this document according to AUTOSAR Release R21-11
Added 规范 Items in R21-11
Changed 规范 Items in R21-11
Deleted 规范 Items in R21-11
Added Constraints in R21-11
Changed Constraints in R21-11
Deleted Constraints in R21-11
Traceable item history of this document according to AUTOSAR Release R22-11
Added 规范 Items in R22-11
Changed 规范 Items in R22-11
Deleted 规范 Items in R22-11
Added Constraints in R22-11
Changed Constraints in R22-11
Deleted Constraints in R22-11
Added Advisories in R22-11
Changed Advisories in R22-11
Deleted Advisories in R22-11
Traceable item history of this document according to AUTOSAR Release R23-11
Added 规范 Items in R23-11
Changed 规范 Items in R23-11
Deleted 规范 Items in R23-11
Added Constraints in R23-11
Changed Constraints in R23-11
Deleted Constraints in R23-11
Added Advisories in R23-11
Changed Advisories in R23-11
Deleted Advisories in R23-11
Traceable item history of this document according to AUTOSAR Release R24-11
Added 规范 Items in R24-11
Changed 规范 Items in R24-11
Deleted 规范 Items in R24-11
Added Constraints in R24-11
Changed Constraints in R24-11
Deleted Constraints in R24-11
Added Advisories in R24-11
Changed Advisories in R24-11
Deleted Advisories in R24-11
Traceable item history of this document according to AUTOSAR Release R25-11
Added 规范 Items in R25-11
Changed 规范 Items in R25-11
Deleted 规范 Items in R25-11
Added Constraints in R25-11
Changed Constraints in R25-11
Deleted Constraints in R25-11
Added Advisories in R25-11
Changed Advisories in R25-11
Deleted Advisories in R25-11
Traceable item history of this document according to AUTOSAR Release R26-11
Added 规范 Items in R26-11
Changed 规范 Items in R26-11
Deleted 规范 Items in R26-11
Added Constraints in R26-11
Changed Constraints in R26-11
Deleted Constraints in R26-11
Added Advisories in R26-11
Changed Advisories in R26-11
Deleted Advisories in R26-11
Splitable Elements in the 范围 of this Document
Variation Points in the 范围 of this Document
Upstream 映射
简介
CryptoInstantiation
持久化

Specification of Manifest (ManifestSpecification)¶

本地文件¶

文档简介¶

模块依赖¶

章节详细内容¶

1. 简介¶

2. 建模 Approach¶

3. 通用 Considerations¶

4. 诊断配置的建模¶

5. The Term 服务¶

6. Document Conventions¶

7. About Tables¶

8. Big Picture of 清单定义¶

9. 设计 vs. Target 配置¶

10. Preface¶

11. 概述¶

12. Relation between 设计 and Target 配置 Models¶

13. 结构 of the document¶

14. About 清单¶

15. Serialization Format¶

16. 范围¶

17. Manifests described in this Document¶

18. 应用设计¶

19. 概述¶

20. Application 结构¶

21. 软件组件¶

22. Executable¶

23. 概述¶

24. Category¶

25. Root 软件组件 Prototype¶

26. Reporting 行为¶

27. Implementation Props¶

28. Logging¶

29. TraceSwitchConfig¶

30. Interaction Endpoint for Application¶

31. Service-oriented Communication¶

32. Port Prototype Props¶

其余 721 章（内容从略，见纯文本全文）¶

Specification of Manifest (`ManifestSpecification`)¶