introduction.rst 7.34 KB
Newer Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

.. _introduction:

============
Introduction
============

About Ocarina
#############

.. index:: Ocarina (introduction)

Ocarina is an application that can be used to analyze and build
applications from AADL descriptions. Because of its modular
architecture, Ocarina can also be used to add AADL functions to
existing applications. Ocarina supports the AADL 1.0 and AADLv2
standards and proposes the following features :

* Parsing and pretty printing of AADL models
* Semantics checks
* Code generation, with the following code generators

  * PolyORB-HI/Ada, a High-Integrity AADL runtime and its code
    generator built on top of Ocarina that targets Ada targets: Native
    or bare board runtimes;
  * PolyORB-HI/C, a High-Integrity AADL runtime and its code generator
    built on top of Ocarina that targets C targets: POSIX systems,
    RTEMS;
  * POK, a partioned operating system compliant with the ARINC653 standard.

* Model checking using Petri nets;
* Computation of Worst-Case Execution Time using the Bound-T tool from Tidorum Ltd.;
* REAL, Requirement Enforcement and Analysis Language, an AADLv2 annex
  language to evaluate properties and metrics of AADLv2 architectural
  models;
* Scheduling analysis of AADL models, with a gateway to the Cheddar
  scheduling analysis tool from the Université de Bretagne
  Occidentale, and MAST from the University of Cantabria

40
41
Licence
#######
42

43
Ocarina is distributed under the GPLv3 plus runtime exception.
44

45
46
47
The GPLv3 plus runtime exception guarantees that Ocarina, but also the
code it generates can be distributed under customer-specific terms and
conditions. Specifically, the licence ensures that you can generate
48
49
proprietary, classified, or otherwise restricted executables.

50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
About AADL
##########

.. index:: AADL

The “Architecture Analysis and Design Language” AADL is a textual and
graphical language for model-based engineering of embedded real-time
systems. It has been published as SAE Standard AS5506B
(http://standards.sae.org/as5506b/). AADL is used to design and
analyze the software and hardware architectures of embedded real-time
systems.

AADL allows for the description of both software and hardware parts of
a system. It focuses on the definition of clear block interfaces, and
separates the implementations from these interfaces. It can be
expressed using both a graphical and a textual syntax. From the
description of these blocks, one can build an assembly of blocks that
represent the full system. To take into account the multiple ways to
connect components, the AADL defines different connection patterns:
subcomponent, connection, and binding.

An AADL model can incorporate non-architectural elements: embedded or
real-time characteristics of the components (such as execution time,
memory footprint), behavioral descriptions. Hence it is possible to
use AADL as a back- bone to describe all the aspects of a system. Let
us review all these elements:

An AADL description is made of components. The AADL standard defines
software components (data, thread, thread group, subprogram, process)
and execution plat- form components (memory, bus, processor, device,
virtual processor, virtual bus) and hybrid components (system).  Each
Component category describe well identified elements of the actual
architecture, using the same vocabulary of system or software
engineering:

* Subprograms model procedures like in C or Ada.

* Threads model the active part of an application (such as POSIX
  threads). AADL threads may have multiple operational modes. Each
  mode may describe a different behavior and property values for the
  thread.

* Processes are memory spaces that contain the threads. Thread groups
  are used to create a hierarchy among threads.

* Processors model microprocessors and a minimal operating system
  (mainly a scheduler).

* Memories model hard disks, RAMs, buses model all kinds of networks,
  wires, devices model sensors, … 


* Virtual bus and Virtual processor models “virtual” hardware
  components. A virtual bus is a communication channel on top of a
  physical bus (e.g. TCP/IP over Ethernet); a virtual processor
  denotes a dedicated scheduling domain inside a processor (e.g. an
  ARINC653 partition running on a processor).

Unlike other components, Systems do not represent anything concrete;
they combine building blocks to help structure the description as a
set of nested components.

Packages add the notion of namespaces to help structuring the
models. Abstracts model partially defined components, to be refined
during the modeling process.

Component declarations have to be instantiated into subcomponents of
other components in order to model system architecture. At the
top-level, a system contains all the component instances. Most
components can have subcomponents, so that an AADL description is
hierarchical. A complete AADL description must provide a top-most
level system that will contain certain kind of components (processor,
process, bus, device, abstract and memory), thus providing the root of
the architecture tree. The architecture in itself is the instantiation
of this system, which is called the root system.

The interface of a component is called component type. It provides
features (e.g. communication ports). Components communicate one with
another by connecting their features. To a given component type
correspond zero or several implementations. Each of them describes the
internals of the components: subcomponents, connections between those
subcomponents, etc.

An implementation of a thread or a subprogram can specify call
sequences to other subprograms, thus describing the execution flows in
the architecture. Since there can be different implementations of a
given component type, it is possible to select the actual components
to put into the architecture, without having to change the other
components, thus providing a convenient approach to configure
applications.

The AADL defines the notion of properties that can be attached to most
elements (components, connections, features, etc.). Properties are
typed attributes that specify constraints or characteristics that
apply to the elements of the architecture: clock frequency of a
processor, execution time of a thread, bandwidth of a bus, . . . Some
standard properties are defined, e.g. for timing aspects; but it is
possible to define new properties for different analysis (e.g. to
define particular security policies).

AADL is a language, with different representations. A textual
representation provides a comprehensive view of all details of a
system, and graphical if one want to hide some details, and allow for
a quick navigation in multiple dimensions. In the following, we
illustrate both notations. Let us note that AADL can also be expressed
as a UML model following the MARTE profile.

The concepts behind AADL are those typical to the construction of
embedded systems, following a component- based approach: blocks with
clear interfaces and properties are defined, and compose to form the
complete system. Besides, the language is defined by a companion
standard document that documents legality rules for component
assemblies, its static and execution semantics.

The following figure illustrates a complete space system, used as a
demonstrator during the ASSERT project. It illustrates how software
and hardware concerns can be separately developed and then combined in
a complete model.

.. figure:: assert.png
   :align: center

   ASSERT MPC Case study