8.1 Ports
Ports are logical connection points between components that can be used for the transfer of control and data between threads or between a thread and a processor or device.  Ports are directional, i.e., an output port is connected to an input port.  Ports can pass data, events, or both.  Data transferred through ports is typed.  From the perspective of the application source text, data ports look like data components, i.e., they are data variables accessible in the source text. From the perspective of the application source text, event ports represent Raise_Event runtime service calls and transfer the event to receiving
components or to the system executive to trigger a mode change.  Event data ports transfer the data along with the event to receiving components.
Syntax
port_spec ::= 
    defining_port_identifier : ( in | out | in out ) port_type
        [ { { port_property_association }+ } ] ;

port_refinement ::= 
    defining_port_identifier : refined to
        ( in | out | in out ) port_type
        [ { { port_property_association }+ } ] ;

port_type ::=
     data port [ data_classifier_reference ]
    |  event data port [ data_classifier_reference ]
    |  event port
Naming Rules
A defining port identifier adheres to the naming rules specified for all features (see Section 8).
The unique component type identifier must be the name of a data component type. The data implementation identifier, if specified, must be the name of a data component implementation associated with the data component type.
Legality Rules
Ports can be declared in subprogram, thread, thread group, process, system, processor, and device component types.
Data and event data ports may be incompletely defined by not specifying the data component classifier reference or data component implementation identifier of a data component classifier reference. The port definition can be completed using refinement.
Data and event data ports may be refined by adding a property association. The data component classifier declared as part of the data or event data port declaration being refined does not need to be included in this refinement.
The property names Overflow_Handling_Protocol, Queue_Processing_Protocol, Dequeue_Protocol and Queue_Size may only appear in property associations for in event ports and in event data ports.
Standard Properties
-- Properties specifying the source text variable representing the port
Source_Name: aadlstring
Source_Text: inherit list of aadlstring
-- property indicating whether port connections are required or optional
Required_Connection : aadlboolean => true 
-- Optional property for device ports
Device_Register_Address: aadlinteger
-- Port specific compute entrypoint properties for event and event data ports
Compute_Entrypoint: aadlstring
Compute_Execution_Time: Time_Range
Compute_Deadline: Time
-- Properties specifying binding constraints for variables representing ports
Allowed_Memory_Binding_Class:
   inherit list of classifier (memory, system, processor)
Allowed_Memory_Binding: inherit list of reference (memory, system, processor)
-- In port queue properties
Queue_Size: aadlinteger 0 .. value(Max_Queue_Size) => 0
Queue_Processing_Protocol: Supported_Queue_Processing_Protocols => FIFO
Overflow_Handling_Protocol: enumeration (DropOldest, DropNewest, Error)
                                                                 => DropOldest
