AUTOSAR_TPS_SoftwareComponentTemplate

Overview: Software Components, Ports, and Interfaces

Introduction

The detailed introduction of all aspects of the Software Component Template in

one move is considered too complex. This chapter therefore provides an overview of

the main conceptual aspects of software components, ports and interfaces.

The overview will then be broken down into further details in chapter 4.

One of the goals of the AUTOSAR concept is the support of re-usability on the level of

application software.

In other words: it should be possible to re-use existing artifacts to create further model

elements instead of being forced to create every single modeling detail from scratch.

One of the consequences of this approach is the application of the so-called typeprototype pattern [11].

The type-prototype pattern is created by using references from prototype to type that

are decorated with the isOfType. The existence of such references is governed

by [constr_2633], see [11].

Among other things, this concept allows for creating hierarchical structures of softwarecomponents with arbitrary complexity. However, the creation of hierarchical structures itself does not have an impact on the run-time behavior of the overall system.

The actual behavior is completely defined within the individual software-components.

This conclusion is backed by the understanding that software-components are developed against the so-called Virtual Functional Bus (VFB), an abstract communication channel without direct dependency on ECUs and communication buses.

The VFB does not provide any means for expressing a hierarchy of softwarecomponents.

Of course, the usage of the VFB has further consequences on the design of softwarecomponents which shall not directly call the operating system or the communication

hardware.

As a result, software-components can be deployed to actual ECUs at a rather late

stage in the development process.

In order to make the description more precise, the following text preferably uses accurate meta-model terms instead of the rather vague terminology of “composition” and “software-component”.

Software Component

Overview

Application software within AUTOSAR is organized in self-contained units called AtomicSwComponentTypes.

Such AtomicSwComponentTypes encapsulate the implementation of their functionality and behavior and merely expose well-defined connection points, called PortPrototypes, to the outside world.

The graphical appearance of AUTOSAR software-components according to [3] is depicted in Figure 3.1.

PortPrototype

Please note that PortPrototypes of a SwComponentType are supposed to be used

for attaching SwConnectors that establish an actual connection between SwComponentPrototypes (see chapter 3.3).

[TPS_SWCT_01002] 

[RS_SWCT_00020]

[RS_SWCT_00030]

[RS_SWCT_00150]

[RS_SWCT_00160]

[RS_SWCT_00200]

[RS_SWCT_00210]

[RS_SWCT_02010]

[RS_SWCT_02030]

SwComponentTypes may only interact by means of their PortPrototypes.

• AtomicSwComponentTypes (and also the more general SwComponentTypes may only interact by means of their PortPrototypes). Hidden communication dependencies that are not expressed by means of PortPrototypes are strictly forbidden.

Therefore, software-components are in theory exchangeable as long as they implement the same functionality and provide the same public communication interface to the remaining system.

[TPS_SWCT_01111] 

[RS_SWCT_00010]

PortPrototypes need an additional model artifact, the PortInterface.

• Please note that PortPrototypes actually need an additional model artifact, the PortInterface, for fully describing the details of the PortPrototype.

The concept of the PortInterface as another means for establishing a high degree

of re-usability is described in chapter 3.4.

[TPS_SWCT_01112]

[RS_SWCT_03250]

Semantics of PortPrototypes

• PortPrototypes can have the following semantics:

• A require-port (in technical terms: RPortPrototype) requires certain services or data.

• A provide-port (or PPortPrototype) on the other hand provides services or data.

• A provide-require-port (or PRPortPrototype) combines the ability to provide and require services or data in one entity.

The semantics of PortPrototype is also depicted in Figure 3.2.

[TPS_SWCT_01573]

[RS_SWCT_00010]

[RS_SWCT_03250]

[RS_SWCT_03130]

A PRPortPrototype is never considered unconnected.

• A PRPortPrototype is never considered unconnected, even if there are no SwConnectors actually referring to it.

Please note that [TPS_SWCT_01573] represents the immediate consequence of the

semantics defined in [TPS_SWCT_01112].

[TPS_SWCT_01113]

[RS_SWCT_03130]

[RS_SWCT_03250]

Connecting two PortPrototypes

• Two SwComponentPrototypes are eventually connected by hooking up a PPortPrototype or PRPortPrototype of one SwComponentPrototype to a compatible RPortPrototype or PRPortPrototype of the other SwComponentPrototypes.

