8.2 Port Groups and Port Group Types
Port groups represent groups of component ports or port groups.  Within a component, the ports of a port group can be connected to individually.  Outside a component, port groups can be connected as a single unit.  This grouping concept allows the number of connection declarations to be reduced, especially at higher levels of a system when a number of ports from one subcomponent and its contained subcomponents must be connected to ports in another subcomponent and its contained subcomponents.  The content of a port group is declared through a port group type declaration.  This declaration is then referenced when port groups are declared as component features.
Syntax
-- Defining the content structure of a port group
port_group_type ::=
    port group defining_identifier
    ( features
       { port_spec | port_group_spec }*
      [ inverse of unique_port_group_type_reference ]
    |
      inverse of unique_port_group_type_reference
    )
[ properties ( { portgroup_property_association }+ | none_statement ) ]
{ annex_subclause }*
end defining_identifier ;

port_group_type_extension ::=
    port group defining_identifier extends unique_port_group_type_reference
    ( features
        { port_spec | port_refinement |
          port_group_spec | port_group_refinement }*
      [ inverse of unique_port_group_type_reference ]
    |
      inverse of unique_port_group_type_reference
    )
[ properties ( { portgroup_property_association }+ | none_statement ) ]
{ annex_subclause }*
end defining_identifier ;

-- declaring a port group as component feature
port_group_spec ::=
  defining_port_group_identifier : port group
      [ unique_port_group_type_reference ]
        [ { { portgroup_property_association }+ } ] ;

port_group_refinement ::=
  defining_port_group_identifier : refined to
      port group [ unique_port_group_type_reference ]
        [ { { portgroup_property_association }+ } ] ;

unique_port_group_type_reference ::=
    [ package_name :: ] port_group_type_identifier
Naming Rules
The defining identifier of a port group type must be unique within the package namespace of the package where the port group type is declared.  If the port group type is declared in the AADL specification directly, it must be unique within the anonymous namespace.
Each port group provides a local namespace.  The defining port identifiers of port and port group declarations in a port group type must be unique within the namespace of the port group type.  The local namespace of a port group type extension includes the defining identifiers in the local namespace of the port group type being extended. This means, the defining identifiers of port or port group declarations in a port group type extension must not exist in the local namespace of the port group type being extended. The defining identifiers of port or port group refinements in a port group type extension must refer to a port or port group in the local namespace of an ancestor port group type. 
The defining port identifiers of port_spec declarations in port group refinements must not exist in the local namespace of any port group being extended. The defining port identifier of port_refinement declarations in port group refinements must exist in the local namespace of any port group being extended.
The package name of the unique port group type reference must refer to a package name in the global namespace. The port group type identifier of the unique port group type reference must refer to a port group type identifier in the named package namespace, or if the package name is absent, in the anonymous namespace.
Legality Rules
A port group type may contain zero or more elements, i.e., ports or port groups.  If it contains zero elements, then the port group type may be declared to be the inverse of another port group type. Otherwise, it is considered to be incompletely specified.
A port group type can be declared to be the inverse of another port group type, as indicated by the reserved words inverse of and the name of a port group type.  Any port group type named in an inverse of statement cannot itself contain an inverse of statement.  This means that several port groups can be declared to be the inverse of one port group.  However, chaining of inverses such as B inverse of A and C inverse of B is not permitted. 
A port group type that is an extension of another port group type cannot contain an inverse of statement. The port group type being extended cannot contain an inverse of statement.
Two port group types are considered to complement each other if the following holds:
    • The number of ports or port groups contained in the port group and its complement must be identical.
    • Each of the declared ports or port groups in a port group must be a pair-wise complement with that in the port group complement, with pairs determined by declaration order. 
If both port group types have zero features, then they are considered to complement each other.  In the case of port group type extensions, the port and port group declarations in the extension are considered to be after the declarations in the port group type being extended.  Ports are pair-wise complementary if they have complementary direction ( out / in, in / out, in out / in out), and are of the same port type. In  the case of event data or data ports, the data component classifier reference must be identical.
A port group declaration that does not specify a port group type reference is incomplete.  Such a reference can be added in a port group refinement declaration.
A port group declaration may be refined by adding a property association. Inclusion of  the port group type reference is optional.
If the Aggregate_Data_Port property of a port group has the value true, all ports contained in its port group type or the port group type of any contained port group must be data ports and they must all have the same port direction.
Standard Properties
Aggregate_Data_Port: aadlboolean =>  false
-- Port properties defined to be inherit, thus can be associated with a
-- port group to apply to all contained ports.
Source_Text: inherit list of aadlstring
Allowed_Memory_Binding_Class:
   inherit list of classifier (memory, system, processor)
Allowed_Memory_Binding: inherit list of reference (memory, system, processor)
Semantics
A port group declaration represents groups of component ports that can be connected to externally through a single connection.  Port groups can contain port groups.  This supports nested grouping of ports for different levels of the modeled system.
Within a component, the ports of a port group can be connected to individually.  The members of the port group are declared in a port group type declaration that is referenced by the port group declaration. The referenced port group type determines the port group compatibility for a port group connection.
The inverse of reserved words of a port group type declaration indicate that the port group type represents the complement to the referenced port group type.  The legality of port group connections is affected by the complementary nature of port groups (see Section 9).
The AADL supports the concept of aggregate data port as an extension of the port group concept. A port group property called Aggregate_Data_Port identifies the role of the port group as an aggregate data port.  This port property applies to all out data ports and in out data ports of the port group.
The role of an aggregate data port is to make a collection of data from multiple out data ports available in a time-consistent manner.  Time consistency in this context means that if a set of periodic threads is dispatched at the same time to operate on data, then the recipients of their data see either all old values or all new values. 
Processing Requirements and Permissions
The functionality of an aggregate data port can be realized as a thread whose only role is to collect the data values from several in data ports and make them available at the same time on their respective out data ports. The function may be optimized by mapping the data ports of the individual threads into a data area representing the aggregate data port variable.  This aggregate is then transferred as a single unit.
Examples
port group GPSbasic_socket
features
   Wakeup: in event port;
   Observation: out data port GPSLib::position;
end GPSbasic_socket;

port group GPSbasic_plug
features
   WakeupEvent: out event port;
   ObservationData: in data port GPSLib::position;
   -- the features must match in same order with opposite direction
   inverse of GPSbasic_socket
end GPSbasic_plug;

port group MyGPS_plug
   -- second port group as inverse of the original
   -- no chaining in inverse and
   -- no pairwise inverse references are allowed
   inverse of GPSbasic_socket
end MyGPS_plug;

port group GPSextended_plug extends GPSbasic_plug
features
   Signal: out event port;
   Cmd: in data port GPSLib::commands; 
end GPSextended_plug;

process Satellite_position
features
   position:   port group GPSBasic_socket;
end Satellite_position;

process GPS_System
features
   position: port group GPSbasic_plug;
end GPS_System;

system implementation Satellite.others
subcomponents
   SatPos: process Satellite_position;
   MyGPS: process GPS_System;
connections
   port group Satpos.position -> MyGPS.position;
end Satellite.others;