Evolving Tiriba Design towards a Product line of Small Electric

I BRAZILIAN CONFERENCE ON CRITICAL EMBEDDED SYSTEMS
1
Evolving Tiriba Design towards a Product line of
Small Electric-Powered UAVs
Rosana T. V. Braga1, Kalinka R. C. Branco1, Onofre Trindade Jr1, and Itana M. S. Gimenes2
Abstract— Unmanned Aerial vehicles (UAV) have been used
in critical applications such as defense and agriculture. They
contain embedded systems that need to be designed according to
strict functional and non-functional requirements. There are
several UAV models that, despite having differences, contain
many common features that can take advantage of reuse
techniques such as software product lines. Tiriba is a family of
UAV designed for domain applications like agricultural
management, defense, urban monitoring, and transmission line
surveillance. It was initially designed based on conventional
software
development
techniques
together
with
Matlab/Simulink support. This paper presents an evolution of
Tiriba design based on product line concepts that improves the
generation of UAVs models as well as reducing its time to
market.
Index Terms— Embedded Software, Unmanned aerial
vehicles, Software Design, Software Reusability
U
I. INTRODUCTION
AV is an embedded system usually applied in critical
applications [1]. Its configuration varies according to the
application requirements and cost.
The software of an embedded system is typically used to
control a larger system. The presence of software in a
embedded system means that there is a software engineering
process within a more complex engineering process.
Usually, the construction of software for embedded systems
is more complex than for other computer systems. In this kind
of systems, the software has to communicate at low level with
hardware devices, run for days and often years without
stopping, even in hostile environments (high temperature,
humidity, vibration) [2].
In addition, there are limited resources of hardware
(memory size, processing power and others). Applications
must be optimized to fit the available resources, an issue
Manuscript sent to review on February 4, 2011. This work was supported by
CNPq and FAPESP in the scope of the INCT-SEC (National Institute of Science
and Technology - Safety-critical Embedded Systems - Brazil), processes
573963/2008-9 and 08/57870-9.
1
R. T. V. Braga, Kalinka R C Branco, and O. T. Junior are with the Instituto
de Ciências Matemáticas e de Computação – USP, São Carlos, SP, Brazil
(phone: 55-16-33738625; fax: 55-16-33712238; e-mails: rtvb, kalinka,
[email protected]).
2
I. M. S. Gimenes is with the Universidade Estadual de Maringá, Maringá,
PR, Brazil (e-mail: [email protected]).
3
http://www.agx.com.br
normally disregarded during the development of other
computer systems that have more abundant resources. The
development of embedded systems demands, thus, a different
software engineering approach than the ones adopted in the
information systems domain [3].
There are evidences of successful application of product
lines in the area of embedded systems [4] [5].This makes the
UAV an interesting domain to apply product line concepts, as
many products can be generated from a core asset and welldefined variation points.
Tiriba is a UAV developed by AGX3 in partnership with
INCT-SEC (National Institute of Science and Technology Critical Embedded Systems) [6]. Its design has followed a
traditional approach based on Matlab/Simulink models from
which C code is generated. In this work, Tiriba design has
been revisited in the context of INCT-SEC, where several
UAV applications are required thus demanding a more
efficient approach that results in higher quality products.
The objective of this paper is to present an evolution of
Tiriba design based on product line concepts that improves
the generation of UAV models as well as reducing its time to
market.
This paper is organized as follows. The next section
presents Tiriba´s overview (hardware and software
components), as well as the main concepts of software
product lines. Section III presents the development of Tiriba
product line. Section IV presents lessons learned from from
this development. Section V concludes the paper and
discusses further research directions in small and low cost
UAVs.
II. BACKGROUND
This section presents an overview of Tiriba family and the
basic concepts of software product lines.
A. The Tiriba domain
Tiriba is a small UAV, mainly designed for applications
such as agricultural management, defense or urban
monitoring and transmission line surveillance. The basic
specification of the original Tiriba aircraft is presented in
Table 1.
Tiriba includes, in addition to the actual aircraft, payload,
sensors, actuators and the embedded software that controls
the missions. As Tiriba is a UAV, it has an on-board system
to control the functions performed by a pilot in a conventional
I BRAZILIAN CONFERENCE ON CRITICAL EMBEDDED SYSTEMS
aircraft, such as: navigation, control, sensors and actuators.
TABLE I
BASIC SPECIFICATIONS OF TIRIBA AIRCRAFT
Propulsion
Max Takeoff weight
Payload
Endurance
Cruiser speed
Takeoff
Landing
Missions
Ground Station
Assembly time
Electric, 1.2KW
3 Kg
0.7 Kg
40min/1h30min
100Km/h/60Km/h
hand launch/catapult
Automatic, parachute
Autonomous
Smartphone based
10 min
According to the particular application requirements, a
specific Tiriba model needs to be configured and its
correspondent
embedded software generated. This
configuration includes equipments, usually called payload, to
capture data from the environment, such as images, or to
undertake procedures, such as insecticide spraying.
The main functions of Tiriba include:
1. to define a mission in which the routes, the data
capturing and actions strategy need to be specified;
2. to allow autonomous and assisted flights;
3. to use a navigation system based on GPS;
4. to allow rolling to adjust the aircraft positioning;
5. to obtain data from the payload equipments.
6. to execute actions over the environment according to
its mission.
Tiriba usually executes safety critical [7] missions, thus
non-functional requirements are rather important, such as
safety and performance. In addition, there are constraints
associated with actual operations such as: flight duration
should be between 1 (one) and two (two) hours; maximum
cruising speed should be between 100 and 150 km/h;
launching system should be hand or catapult; and, landing
system should be automatic or using parachutes. Tiriba
products are exemplified in Figure 1.
B. Product Line
A software product line (SPL) is a set of software systems
that share common and managed features and fulfills
requirements of a particular market segment [8]. A feature is
a product characteristic that both customers and developers
consider important both to describe the product and to
differentiate one product from another [9]. A SPL is
developed from a common set of core assets in a systematic
manner [8]. The distinction between products is denoted by
variabilities.
SPL development encompasses two phases: domain
engineering and application engineering. The first analyzes
the domain and produces artifacts that implement core assets
2
(features that are present in every product of the SPL) and
variabilities (features that can be present, but not necessarily).
The latter configures the artifacts designed during domain
engineering to assemble them into products, according to the
specific customer needs.
Fig. 1. Tiriba products.
A SPL can be developed from three different perspectives
[10]: proactive, where there is not a concrete product to base
the SPL on, so prospective investigation needs to be done to
look ahead and figure out the features that would be relevant
to compose the SPL; reactive, which starts with one existing
product, and then evolution is done in an iterative manner,
according to customers needs or market issues; and
extractive, where the SPL is extracted by analyzing two or
more exiting products. In this paper we have used the reactive
approach, as we have already developed one product, thus the
SPL conception was based on it.
Core and variable features of a SPL are identified during
domain engineering. They are usually documented using
feature models [11], which are hierarchical structures
consisting of features and constraints among them. There are
several different notations for feature models. In this paper we
use the pure::variants notation [12], shown in Figure 2.
Examples of feature models are given in the following
Section.
I BRAZILIAN CONFERENCE ON CRITICAL EMBEDDED SYSTEMS
3
A. Feature Model
Fig. 2. Feature Model Notation (based on pure::variants)
III. TIRIBA PRODUCT LINE
With the increasing demand for Tiriba applications, a
better structure to explore its features and to facilitate the
generation of new products was required. In this section we
describe how we have evolved Tiriba towards a product line
of Small Electric-Powered UAVs, called Tiriba SPL.
The development of the Tiriba SPL started with the
creation of its feature model, partially illustrated in Figures 3,
4 and 5. The feature model is composed of 108 features,
including mandatory, alternative and optional features. These
include both hardware and software features. In fact, many
features can be implemented in hardware or in software,
depending on decisions that are made throughout the
development process. The root of the feature model refers to
the whole system as UAS (Unmanned Aircraft System), a
term adopted by both the FAA (Federal Aviation
Administration) and the international academic community to
designate not only the aircraft but also the associated
elements – the control base station and communications links
(the ground station and other elements) [13].
Fig. 3. Partial Tiriba´s Feature Model
Fig. 4. Partial Tiriba´s Feature Model - Payload feature
Physical characteristics of the UAV are mostly
implemented in hardware, with no associated software, but
we found that it is important to identify this type of feature so
that our feature model is as complete as possible. An example
of a hardware feature is Aircraft, shown in the left size of
Figure 3. There are also hardware features with associated
software, such as the Auxiliary board feature (Figure 5),
where there is hardware (eg. battery and engine) but there is
also the associated software to control temperature and battery
level.
The Payload feature (Fig. 4) illustrates the several types
of features of the model. It is an optional feature, as a UAV
can fly without it or customers may want to use specific
payload for certain missions other than the ones addressed by
the Tiriba SPL. Once selected, there are options that can be
chosen, such as Photo Imaging and/or Video Imaging
features. Video Imaging has itself other options: Onboard
recorded video or real time video. Real time
video implies in an alternative exclusive choice between
Thermal or RGB. If Thermal is chosen, for example, then
features Video Assembly Kit Opt3 and Video
Thermal Camera are mandatory.
Constraints among features are also part of the feature
model. Examples of such constrains are shown in Fig. 6. For
example, if the application engineer chooses the Real Time
feature, the Video Transmitter must be chosen too.
Fig. 5. Partial Tiriba’s Feature Model – Auxiliary Board feature
I BRAZILIAN CONFERENCE ON CRITICAL EMBEDDED SYSTEMS
Fig. 6. Tiriba Feature Model – constraints among features (partial)
B. Architecture
Fig. 7 shows a simplified view of the Tiriba SPL
architecture. It includes the three main components of a UAS:
the aircraft (Airframe + Propulsion System +
Avionics), the ground control station and the
payload. Optional blocks in Fig. 7 are inside dashed-line
4
boxes. These blocks can contain one or more features of the
feature model. The propulsion system components change
according to the two airframe versions: standard, a glider-like
configuration, or the flying wing configuration.
There is some variability concerning the avionics (aviation
+ electronics). This variability is introduced by some optional
sensors, such as the Optical Measurement Unit and the
Magnetic Field 3D. It is worth noting that Magnetic Field 3D
will be mandatory in Tiriba’s V2 products.
The Launch/Recovery Systems block is also optional. Tiriba
aircraft normally do hand launch takeoffs and belly landings.
Slingshot takeoffs can be used to avoid the need of trained
personnel to launch high wing loaded configurations.
Parachute landings can also avoid trained personnel in the
landing phase of the flight, allowing an automatic landing
procedure.
Fig. 7. Tiriba’s Product Line Architecture
C. Code generation
Tiriba´s initial architecture had the code automatically
generated to the target hardware, based on Matlab/Simulink
and Model-Driven Development (MDD) [14]. The use of
MDD allows code reuse and decreases time spent in code
maintenance and development, thus reducing the final cost of
the aircraft [15].
The hardware architecture for the target system was
defined and the system was partitioned and allocated among
the several processors of the target architecture. An example
of the automatic code generation from the corresponding
block is shown in Figure 8, and the syringe represents a code
injection made directly in some blocks before code
generation. State machines are also used as shown in Figure
8.
For the Tiriba SPL, we intend to develop the code
corresponding to each feature (mandatory or optional). Most
of them will be reused from previous products. We also need
to define the glue code needed to compose features and the
mapping rules that are required to guarantee that the
constraints of the feature model are satisfied. Finally, to ease
the instantiation of SPL products, we plan to use automatic
generation tools, such as pure::variants [12], through which it
is possible to obtain automatic generated code just by
choosing the particular features of the target product.
IV. LESSONS LEARNED
Tiriba initial project has paid special attention to software
reuse. Thus, a development methodology [15] was followed
and applied with success. This methodology is closely based
on MDD and the use of Matlab/Simulink as a development
tool for modeling, functional simulation and testing, and
I BRAZILIAN CONFERENCE ON CRITICAL EMBEDDED SYSTEMS
automatic code generation. The entire system resulted in
25.000+ lines of C code (not considering comments), split
among four processors. Functional blocks were mapped into
5
RTOS (Real Time Operating System) processes inside the
processors.
Fig. 8. Tiriba Logic block and Corresponding Automatically Generated Code.
The feature model design, in the domain engineering
described in this paper, was not a straightforward task as
previously thought. The complexity and size of the Tiriba
project is far beyond toy examples that cannot demonstrate
the feasibility, in the practical domain, of new approaches or
methodologies. It is not easy to understand an entire new
domain from different points of view, ranging from the
technical, passing over the applications and reaching
commercial issues, sometimes neglected, but everyday more
important. Thus, the work presented in this paper is of
unquestionable importance for our research team, which feels
more comfortable to target the much more complex tasks
proposed in the new projects to come.
It is also important to highlight the difficulty in defining
the correct granularity level of SPL features, as well as the
separation into hardware and software features. The
customer, who had little background on SPL, tended to define
very high level features, which needed to be refined over and
over. Some abstract features were created whenever needed to
allow more fine-grained alternative sub-features. The decision
about how to implement the feature (in hardware or in
software) was postponed to later phases (after obtaining
simulation results, for example) in order to increase its
chance of being correct.
Despite Tiribas’ development success, shortly after the
project completion, it was realized that a systematic procedure
to provide reuse of models in other two similar projects under
development was missing. It is expected that one of these
projects will be ten times bigger than Tiriba. Thus, we
consider that the product line approach will be the missing
approach to achieve our goals. Thus, two tasks were started
towards this direction: the first one was described in this
paper, and will make possible the configuration of alternative
products followed by immediate and automated code
generation of new products in the domain of Small ElectricPowered Unmanned Aircraft. The second task focuses on the
improvement of the MDD methodology, used so far, adding
the concepts and practices of SPL.
V. RELATED WORK
Nord [16] describes an architecture that allows embedded
I BRAZILIAN CONFERENCE ON CRITICAL EMBEDDED SYSTEMS
systems to attend the objectives of SPL. His work proposes
some quality goals and the respective solutions to achieve
them. For example, portability is treated with a layered design
associated with common processing libraries. To ease the
inclusion and configuration of features, they suggest an
approach based on rules. Real time requirements are solved
using a task-based architecture, in which tasks are managed
in a flexible way.
Koong and others [17] present an approach in which the
concept of SPL was used to ease dynamic reconfiguration of
a product line for Lego robots. They use XML configuration
files to describe the dynamic function composition of the
system and, when hardware or software function demand is
changed, the XML configuration file is modified causing the
system to perform the new configuration.
Kim [18] discusses the advantages of applying SPL to
embedded systems and the need to evolve existing
methodologies due to the large dependency that embedded
systems have in terms of real-time features. His work
proposes an embedded system development workbench,
however it is rather complex and the implementation was not
shown.
Yoshimura and others [19] build product lines based on
existing embedded systems. The first step is to check whether
the introduction of the product line is economically feasible,
by analyzing the expectations about return of investment
(ROI) and the effort required to develop the reusable artifacts.
The analysis of commonalities is focused on source-code
analysis, which leads to the detection of common parts among
systems. However, the approach does not take into
consideration specific real time issues.
Our work has a different focus from the works mentioned,
as we highlight the domain engineering phase and how to
obtain the feature model and the SPL architecture.
The products obtained may explore several applications of
Tiriba, such as agriculture, security, civil defense and
environmental monitoring.
As future work, an extension of a methodological approach
to the Development of Safety-Critical Embedded Systems,
called SAFE-CRITES, will be provided focused on Product
Lines.
VII. ACKNOWLEDGMENT
The authors acknowledge the support granted by CNPq and
FAPESP to the INCT-SEC (National Institute of Science and
Technology - Critical Embedded Systems - Brazil), processes
573963/2008-9 and 08/57870-9.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
VI. CONCLUSIONS
The main goal of the Tiriba project is the development and
manufacturing of an Automatic Guidance Unit for
lightweight UAVs based on inertial and barometric pressure
sensors and Global Position Systems (GPS). The system
should be as simple and easy to use as possible, once the
mission is defined using a regular cell phone. The operation
must be totally automatic and intuitive.
The system development using MDD accelerated the
process by using automatic code generation and made easier
the source code reuse.
With the advances and new possibilities of using Tiriba, as
mentioned before, this paper proposed a reengineering of
Tiriba based in a reactive SPL. Starting with the original
Tiriba architecture, some new products can be more easily
instantiated by using the core assets and choosing the
variabilities to compose a new product of Tiriba’s family.
The products from this family are not simple examples,
they are a real life use of Product Line Software Engineering.
6
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
Musial, M. System Architecture of Small Autonomous UAVs, VDM
Verlag Dr. Mueller e.K. , 2008.
Douglass, B. P. Real Time UML: Advances in The UML for Real-Time
Systems. Boston: Addison Wesley, 3 edition, 2004.
Hugues, J; Perrotin, M.; Tsiodras T. Using MDE for the Rapid
Prototyping of Space Critical Systems. In The 19th IEEE/IFIP
International Symposium on Rapid System Prototyping, Monterey, CA,
USA, p. 10–16, 2008.
SEI Hall of Fame, [Online June, 29, 2010], Available at
http://www.sei.cmu.edu/productlines/plp_hof.html, 2010.
Bosch, J.; Bosch-Sijtsema, P. From Integration to Composition: On the
Impact of Software Product Lines, Global Development, and Ecosystems.
Journal of Systems and Software, v. 83, n. 1, p. 67-76, 2010.
INCT-SEC, Critical Embedded Systems: applications in safety and
agriculture, CNPq 2008, [Online] available at http://www.inct-sec.org/.
Fowler, K., Mission-Critical and Safety-Critical Systems Handbook:
Design and Development for Embedded Applications, Newnes, 2009.
Clements, P. and Northrop, L. Software Product Lines: Practices and
Patterns, Addison Wesley, 2001.
Griss, M. L. Implementing Product-Line Features with Component Reuse,
International Conference on Software Reuse, p. 137-152, 2000.
Krueger, C. Easing the transition to software mass customization. In
Proceedings of the 4th International Workshop on Software ProductFamily Engineering, pages 282–293, Bilbao, Spain, October 2001.
Kang, K.; Cohen, S.; Hess, J; Novak, W; Peterson A. Feature-Oriented
Domain Analysis (FODA) Feasibility Study. Technical Report, CMU/SEI90-TR-21, Software Engineering Institute, Carnegie Mellon University,
1990.
Pure-Systems, PURE::VARIANTS. [Online]. Available: http://www.puresystems.com/pure variants.49.0.html, 2009.
GAO. Unmanned aircraft systems - federal actions needed to ensure safety
and expand their potential uses within the national airspace system. GAO08-511, 2008.
Stahl, T.; Voelter, M.; Czarnecki, K. Model-Driven Software evelopment:
Technology, Engineering, Management. Wiley, 2006.
Trindade Jr, O.; Braga, R. T. V.; Neris, L. O.; Branco, K. R. L. J. C. A
methodology to develop critical embedded systems aiming at certification
(in Portuguese). In Proceedings of the IX Brazilian Simposium on
Intelligent Automation (SBAI), p. 1-6, 2009.
Nord, R. L. Meeting the product line goals for an embedded real-time
system. Workshop on Software Architectures for Product Families,
Springer Berlin / Heidelberg, p.19-29 (Lecture Notes in Computer Science,
v.1951), 2000.
Koong, C-S.; Lai, H-J.; Lai, K-C. An Embedded Software Architecture for
Robot with Variable Structures, International Conference on Frontier of
Computer Science and Technology, Shangai, China, p.478-484, 2009.
Kim, H-K. Applying Product Line to the Embedded Systems. 10th
International Conference on Computational Science and Its Applications
(ICCSA), p. 163-171, 2006.
Yoshimura, K.; Ganesan, D.; Muthig, D. Defining a strategy to introduce a
software product line using existing embedded systems. In: EMSOFT '06:
Proceedings of the 6th ACM & IEEE International conference on
Embedded software, New York, NY, USA: ACM, p. 63-72, 2006.