Please find more information concerning the definition of “compatibility” in section 6.

[TPS_SWCT_01096] 

[RS_SWCT_03201]

PortGroup 

• PortPrototypes can be logically grouped into PortGroups. This mechanism is used for implementing mode management features.

Further explanations about the semantics of meta-class PortGroup can be found in

chapter 4.6.

There are cases where an RPortPrototype is intentionally left unconnected. Such

a scenario would typically be reported if the RTE Generator is executed in strict mode.

By means of setting attribute RPortPrototype.mayBeUnconnected, the designer of

the respective software-component has the ability to express that the "open" RPortPrototype is part of the final design and shall not be reported, even in strict mode.

The attribute can be used in combination of an RPortPrototype and any kind of

PortInterface.

Note that the attribute applies to the entire RPortPrototype, not to individual elements

of the applicable PortInterface.

In other words, the attribute does not affect the case, where e.g. only one dataElement

of several sender/receiver RPortPrototype is left unconsidered, as described

by [TPS_SWCT_01101].

Please note that the usage of RPortPrototype.mayBeUnconnected is potentially

dangerous because it removes a warning and this can be harmful if the suppression of

a legitimate warning were done by mistake.

It is therefore advised to handle the existence of RPortPrototype.mayBeUnconnected

with care.

AtomicSwComponentType

[TPS_SWCT_01108]

[RS_SWCT_03040]

Added value of an AtomicSwComponentType.

• As mentioned before, the term AtomicSwComponentType is a specific form of the general concept of the SwComponentType. The added value of an AtomicSwComponentType is that it can aggregate an InternalBehavior.

More information regarding the semantics of InternalBehavior can be found in

chapter 7.

[TPS_SWCT_01109]

[ ]

Adding the SwcInternalBehavior in a later process step.

• The aggregation of SwcInternalBehavior is stereotyped <atpSplitable> to allow for adding the SwcInternalBehavior in a later process step. In other words, it is possible to completely develop the VFB view of a software-component and later add more details like InternalBehavior.

There are several specialized SwComponentTypes to describe specific softwarecomponents used in the different parts of the AUTOSAR Layered Architecture [5]. Further details are mentioned in chapter 10 and 11.

The ApplicationSwComponentType is a specialization of AtomicSwComponent-

Type for representing hardware-independent application software. The Parameter-

SwComponentType is a specialization of SwComponentType that can - in contrast to

AtomicSwComponentType - not aggregate SwcInternalBehavior.

The purpose of the NvBlockSwComponentType is described in detail in section

11.4.2. The ServiceSwComponentType is described in section 11.2. Further on,

the EcuAbstractionSwComponentType and the ComplexDeviceDriverSwComponentType are discussed in detail in section 10.

A description of the ServiceProxySwComponentType can be found in section 11.3

while the SensorActuatorSwComponentType is described in section 10.4.

ParameterSwComponentType

[constr_1092]

[ ]
Restrictions for the ParameterSwComponentType.

• The following restrictions exist for a ParameterSwComponentType:

• it shall never aggregate a SwcInternalBehavior and

• the only aggregated PortPrototypes shall be PPortPrototypes of type ParameterInterface.

        This rule shall be imposed at the time when the contract phase generation

        is executed.

[TPS_SWCT_01847]

[ ]

Define role-specific data properties of elements of composite data types used for the definition of calibration parameters.

• A ParameterSwComponentType shall have the ability to aggregate InstantiationDataDefProps. By this means it is possible to define role-specific data properties of elements of composite data types used for the definition of calibration parameters in the scope of a ParameterSwComponentType.

For more information about this aspect please refer to section 7.5.4.

Symbolic Name of a Software-Component

Please note that an AtomicSwComponentType manifests itself in the source code of

an RTE into which an instance of the AtomicSwComponentType is deployed. This

implies potential naming conflicts if instances of AtomicSwComponentType that have

identical shortNames are deployed into a specific RTE.

[TPS_SWCT_01110]

[ ]

Symbolic name of a software-component

