Autosar Ports and Port Interfaces

========================================================================================================
This blog is about understanding of AUTOSAR port and its port Interfaces and also port communication specification like PPortComSpec or RPortComSpec. ========================================================================================================



========================================================================================================

Port

Ports are the interaction points between the SWCs. Software components are communicate with other software components or Basic-Software modules via ports.

Application Ports - These ports are used for communication of application SWCs
Service Ports - These ports used for communication application SWCs with BSW

PortPrototype

PortPrototypes of a SwComponentType are supposed to be used for attaching SwConnectors that establish an actual connection between SwComponentPrototypes.
In AUTOSAR terminology Ports are called "PortPrototypes" . other words graphical connection points.

Port Interface

Declaration or details of the data elements or operations that are provided or required by a port is called "Port Interface".
The details, i.e. with respect to what kind of information is actually transported between two PortPrototypes is defined by the PortInterface.
========================================================================================================

Sender-Receiver port

Sender-Receiver(S/R) ports used to exchange the data between SWCs or SWCs with BSW.
Sender Port is Provide port (PPort) : writing data to one or more receivers.
Receiver Port is Require port(RPort) : Reading data from sender.

SR communication should cover following topics:
Sender-Receiver Port Interface:

• SenderReceiverInterfaces allow for the specification of the typically asynchronous communication pattern where a sender provides data that is required by one or more receivers.
• Each SR port has its own SenderReceiverInterface. Don't confuse we can use one PortInterface used for many ports but each port should assign with one PortInterface. example 4 doors having one interface like DoorInterface with boolean datatype but we can use it same Interface for front left, front right, rear left and rear right doors.
• A SenderReceiverInterface focuses on the description of information items represented by VariableDataPrototypes(VDP)
• VDP implemented as "Data Element" which contains information such as Name, datatype, swImplPolicy (queue or nonqueued) for receiver.
• Assembly connectors used by PortPrototypes to connect the SWCs.

Sender-Receiver Port ComSpec: 

The attribute swImplPolicy of a dataElement reference the queue or Nonqueue

• QueuedSenderComSpec: Communication attributes for Queued sender side. 
• NonqueuedSenderComSpec: Communication attributes for non-queued sender side. such as initValue
• QueuedReceiverComSpec: Communication attributes specific to queued receiving. such as queueLength
• NonqueuedReceiverComSpec: Communication attributes specific to non-queued receiving such as aliveTimeout, filter, handleNeverReceived

Access points: How to access ports within the Runnable is called "Access point". 

• Implicit
• datareadAccess
• dataWriteAccess
• Explicit
• dataReceivePointByArgument
• dataReceivePointByValue
• dataSendPoint

RTEEvents: How to Trigger or activate an Runnable is called "RTEEvents". Runnable can be triggered by using Init call or Time or Events. 

Event Runnable triggers as follows:

• DataSendCompletedEvent
• DataWriteCompletedEvent
• DataReceivedEvent
• DataReceivedErrorEvent

Block Diagram of Sender-Receiver Port

Some simple Rte code for implicit communication







Definitions: 

• Implicit Communication: The term "implicit" for communication based on data-access. when using a dataWriteAccess, the RunnableEntity only needs to modify the value of certain variables hence receiver reads the value when RunnableEntity called. Here Runnable working on the local copies of data.
• Explicit Communication: The term "explicit" for communication based on so-called data-points. Using the dataSendPoint, the RunnableEntity needs to explicitly "send" through an API.
• Queued Communication: The swImplPolicy indicates the way how a VariableDataPrototype shall be processed at the receiver’s side. in this method, enable Queued communication during PortInterface creation and mention queue >1 while accessing, If set to queued the semantics is that the corresponding VariableDataPrototype needs to be added to a queue.
• Nonqueued Communication: The attribute swImplPolicy of a dataElement referenced by a NonqueuedSenderComSpec shall not be set to the value queued.

Please Refer blog: AUTOSAR Communication
========================================================================================================

Client-Server port

Client initiates the communication and server perform a service. the server is the provider of operations or functions and the client is a user of operations or functions.

Client-Server communication related topics
Client-Server Port Interface :

• A client/server interface declares a number of operations that can be invoked on a server by a client.
• Direction of ArgumentDataPrototypes: To cover these cases, ArgumentDataPrototype defines an attribute direction, possible values are in (pass to operation), out (return from operation), and inout (pass to and return from operation). in simple word functions with arguments and provide direction to the function arguments.
• Define Application errors like E_Ok or E_NOT_OK while defining the operations we should define errors
• AUTOSAR supports Application Errors only for ClientServerInterfaces

Client-Server Port ComSpec: Both, the ClientComSpec and the ServerComSpec reference a ClientServerOperation of the ClientServerInterface. Operations of the Interface which are not referenced by any ComSpec.



Access Points

