![]() ![]() |
||||
|
||||
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 threads 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; |
||||