• To mitigate this potential hazard it is possible to provide the AtomicSwComponentType along with an accompanying symbolic name that can be used for resolving the name clash. The symbolic name is provided by means of the attribute symbol of the meta-class SymbolProps owned by AtomicSwComponentType in the role symbolProps.

Please note that more information about the symbolic name provided by means of the

attribute symbol of the meta-class SymbolProps owned by AtomicSwComponentType in the role symbolProps can be found in Figure 3.6.

For more detailed information about how SymbolProps can be used to mitigate name

clashes occurring during the integration of software-components on an AUTOSAR

ECU, please refer to [4].

[TPS_SWCT_01000]

[RS_SWCT_00230]

Usage of attribute symbol of the symbolProps

• In particular, the RTE generator shall take over the value of the attribute symbol of the symbolProps owned by a given AtomicSwComponentType. If and only if symbolProps is not defined the RTE generator shall take the shortName of the AtomicSwComponentType. For the generation of symbols for RunnableEntitys [TPS_SWCT_01001] shall be observed.

[TPS_SWCT_01001]

[RS_SWCT_00230]

Prefix symbols generated for the RunnableEntity

• If and only if the attribute symbol of a symbolProps owned by an AtomicSwComponentType exists, its value shall also be taken for prefixing the symbols generated for the RunnableEntitys owned by the AtomicSwComponentType.

Note: if symbolProps is not defined the behavior of the RTE generator is fully backwards compatible, i.e. existing implementations of RunnableEntitys do not have to

be touched in order to conform with this version of the AUTOSAR standard.

This is a further measure to mitigate the risk of potential name clashes in the RTE code.

[TPS_SWCT_01635]

[RS_SWCT_00230]

Naming conventions may support the effectiveness of SymbolProps.

• Of course, there is a residual risk that even in the presence of SymbolProps name clashes may occur. Therefore, the definition of naming conventions may facilitate the avoidance of name clashes to the further degree.

Composition

Overview

[TPS_SWCT_01032]

[RS_SWCT_00190]

[RS_SWCT_02000]

[RS_SWCT_02020]

[RS_SWCT_03000]

CompositionSwComponentType

• The purpose of an AUTOSAR CompositionSwComponentType is to allow the encapsulation of specific functionality by aggregating existing software components.

[TPS_SWCT_01033]

[RS_SWCT_00190]

[RS_SWCT_02000]

[RS_SWCT_02020]

[RS_SWCT_03000]

Nested definition of CompositionSwComponentTypes

• Since a CompositionSwComponentType is also a SwComponentType, it again may be aggregated in further CompositionSwComponentTypes.

This recursive relation is formally expressed in Figure 3.7.

It is important to understand that while compositions allow for (sub-) system abstraction, they are solely an architectural element for the implementation of model scalability.

They simply group existing software-components and thereby take away complexity

when viewing or designing logical software architecture.

Therefore, the definition of CompositionSwComponentTypes has no effect on how

software-components interact with the Virtual Functional Bus (VFB). Composition-

SwComponentTypes do not add any new functionality to what is already provided by

the software-components they aggregate.

[TPS_SWCT_01034]

[RS_SWCT_00190]

[RS_SWCT_02000]

[RS_SWCT_02020]

[RS_SWCT_03000]

CompositionSwComponentTypes do not have any binary footprint.

• As the main consequence, CompositionSwComponentTypes do not have any binary footprint in the ECU software.

SwComponentPrototype

[TPS_SWCT_01035]

[RS_SWCT_00190]

[RS_SWCT_02000]

[RS_SWCT_02020]

[RS_SWCT_03000]

CompositionSwComponentType aggregates SwComponentPrototypes

• In terms of the AUTOSAR meta-model, a composition of softwarecomponents realized by the meta-class CompositionSwComponentType aggregates SwComponentPrototypes which in turn are typed by a SwComponentType.

Please note that a CompositionSwComponentType is also a SwComponentType.

[TPS_SWCT_01036]

[RS_SWCT_00190]

[RS_SWCT_02000]

[RS_SWCT_02020]

[RS_SWCT_03000]

SwComponentPrototype implements a specific role.

• Therefore, a SwComponentPrototype implements the usage of a SwComponentType in a specific role.

[TPS_SWCT_01037]

[RS_SWCT_00190]

[RS_SWCT_02000]

[RS_SWCT_02020]

[RS_SWCT_03000]

