![]() ![]() |
||||
|
||||
A mode represents an operational mode state, which
manifests itself as a configuration of
contained components, connections, and mode-specific property value associations. A
configuration may be an execution platform configuration in the form of a set of processors,
memories, buses, and devices; an application system configuration in the form of a set of
communicating threads within or across processes and systems; or a source text operational
mode within a thread, i.e., an execution behavior embedded in the source text itself. When
multiple modes are declared for a component, a mode transition behavior declaration identifies
which events cause a mode switch and the new mode, i.e., a change to a different configuration.
Exactly one mode is considered the current mode. The current mode determines the set of
threads that are considered active, i.e., ready to respond to dispatches, and the connections
that
are available to transfer data and control.
A mode transition specifies possible runtime passage
from one state or condition to another. Such
transitions are triggered by events. When declared for processes and systems, mode transitions
model the switch between alternative configurations of active threads. When declared for execution
platforms, mode transitions model the change between different execution platform configurations.
When declared for threads and data, mode transitions model the changeover between modes that
are encoded in the source text and may result in different associated property values.
Syntax
mode ::=
defining_mode_identifier
: [ initial ] mode
[ { { mode_property_assocation
}+ } ];
mode_transition ::=
source_mode_identifier
{ , source_mode_identifier }*
-[
unique_port_identifier { , unique_port_identifier }* ]->
destination_mode_identifier ;
mode_refinement ::=
defining_mode_identifier
: refined to mode
{ { mode_property_assocation
}+ } ;
in_modes ::=
in modes (
( mode_identifier { , mode_identifier }*
| none ) )
in_modes_and_transitions ::=
in modes (
( mode_or_transition { , mode_or_transition }*
| none ) )
mode_or_transition ::=
mode_identifier
| ( old_mode_identifier -> new_mode_identifier )
Naming Rules
The defining mode identifiers must be unique within the
local namespace of the component
implementation.
The identifiers in a mode transition that refer to modes
must exist in the local namespace of the
component implementation that contains the mode subclause. In other words, only modes
declared in the component implementation that contains the mode transition or in any of its
extension ancestors can be referenced.
The mode identifiers named in an in
modes statement must refer to modes declared in the mode
subclause of the component implementation that contains the subcomponent declaration,
connection declaration, or property association with the in modes, or any of its extension
ancestors. In other words, subcomponents, connections, and property associations can only be
applicable to modes of the component implementation they are contained in.
The same mode or mode transition must not be named in
the in modes statement of different
mode-specific declarations of the same subcomponent, call sequence, flow implementation, and
property association.
An in modes
statement in a refinement declaration may be used to specify mode membership to
replace the one, if any, in the declaration being refined.
The old and new mode identifier in a mode_or_transition clause must not
be the same.
Legality Rules
A mode can be declared in data, thread, thread group,
process, system, processor, bus, memory,
and device component implementations.
If a component implementation contains mode declarations,
one of those modes must be declared
with the reserved word initial. If the component implementation extends another component
implementation, the initial mode may have been declared in one of the ancestor component
implementations.
The set of transitions declared within a single component
implementation must define a
deterministic transition function. For each mode, there must exist exactly one transition
associated with a single event arrival, which can cause transition to another mode.
The unique port identifier
must be either an in or in out event port identifier in the interface
namespace of the associated component type or an out or in out event port in the interface
namespace of the component type associated with the named subcomponent.
Semantics
The mode semantics described here focus on a single mode
subclause. A system instance that
represents the runtime architecture of an operational system can contain multiple components with
their own mode transitions. The semantics of system-wide mode switching are discussed in
Section 12.3.
A mode represents an operational state that is represented
as a runtime configuration of containee
components, connections, and mode-specific property value associations. A runtime configuration
of interconnected systems, processes and threads is such an operational state. As is a collection
of execution platform components. An operational mode embedded in the source text may be
represented as threads and data with modes and different associated property values.
Systems and their components may have mode-specific property
value associations. The modes
for subcomponents, connections, flow implementations or property associations are specified using
the associated in modes statement.
A component implementation may contain several declared
modes. Exactly one of those modes is
the current mode. Initially, the initial mode is the current mode.
In the case of modes declared in system and process implementations,
only the threads that are
part of the current mode are in the suspended awaiting dispatch state responding to dispatch
requests. All other threads are in the suspended awaiting mode state or thread terminated state.
In the case of modes in threads, the current mode reflects
conditional execution within the source
text. Observable differences in execution can be reflected in AADL by mode-specific call
sequences, flow implementations, connections, and property associations (see Section 10.4).
In the case of execution platforms, only the execution
platform components that are part of the
current mode are accessible to software components. Only the processors and memories that are
part of the current mode can be the target of bindings of components active in that mode.
The in modes
statement is declared as part of subcomponent declarations, subprogram call
sequences, flow implementations, and property associations. It specifies the modes for which
these declarations and property values hold. The mode identifiers refer to mode declarations in the
modes subclause of the component implementation. If the in modes statement is not present,
then the subcomponent, subprogram call sequence, flow implementation, or property association is
part of all modes. If a property association has both mode-specific declarations and a declaration
without an in modes statement, then the
declaration without the in modes statement
applies to
those modes not covered by the mode-specific declarations. The reserved word none is used
to
indicate a declaration is not part of any mode.
The in modes
statement declared as part of connection declarations specify the modes or mode
transitions for which these connection declarations hold. The mode identifiers refer to mode
declarations in the modes subclause of the component implementation. If a connection is declared
to be part of a mode transition, then the content of the ultimate source port is transferred to the
ultimate destination port at the actual mode switch time. If the in modes statement contains only
mode transitions, then the connection is part of the specified mode transitions, but not part of any
particular mode. If the in modes
statement is not present, then the connection is part of all
modes. If a connection has both mode-specific declarations and a declaration without an in
modes statement, then the declaration without the in modes statement applies
to those modes
not covered by the mode-specific declarations. The reserved word none is used to indicate
a
declaration is not part of any mode or mode transition.
If the in modes statement is declared as part of a refinement, the newly named modes replace
the
modes specified in the declaration being refined.
Mode Switch
The modes subclause declares a state machine describing
the dynamic mode switching behavior
of modes. The states of the state machine represent the different modes and the transitions specify
the event(s) that can trigger a mode switch to the destination mode. Only one mode alternative
represents the current mode at any one time. A mode switch is triggered when an event arrives
at
an event port that is named in one of the transitions out of the state representing the current mode.
If an event is raised and there is no transition out of the current mode naming the event port through
which the event arrives, the event is ignored. If several events occur logically simultaneously
and
affect different mode transitions out of the current mode, the order of arrival for the purpose of
determining the mode transition is implementation dependent. If an Urgency property is
associated with each mode transition, then the mode transition with the highest urgency takes
precedence.
Any change of the current mode has the effect of changing
the property value in property
associations with mode-specific values as expressed by the in modes statement.
A mode switch within a thread results in a change of
its current mode. The effect is a change in
the subprogram call sequence and mode-specific property values to reflect a change in source text
internal execution behavior. Such a change in property values may include a change in the
threads period, deadline, or worst-case execution time. A mode switch within a thread does
not
affect the set of active threads, processors, devices, buses, or memories, nor does it affect the set
of active connections.
A mode switch within a system, process, or thread group
implementation has the effect of
deactivating and activating threads to respond to dispatches, and changing the pattern of
connections between components. Deactivated threads transition to the suspended awaiting mode
state. Background threads that are not part of the new mode suspend performing their execution.
Activated threads transition to the suspended awaiting dispatch state and start responding to
dispatches. Suspended background threads that are part of the new mode resume performing
execution once the transition into the new mode is complete. Threads that are part of both the
old
and new mode of a mode transition continue to respond to dispatches and perform execution.
Ports that were connected in the old mode, may not be connected in the new mode and vice versa.
When a mode switch is requested through the arrival of
an event on a mode transition, the actual
mode switch occurs immediately if no periodic threads are part of the old mode, otherwise it occurs
once these periodic threads in the old mode are synchronized at their hyperperiod. Only those
threads with a Synchronzied_Component property value of true are considered in the
determination of the hyperperiod (see Section 12.3).
Starting with the actual time of mode switch, the component
is in a mode transition in progress
state for a limited amount of time. During this time some threads are deactivated, other threads
are activated, connections are adjusted, and the active threads in the new mode start to execute.
This time period takes the Synchronized_Component property into account and is determined
at the level of the whole system instance (see Section 12.3). After that period of time, the
component is considered to operate in the new mode.
At the time of the actual mode switch, the deactivate
entrypoint is invoked for the following threads
that must be deactivated: periodic threads that are synchronized with the mode switch; aperiodic or
sporadic threads that are in the suspended awaiting dispatch state. This is shown in Figure 5
with
the transition labeled thread exit(mode).
At the time instant of actual mode switch, aperiodic
and sporadic threads as well as periodic
threads not synchronized with the mode switch may still be in the perform computation state (see
Figure 5). The Active_Thread_Handling_Protocol property specifies for each such thread
what action is to be taken. Possible actions are:
Abort the execution of the thread and permit the thread
to recover any state through execution of
its recover entrypoint. This permits the thread to recover to a consistent state for future activation
and dispatch. Upon completion of the recover entrypoint, execution, event and event data port
queues of the thread are flushed and the thread enters the suspended awaiting mode state. If the
thread was executing a server subprogram, the current dispatch execution of the calling thread of a
call in progress or queued call is also aborted.
Permit the thread to complete the execution of its current
dispatch. Any remaining queued events,
or event data may be flushed, or remain in the queue until the thread is activated again as specified
by the Active_Thread_Queue_Handling_Protocol property.
Permit the thread to finish processing all events or
event data in its queues.
The semantics of any such actions for threads in the
performing computation state at the time
instant of actual mode switch is not shown in the hybrid automaton in Figure 5.
Background processes that are only part of the old mode
are suspended when the actual mode
switch occurs.
At the time of the actual mode switch, any threads that
were inactive in the old mode and are
active in the new mode execute their activate entrypoint. In the case of periodic threads, this is
immediately followed by their first dispatch of the compute entrypoint. In the case of background
threads, the thread resumes execution from where it was suspended at the last deactivation.
Threads that are active in both the old and the new mode
are dispatched in their usual manner; in
the case of background threads, they continue in the execute state.
Some property values for a component or its subcomponents
may be mode-specific, for example
the period of a periodically dispatched thread may be different in different modes of operation.
It
changes at the time of actual mode switch.
Processing Permissions and Requirements
Every method for processing specifications must parse
mode transition declarations and check the
legality rules defined in this standard. However, a method of processing specifications need not
define how to build a system from a specification that contains mode transition declarations.
That
is, complex behaviors that may have multiple modes of operation may be rejected by a method of
building systems as an unsupported capability.
If two different events that occur logically simultaneously
result in more than one possible transition
out of the current mode, a method of implementation may supply an implementation-dependent
order or response to these events. An implementation may provide an Urgency parameter to the
Raise_Event
service call (see Section 5.3) to prioritize the response to simultaneous events. A
method of implementation is permitted to raise a runtime error to indicate the nondeterministic
nature of the system. Or, a method of implementation may specify additional rules to define the
order in which transitions will occur.
In a physical distributed system, exact simultaneity
among multiple events cannot be achieved. A
physical system implementation must use synchronization protocols sufficient to insure that the
causal ordering of event and data transfers defined by the logical temporal semantics of this
standard are satisfied by the physical system, to the degree of assurance required by an
application.
A method of implementation is permitted to provide preservation
of queue content for aperiodic and
sporadic threads on a mode switch until the next activation. This is specified using the thread
property Active_Thread_Queue_Handling_Protocol.
A method of implementation is permitted to support a
subset of the described protocols to handle
threads that are in the performing computation state at the time instant of actual mode switch.
They must document the chosen subset and its semantic behavior as part of the
Supported_Active_Thread_Handling_Protocol property.
Examples
data Position_Type
end Position_Type;
process Gps_Sender
features
Position: out data
port Position_Type;
-- if connected secondary
position information is used to recalibrate
SecondaryPosition: in
data port Position_Type
{ Required_Connection => false;};
end Gps_Sender;
process implementation Gps_Sender.Basic
end GPD_Sender.Basic;
process implementation
Gps_Sender.Secure
end Gps_Sender.Secure;
process GPS_Health_Monitor
features
Backup_Stopped: out event port;
Main_Stopped: out event port;
All_Ok: out event port;
Run_Secure: out event port;
Run_Normal: out event port;
end GPS_Health_Monitor;
system Gps
features
Position: out data
port Position_Type;
Init_Done: in event port;
end Gps;
system implementation Gps.Dual
subcomponents
Main_Gps: process
Gps_Sender.Basic in modes (Dualmode, Mainmode);
Backup_Gps: process
Gps_Sender.Basic in modes (Dualmode, Backupmode);
Monitor: process
GPS_Health_Monitor;
connections
data port Main_Gps.Position
-> Position in modes (Dualmode,
Mainmode);
data port Backup_Gps.Position
-> Position in modes (Backupmode);
data port Backup_Gps.Position
-> Main_Gps.SecondaryPosition
in modes (Dualmode);
modes
Initialize: initial
mode;
Dualmode : mode;
Mainmode : mode;
Backupmode: mode;
Initialize [ Init_Done
]-> Dualmode;
Dualmode [ Monitor.Backup_Stopped
]-> Mainmode;
Dualmode [ Monitor.Main_Stopped
]-> Backupmode;
Mainmode, Backupmode [
Monitor.All_Ok ]-> Dualmode;
end Gps.Dual;
system implementation Gps.Secure extends
Gps.dual
subcomponents
Secure_Gps: process
Gps_Sender.Secure in modes ( Securemode );
connections
data port Secure_Gps.Position
-> Position in modes ( Securemode );
modes
Securemode: mode;
SingleSecuremode: mode;
Dualmode [ Monitor.Run_Secure
]-> Securemode;
Securemode [ Monitor.Run_Normal
]-> Dualmode;
Securemode [ Monitor.Backup_Stopped
]-> SingleSecuremode;
SingleSecuremode [
Monitor.Run_Normal ]-> Mainmode;
Securemode [ Monitor.Main_Stopped
]-> Backupmode;
end Gps.Secure; |
||||