11.1 Mode
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 thread’s 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;