arbitrary numbers of SwComponentPrototypes can be created.

• In general, arbitrary numbers of SwComponentPrototypes that refer to specific SwComponentTypes can be created.

Example: a SwComponentPrototype “LeftDoorControl” fulfills the role of implementing the SwComponentType “DoorControl” for the left door of a vehicle while the SwComponentPrototype “RightDoorControl” fulfills the role of the SwComponentType “DoorControl” for the right door.

[TPS_SWCT_01080]

[RS_SWCT_03130]

Delegation ports

• Note that being a SwComponentType, a CompositionSwComponentType also exposes PortPrototypes to the outside world. However, the PortPrototypes are only delegated and do not play the same role as PortPrototypes attached to AtomicSwComponentTypes.

[TPS_SWCT_01081]

[RS_SWCT_03130]

Implications of being a delegation port

• Being a PortPrototype attached to a CompositionSwComponentType has the following implications:

• The delegation has to follow the rules for basic compatibility.

• By creating PortPrototypes on the surface of a specific CompositionSwComponentType it is explicitly decided whether the contents of an “inner” port contained in the CompositionSwComponentType is exposed to the outside world.

Please note that the rules for compatibility are described in chapter 6.

Please note further that the semantics of the delegation of PortPrototypes are similar

to encapsulation mechanisms like public and private members in object-oriented

programming languages.

One implication of the concept of CompositionSwComponentType is that the application software of an entire vehicle eventually is represented by one CompositionSwComponentType. This so-called top-level composition has a special role in the context of the AUTOSAR System Template [10].

However, please note that a top-level composition might have (unconnected) Port-

Prototypes in order to allow for reuse as part of another system.

[constr_1035]

[ ]

Recursive definition of CompositionSwComponentType

• The recursive definition of a CompositionSwComponentType that eventually contains a SwComponentPrototype typed by the same CompositionSwComponentType shall not be feasible at any time in the workflow.

Connectors

[TPS_SWCT_01079]

[RS_SWCT_03130]

SwConnector

• Note that CompositionSwComponentType also aggregates the abstract meta-class SwConnector for connecting the contained SwComponentPrototypes among each other.

More information can be found in Figure 3.8.

CompositionSwComponentTypes contain three kinds of SwConnectors:

[TPS_SWCT_01082]

[RS_SWCT_03130]

AssemblySwConnector

• AssemblySwConnectors interconnect PortPrototypes of SwComponentPrototypes that are part of the CompositionSwComponentType.

[TPS_SWCT_01083]

[RS_SWCT_03130]

DelegationSwConnector

• DelegationSwConnectors connect from “inner” PortPrototypes to delegated “outer” PortPrototypes.

[TPS_SWCT_01084]

[RS_SWCT_03130]

Outer PortPrototype is referenced by multiple DelegationSwConnectors.

• In the case that an outer PortPrototype is referenced by multiple DelegationSwConnectors the semantic is the multiplication of the AssemblySwConnectors referencing the outer PortPrototypes.

PassThroughSwConnector, see [TPS_SWCT_01507].

[constr_1086]

[ ]

SwConnector between two specific PortPrototypes

• Each pair of PortPrototypes can only be connected by one and only one SwConnector at the time when the RTE is generated.

In other words, it is not supported to create two different SwConnectors that connect

the same pair of PortPrototypes.

[TPS_SWCT_01638]

[ ]

Existence of SwConnector between two PRPortPrototypes

• [constr_1086] applies also in the case that two PRPortPrototypes are connected with each other. In particular, the roles

• AssemblySwConnector.requester

• AssemblySwConnector.provider

• PassThroughSwConnector.providedOuterPort

• PassThroughSwConnector.requiredOuterPort

        do not establish a direction in this case.

For clarification, [TPS_SWCT_01638] means that the SwConnector represents the

ability for bi-directional communication between the two PRPortPrototypes.

[constr_1087]

[ ]

AssemblySwConnector inside CompositionSwComponentType

• An AssemblySwConnector can only connect PortPrototypes of SwComponentPrototypes that are owned by the same CompositionSwComponentType at any time in the workflow.

[constr_1088]

[ ]

DelegationSwConnector inside CompositionSwComponentType