Urgency: aadlinteger 0 .. value(Max_Urgency)
Dequeue_Protocol: enumeration ( OneItem, AllItems ) => OneItem
Semantics
A port specifies a logical connection point in the interface of a component through which incoming or outgoing data and events may be passed.  Ports may be named in connection declarations. Ports that pass data are typed by naming a data component classifier reference. 
A data or event data port represents a data instance that maps to a static variable in the source text.  This mapping is specified with the Source_Name and Source_Text properties.  The Allowed_Memory_Binding and Allowed_Memory_Binding_Class properties indicate the memory (or device) hardware the port resources reside on.
Event and event data ports may dispatch a port specific Compute_Entrypoint.  This permits threads with multiple event or event data ports to execute different source text sequences for events arriving at different event ports.  If specified, the port specific Compute_Time and Compute_Deadline takes precedence over those of the containing thread.
Ports are directional.  An out port represents output provided by the sender, and an in port represents input needed by the receiver.  An in out port represents both an in port and an out port. Incoming connection(s) and outgoing connection(s) of an in out port may be connected to the same component or to different components. An in out port maps to a single static variable in the source text.  This means that the source text will overwrite the existing incoming value of the port when writing the output value to the port variable.
A port can require a connection or consider it as optional as indicated by the Required_Connection property.  In the latter case it is assumed that the component with this port can function without the port being connected. 
Data and event data ports are used to transmit data between threads. They appear to the thread as input and output buffers, accessible in source text as port variables.  In the case of a data out port, data is automatically transmitted at the completion of thread dispatch execution.  In the case of an event data out port, data is automatically transmitted at the time of the Raise_Event runtime service call (see Section 9). 
Data ports are intended for transmission of state data such as signals.  Therefore, no queuing is supported for data ports.  A thread can determine whether the input buffer of an in data port has new data at this dispatch by checking the port status, which is accessible through the port variable.
Event ports are used to communicate events.  Events can be raised by source text executing in subprograms, threads, and by processors and devices.  Events can trigger the dispatch of other threads or can cause a mode switch.  If the receiving thread is already active, the event is queued. Events are triggered by an explicit Raise_Event runtime service call executed within a thread. Or if the thread’s predeclared Complete port (see Section 5.3) is connected, then  a runtime system completion event is generated. 
Event ports are represented by port variables. When a thread dispatch is the result of an event, the value of the event port variable is set to one and the event is dequeued. If the Dequeue_Protocol property is set to AllItems,then the value of the event port variable is set to the number of events in the queue and the event queue is emptied.  The port variable value of other event ports is set to zero.
When  the thread dispatch is triggered through the predeclared Dispatch port or, in the case of periodic threads, by the clock, then the port variable value of all event ports is set to one and one event is dequeued.  If the Dequeue_Protocol property is set to AllItems, then the value of each port variable is set to the number of queued events at that time and the queue is emptied. This capability allows a periodic thread to sample an event stream to determine the number of events that arrive in a given time interval. For example, it permits the thread to determine the speed of a wheel based on a rotational sensor on the wheel. It also permits a system health monitor thread to periodically process system alarms without overloading the processor due to spikes in alarm arrivals.
Event data ports are intended for message transmission, i.e., the queuing of the event and associated data at the port of the receiving thread.  If the receiving thread is not executing a dispatch and the Dispatch port is not connected, then the arrival of a message triggers a dispatch of the receiving thread.  The message transmission is triggered by an explicit Raise_Event runtime service call on the specific event data port. If not transmitted through an explicit Raise_Event runtime service call, then the event data is transmitted at completion of dispatch execution for those event data ports into which new values were written.
Event data ports are represented by port variables. The status of whether an event data port provides a new value to a thread is accessible through the port variable.  If the queue is empty at the time of thread dispatch, the event data port variable retains its old value.
When a thread dispatch is the result of an event, the value of the event data port variable is set to the data value of the event data in the queue that triggered the dispatch and the event data is dequeued. If the Dequeue_Protocol property is set to AllItems, then the data of all event data is placed in the port variable and the event data queue is emptied.  The port variables of other event data ports retain their old value.  If the thread dispatch is triggered through the predeclared Dispatch port, then the port variable value for each event data ports is set to the data value of the first event data in the queue and the event data is dequeued.  If the Dequeue_Protocol property is set to AllItems, then all event data is placed in the port variable for each event data port and the event data queue is emptied. 
Any subprogram, thread, device, or processor with an outgoing event port, i.e., out event, out event data, in out event, in out event data, can be the source of an event.  During a single dispatch execution, a thread may raise zero or more events and transmit zero or more event data through Raise_Event runtime service calls.  It may also raise an event at completion through its predeclared Complete port (see Section 5.3) and transmit event data through event data ports that contain new values that have not been transmitted through explicit Raise_Event runtime service calls.
Events are received through in event, in out event, in event data, and in out event data ports, i.e., incoming ports.  If such an incoming port is associated with a thread and the thread does not contain a mode transition naming the port, then the event or event data arriving at this port is added to the queue of the port.  If the thread is aperiodic or sporadic and does not have its Dispatch event connected, then each event and event data arriving and queued at any incoming ports of the thread results in a separate request for thread dispatch.
If an event port is associated with a component (including thread) containing modes and mode transition, and the mode transition names the event port, then the arrival of an event is a mode change request and it is processed according to the mode switch semantics (see Sections 11 and 12.3). 
The Queue_Size, Queue_Processing_Protocol, and Overflow_Handling_Protocol port properties specify queue characteristics.  If an event arrives and the number of queued events (and any associated data) is equal to the specified queue size, then the Overflow_Handling_Protocol property determines the action. If the Overflow_Handling_Protocol property value is Error, then an error occurs for the thread. The thread can determine the port that caused the error by calling the standard Dispatch_Status runtime service. For Overflow_Handling_Protocol property values of DropNewest and DropOldest, the newly arrived or oldest event in the queue event is dropped.
Queues will be serviced in a first-in, first-out order.  When an event-driven thread declares multiple in event and event data ports in its type and more than one of these queues are nonempty, the port with the higher Urgency property value gets serviced first.  If several ports with the same Urgency are non-empty, then the oldest event will be serviced (global FIFO).  It is permitted to define and use other algorithms for picking among multiple non-empty queues. Disciplines other than FIFO may be used for managing each individual queue .
Processing Requirements and Permissions
For each data or event data port declared for a thread, a system implementation method must provide sufficient buffer space within the associated binary image to unmarshall the value of the data type. Adequate buffer space must be allocated to store a queue of the specified size for each event data port.  The applicable source language annex of this standard defines data variable declarations that correspond  to the data or event data features. Buffer variables may be allocated statically as part of the source text data declarations.  Alternatively, buffer variables may be allocated dynamically while the process is loading or during thread initialization.  A method of implementing systems may require the data declarations to appear within source files that have been specified in the source text property.  In some implementations, these declarations may be automatically generated for inclusion in the final set of source text.  A method of implementing systems may allow direct visibility to the buffer variables. Runtime service calls may be provided to access the buffer variables.
The type mark used in the source variable declaration must match the type name of the port data component type.  Language-specific annexes to this standard may specify restrictions on the form of a source variable declaration to facilitate verification of compliance with this rule.
For each event or event data port declared for a thread, a method of implementing the system must provide a source name that can be used to refer to that event within source text.  The applicable source language annex of this standard defines this name and defines the source constructs used to declare this name within the associated source text.  A method of implementing systems may require such declarations to appear within source files that have been specified in the source text property.  In some implementations, these declarations may be automatically generated for inclusion in the final set of  source text.
A method of implementing systems must provide a capability for a thread to determine whether a data port has been updated with a new value since the previous dispatch.  This capability may be implemented  in the form of a “fresh” field in the port variable.  A runtime service call may be provided to supply port variable status information.
If any source text associated with a software component contains a runtime service call that operates on an event, then the enumeration value used in that service call must have a corresponding event feature declared for that component.
A method of processing specifications is permitted to use non-standard property names and associations to define alternative queuing disciplines.
A method of implementing systems is permitted to optimize the number of port variables necessary to perform the transmission of data between ports as long as the semantics of such connections are maintained.  For example, the source text variable representing an out data port and the source text variable representing the connected in data port may be mapped to the same memory location provided their execution lifespan does not overlap.
Examples
package Nav_Types public
   data GPS properties Source_data_Size => 30 B; end GPS;
   data INS properties Source_data_Size => 20 B; end INS;
   data Position_ECEF properties Source_data_Size => 30 B; end Position_ECEF;
   data Position_NED properties Source_data_Size => 30 B; end Position_NED;
end Nav_Types;

process Blended_Navigation
features
   GPS_Data : in data port Nav_Types::GPS;
   INS_Data : in data port Nav_Types::INS;
   Position_ECEF : out data port Nav_Types::Position_ECEF;
   Position_NED : out data port Nav_Types::Position_NED;
end Blended_Navigation;

process implementation Blended_Navigation.Simple
subcomponents
   Integrate : thread;
   Navigate : thread;
end Blended_Navigation.Simple;