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.
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.
ASSL expresses fluents with fluent-activating and fluent-terminating events, i.e., the self-management policies are driven by
events. In order to express mappings, conditions and actions are considered, where the former determine the latter in a
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.