• A DelegationSwConnector can only connect a PortPrototype of a SwComponentPrototype that is owned by the same CompositionSwComponentType that also owns the connected delegation PortPrototype at any time in the workflow.

In the context of attaching a DelegationSwConnector to an inner PRPortPrototype

there is some ambiguity to be considered. In particular, from the formal point of

view it would be feasible to use either a PPortInCompositionInstanceRef or a

RPortInCompositionInstanceRef.

The ability to use one or the other meta-class arbitrarily is considered confusing. Therefore, [TPS_SWCT_01515] has been defined to remove the unnecessary degree of freedom.

[TPS_SWCT_01515]

[RS_SWCT_03130]

PPortInCompositionInstanceRef shall be used for attaching DelegationSwConnector to an inner PRPortPrototype.

• For the implementation of the attachment of a DelegationSwConnector to an inner PRPortPrototype the meta-class PPortInCompositionInstanceRef shall be used.

[constr_1100]

[ ]

Unconnected RPortPrototype typed by a DataInterface

• For any element in an unconnected RPortPrototype typed by a DataInterface, there shall be a requiredComSpec that defines an initValue at the time when the RTE is generated.

One specific use case for the application of SwConnectors is exemplified by the figures

3.9 and 3.11. A specific CompositionSwComponentType exists in two variants

where one (more complex) variant foresees the existence of a SwComponentPrototype

inside the CompositionSwComponentType (depicted by 3.9) and the other

(because it is implementing a simpler semantics) does not need the SwComponentPrototype.

[constr_1860]

[ ]

Multiplicity of DelegationSwConnector.innerPort

• For each DelegationSwConnector, the reference DelegationSwConnector.innerPort shall exist at the time when the creation of the CompositionSwComponentType is finished.

[constr_1861]

[ ]

Multiplicity of DelegationSwConnector.outerPort

• For each DelegationSwConnector, the reference DelegationSwConnector.outerPort shall exist at the time when the creation of the CompositionSwComponentType is finished.

Without the ability to define a PassThroughSwConnector the second variant could

only be implemented by defining a dummy SwComponentPrototype inside the

CompositionSwComponentType. However, the dummy SwComponentPrototype

would need to define RunnableEntitys that are created for the sole purpose of being

able to shove the data from (e.g. for sender-receiver communication) RPortPrototypes

to PPortPrototypes.

This would not only be cumbersome it would also obviously require additional resources (memory and code) at run-time. Plus, the existence of addition RunnableEntitys also unnecessarily increases the propagation delay of information flowing around inside the ECU.

[TPS_SWCT_01507]

[RS_SWCT_03130]

The role of PassThroughSwConnector

• PassThroughSwConnector can be taken to connect PortPrototypes owned by the same CompositionSwComponentType. In other words, PassThroughSwConnector creates a bypass inside a CompositionSwComponentType from the requiredOuterPort to the providedOuterPort (or vice versa) without involving SwComponentPrototypes.

[constr_1252]

[ ]

Creation of a loop involving a PassThroughSwConnector is not allowed.

• at any time in the workflow, a PassThroughSwConnector is not allowed if the required outer PortPrototype is directly or indirectly connected to the provided outer PortPrototype without the placement of a SwComponentPrototype typed by an AtomicSwComponentType in the chain of SwConnectors.

In other words, according to [constr_1252] it is not allowed to create a “infinite loop” by means of a PassThroughSwConnector and at least one AssemblySwConnector

that connects the requiredOuterPort to the providedOuterPort.

[constr_1862]

[ ]

Multiplicity of PassThroughSwConnector.requiredOuterPort

• For each PassThroughSwConnector, the reference PassThroughSwConnector. requiredOuterPort shall exist at the time when the creation of the CompositionSwComponentType is finished.

[constr_1863]

[ ]

Multiplicity of PassThroughSwConnector.providedOuterPort

• For each PassThroughSwConnector, the reference PassThroughSwConnector. providedOuterPort shall exist at the time when the creation of the CompositionSwComponentType is finished.

[TPS_SWCT_01843]

[RS_SWCT_03130]

Value of PassThroughSwConnector.category

• Meta-class PassThroughSwConnector can be used in different contexts:

• The PassThroughSwConnector is designed to implement VFB communication and therefore is considered in the generation of the RTE. In this case the attribute PassThroughSwConnector.category should either not exist or should be set to the value VFB.

