12  Modes and Mode Transitions

(1)   A mode represents an operational mode state, which manifests itself as a configuration of contained components, connections, and mode-specific property value associations.  Modes can be defined for different components in a system and modes can be inherited from the enclosing component. 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 threads communicating through connections or calls 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 event and event data arrivals 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 set of modes may be inherited from the containing component.

(2)   Mode transitions model dynamic operational behavior that represents switching between configurations and changes in components internal characteristics.  Such transitions are initiated by mode transition triggering events, i.e., the arrival of events or event data on ports named in a mode transition or an event raised by the component itself (self).  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 subprograms, modes may represent application logic that is encoded in the source text and may result in different associated property values for the thread or data component.

Syntax

modes_subclause ::=
    modes ( { mode | mode_transition }+ | none_statement )
 
requires_modes_subclause ::=
    requires modes ( { mode }+ | none_statement )
 
mode ::= 
    defining_mode_identifier : [ initial ] mode
        [ { { mode_property_association }+ } ];
 
mode_transition ::=
    [ defining__mode_transition_identifier : ]
    source_mode_identifier 
        -[ mode_transition_trigger { , mode_transition_trigger }* ]-> 
        destination_mode_identifier 
      [ { { mode_transition_property_association }+ } ] ;
 
mode_transition_trigger ::= 
    unique_port_identifier | self . event_or_event_data_source_identifier 
    | processor . port_identifier
 
unique_port_identifier ::= 
   [ subcomponent_or_feature_group_or_subprogram_call_identifier . ] port_identifier
 
in_modes ::= 
    in modes ( mode_identifier { , mode_identifier }* )
 
component_in_modes ::= 
    in modes ( ( mode_name { , mode_name }* ) )
 
mode_name ::= local_mode_identifier [ => subcomponent_mode_identifier ]
 