• ServerCallPoint: If a RunnableEntity owns a ServerCallPoint it is entitled to invoke a particular ClientServerOperation of a specific RPortPrototype of the corresponding AtomicSwComponentType. 
• SynchronousServerCallPoint: for Runnable that invoke a ClientServerOperation synchronously, synchronous calls are blocking calls, meaning that they only return after the operation has been finished.
• AsynchronousServerCallPoint: for Runnable that invoke a ClientServerOperation asynchronously, asynchronous calls are non-blocking calls, meaning that the call immediately returns even if the actual operation has not yet concluded.
• AsynchronousServerResultPoint: must be used to indicate the completion of the ClientServerOperation.

RTEEvents

• OperationInvokedEvent: The OperationInvokedEvent references the ClientServerOperation invoked by the client. Client is invoking an operation on the server.
• AsynchronousServerCallReturnsEvent: the notification about an asynchronously executed operation having completed is implemented as an AsynchronousServerCallReturnsEvent.

========================================================================================================

Parameter port

• Parameter ports are defined for ParameterSwComponentType. these ports are only send type in the ParameterSwComponentType.
• A parameter interface declares a number of parameter and characteristic values to be exchanged between parameter components and software components.
• Note that a ParameterInterface is not restricted to parameters which can actually can be calibrated. It can be used whenever there shall be no write access to the data during normal operation of the software, i.e. only constant data are visible over the interface.
• Parameter port ComSpec: only initValue is defined in the ParaemeterComSpec of ParameterdataPrototypes. initValue on the level of a ComSpec is relevant for connections to the corresponding PortPrototype
• Access Point: The presence of a ParameterAccess implies that a RunnableEntity needs access to a ParameterDataPrototype.

========================================================================================================

Nonvolatile Data port

• These ports are used to exchange the NV data between NvBlockSwComponentType with other SWCs. The non volatile data of the NvBlockSwComponentType are accessible via provided and required ports.
• nvdatainterface: A non volatile data interface declares a number of VariableDataPrototypes to be exchanged between non volatile block components and atomic software components
• NvProvideComSpec : The main purpose of this kind of ComSpec is the definition of initial values for the RAM block and the ROM block that corresponds to an nvData defined in the context of the NvDataInterface used to type the given PPortPrototype.
• NvRequireComSpec: the NvRequireComSpec can be define an initValue.

========================================================================================================

Trigger port

• Trigger ports are similar to Client-Server but it does not have ComSpec and TriggerInterface does not have any arguments.
• TriggerInterface: The TriggerInterface defines a set of Trigger to be communicated between software-components. The Trigger represents a special kind of events at which occurrence the trigger sinks shall react in a particular manner.
• Access points: If a RunnableEntity owns an ExternalTriggeringPoint it is entitled to raise an ExternalTriggerOccurredEvent.
• RTEEvents: ExternalTriggerOccurredEvent: The event is raised when the referenced trigger have been occurred.

========================================================================================================

Mode Switch port

• Mode switches are necessary because Software Components need to be capable of reacting to state changes initiated by a ModeManager.
• ModeSwitchInterface: A mode switch interface declares a ModeDeclarationGroupPrototype to be sent and received. For every ModeDeclarationGroup referenced by a ModeDeclarationGroupPrototype used in a Port-Prototype typed by a ModeSwitchInterface.
• ModeSwitchSenderComSpec: Communication attributes of PPortPrototypes with respect to mode communication i.e. modeGroup, modeSwitchedAck
• ModeSwitchReceiverComSpec: Communication attributes of RPortPrototypes with respect to mode communication .i.e. modeGroup supportsAsynchronousModeSwitch
• Access Points:
• ModeAccessPoint : A ModeAccessPoint is required by a RunnableEntity owned by a Mode Manager or Mode User.
• ModeSwitchPoint : A ModeSwitchPoint is required by a RunnableEntity owned a Mode Manager. Its semantics implies the ability to initiate a mode switch.

RTEEvents:

• SwcModeSwitchEvent: This event is raised upon a received mode change. i.e. ModeActivation Kind, ModeDeclaration.
• ModeSwitchedAckEvent: The event is raised when the referenced modes have been received or an error occurs.

========================================================================================================

Port Interface Mapping: 

• By default, the shortNames of PortInterface elements are used to identify the matching element pairs of connected PortPrototypes.
• Each PortInterfaceMapping describes the mapping of the PortInterface elements of exactly two  PortInterfaces
• In SR Communication: VariableAndParameterInterfaceMapping, DataPrototypeMapping, 
• In CS Communication: ClientServerInterfaceMapping,  ClientServerOperationMapping, ClientServerApplicationErrorMapping.
• Mode Communication:  ModeInterfaceMapping,  ModeDeclarationGroupPrototypeMapping,  ModeDeclarationMappingSet,  ModeDeclarationMapping.
• Trigger Port : TriggerInterfaceMapping, TriggerMapping.

========================================================================================================
Note: RTE APIs like Rte_Read, Rte_Write, Rte_Receive, Rte_Send will discuss in upcoming posts.

References:

Application Interface user Guide

Software Component Template

AUTOSAR: Application Layer

========================================================================================================

Thanks for visiting the Post..!!

========================================================================================================