Types of Interfaces and Ports

Interfaces and ports are a vital part of a Software Component's ability to communicate. Learn what they are and how they're used

Previously on Autosar Today, we have talked about events and software components, on three different articles: Types of Software Components (opens in a new tab), Overview of Events (opens in a new tab) and How to Create Arxml for Software Components (opens in a new tab). Today, we take an extra step and discuss how Software Component communication is performed, with a bit of detail.

You may already have learned that the RTE enables the communication between Software Components and also between those components and BSW modules, namely, through something called VFB (Virtual Function Bus). By definition, it's a bit more than that. Maybe, after this article, it might be worth for you to take a look at the article What is the Autosar Virtual Function Bus (coming soon). It's not the focus of this article to go deeper than the aforementioned definition. Regarding ports and interfaces, a possible way to sum this relationship is: the port is a Sw-C's means of communication with the outside world. Each port is made to connect with its counterpart, on another component (it can either require/be a client or provide/be a server. Depending on the type of port the nomenclature changes, more on that later). An interface, or port interface, describes the data or operation(s) that can be exchanged through a specific port.

Since the port is bound to an interface, their types are bound by name. The particularity of ports is that they have a direction, which we'll specify the naming for each interface. But, in essence, this is an option for how you can declare a port in Arxml:

    <R-PORT-PROTOTYPE>
        <SHORT-NAME>WipgSpdIntlFromHmi</SHORT-NAME>
        <LONG-NAME><L-4 L="EN">Wiping Speed Interval From Hmi</L-4></LONG-NAME>
        <REQUIRED-INTERFACE-TREF
            DEST="SENDER-RECEIVER-INTERFACE">
            WipgSpdIntlReq1
        </REQUIRED-INTERFACE-TREF>
    </R-PORT-PROTOTYPE>

An important thing to keep in mind is, whether you have the interface defined in a single component or in multiple, the interface has to be exactly the same, otherwise your Autosar toolchain will not let you connect both ports. First, let's check the existing types of interfaces for our ports:

• Sender Receiver - Used to exchange data between software components, which can be provided or required by a port. The interface defines the data elements sent/received by the components. The interface defines the data elements that are transferred:

    <SENDER-RECEIVER-INTERFACE>
        <SHORT-NAME NAME-PATTERN="{anyName}">WipgSpdIntlReq1</SHORT-NAME>
        <LONG-NAME><L-4 L="EN">Wiping Speed Interval Request</L-4></LONG-NAME>
        <DESC><L-2 L="EN">Requests the interval speed.</L-2></DESC>
        <IS-SERVICE>false</IS-SERVICE>
        <DATA-ELEMENTS>
            <VARIABLE-DATA-PROTOTYPE>
                <SHORT-NAME NAME-PATTERN="{anyName}">Req</SHORT-NAME>
                <TYPE-TREF DEST="APPLICATION-PRIMITIVE-DATA-TYPE"
                BASE="ApplicationDataTypes">WipgSpdIntl1</TYPE-TREF>
            </VARIABLE-DATA-PROTOTYPE>
        </DATA-ELEMENTS>
    </SENDER-RECEIVER-INTERFACE>

You can call the respective API's in your source code to use it on your Software Components:

    Rte_Write
    Rte_Read
    
    Rte_IRead
    Rte_IWrite

    Rte_Send
    Rte_Receive 

