13.7    System-wide Fault Handling, Shutdown, and Restart

(1)   Thread unrecoverable errors result in transmission of event data on the Error port of the appropriate thread, processor, or device.  The ultimate destination of this semantic connection can be a thread or set of threads whose role is that of a system health monitor and system configuration manager.  Such threads make decisions about appropriate fault handling actions to take.  Such actions include raising of events to trigger mode switches, e.g., to request SOM transitions.

Runtime Services

(2)   Several runtime services are provided to control starting and stopping of the system, processors, virtual processors, and processes. They may be explicitly called by application source code, or they may be called by an AADL runtime system that is generated from an AADL model.

(3)   Current_System_Mode returns a value corresponding to the active system operation mode (SOM).

    subprogram Current_System_Mode
    features
      ModeID: out parameter <implementor-specific>; -- ID of the mode
    end Current_System_Mode;

(4)   Set_System_Mode indicates the next SOM the runtime system must switch to.  System modes are assumed to have identifying numbers.

    subprogram Set_System_Mode
    features
      ModeID: in parameter <implementor-specific>; -- ID of the SOM
    end Set_System_Mode;

(5)   The following subprograms take a process, virtual processor, or processor ID as parameter.  The ID representation is determined by the runtime system.

(6)   Stop_Process is called for a controlled shut-down of a process, i.e., all of its contained threads, whether executing, awaiting a dispatch, or not part of the current mode, are given a chance to execute their finalize entrypoint before being halted.

(7)   Abort_Process is called for a shut-down of a process due to an anomaly.  All of its contained threads are terminated immediately.

(8)   Stop_Virtual_Processor is called to initiate a transition to the virtual processor stopping state at the next hyperperiod. This has the effect of initiating Stop_Virtual_Processor for all virtual processors bound to the virtual processor, and Stop_Process for all processes bound to the virtual processor.

(9)   Abort_Virtual_Processor  is called for a shut-down of a virtual processor due to an anomaly.  All virtual processors and processes bound to the virtual processor are aborted.

(10)  Stop_Processor is called to initiate a transition to the processor stopping state at the next hyperperiod. This has the effect of initiating Stop_Virtual_Processor for all virtual processors bound to the processor, and Stop_Process for all processes bound to the processor.

(11)  Abort_Processor  is called for a shut-down of a processor due to an anomaly.  All virtual processors and processes bound to the processor are aborted.

(12)  Stop_System is called to initiate a transition to the system stopping state, which will initiate a Stop_Processor for all processors in the system.

(13)  Abort_System is called for a shut-down of the system due to an anomaly.  All processors in the system are aborted.

Processing Requirements and Permissions

(14)  This standard does not require that source text be associated with a software or execution platform category.  However, a method of implementing systems may impose this requirement as a precondition for constructing a actual system from a specification.

(15)  A system instance represents the runtime architecture of an application system that is to be analyzed and processed.  A system instance is identified to a tool by a component classifier reference to an instantiable system implementation.  For example, a tool may allow a system classifier reference to be supplied as a command line parameter.  Any such externally identified component specification must satisfy all the rules defined in this specification for system instances.

(16)  A method of building systems is permitted to only support static process loading.

(17)  A method of building systems is permitted to create any set of loadable binary images that satisfy the semantics and legality rules of this standard.  For example, a single load image may be created for each processor that contains all processes and threads executed by that processor and all source text associated with devices and buses accessible by that processor.  Or a separate load image may be created for each process to be loaded into memory to make up the process virtual address space, in addition to the kernel address space created for each processor.

(18)  A process may define a source namespace for the purpose of compiling source programs, define a virtual address space, and define a binary image for the purpose of loading.  A method of building systems is permitted to separate these functions.  For example, processes may be compiled and pre-linked as separate programs, followed by a secondary linking to combine the process binary images to form a load image.

(19)  A method of building systems is permitted to compile, link and load a process as a single source program.  That is, a method of building systems is permitted to impose the additional requirement that all associated source text for all threads contained in a process form a legal program as defined in the applicable programming language standard.

(20)  If two software components that are compiled and linked within the same namespace have identical component types and implementations, or the intersection of their associated source text compilation units is non-empty, then this must be detected and reported.

(21)  A method of building systems is permitted to omit loading of processor, device driver, and bus protocol software in a processor kernel address space if none of the threads bound to that processor need to access or execute that software.

(22)  This standard supports static virtual memory management, i.e., permits the construction of systems in which binary images of processes are loaded during system initialization, before a system begins operation. 

(23)  Also permitted are methods of dynamic virtual memory management or dynamic library linking after process loading has completed and thread execution has started.  However, any method for implementing a system must assure that all deadline properties will be satisfied for each thread. 

(24)  An alternative implementation of the process and thread state transition sequences is permitted in which a process is loaded and initialized each time the system changes to a mode of operation in which any of the containing threads in that process are active.  This process load and initialize replaces the perform thread activate action in the thread state transition sequence as well as the process load action in the process state transition sequence. These alternative semantics may be adopted for any designated subset of the processes in a system.  All threads contained in a process must obey the same thread semantics.