• The PassThroughSwConnector is used to support the early design of a signal/service translation. At some point, the early design is replaced by actual ApplicationSwComponentTypes that finally implement the intended communication path sketched by the early design on the VFB.

    For more details about designing a signal/service translation by means of a

PassThroughSwConnector, please refer to the TPS System Template [10]. To

indicate the usage of the PassThroughSwConnector for the early design purpose,

the value of the attribute PassThroughSwConnector.category should

be set to S2S_DESIGN.

Please note that, on the AUTOSAR adaptive platform, the PassThroughSwConnector

is also used for the design of a signal/service translation in a way that is very similar to the approach described in the TPS System Template [10]. More details can

be found in the TPS Manifest Specification [14].

Instantiation-specific RTEEvents

[TPS_SWCT_02507]

[RS_SWCT_03046]

[RS_SWCT_03270]

Instantiation-specific RTEEvents

• It is possible to specify instantiation specific properties of an RTEEvent by applying InstantiationRTEEventProps in the role instantiationRTEEventProps.

• This allows to use the same ApplicationSwComponentType in different timing scenarios. Even if the scheduling is an issue of the SwcInternalBehavior, the instance specific definition of timing needs to be specified on the level of a CompositionSwComponentType.

As an example for [TPS_SWCT_02507], please consider a software-component that

implements a closed-loop control algorithm.

This software-component can potentially be deployed to “slow” and “fast” control scenarios. As the actual time-base of the control algorithm is derived from the scheduling implemented in the RTE it obviously facilitates the overall design if the timing can be defined on “instance” level.

[constr_1233]

[ ]

• InstantiationTimingEventProps shall only reference TimingEvent at any time in the workflow, an InstantiationTimingEventProps shall only reference TimingEvent in the role refinedEvent. A reference to other kinds of RTEEvents is not supported.

[constr_1864]

[ ]

Multiplicity of InstantiationRTEEventProps.refinedEvent

• For each InstantiationRTEEventProps, the instance-reference InstantiationRTEEventProps. refinedEvent shall exist at the time when the RTE is generated.

Please note that the attribute shortLabel only contributes to model semantics if the

ability to split the definition of the aggregation CompositionSwComponentType.instantiationRTEEventProps over several physical files is actually utilized1.

More explanation about the ability to split models over physical files can be found

in [11].

Port Interface

[TPS_SWCT_01025]

[RS_SWCT_00010]

[RS_SWCT_00080]

[RS_SWCT_00110]

[RS_SWCT_02030]

[RS_SWCT_03010]

The role of PortPrototypes in the AUTOSAR architecture

• A PortPrototype mainly contributes the functionality of being a connection point to the AUTOSAR concept. The details, i.e. with respect to what kind of information is actually transported between two PortPrototypes is defined by the PortInterface.

[TPS_SWCT_01026]

[RS_SWCT_00010]

[RS_SWCT_00080]

[RS_SWCT_00110]

[RS_SWCT_02030]

[RS_SWCT_03010]

The role of PortInterfaces in the AUTOSAR architecture

• PortInterfaces are used to support a design-by-contract work-flow, i.e. a PortInterface provides means to formally verify structural and dynamic compatibility between software-components.

In other words: PortInterfaces (see Figure 3.14) represent a pivotal point in the

AUTOSAR concept.

Please note that a PortInterface creates a name space for the information contained.

This allows for defining the details of a specific PortInterface without having

to care for possible side effects on other PortInterfaces. Again, this property

of the AUTOSAR concept directly supports re-usability.

[TPS_SWCT_01027]

[RS_SWCT_00010]

[RS_SWCT_00080]

[RS_SWCT_00110]

[RS_SWCT_02030]

Different flavors of PortInterfaces

• Within the AUTOSAR concept, different flavors of PortInterfaces are defined:

• SenderReceiverInterface

• NvDataInterface

• ParameterInterface

• ModeSwitchInterface

• ClientServerInterface

• TriggerInterface

[TPS_SWCT_01069]

[RS_SWCT_00010]

[RS_SWCT_00080]

[RS_SWCT_00110]

[RS_SWCT_03010]

DataInterface is defined as abstract base class