in_modes_and_transitions ::= 
    in modes ( ( mode_or_transition { , mode_or_transition }* )
 
mode_or_transition ::= 
        mode_identifier | mode_transition_identifier

Naming Rules

(N1)     The defining mode and mode transition identifiers must be unique within the local namespace of the component classifier that contains the mode subclause.  This means that modes declared in component types and in component implementations for the same type must have different identifiers.

(N2)     The identifiers in a mode transition that refer to modes must exist in the local namespace of the component classifier that contains the mode subclause.  In other words, mode transitions of a component can only refer to modes of the same component.

(N3)     The unique port identifier must be either an in or in out event, data, or event data port identifier in the namespace of the associated component type, or an out or in out event, data, or event data port in the namespace of the component type associated with the named subcomponent, or an event or event data identifier in a self declaration. 

(N4)     The mode and mode transition identifiers named in an in modes statement of a subcomponent or connection must refer to modes or mode transitions declared in the local namespace of the component implementation that contains the subcomponent or connection.  The modes and mode transitions in the local name space are those declared in the modes_subclause or requires_modes_subclause of the component implementation or the component type.

(N5)     The subcomponent_mode_identifier in a component_in_modes must refer to a required mode of the subcomponent for which the in modes is declared.  If the subcomponent’s component type has a requires modes clause and no mapping to a subcomponent mode identifier is specified, then for each such mode in the subcomponent there must be a mode with the same name in the containing component.

(N6)     An in modes statement in a subcomponent or connection refinement declaration may be used to specify mode membership to replace the one, if any, in the declaration being refined. A subcomponent or connection refinement declaration without an in modes statement specifies that the connection is active in all modes.

Special rules apply for in modes in property associations (see Section 11.3).

(N7)     For a contained property association with an in modes statement, the identifier must refer to modes or mode transitions of the last subcomponent named in the dot-separated identifier list of the applies to subclause, or to modes and mode transitions of the component containing the property association if the applies to subclause does not start with a subcomponent identifier. 

Legality Rules

(L1)      A mode or mode transition can be declared in any of the component categories.

(L2)      If a component classifier contains mode declarations, one of those modes must be declared with the reserved word initial.  If the component classifier extends another component classifier, the initial mode must have been declared in one of the ancestor component classifier. This rule does not apply to requires modes subclauses.

(L3)      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, which can cause transition to another mode. 

(L4)      If a component has been declared with a requires_mode_clause, then a subcomponent declaration referencing this component classifier may include a component_in_modes that specifies a mapping for the inherited modes by specifying the subcomponent’s mode identifier after the optional =>; if the mapping is not specified the same mode identifier is assumed.

Standard Properties

Mode_Transition_Response: enumeration ( emergency, planned )

 

Semantics

Mode Sensitive Architecture

(3)   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 transitions are discussed in Section 13.6.

(4)   A mode represents an operational state that is represented as a runtime configuration of contained components, connections, and mode-specific property value associations. 

(5)   A mode may represent a runtime configuration of systems, processes, thread groups and threads and their connections for a given operational state.  In this case the modes are declared in thread groups, processes and systems, and in modes clauses indicate which subcomponents and connections are active in a given mode.  In this case, 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 halted state. 

(6)   A mode may also represent logical execution state within a thread. In this case the mode logic is embedded in the source text and may be represented as thread modes and mode-specific thread property values or mode-specific call sequences through the use of the in modes clause. Thread and subprogram internal modes effectively represent a set of behavioral states, whose state transition behavior can be specified through annex subclauses of the Behavior Annex notation (see Annex Document D).

(7)   System and execution platform component declarations can have subcomponents with in modes clauses.  In this case, only the execution platform components that are part of the current mode are accessible to software components. For example, only the processors and memories that are part of the current mode can be the target of bindings of application components active in that mode. 

(8)   For execution platform components a mode can represent an operational mode that is internal to the execution platform component.  For example, a processor may execute at two execution speeds.  The different execution speeds are reflected in mode-specific property values

(9)   A component type or component implementation may contain several declared modes.  Exactly one of those modes is the current mode.  Initially, the initial mode is the current mode.

(10)  A component that has modes itself can be a subcomponent of another component with modes.  As a result, the component can be deactivated and activated as result of mode transitions in the enclosing component. On activation of a components with modes the Resumption_Policy property determines whether the initial mode is entered or the mode from the last deactivation is resumed.

(11)  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 classifier.  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. 

(12)  A component type may specify through a requires modes declaration that a subcomponent should inherit the modes of its containing component.  In this case the in modes declared as part of a subcomponent defines a mapping of the modes of the containing component to the inherited modes of the subcomponent.  The modes of both may have the same names, or they may be different.  Multiple modes of the containing component may be mapped to the same subcomponent mode.

(13)  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. 

(14)  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 Transition

(15)  The modes subclause declares a state machine describing the dynamic mode transition behavior between modes. The states of the state machine represent the different modes and the transitions specify the event(s) that can trigger a transition to the destination mode. Only one mode alternative represents the current mode at any one time. 

(16)  The arrival of an event or event data through an event or event data port that is named in one of the transitions is called a mode transition trigger event. A mode transition is triggered if one of the ports named in a mode transition out of the state representing the current mode causes the trigger event. If such a trigger event occurs and there is no transition out of the current mode naming the port with the trigger event, the trigger event is ignored with respect to mode transitions of the receiving modal component. 

(17)  A mode transition may actually be performed immediately if it is considered an emergency, or it may be performed in a planned fashion after currently executing threads complete their execution and the dispatches of a set of critical thread are aligned (see Section 13.6 for more detail). This is indicated by the Mode_Transition_Response property on the mode transition with the default being planned. 

(18)  If several trigger 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 port named in mode transitions, then the mode transition with the highest port urgency takes precedence. If several ports have the same urgency then the mode transition is chosen non-deterministically.

(19)  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.

(20)  A thread may execute different source text sequences under different modes declared within a thread. This may be represented by different compute execution times and different entrypoints or call sequences for different modes. The current mode at dispatch time determines the source text sequence to be executed. In other words, a thread-internal mode represents a behavioral state, in which the thread completes execution of one dispatch and awaits the next dispatch.

(21)  The semantics of mode transitions between modes declared inside threads have been described in Section 5.4.5.

(22)  Mode transitions within an execution platform component occur as a result of external or internal events, e.g., a processor may switch to a different execution speed. A mode transition within a thread or execution platform component does not affect the set of active threads, processors, devices, buses, or memories, nor does it affect the set of active connections external to the thread or execution platform component.

(23)  A mode transition 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.  Previously 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.

(24)  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.

(25)  At the time of the actual mode switch, any threads that were active in the old mode and are inactive in the new mode execute their Deactivate_Entrypoint.

(26)  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.

NOTES:

Mode transitions can only be triggered by the arrival of an event or event data on a named port or a self event. This means that trigger conditions based on the content of any data cannot be expressed in the mode transition declaration. Instead, they have to be connected to a thread whose source text interprets the data portion to identify the error type and then raise an appropriate event through an out event port that triggers the appropriate mode transition.  Such a thread typically plays the role of a system health monitor that makes system reconfiguration decisions based on the nature and frequency of detected faults.

The default mode transition trigger conditions based on a set of ports is a disjunction.  Other conditions can be modeled through the use of the Behavior Annex (see Annex Document D).

Processing Permissions and Requirements

(27)  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.

(28)  In an actual distributed system, exact simultaneity among multiple events cannot be achieved.  A system realization must use synchronization protocols sufficient to ensure that the causal ordering of event and data transfers defined by the logical temporal semantics of this standard are satisfied by the actual system, to the degree of assurance required by an application.

(29)  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.

(30)  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.

(31)  A method of implementation may enforce that there is a mode-specific property value defined for each mode.

Examples

-- This is an AADL fragment inside a package

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 Gps_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

   conn1 : port Main_Gps.Position -> Position in modes (Dualmode, Mainmode);

   conn2 : port Backup_Gps.Position -> Position in modes (Backupmode);

   conn3 : port Backup_Gps.Position -> Main_Gps.SecondaryPosition

                                       in modes (Dualmode);

modes

   Initialize: initial mode;

   Dualmode : mode

   Mainmode : mode;

   Backupmode: mode;

   Started: Initialize –[ Init_Done ]-> Dualmode;

   Dualmode –[ Monitor.Backup_Stopped ]-> Mainmode;

   Dualmode –[ Monitor.Main_Stopped ]-> Backupmode;

   Mainmode –[ Monitor.All_Ok ]-> Dualmode;

   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

   secureconn: 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;

The following example illustrates inherited modes. A process declares a high fidelity and a low fidelity mode.  All threads in the process respond to these two modes by performing high or low fidelity computation.

thread Calculate

features

  Incoming: in event data port;

  Outgoing: out event data port;

requires modes

  HighFidelity: initial mode;

  LowFidelity: mode;

end Calculate;

process Altitude

features

  doHigh: in event port;

  doLow: in event port;

  Incoming: in event data port;

  Outgoing: out event data port;

end Altitude;

process implementation Altitude.impl

subcomponents

  calc: thread Calculate in modes (LowFid => LowFidelity, HiFid => HighFidelity);

connections

  inconn: port Incoming -> calc.Incoming;

  outconn: port calc.Outgoing -> Outgoing;

modes

  HiFid: initial mode;

  LowFid:  mode;

  HiFid –[ doLow ]-> LowFid;

  LowFid –[ doHigh ]-> HiFid;

end Altitude.impl;