Ports

For Ports, we distuinguish between AUTOSAR ports and UML ports:

AUTOSAR ports for which you must use RTE generated APIs to access other SW-Cs and/or Basic Software
UML ports for which Rhapsody can generate code

Before modeling ports, there are a few issues you must be aware of: the meaning of a Reversed port and the Behavior checkbox:

Reversed or not

In Rhapsody, there are different ways to model ports and specify a port contract. If you explicitely specify a contract on the General tab of a port, you must use Reversed when using an interface which is in the Provided Interfaces but must be used as a required interface:

Sometimes Rhapsody does not show the Reversed checkbox. You can use the Helper Force Port Reverse from the menu with your RHS mouse, when selecting the port.

Alternatively, if you do not explicitely specify a contract on the General tab of a port, Rhapsody allows you to add a required interface to the Required Interfaces:

Behavior or not

For AUTOSAR ports, no code is generated - only a sample implementation in some cases: you must use the RTE APIs.
So, the Behavior checkbox must be unchecked. If it is checked, the port symbol shown differs:


Behavior checked	Behavior unchecked

AUTOSAR Ports

AUTOSAR ports are shown in an SWC diagram

All communication between SWCs and other SWCs or Basic Software is handled by the RTE. A mini-RTE can be generated to debug and test your model, including AUTOSAR port communication.

The ARXF-CP supports two kinds of AUTOSAR ports:

sender/receiver ports.
- to send data, we use by default so-called explicit sending, blocking. The tag Explicit is set at the port level.
  The RTE API to call a send operation, is specified in the RTE contract for the SWC which uses that send port. The RTE API can be called from anywhere, for example a statechart. In that case, from an AUTOSAR perspective, the runnable "eventDispatcher" is the calling context of the RTE API.
- to receive data, we use by default so-called implicit reading, non-blocking. The tag Explicit is set to false at the port level.
  The RTE API to call a read operation, is specified in the RTE contract for the SWC which uses that receiver port. We use a dedicated runnable per receiver port. Such a runnable must have a portAccess dependency between the reciever port and runnable. The RTE API is called from within this runnable.
client/server ports.
- to call an operation provided by a server port, we use by default a synchronous call by the client.
  The RTE API to call a server operation is specified in the RTE contract for the SWC which uses the client port connected to the server port. The RTE API can be called from anywhere, for example a statechart. In that case, from an AUTOSAR perspective, the runnable "eventDispatcher" is the calling context of the RTE API.
- to provide an operation via a server port, we use by default an extra runnable with the signature of the operation specified in the interface.
  The mini-RTE you can generate offers runnables used for synchronous server communication. Such a runnable must have a portAccess dependency between the server port and runnable. The RTE API to provide a server operation, is specified in the RTE contract for the SWC which offers the server port. The RTE API is called from within this runnable.

Interface2Runnable

The helper Interface2Runnable can be used to generate a runnable for a server port or a runnable for a receiver port:

for a server port, runnable(s) are added to the SCW: one for each operation specified in the interface which matches the signature of the operation.
for a receiver port, a runnable is added to the SCW. In C comment, sample RTE API read calls are listed for all data items specified in the port interface.

The runnable(s) added to the SWC on which the server port resides also have a portAccess dependency to the server port.

Check Wellformedness

The generator of the mini-RTE, as well as the Helper Interface2Runnable have requirements like a proper interface specified in a port or a portAccess dependency when dealing with a server or a receiver port. You can use a Helper to verify the port being wellformed:

UML Ports

You can find the example BlinkyPlusPorts in the folder <ARXF_CP_V8.0.1 installation folder>\ARXF_CP_V8.0.1\Samples\Autosar\Model\BlinkyPlusPorts
It shows use of a UML port in SwcA. This BlinkyPlusPorts is based on the Blinky example and shows communication between ControllerA and LED_SwcA:

You can not use flowports and UML ports on the same class. To use flow ports you must enable the property C_CG::Port::Generate. The default for the property C_CG::Port::Generate using the RXF is disabled which activates generation of optimized code for UML ports.