• Please note that the conceptual relationship of SenderReceiverInterface, NvDataInterface, and ParameterInterface is expressed by the definition of the abstract base class DataInterface.

Please find more details about the specialization of the PortInterface concept in

chapter 4.2.3 and 4.2.2.

[TPS_SWCT_01070]

[RS_SWCT_00010]

[RS_SWCT_00080]

[RS_SWCT_00110]

[RS_SWCT_03010]

PortInterface acts as a type for a PortPrototype

• From an abstract point of view, a PortInterface acts as a type for a PortPrototype. This means in particular that several PortPrototypes can be typed by the same PortInterface.

Of course, this aspect facilitates the creation of valid connections between softwarecomponents dramatically. By using a specific PortInterface for typing particular PortPrototypes the latter are eligible for being connected to each other by definition.

However, the creation of a valid connection does not need to be based on the usage

of identical PortInterfaces. It is also possible to use different, but compatible

PortInterfaces. The details about compatibility of PortInterfaces are described

in chapter 6.

[constr_1036]

[ ]

Connect kinds of PortInterfaces

• It shall not be possible to connect PortPrototypes typed by PortInterfaces of different kinds at the time when the RTE is generated. Subclasses of DataInterface make an exception to this rule and can be used for creating connections to each other.

For clarification, a connection between a PortPrototype typed by a SenderReceiverInterface and a PortPrototype typed by a ClientServerInterface shall not be possible. However, the creation of a connection between a PortPrototype typed by a SenderReceiverInterface and a PortPrototype typed by a ParameterInterface is supported.

[constr_1137]

[ ]

Applicability of ParameterInterface

• A PPortPrototype typed by a ParameterInterface can only be owned by a ParameterSwComponentType or a CompositionSwComponentType at any time in the workflow.

Please note that PortInterfaces also play an important role in the context of defining

so-called AUTOSAR services. In particular, by means of the attribute isService

a PortInterface can define whether it is supposed to be used in the context of

an AUTOSAR service and in addition to this it may define (by means of the attribute

serviceKind) what kind of service is intended.

The creation of an AssemblySwConnector between PortPrototypes where the

respective PortInterfaces have set attribute isService to true puts requirements

on the nature of the enclosing SwComponentTypes.

For example, it does not make sense to establish a service communication between

two SwComponentPrototypes that each are typed by ApplicationSwComponentTypes.

For service communication, at least one of the participating SwComponentPrototypes

has be to be typed by a ServiceSwComponentType.

[constr_10067]

[ ]

Creation of AssemblySwConnector for service communication

• If an AssemblySwConnector is created between two PortPrototypes and the affected PortInterfaces set the attribute isService to the value true, then at least one of the SwComponentPrototypes shall be typed by a ServiceSwComponentType. This constraint shall be imposed at the time when the RTE is generated.

The information contained in serviceKind can be used in various ways. The primary

intent is to distinguish between the usage of standardized AUTOSAR services from

the usage of a vendor-specific service. This information may have an impact on the

development- and build process of software-components that use the PortInterface.

In addition, it is also possible to use the information contained in serviceKind for

filtering the presentation of an AUTOSAR model in an AUTOSAR authoring tool and

e.g. display the nature of the service PortPrototypes independently of the content

of the corresponding PortInterface.

[TPS_SWCT_01003]

[RS_SWCT_00030]

Inconsistencies regarding the value of serviceKind and the actual implementation of the PortInterface.

• In case of inconsistencies between the value of serviceKind and the actual implementation of the PortInterface the implementation of the PortInterface wins over the value of attribute PortInterface.serviceKind (which, for the intended purpose shall be considered an annotation rather than a semantically binding information).

[TPS_SWCT_01004]

[RS_SWCT_00030]

• Specific default value if serviceKind is not defined if the attribute serviceKind is not defined in the context of a specific PortInterface the default value anyStandardized shall be assumed.

[constr_1174]

[ ]

PortInterfaces used in the context of CompositionSwComponentTypes cannot refer to AUTOSAR services.

• CompositionSwComponentTypes shall not own PortPrototypes typed by PortInterfaces where the attribute isService is set to true at any time in the workflow.

Please find more details about the relation of PortInterfaces to AUTOSAR services

in chapter 11.