5.2 Subprograms and Subprogram Calls
A subprogram component represents an execution entrypoint in source text.  A subprogram may not have any internal state (static data).  All parameters and required access to external data must be explicitly declared as part of the subprogram type declaration.  In addition, any events raised within a subprogram must be specified as part of its type declaration.
Subprograms can be called from threads and from other subprograms. These calls are sequential calls local to the virtual address space of the thread.  Subprograms can also be called remotely from threads in other virtual address spaces through server subprograms (see Section 8.3 ).  A subprogram call sequence is declared in a subprogram or thread implementation and may be mode- specific.
Syntax
subprogram_call_sequence ::=
    [ defining_call_sequence_identifier :]
    { { subprogram_call }+ } [ in_modes ] ;
 
subprogram_call ::=
    defining_call_identifier : subprogramcalled_subprogram
       [ { { subcomponent_call_property_association }+} ] ;
 
called_subprogram ::=
        subprogram_classifier_reference 
        | data_unique_type_reference . data_subprogram_identifier
 
NOTES:
Subprogram type and implementation declarations follow the syntax rules for component types and implementations.  Subprograms are not instantiated as subcomponents. Instead subprogram calls represent their instantiation (use) with a specific set of parameter values.  The syntax for specifying call sequences is shown here.
Naming Rules
The defining identifier of a subprogram call sequence declaration, if present in a component implementation, must be unique within the local namespace of the component implementation that contains the subprogram call. 
The defining identifier of a subprogram call declaration must be unique within the local namespace of the component implementation that contains the subprogram call. 
If the called subprogram name is a subprogram classifier reference, its component type identifier or component implementation name must exist in the specified (package or anonymous) namespace.  
If the called subprogram name is a subprogram feature reference in a data component, the data component type identifier must refer to a data component type, or it must refer to a requires data access declaration in the component type of the component containing the subprogram call declaration.
Legality Rules
Category
Type
Implementation
subprogram
Features:
  • out event port
  • out event data port
  • port group
  • requires data access
  • parameter

Flow specifications: yes
Properties: yes
Subcomponents:
  • None

Subprogram calls: yes
Connections: yes
Flows: yes
Modes: yes
Properties: yes
 
A subprogram type declaration can contain parameter, out event port, out event data port, and port group declarations as well as required data access declarations.  It can also contain a flow specification subclause as well as property associations.
A subprogram implementation can contain a connections subclause, a subprogram calls subclause, a flows subclause, a modes subclause and subprogram property associations.
A subprogram implementation must not contain a subcomponent subclause.
Only one subprogram call sequence can apply to a given mode.  In other words, a mode identifier can be specified in the in_modessubclause of at most one subprogram call sequence.
Standard Properties
-- Properties related to source text
Source_Name: aadlstring
Source_Text: inherit list of aadlstring
Source_Language: Supported_Source_Languages
-- Properties specifying memory requirements of subprograms
Source_Code_Size: Size
Source_Data_Size: Size
Source_Stack_Size: Size
Source_Heap_Size: Size
Allowed_Memory_Binding_Class:
   inherit list of classifier (memory, system, processor)
Allowed_Memory_Binding: inherit listof reference (memory, system, processor)
-- execution related properties
Compute_Execution_Time: Time_Range
Compute_Deadline: Time
-- remote subprogram call related properties
Actual_Subprogram_Call: reference (server subprogram)
Allowed_Subprogram_Call: list ofreference (server subprogram)
Actual_Subprogram_Call_Binding: reference(bus, processor, memory)
Allowed_Subprogram_Call_Binding:
   inherit list of reference (bus, processor, device)
