ASSL Tiers

The ASSL framework is defined through formalization tiers. Over these tiers, ASSL provides a multi-tier specification model that is designed to be scalable and exposes a judicious selection and configuration of infrastructure elements and mechanisms needed by an AS. Thus, ASSL defines an AS with interaction protocols and autonomic elements (AEs), where the ASSL tiers and their sub-tiers describe different aspects of the AS under consideration, e.g., self-management policies, communication interfaces, execution semantics, actions, etc.
  The ASSL specification model decomposes an AS in two directions - first into levels of functional abstraction, and second into functionally related sub-tiers. With the first decomposition, we present the system from three different perspectives - three major tiers:

• a general and global AS perspective, where we define the general system rules, architecture and global actions, events, and metrics applied in these rules;
• a communication protocol perspective, where we define the means of communication between AEs within the AS under consideration. This is crucial, since ASSL considers ASs as multi-agent systems;
• a unit-level perspective, where we define interacting sets of individual computing elements (AEs) with their own behavior, which must be synchronized with the rules from the global AS perspective.

With the second decomposition, we decompose the major tiers into functionally related sub-tiers, where new AS properties emerge at each sub-tier. This allows a very flexible approach to specification. For example, we can start with the global understanding about the system by specifying the service-level objectives and digging down to find at the very detailed-level the needed metrics, or we can start working at the detailed levels and build-up our system, or we can work on both abstract and detailed-level sides by constantly synchronizing their specification.

»  ASSL Grammar

The ASSL tiers are intended to specify different aspects of the AS in question but it is not necessary to employ all of them in order to model an AS. Usually, an ASSL specification is built around self-management policies, which make that specification AC-driven. This copes well with the main goal of AC - self-management based on four main principles: self-configuring, self-healing, self-optimizing, and self-protecting (the so-called self-CHOP). The ASSL formal model addresses these four AC self-management principles as policies specified at both AS and AE tiers. Policies are specified with special constructs called fluents and mappings.

• A fluent has a time duration and when the system gets into that specific condition, a policy is activated.
• Mappings map particular fluents to particular actions to be undertaken by the specified AS.