Ports on subprograms

[reteprelief]

(source Vestal) Section 5.2 Legality rules only allow out event and out event data ports in subprogram types. Section 5.3 Legality rules do not allow any port features in subprogram groups. It is not possible to declare that a subprogram or subprogram group contains a call to an RTOS API to send/receive messages through a port. This also prevents modeling a FACE Software Unit of Portability as an AADL subprogram group, which would be the most intuitive mapping of a UoP to AADL.

Proposed correction: Allow port features to be declared in subprogram and subprogram group types without restriction. This is backwards-compatible. The rules for connections to ports of subprograms and subprogram groups that are not nested within threads require some thought. Push and pull connections to in and out data ports of subprogram components of processes, and subprograms accessed by and called from multiple threads, have meaningful semantics.

[reteprelief]

At the 7/2014 we discussed the issue with a recommendation not to act on it. It seems that the desired effect of in ports on subprograms and subprogram groups should be passing the port itself as a parameter. Calls to send or receive data from ports are expressed by Send_Output and Receive_Input calls. They take as parameter an identification of the port that is implementation specific, e.g., by port name as string.

[reteprelief]

In a follow-up discussion with Steve and with Lutz I came to the conclusion that we reopen the issue as an errata. Here is the reason: We already support outgoing ports on subprograms. The interpretation is that effectively a subprogram can perform a send on the port. For incoming ports we would connect the port to a parameter. In this case, the port content has to be frozen and read before the call (parameters are pass by value). By supporting incoming ports as part of the subprogram signature we allow users to specify that a port is being read from within a subprogram after it has been called.

[reteprelief]

In a follow-up discussion with Steve and with Lutz I came to the conclusion that we reopen the issue as an errata. Here is the reason: We already support outgoing ports on subprograms. The interpretation is that effectively a subprogram can perform a send on the port. For incoming ports we would connect the port to a parameter. In this case, the port content has to be frozen and read before the call (parameters are pass by value). By supporting incoming ports as part of the subprogram signature we allow users to specify that a port is being read from within a subprogram after it has been called.