[fr] [en]
In the early 90's, some research initiatives have been started in the domain of software architecture with the purpose to shift the focus from lines-of-code to coarser-grained elements and their interconnection structure. The expected benefits were to improve software and system evolvability and understanding, support architecture based development (product lines, reuse) and to provide a more flexible approach for system integration. An Architecture Description Language (ADL) is a semi-formal approach for software and system architecture specification. An ADL is a computer language used to describe the software, or software and hardware components of a system and the interfaces between those components. The language is used to describe the structure of such a system as an assembly of software and hardware components. The language can describe functional interfaces to components (for both control and data flows) and non-functional aspects of components (such as timing, safety level, reliability attributes). At a higher level, an architecture specification describes how components are combined into subsystems, how they interact (structure of data flow and control flow), and how they are allocated to hardware components.
MetaH is a domain-specific ADL dedicated to avionics systems which has been developed at Honeywell Labs since 1991 under the sponsorship of DARPA and the US Army. A significant set of tools (graphical editor, typing, safety, reliability, and timing/loading/schedulability analyzers, code generator...) has already been prototyped and used in the context of several experimentation projects which have shown development benefits ranging from 50% (new project) to 90% (modification of an existing project).
In 2001, MetaH has been taken as the basis of a standardization effort aiming to defining an Avionics Architecture Description Language (AADL) standard under the authority of SAE . This emerging AADL is an ADL developed to meet the special needs of embedded real-time systems such as avionics systems. In particular, the language can describe standard control and data flow mechanisms used in avionics systems, and important non-functional aspects such as timing requirements, fault and error behaviors, time and space partitioning, and safety and certification properties.
The name 'AADL' means Architecture Analysis & Design Language. Initially, for historical reasons, the acronym meant Avionics Architecture Description Language. In practice, AADL covers all the embedded real time systems, and not only the avionics ones.
AADL is initially a textual language. An annex of the standard defines a graphical notation. Another annex will define a UML profile for AADL.
The description of an architecture with AADL consists in the description of its components and their composition in a tree organisation. This description may be contained in files, in a database, etc.
All the examples given below respect the version 1.0 of the standard.
Each component is described in AADL with two phases. The first one, the type, represents the functional interface of the component, what is visible by other components. The second one, the implementation, describes the contents of the component (subcomponents, properties, connections, etc.).
What is interesting in the division of a component description into a type and an implementation is to separate two points of view. Describing the type means specifying the component interface, expressing how it is seen from an external point of view. On the other hand, the implementation represent the interior. In practice, the description of the type and the implementation may be done by different persons, each of them dealing with one step in the refinement of the architecture description, from the top level to the smallest details.
Each component belongs to a given category. These categories are predefined and are divided into hardware categories, software categories and composite categories:
Each implementation is associated with a type of the same category. With each type may be associated zero, one or more implementations. The following diagram shows two component types, the first of them is associated with two component implementations. The excerpt given below shows an example of a system component description corresponding with the diagram.
 |
system type1 end type1; system type2 end type2; system implementation type1.impl1 end type1.impl1; system implementation type1.impl2 end type1.impl2; |
An inheritance mechanism exists to describe the components. It may be used for both the types and the implementations. This mechanism is useful to refine a description by overwritting an already existing component.
Restrictions exist, which must be respected. Thus, a component type may inherit from another component type of the same category. In the same way, a component implementation may inherit from another component implementation of the same category.
The type/implementation relations are combined with the inheritance relations. This may provide pretty complex diagrams, as illustrated by the figure below.
 |
system type1 end type1; system type2 extends type1 end type2; system implementation type1.impl1 end type1.impl1; system implementation type1.impl2 extends type1.impl1 end type1.impl2; system implementation type2.impl1 end type2.impl1; system implementation type2.impl2 extends type1.impl2 end type2.impl2; |
Each component be associated with properties and their values. The properties enable a characterization of the component.
Some properties are predefined, that is they are identified by a name, a type and the list of the categories onwhich they may be applied. For example, the tasks (thread) have real time properties as period, deadline or execution time.
New properties, and new types of properties, may also be defined by the user, and associated to some or all the component categories. This property mechanism is a strong point of AADL for its extensibility. Thanks to it, any specific notion of a user need may be taken into account into its description.
thread thread1
properties
Period => 15 ms;
Deadline => 10 ms;
end thread1;
|
The description of data and control flows between components may be givent by the use of ports and connections. A port is an entry or exit point in a component, where data, events, or associated data and events may transit A connection enables the link between two ports, either the ports of two subcomponents, or the port of a subcomponent and the port of its owner component. A verification is done to ensure the conformity between the types and directions of the connected ports.
The following diagram shows a system containing two processes, each of them containing a thread. A string of ports, represented by the triangles, and connections, represented by the lines, establish a link between the two threads.
 |
system system1
end system1;
system implementation system1.impl
subcomponents
p1: process process1.impl;
p2: process process2.impl;
connections
cn: data port p1.outport -> p2.inport;
end system1.impl;
process process1
features
outport: out data port;
end process1;
process implementation process1.impl
subcomponents
t1: thread thread1.impl;
connections
cn: data port t1.outport -> outport;
end process1.impl;
process process2
features
inport: in data port;
end process2;
|
process implementation process2.impl
subcomponents
t2: thread thread2.impl;
connections
cn: data port inport -> t2.inport;
end process2.impl;
thread thread1
features
outport: out data port;
end thread1;
thread implementation thread1.impl
end thread1.impl;
thread thread2
features
inport: in data port;
end thread2;
thread implementation thread2.impl
end thread2.impl;
|
The AADL standard provides many other characteristics which are not described in this pages. Let's briefly mention some of these mechanisms:
To have more information, to ask questions, please contact us.
Axlog and its subsidiary Adalog propose complete AADL courses (description of the course, practical information and contacts here).