12.2 System Binding
This section defines how binary images produced by compiling source units are assigned to and loaded onto processor and memory resources, taking into account requirements for component sharing and the interconnect topology between processors, memories and devices.  The decisions and methods required to combine the components of a system to produce a physical system implementation are collectively called bindings.
Naming Rules
TheAllowed_Processor_Bindingproperty values evaluate to a processor, or a system that contains a processor in its component containment hierarchy. 
TheAllowed_Memory_Bindingproperty values evaluate to a memory, a processor that contains memory or a system that contains a memory or a processor containing memory in its component containment hierarchy. 
The first identifier of the property value for each element of a property value list must exist in the local namespace of the containing component implementation or in one of its containing component implementations.  The first containing component with a match must be an execution platform system, i.e., must be a processor component or a system component containing a processor or memory in its containment sub-hierarchy.  Subsequent identifiers must exist in the local namespace of the component implementation associated with the component identified by the preceding identifier.  The final identifier identifies the system, processor, or memory component that represents a legal candidate for processor or memory binding.
Legality Rules
Every mode-specific configuration of a system instance must have a binding of every process component to a (set of) memory component(s), and a binding of every thread component to a (set of) processor(s).  In the case of dynamic process loading, the actual binding may change at runtime.  In the case of tightly coupled multi-processor configurations, the actual thread binding may change between members of an actual binding set of processors as these processors service a common set of thread ready queues.  Multiple software components may be bound to a single memory component. A software component may be bound to multiple memory components.  A thread must be bound to a single processor. Multiple threads can be bound to a single processor.
All software components for a process must be bound to memory components that are all accessible from every processor to which any thread contained in the process is bound.  That is, every thread is able to access every memory component into which the process containing that thread is loaded.
A shared data component must be bound to memory accessible by all processors to which the processes sharing the data component are bound.
For all threads in a process, all processors to which those threads are bound must have identical component types and component implementations.  That is, all threads that are contained in a given process must all be executing on the same kind of processor, as indicated by the processor classifier reference value of the Allowed_Processor_Binding_Classproperty associated with the process.  Furthermore, all those processors must be able to access the memory to which the process is bound.
The complete set of software components making up the kernel address space of a processor must be bound to memory that is accessible by that processor.
Each thread must be bound to a processor satisfying the Allowed_Processor_Binding_Classand Allowed_Processor_Bindingproperty values of the thread.  TheAllowed_Processor_Bindingproperty may specify a single processor, thus specifying the exact processor binding.  It may also specify a list of processor components or system components containing processor components, indicating that the thread is bindable to any of those processor components.
Each process must be bound to a memory satisfying the Allowed_Memory_Binding_Classand Allowed_Memory_Bindingproperty values of the process.  The Allowed_Memory_Bindingproperty may specify a single memory component, thus specifying the exact memory binding. It may also specify a list of memory components or system components containing memory components, indicating that the process is bindable to any of those memory components.
The memory requirements of the binary images and the runtime memory requirements of threads and processes bound to a memory component must not exceed that memory’s capacity. The execution time requirements of all threads bound to a processor must not exceed the schedulable cycles required to insure that all thread timing requirements are met.  These two constraints may be checked statically or dynamically.  Runtime detection of such a memory capacity or timing requirements violation results in an error that the application system can choose to recover from.
The memory requirements of ports and data components are specified as property values of their data types.  Those property associations can have binding-specific values. 
Semantics
A complete system instance is instantiated and bound by identifying the actual binding of all threads to processors, all binary images reflected in processes and other components to memory, and all connections to buses if they span multiple processors.  The actual binding can be recorded for each component in the containment hierarchy by property associations declared with in the system iimplementation. 
The actual binding must be determined within specified binding constraints. Binding constraints of application components to execution platform components are expressed by the allowed binding and allowed binding class properties for memory, processor, and bus.  In the case of an allowed binding property, the execution platform component is identified by a sequence of ‘.’ (dot) separated subcomponent names. This sequence starts with the subcomponent contained in the component implementation for which the property association is declared. Or the sequence begins with the subcomponent contained in the component implementation of the subcomponent or system implementation for which the property association is declared. This means that the property association representing the binding constraint or the actual binding may have to be declared as a component instance property association of a component that represents a common root of the components to be bound.
Processing Requirements and Permissions
A method of building systems is permitted to require bindings of selected kinds to be fixed at development time, or to be fixed at the time of physical system construction.  A method of building systems is permitted to allow bindings of selected kinds to change dynamically at runtime.  For example, a method of building systems may require process to memory binding and loading to be fixed during physical system construction, and may require thread to processor bindings to be fixed at mode changes.  Other choices are possible and permitted.
A method of building systems must check and enforce the semantics and legality rules defined in this standard.  Property associations may impose constraints on allowed bindings.  The access semantics impose a number of constraints on allowed bindings for processes and threads to execution platform systems, and ultimately to processors and memories.  In general, the semantic constraints depend on the particular software and hardware architecture interconnect topologies.  In particular, for most hardware and operating system configurations all threads contained in a process must execute on the same processor.  Such additional restrictions must be taken into account by the method of building systems.  A method of building systems is otherwise permitted to make any partitioning and binding choices that are consistent with the semantics and legality rules of this standard.
NOTES:
If multiple processes share a component, then the physical memory to which the shared component is bound will appear in the virtual address space of all those processes.  This physical memory is not necessarily addressed using either the same virtual address in different processes or the same physical address from different processors.  An access property association may be used to specify different addresses used to access the same component from different processors.
The AADL supports binding-specific property values.  This allows different property values to be specified for a component property whose values are sensitive to binding decisions. 
Examples
systemsmp
endsmp;
system implementation smp.s1
-- a multi-processor system
subcomponents
   p1: processor cpu.u1;
   p2: processor cpu.u1;
   p3: processor cpu.u1;
endsmp.s1;
processp1
endp1;
process implementation p1.i1
subcomponents
   ta: thread t1.i1;
   tb: thread t1.i1;
endp1.i1;
threadt1
endt1;
threadimplementation t1.i1
endt1.i1;
processorcpu
endcpu;
processorimplementation cpu.u1
endcpu.u1;
systemS
endS;
system implementation S.I
-- a system combining application components
-- with execution platform components
subcomponents
   p_a: process p1.i1;
   p_b: process p1.i1;
   up1: processor cpu.u1;
   up2: processor cpu.u1;
   ss1: system smp.s1;
properties
    Allowed_Processor_Binding =>( reference up1, reference up2 )
                                     applies to p_a.ta;
    Allowed_Processor_Binding =>( reference up1, reference up2 )
                                     applies to p_a.tb;

   -- ta is restricted to a subset of processors that tb can be bound to;
   -- since ta and tb are part of the same process they must be bound to the
   -- same processor in most hardware configurations
   Allowed_Processor_Binding => reference ss1.p3 applies to p_b.ta;
   Allowed_Processor_Binding => reference ss1 applies to p_b.tb;
endS.I;
NOTES:
Binding properties are declared in the system implementation that contains in its containment hierarchy both the components to be bound and the execution platform components that are the target of the binding.  Binding properties can also be declared separately for each instance of such a system implementation, either as part of the system instantiation  or as part of a subcomponent declaration.