The differences between all of them are that in the Read and Write, the RTE accesses the buffer directly, so you always get the latest value, where in the IRead and IWrite, the RTE uses a buffered copy stored before executing the runnable (so a subsequent write while the runnable for reading is in place won't affect the IRead result) and in Send and Receive, the RTE reads from a specific queue.

Sender (left) and receiver (right) ports symbol

If the service involves a Service Software Component, the port color will be inverted (symbol in white, background color in black), while the opposite is valid for the other Software Components.

Symbol of service ports

• Client Server - Used to provide functionalities from a Software Component (server) for another to consume (client). A single interface can be used to provide multiple operations at once, with each one having input, output or inout arguments. An example of Arxml can be:

    <CLIENT-SERVER-INTERFACE>
        <SHORT-NAME NAME-PATTERN="{anyName}">TrsmRatGear1</SHORT-NAME>
        <LONG-NAME><L-4 L="EN">Transmission: Gear Ratio for a Given Gear</L-4></LONGNAME>
        <DESC><L-2 L="EN">Returns the gear ratio for a given gear</L-2></DESC>
        <IS-SERVICE>false</IS-SERVICE>
        <OPERATIONS>
            <CLIENT-SERVER-OPERATION>
                <SHORT-NAME NAME-PATTERN="{anyName}">GetTrsmRatGear</SHORT-NAME>
                <LONG-NAME><L-4 L="EN">Returns the Gear Ratio for a Given Gear</L4></LONG-NAME>
                <DESC><L-2 L="EN">Returns the gear ratio for a given gear</L2></DESC>
                <ARGUMENTS>
                    <ARGUMENT-DATA-PROTOTYPE>
                        <SHORT-NAME NAME-PATTERN="{anyName}">Gear</SHORT-NAME>
                        <LONG-NAME><L-4 L="EN">Gear for Which the Ratio Should Be
                        Returned</L-4></LONG-NAME>
                        <DESC><L-2 L="EN">Gear for which the ratio should be
                        returned</L-2></DESC>
                        <TYPE-TREF DEST="APPLICATION-PRIMITIVE-DATA-TYPE"
                            BASE="ApplicationDataTypes">Nr4</TYPE-TREF>
                        <DIRECTION>IN</DIRECTION>
                    </ARGUMENT-DATA-PROTOTYPE>
                </ARGUMENTS>
            </CLIENT-SERVER-OPERATION>
        </OPERATIONS>
    </CLIENT-SERVER-INTERFACE>

As for API's, there is only the option to call an API from a client port, which works (mostly) in the same way as calling a function:

    Rte_Call

The way you distinguish between what operation gets called is through the suffix, which is appended when you generate the source code through your Autosar toolchain.

Server (left) and client (right) ports symbol

• Mode Switch - If you've heard of ECU modes, this will sound familiar to you. If not, I recommend you to take a look at our article Mode Management (opens in a new tab). This interface is used to notify a Software Component when the a mode is changed (can be from the ComM, the EcuM, ...), allowing your component to perform specific operations or adjust its behavior according to the mode. The available API's are:

    Rte_Mode
    Rte_Switch

Where RTE_Mode motifies the new mode and Rte_Switch initiates the switch to the requested mode.

Mode switch manager (left) and mode switch user (right) ports symbol

• Parameter - The parameter interface is used for calibrations (to learn more about calibration, you can consult the article Calibration Overview (opens in a new tab)). As you may have read on the article Types of Software Components (opens in a new tab), some specific components, provide calibrations to be used in other Software Components, through these ports. These are required by other components to use. The required port can access the parameters provided by the port through the following API:

    Rte_Prm

Where, of course, the parameter name gets appended.

Parameter provider (left) and parameter requirer (right) ports symbol

• Trigger - Allows a Software Component to trigger an event on another Software Component (or within the same SW-C). You can find more about events on the article Overview of Events (opens in a new tab). The following API's can be used to trigger an event:

    Rte_Trigger
    Rte_IrTrigger

Where the former works from an SW-C to another and the latter for an internal trigger within a SW-C.

Trigger source (left) and trigger sink (right) ports symbol

• NV Data - Provides access to the configured block on the NvM module (to learn more about the NvM, please consult the article Autosar Memory Stack, coming soon), at an application level. They depend on the block configured.

NvData sender (left) and NvData receiver (right) ports symbol

As some closing thoughts, I hope this article has provided you a deep overview of the available Autosar interfaces an ports, their usefulness, and how they are declared and used.

Author: Micael Coutinho (opens in a new tab)

References:

• Software Component Template - Autosar Specification (opens in a new tab)
• Application Interfaces User Guide - Autosar Specification (opens in a new tab)
• Virtual Functional Bus - Autosar Specification (opens in a new tab)