Queue_Processing_Protocol: Supported_Queue_Processing_Protocols => FIFO
Semantics
A subprogram component represents sequentially executable source text that is called with parameters.  A subprogram type declaration specifies all interactions of the subprogram with other parts of the application source text.  Subprogram parameters are specified as features of a subprogram type (see Section 8.4).  This includes in and in out parameters passed into a subprogram and out and in out parameters returned from a subprogram on a call  In addition, events being raised from within the subprogram through its out event port and out event data port, and required access to static data by the subprogram are specified as part of the features subclause of a subprogram type declaration. 
A subprogram implementation represents implementation details that are relevant to architecture modeling.  It specifies calls to other subprograms and the mode in which the call sequence occurs.  
If required data access is declared for a subprogram type, access to the data subcomponent is performed in a critical region to assure concurrency control for calls from different threads (for more on concurrency control see Sections 5.1 and 5.3). 
Subprogram source text can contain Raise_Eventservice calls to cause the transmission of events and event data through its out event ports. The fact that events may emit from a subprogram call is documented by the declaration of out event ports and out event data ports as features of the subprogram.
Subprogram implementations and thread implementations can contain subprogram calls. The flow of parameter values between subprogram calls as well as to and from ports of enclosing threads is specified through parameter connection declarations (see Section 9.1.2). 
A thread or subprogram can contain multiple calls to the same subprogram - with the same parameters or with different parameters. 
Ordering of subprogram calls is by default determined by the order of the subprogram call declarations. Annex-specific notations can be introduced to allow for other call order specifications, such as conditional calls and iterations.
Declaration of subprogram calls in thread and subprogram implementations implies that an instance of the subprogram executable binaries exists in the load image of the process that contains the thread performing the subprogram calls. For subprograms, whose source text implementation is reentrant, it is assumed that a single instance of the subprogram binaries exist in the process virtual address space.  In the case of remote subprogram calls a proxy may be loaded for the calling thread and the actual subprogram is part of the load image of the process with the thread servicing the remote subprogram call.
Subprogram calls can be calls to server subprograms provided in other threads.  Such calls model synchronous remote subprogram calls.  AnAllowed_Subprogram_Callproperty, if present, identifies the server subprogram(s) that are allowed to be used in a call binding. AnActual_Call_Bindingproperty records the actual binding to a server subprogram.  Constraints on the buses and processors over which such calls can be routed can be specified with the Allowed_Subprogram_Call_Bindingsproperty.
Subprogram call sequences can be declared to apply to specific modes.  In this case a call sequence is only executed if one of the specified modes is the current mode.
Modeling of subprograms is not required and the level of detail is not prescribed by the standard. Instead it is determined by the level of detail necessary for performing architecture analyses.
Processing Requirements and Permissions
The subprogram call order defines a default execution order for the subprogram calls.  Alternate call orders can be modeled in an annex subclause introduced for that purpose.
Examples
dataMatrix
endMatrix;
 
subprogramMatrix_delta
features
   A: in parameter matrix;
   B: in parameter matrix;
   result: out parameter matrix;
endMatrix_delta;
 
subprogramInterpret_result
features
   A: in parameter matrix;
   result: out parameter weather_forecast;
endInterpret_result;
 
dataweather_DB
features
   getCurrent: subprogram getCurrent;
   getFuture: subprogram getFuture;
endweather_DB;
 
subprogramgetCurrent
features
   result: out parameter Matrix;
endgetCurrent;
 
subprogramgetFuture
-- a subprogram whose source text contains a raise_event service call
-- the subprogram also has access to shared data
features
  date: in parameter date;
   result: out parameter Matrix;
   bad_date: out event port;
   wdb: requires data access weather_DB;
endgetFuture;
 
threadPredict_Weather
features
   target_date: in event data port date;
   prediction: out event data portweather_forecast;
   past_date: out event port;
   weather_database: requires data accessweather_DB;
endPredict_Weather;
 
thread implementation Predict_Weather.others
calls{
   -- subprogram call on a data component subprogram feature
   -- out parameter is not resolved, but will be identified by user of value
   current: subprogram weather_DB.getCurrent;
 
   -- subprogram call on a data component subprogram feature with port value
   -- as additional parameter. Event is mapped to thread event   
   future: subprogram weather_DB.getFuture;
 
   -- in parameter actuals are out parameter values of previous calls
   -- they are identified by the call name and the out parameter name
   diff: subprogram Matrix_delta;
 
   -- call with out parameter value resolved to be passed on through a port
   interpret: subprogram Interpret_result;
   };
connections
   parameter target_date -> future.date;
   event port future.bad_date -> past_date;
   parameter current.result -> diff.A;
   parameter future.result -> diff.B;
   parameter diff.result -> interpret.A;
   parameter interpret.result -> prediction;
   data access weather_database -> future.wdb;
endPredict_Weather.others;