RA2DL-Pool: New Useful Solution to Handle Security of Reconﬁgurable

Embedded Systems

Farid Adaili

1,2,3

, Olfa Mosbahi

, Mohamed Khalgui

1,4

and Samia Bouzefrane

LISI Laboratory, National Institute of Applied Sciences and Technology, University of Carthage, Tunis, Tunisia

Tunisia Polytechnic School, University of Carthage, Tunis, Tunisia

CEDRIC Laboratory, National Conservatory of Arts and Crafts, Paris, France

SystemsControl Laboratory, Xidian University, Xi’an, China

Keywords:

Embedded System, Component-based Approach, Reconﬁguration, Security, RA2DL, Implementation,

Evaluation.

Abstract:

The importance of security in software and hardware components becomes the major concern nowadays.

This paper focuses on adaptive component-based control systems following the reconﬁguration architecture

analysis and design language (denoted by RA2DL). Despite of its efﬁciency, RA2DL component can be com-

promised due to its lack in terms of security. This paper proposes a new method for modeling the security of

RA2DL component, argues for a more comprehensive treatment of an important security aspect with several

mechanisms such as authentication and access control. In this paper, we propose a new architecture of RA2DL

where pools are containers of sets of RA2DL components characterized by similar properties. The proposed

approach is applied to a real case study dealing with Body-Monitoring System (BMS).

1 INTRODUCTION

The increasing use of the embedded and reconﬁgu-

ration technologies in the information systems is not

only a concern of major corporations and govern-

ments but also an interest of individual users. Due

to this wide use, many of these systems manage and

store information that is considered sensitive, such as

personal or business data. The need to have secured

components for each system that contains such in-

formation becomes a necessity rather than an option

(Mouratidis et al., 2005). The embedded components

(MS, 2008) are getting increasingly connected and are

more and more involved in networked communica-

tions. The users of these components are now able to

execute almost all the network/internet applications.

These components are also increasingly involved in

the transfer of secured data through public networks

that need protection from unauthorized access. Thus

the security requirements in embedded systems have

become critical.

Traditional security research has been focusing on

how to provide assurance on conﬁdentiality, integrity,

and availability (Clements, 1996). However, with the

exception of mobile code protection mechanisms, the

focus of past research is not how to develop secured

software that is made of components from different

sources. Previous research provides necessary infras-

tructures, but a higher level perspective on how to use

them to describe and enforce security, especially for

component-based systems, has not received sufﬁcient

attention from research communities so far.

The authors propose in (F.Adaili et al., 2015) a

new concept of components named RA2DL as a solu-

tion for reconﬁgurable AADL components composed

of controller and controlled modules. The ﬁrst one is

a set of reconﬁguration functions applied in RA2DL

to adapt its execution to any evolution in the environ-

ment, described by three reconﬁguration forms:

(i) Form 1: Architectural level: modiﬁes the com-

ponent architecture when particular conditions are

met. This is made by adding new algorithms, events

and data or removing existing operations in the inter-

nal behaviors of the component.

(ii) Form 2: Compositional level: modiﬁes the

composition of the internal components (algorithms)

for a given architecture.

(iii) Form 3: Data level: changes the values

of variables without changing the component algo-

rithms, and the second one is a set of input/output

events, algorithms, and data as represented by recon-

ﬁguration modules.

102

Adaili, F., Mosbahi, O., Khalgui, M. and Bouzefrane, S.

RA2DL-Pool: New Useful Solution to Handle Security of Reconﬁgurable Embedded Systems.

In Proceedings of the 11th International Conference on Evaluation of Novel Software Approaches to Software Engineering (ENASE 2016), pages 102-111

ISBN: 978-989-758-189-2

However, securing an RA2DL component is

not an easy task. With rapidly advancing hard-

ware/software technologies and ubiquitous use of

computerized applications (Ren and Taylor, 2005),

modern software is facing challenges that it has

not seen before. More and more software is built

from existing components which come from differ-

ent sources. This complicates analysis and com-

position, even if a dominant decomposition mech-

anism is available. Additionally more and more

software/hardware components are running in a net-

worked environment. These network connections

open possibilities for malicious attacks that were not

possible in the past. These situations raise new chal-

lenges on how to handle security so that to design a

component-based architecture that is more resistant to

attacks and less vulnerable.

Facing the new challenges for security of reconﬁg-

urable RA2DL-based systems, we propose new solu-

tions allowing the required authentiﬁcation for the ac-

cess control to components under a set of constraints

such as the limitation in memory. These solutions are

supported by a new concept called pool which is a

container that gathers networked RA2DL under se-

curity constraints. The container allows the control of

any operation allowing the reconﬁguration of RA2DL

components as well as the access to local algorithms

and data.

The current paper is organized as follows: We

discuss in Section 2 the originality of the paper by

studying the state of the art. Section 3 describes the

background of RA2DL. Section 4 deﬁnes the new ex-

tension for secured RA2DL components. We expose

in Section 5 the case study: Body-Monitoring Sys-

tem (BMS) and how the implementation is performed

to secure RA2DL. Section 6 concludes the paper and

gives some perspectives as a future work.

2 STATE OF THE ART

In this section, we present a state of the art of se-

cured component-based design approaches. In (Br-

ereton and Budgen, 2000), the authors present a clas-

siﬁcation of component-based systems by describing

software components as independent units that inter-

act to form a functional system. A component does

not need/have to be compiled before it is used. Each

component offers services to the rest of the system

and adopts a provided interface that speciﬁes the ser-

vices that other components can use.

The authors in (Ren and Taylor, 2005) present a

treatment of an important security aspect, access con-

trol, at the architecture level and modeling of secu-

rity subject, resource, privilege, safeguard, and policy

of architectural constituents. The modeling language,

Secure xADL, is based on the existing modular and

extensible architecture description language.

In (Cai et al., 2000), the authors propose a QA

(Quality Assurance) model for component-based soft-

ware which covers component requirement analy-

sis, component development, component certiﬁca-

tion, component customization, and system architec-

ture design, integration, testing and maintenance. An

extension of the Component Object Model (COM),

Distributed COM (DCOM), is a protocol that enables

software components to communicate directly over a

network in a reliable, secure, and efﬁcient manner.

DCOM is designed for use across multiple network

transports, including internet protocols such as HTTP.

When a client and its component reside on different

machines, DCOM simply replaces the local interpro-

cess communication with a network protocol. Neither

the client nor the component is aware of the changes

of the physical connections.

In (elena Rugina et al., 2006), Rugina and al.

present an iterative dependency-driven approach for

dependability modeling using AADL. This approach

is a part of a complete framework that allows the gen-

eration of dependability analysis and evaluation mod-

els from AADL models to support the analysis of soft-

ware and system architectures in critical application

domains.

AADL and OSATE tools can be used to validate

the security of systems designed using MILS4 archi-

tecture (Hansson et al., 2008). The work in (J. Alves-

Foss and Taylor, 2006) uses two mechanisms to mod-

ularize or divide and conquer in secure systems:

partitions, and separation into layers. The MILS ar-

chitecture isolates processes in partitions that deﬁne a

collection of data objects, code, and system resources

and can be evaluated separately. Each partition is di-

vided into the following three layers: Separation Ker-

nel Layer, Middleware Service Layer and Application

Layer each of which is responsible for its own secu-

rity domain and nothing else.

In (J

urjens, 2002), the author presents the exten-

sion UMLsec of UML that allows to express security

relevant information within the diagrams in a system

speciﬁcation. UMLsec is deﬁned as an UML proﬁle

using the standard UML extension mechanisms. In

particular, the associated constraints give criteria to

evaluate the security aspects of a system design by re-

ferring to a formal semantic of a simpliﬁed fragment

of UML.

In (Bernstein, 2014), Bernstein deﬁne a Docker

(www.docker.com) is an open source project provid-

ing a systematic way to automate the faster deploy-

RA2DL-Pool: New Useful Solution to Handle Security of Reconﬁgurable Embedded Systems

103

ment of Linux applications inside portable contain-

ers. Basically, Docker extends LXC with a kernel-

and application-level API that together run processes

in isolation: CPU, memory, I/O, network, and so on.

Docker also uses namespaces to completely isolate an

applications view of the underlying operating envi-

ronment, including process trees, network, user IDs,

and ﬁle systems.

Docker containers are created using base images.

A Docker image can include just the OS fundamen-

tals, or it can consist of a sophisticated prebuilt appli-

cation stack ready for launch. When building images

with Docker, each action taken (that is, command ex-

ecuted, such as apt-get install) forms a new layer on

top of the previous one. Commands can be executed

manually or automatically using Dockerﬁles.

Note that, no one in all related works deals with

secured reconﬁgurable components. We propose in

this paper a new concept of security of RA2DL

components to be named RA2DL − Pool that allows:

(i) Grouping of RA2DL components that have the

same similar properties. (ii) Associating to each

RA2DLPool a security mechanism like authentication

and access control mechanisms.

3 RA2DL BACKGROUND

We deﬁned in a previous paper (F.Adaili et al., 2015)

the concept of RA2DL components as an extension of

reconﬁgurable AADL (Vergnaud et al., 2005) (Archi-

tecture Analysis and Design Language). RA2DL as

depicted in Figure 1 is composed of controller and

controlled modules where the ﬁrst one is a set of

reconﬁguration functions applied in AADL, and the

second one is a set of input/output events, algorithms,

and data. The controlled module is described by the

following four modules:

IEM (Input Events Module): This module processes

the reconﬁguration of input events (IE) stored in

the IEDB database of input events. It deﬁnes and

activates at a particular time a subset of events to

execute the corresponding algorithms in RA2DL.

OEM (Output Events Module): This module pro-

cesses the reconﬁguration of output events (OE)

stored in the OEDB database of output events. It

deﬁnes and activates at a particular time a subset

of events to be sent once the corresponding algo-

rithms ﬁnish their execution in RA2DL.

ALM (Algorithms module): This module processes

the reconﬁguration of the active algorithms (ad-

dition or removal) at a particular time in order to

be coherent with active input and output events of

IEM and OEM. These algorithms are stored in

the ALDB database of algorithms.

DM (Data Module): This module processes the re-

conﬁgurations of data in RA2DL in coherence

with the rest of modules. It is stored in the DDB

database of data values.

We focus on three hierarchical reconﬁguration

levels in RA2DL: (i) Form 1: Architectural level:

modiﬁes the component architecture when particular

conditions are met. This is made by adding new al-

gorithms, events and data or removing existing oper-

ations in the internal behaviors of the component. (ii)

Form 2: Compositional level: modiﬁes the compo-

sition of the internal components (algorithms) for a

given architecture. (iii) Form 3: Data level: changes

the values of variables without changing the compo-

nent algorithms.

Figure 1: Architecture of an RA2DL component.

In another extension in (Adaili et al., 2015) for

enhancing the execution of RA2DL components, a

new execution model is proposed which is composed

of three layers: (i) Middleware Reconﬁguration

level that handles the input reconﬁguration ﬂows, (ii)

Execution Controller level to control the execution

and reconﬁguration of RA2DL and (iii) Middleware

Synchronization level that controls and manages the

synchronization of the reconﬁguration. Addition-

ally, we proposed a new approach to coordinate sev-

eral RA2DL components in a distributed architecture

based on a coordination matrix.

Because of the resource limitations in adaptive

systems, satisfying a non-functional requirement such

as security requires careful balance and trade-off with

other properties and requirements of the system such

as performance, memory usage and access rights of

the RA2DL. This further emphasizes the fact that se-

curity cannot be considered as a feature that is added

later to the design of an RA2DL component. It needs

to be considered from early stages of development

and along with other requirements. In fact, the secu-

ENASE 2016 - 11th International Conference on Evaluation of Novel Software Approaches to Software Engineering

104

rity by design approach as deﬁned by Arnab (Ray and

Cleaveland, 2006) in software engineering ensures

that security is addressed at the point of conception

to avoid the security vulnerabilities. Considering the

characteristics of RA2DL components, major impacts

of security features in these systems are based on per-

formance, power consumption, ﬂexibility, maintain-

ability and cost (Kocher et al., 2004). Therefore in

the design of RA2DL components, implications of

introducing security decisions should be taken into

account and analyzed. Several related works do not

provide solutions to develop security of RA2DL com-

ponents of adaptive embedded systems. The current

paper proposes new extended solutions to secure an

RA2DL component. However, in this work we want

to extend this study by considering a new architecture

of secured RA2DL-based pools.

4 NEW EXTENSION FOR

SECURED RA2DL

In this section, we enrich RA2DL by security mech-

anisms that undergo such a failure to enhance their

execution and simulation.

4.1 Motivation: RA2DL-Pool

Security is an aspect that is often neglected in the de-

sign of adaptive systems. However, the use of these

systems for critical applications such as controlling

power plants, vehicular systems control, and medical

devices (Salem et al., 2015) makes security consid-

erations even more important. Also because of the

operational environment of adaptive systems and the

reconﬁguration actions applied by an RA2DL com-

ponent. To allow the required security, we introduce

the concept of RA2DL − Pool as a container which is

an abstract class that offers different services dealing

with security, where each RA2DL − Pool has a level

of sensitivity of the information of its RA2DL com-

ponents. RA2DL − Pool container serves as a gen-

eral purpose holder of other components. It holds

well-deﬁned methods for grouping RA2DL compo-

nents together. RA2DL − Pool is represented by the

following elements:

- Controller: it is the crucial part of the pool that

contains methods and represents ﬁrstly the interface

between the user and the pool, and secondly between

the pool and the RA2DL components,

- Tables: there are three kinds of tables : use

table (UT), reconﬁguration table (RT) and security ta-

ble(ST),

- Database: is the database containing the sets of

RA2DL components,

- Reconﬁguration Scenarios: deﬁne the set of

reconﬁguration scenarios realized in pool or in its

RA2DL components. Each scenario will be applied

in relation with the three tables (UT, RT and ST),

- RA2DL: it is the RA2DL component with its

algorithms and input/output ports,

Figure 2 presents the class diagram of RA2DL −

Pool. An RA2DL − Pool container holds a set of

RA2DL components with a set of methods. This

set of components has a set of methods that describe

how to examine and add or delete components to the

RA2DL − Pool. It contains the following methods de-

scribed in Table 1.

4.2 Security Mechanisms for RA2DL

To consolidate the RA2DL technology, we will put a

set of security-mechanisms divided into two families:

4.2.1 Authentication Mechanism

This is a critical mechanism where all users must

authenticate to access to the reserved services of

RA2DL − Pool or RA2DL components. This mech-

anism is always in relation with the user table

(UT), where the columns u are the identiﬁers of

users (id user) and lines s represent the services

(services user). To implement the authentication

mechanism, we use RADIUS (Remote Authentica-

tion Dial-In User Service) developed by Livingston

Enterprise (Yoon et al., 2007), which is a network-

ing protocol that provides centralized Authentication,

Authorization, and Accounting (AAA) management

for users who connect and use a network service. The

principle of the authentication of an RA2DL with RA-

DIUS is as follows:

(i) the Controller executes a connection request.

UT table recovers the identiﬁcation information, (ii)

the Controller transmits this information to the target

service in RA2DL, (iii) the target component receives

the connection request from the Controller, controls

and returns the conﬁguration information required for

the user to provide or deny access, (iv). Controller

refers to the user an error message if it fails an au-

thentication.

4.2.2 Access Control Mechanism

This mechanism comes just after authentication to

control the access to the RA2DL components. Two

tables are used in this case: security and reconﬁgu-

ration tables. The ﬁrst one is the security table ST

which contains in lines (p) all the user privileges

RA2DL-Pool: New Useful Solution to Handle Security of Reconﬁgurable Embedded Systems

105

Figure 2: Class diagram of RA2DL-Pool.

Table 1: RA2DL-pool Methods.

Method Description

getRA2DL () returns the number of components within the RA2DL − Pool

Component-getRA2DL(int position) returns the component at the speciﬁc position

Componentde getRA2DL () returns an array of all the RA2DL components held within the container

RA2DL-add (Component RA2DL, int position) adds RA2DL component to the container RA2DL − Pool at position

add (Component RA2DL, RA2DL constraints) necessary for layouts that require additional information

public void remove (int index) deletes the RA2DL component at position index from the RA2DL −Pool

remove (RA2DL component) deletes the RA2DL component from the container RA2DL − Pool

removeAll () removes all RA2DL components from the RA2DL − Pool container

boolean isAncestorOf (RA2DL) checks to see if the RA2DL component is a parent of container

addContainerListener (pool) registers listener as a controller of RA2DL-Pool

removeContainerListener (pool) removes listener as an interested listener of RA2DL-Pool

processEvent( RA2DLEvent e) receives all RA2DL events with this RA2DL − Pool container as its target

addNotify () creates the peer of all the components within it

removeNotify () destroys the peer of RA2DL components contained within it

Insetsgetinsets() gets the containers current insets

list() useful method to ﬁnd out what is inside a container

(privilege user) and in columns (u) the (id user).

The second one is the reconﬁguration table (RT )

that contains in lines (r) reconﬁgurations identiﬁers

(id recon f ) and in columns (c) the identiﬁers of

RA2DL components (id RA2DL). This mechanism

may be represented by a triplet (S, C, M

) where S

denotes the service, C denotes the RA2DL compo-

nent (or RA2DL-pool) and M

that maps each pair

(C and S) to a set of access rights.

Figure 3 presents the sequencing of the interaction

between the RA2DL components and the RA2DL-

Pool. The main goal is to show this interaction and

how to apply authentication and access control mech-

anisms.

Figure 4 highlights the activity of these two mech-

anisms and tests in order to achieve a secure RA2DL

component.

4.3 Architecture of Secured

RA2DL-based Pools

We present in Figure 5 the class diagram of the se-

cured RA2DL-based pool. This diagram represents

the architecture of RA2DL-based pools with the static

aspect of the relation between the RA2DL compo-

nents and the pool. It does not provide any informa-

tion about its behavior. The architecture of secured

RA2DL-based pools is composed of the following

distinct classes: (i) RA2DL : The main class of the

architecture, the component concerned by the secu-

rity concept, (ii) RA2DL − Pool: It is the container

of RA2DL components, (iii) Security: Is an associa-

tion between RA2DL and RA2DL-Pool which repre-

sents the security-mechanisms, (iv) RA2DL − So ft: It

is the software component of RA2DL, (v) RA2DL −

ENASE 2016 - 11th International Conference on Evaluation of Novel Software Approaches to Software Engineering

106

Figure 3: Sequence diagram.

Figure 4: Activity diagram.

Hard: It is the hardware component of RA2DL, (vi)

Algorithm: Is a set of methods to be executed by each

RA2DL component, (vii)Recon f iguration: Repre-

sents all of the reconﬁguration scenarios to execute

with RA2DL, (viii) Architecture: Describes the re-

conﬁguration scenarios that touch on the RA2DL ar-

chitecture, (ix) Structure: Describes the reconﬁgu-

ration scenarios that touch on the RA2DL composi-

tion or structure,(x) Data: Describes the reconﬁgu-

ration scenarios that touch on the RA2DL data, (xi)

EventPort: Port for input/output event of RA2DL,

(xii) DataPort: Port for input/output data of RA2DL.

4.4 Modelling and Veriﬁcation

We propose in this section the modelling and veriﬁca-

tion of the new architecture of secured RA2DL-based

pools by using UPPAAL (Bengtsson et al., 1996).

Firstly, we model the pool with its security aspect.

Secondly we check a set of properties to ensure the

security of the pool.

4.4.1 Modelling of Secured RA2DL-based Pool

The modelling of the RA2DL-based pool with the se-

curity aspect is described by the state machine pre-

sented in Figure 6.

The states of this model are described as fol-

lows: start to start the querying or the connection of

RA2DL − pool. Controller represents the ﬁrst con-

tact with the pool, in this state the checking of id

user

is important after veriﬁcation of the password user

in the table UT . If the authentication is accepted

and the password is checked, it can go to the state

Recon f iguration which represents all the reconﬁg-

uration scenarios. After the veriﬁcation of the fol-

lowing parameters: (i) id sr for the IDs of scenarios,

privilege user for the privilege of the user in the table

ST and (iii) id recon f for the IDs of the reconﬁgura-

tion in the table RT . If all of the IDs are accepted,

then the user may apply the reconﬁguration in the tar-

get RA2DL component after checking the id RA2DL.

A database is associated to this level to facilitate the

reconﬁguration of the RA2DL components.

4.4.2 Veriﬁcation of Secured RA2DL-based Pool

We propose the following properties in order to verify

the security of the RA2DL components.

- Property 1: (Controller[].check id user)AND

(UT[].check passeword user): for each connection

with the pool, we should check the user authentiﬁ-

cation by using the UT table,

- Property 2: (Reconﬁguration[].check id sr)

AND (RT[].check id reconf): before the execution of

any reconﬁguration scenario, it is important to check

if it is registered in the reconﬁguration table (RT),

- Property 3: (Reconﬁguration[].Reconﬁgure!

⇒ RA2DL[].check id RA2DL) AND (ST[].check

privilege user): this property concerns the veriﬁca-

tion of the access control mechanism,

- Property 4: RA2DL[].save ⇒

Database[].check id db: each RA2DL compo-

nent should be imperatively saved in a Database

to facilitate the use of RA2DL components and to

minimize the execution time,

- Property 5: (Controller[] AND Reconﬁgura-

tion[] AND RA2DL[] AND Database[] AND ST[]

AND RT[] AND UT[]) not deadlock: the system is

deadlock-free.

The veriﬁcation of these properties is summarized

in Table 2.

RA2DL-Pool: New Useful Solution to Handle Security of Reconﬁgurable Embedded Systems

107

Figure 5: Architecture of a secured RA2DL-based pool.

Figure 6: Modelling of Secured RA2DL-Based Pools.

Table 2: Veriﬁcation results.

Property Result Time (sec) Memory (Mo)

Property 1 True 10.52 5.72

Property 2 True 9.12 4.82

Property 3 True 5.32 3.20

Property 4 True 13.25 6.56

Property 5 True 8.23 4.37

5 CASE STUDY AND

IMPLEMENTATION

We use as a running example in the current paper the

body-monitoring system (BMS) to evaluate the pa-

per’s contribution.

5.1 Case Study: Body-Monitoring

System (BMS)

During the last few years there has been a signiﬁ-

cant increase in the number and variety of wearable

health monitoring devices ranging from simple pulse

monitors, activity monitors, and portable Holter mon-

itors, to sophisticated and expensive implantable sen-

sors. The Body-Monitoring System (BMS) (Huse-

mann et al., 2004) is designed as a mobile device that

is able to collect measured data and to act according to

ENASE 2016 - 11th International Conference on Evaluation of Novel Software Approaches to Software Engineering

108

instructions set by a supervisor. The system consists

of a body-monitoring network. In order to recognise

the monitored person’s state, the monitor unit con-

nects to various body sensors and i/o devices by using

either wired or wireless communication technologies.

Data from all sensors are collected, stored and anal-

ysed at real-time and, according to the analysis, ac-

tions may then be performed. A computer is used as

an interface to the body-monitoring network, and de-

veloped software allow a supervisor to conﬁgure the

monitor unit for the monitored person, to connect sen-

sors and i/o devices, deﬁne and upload instructions for

monitoring and download collected data (Figure 7).

The monitor unit software consists of a commu-

nication module (responsible for connecting and con-

trolling sensors, and for gathering and pre-processing

measured data), a storage module (for storage of col-

lected data), and a policy interpretation module re-

sponsible of controlling the behaviour of the monitor

unit according to instructions deﬁned by a supervisor.

To secure this system, we must take into account

these steps: (i) make the grouping of RA2DL compo-

nents according to similar characteristics in RA2DL-

Pool. (ii) assign for each RA2DL-pool a security

level (depending on the degree of importance of the

RA2DL components that they contain). (iii) allocate

for each RA2DL-pool a security mechanism.

Figure 7: Overview of the Body Monitoring System

(Bielikov, 2002).

Running Example: We group the RA2DL com-

ponents of BMS system in ﬁve RA2DL-Pools as

shown in Figure 8. (i) RA2DL-Pool 1: includes

the following RA2DL components: RA2DL-G for

the Glucose detection, RA2DL-C for the chloride

detection and RA2DL-W for the water detection.(ii)

RA2DL-Pool 2: includes the following RA2DL

components: RA2DL-L for the lactate detection and

RA2DL-PH for the PH detection. (iii) RA2DL-

Pool 3: includes the following RA2DL components:

RA2DL-DM for the Diabetes mellitus detection and

the RA2DL-BP for the Blood pressure. (iv) RA2DL-

Pool 4: contains the display device which is the com-

ponent RA2DL-Mobil. (v) RA2DL-Pool 5: contains

the RA2DL-Soft for the transmission of data with a

protocol until RA2DL-Mobil.

5.2 Implementation

We present in this section the tool of the BMS sys-

tem that we developed in LISI Laboratory at IN-

SAT Institute of University of Carthage in Tunisia

and CEDRIC Laboratory at National Conservatory of

Arts and Crafts of Paris in France. We assume ﬁve

pools with their parameters such as the number of

RA2DL components in pool, Worst Case Execution

Time (WCET), the authentication and the access con-

trol mechanisms (Figure 9).

Figure 10 shows the connectivity test of the differ-

ent pools according to the authentication mechanisms

and also to check the conﬁguration between the vari-

ous RA2DL components in each pool.

Running Example: The application of our ap-

proach to the BMS case study is illustrated in Table

3, where we give a security level (S.L) for the ﬁve

pools depending on the sensitivity of the comprising

components. In the BMS system, the RA2DL-pool 3

is the most secured and RA2DL-pool 1 is the less se-

cured one. Both security mechanisms are applied to

the ﬁve pools.

Table 3: Running example.

S.L Authen. AccessControl Security

Pool 1 1 No Yes Yes

Pool 2 2 Yes No Yes

Pool 3 6 Yes Yes Yes

Pool 4 5 Yes Yes Yes

Pool 5 5 Yes Yes Yes

5.3 Evaluation

This step is devoted mainly to test our approach and

evaluate the execution time. Ten assessments are ap-

plied to the two mechanisms that are focused on two

stolen: RA2DL without pool and RA2DL with pool

of the BMS system. We show in Figure 11 the re-

sults of the evaluation. We are interested in response

time gains for secured and not secured RA2DL com-

ponents.

The proposed approach has the following advan-

tages:

(a) Functionality: RA2DL component in

RA2DL − Pool are at a functional level much more

adaptable and extendable than traditional RA2DL

components.

(b) Reusability: A reusability is an important

characteristic of a high-quality RA2DL component.

Programmers should design and implement RA2DL

components in such a way that many different pro-

grams can reuse them.

RA2DL-Pool: New Useful Solution to Handle Security of Reconﬁgurable Embedded Systems

109

Figure 8: Object diagram of BMS.

Table 4: Comparison between Pool and Docker.

Pool Docker

Main Goal Secure RA2DL Component Lightweight virtualized environent for portable applications

Continent RA2DL component Applications

System RA2DL-Based system OS

Relationship Between Them Yes No

Security Mechanism Yes No

Figure 9: RA2DL-Pools of BMS system.

Figure 10: Test of Authentiﬁcation mechanism.

functionality ideally is implemented just once. It is

self-evident that this results in easier maintenance of

Figure 11: Result of evaluation.

system, which leads to lower cost, and a longer life.

We shows in Table 4 a comparative study between

our approach Pool containers and Docker containers.

6 CONCLUSION

This paper deals with new solutions for a required

security in adaptive RA2DL control based systems.

Firstly, we deﬁne a new grouping methodology

named RA2DL-Pool which has its own methods for

the grouping and security techniques. Secondly, we

ENASE 2016 - 11th International Conference on Evaluation of Novel Software Approaches to Software Engineering

110

propose two important mechanisms to control the se-

curity in pools. Finally their implementation is ap-

plied to a Body-Monitoring system (BMS). The fu-

ture work will deal with the ﬂexibility in the network

that links different devices of RA2DL-based systems.

In addition, we will be interested either in the different

real-time aspects of RA2DL or in the run-time tests of

components once deployed on the target devices.

REFERENCES

Adaili, F., Mosbahi, O., Khalgui, M., and Bouzefrane, S.

(2015). New solutions for useful execution models

of communicating adaptive ra2dl. In Intelligent Soft-

ware Methodologies, Tools and Techniques, volume

532, pages 87–101. Springer International Publishing.

Bengtsson, J., Larsen, K., Larsson, F., Pettersson, P., and Yi,

W. (1996). Uppaal: A tool suite for automatic veriﬁca-

tion of real-time systems. pages 232–243, Secaucus,

NJ, USA. Springer-Verlag New York, Inc.

Bernstein, D. (2014). Containers and cloud: From lxc

to docker to kubernetes. Cloud Computing, IEEE,

1(3):81–84.

Bielikov, M. (October 2002). A body-monitoring system

with eeg and eog sensors. Journal of ERCIM News

No. 49.

Brereton, P. and Budgen, D. (2000). Component-based sys-

tems: a classiﬁcation of issues. Computer, 33(11):54–

62.

Cai, X., Lyu, M., Wong, K.-F., and Ko, R. (2000).

Component-based software engineering: technolo-

gies, development frameworks, and quality assur-

ance schemes. In Software Engineering Confer-

ence, 2000. APSEC 2000. Proceedings. Seventh Asia-

Paciﬁc, pages 372–379.

Clements, P. C. (1996). A survey of architecture descrip-

tion languages. In Proceedings of the 8th Interna-

tional Workshop on Software Speciﬁcation and De-

sign, IWSSD ’96, pages 16–, Washington, DC, USA.

IEEE Computer Society.

elena Rugina, A., Kanoun, K., and Kaniche, M. (2006).

An architecture-based dependability modeling frame-

work using aadl. In In 10th IASTED International

Conference on Software Engineering and Applica-

tions SEA2006.

F.Adaili, O.Mosbahi, M.Khalgui, and S.Bouzefrane (2015).

Ra2dl: New ﬂexible solution for adaptive aadl-based

control components. In Proceedings of the 5th In-

ternational Conference on Pervasive and Embedded

Computing and Communication Systems, pages 247–

258.

Hansson, J., Feiler, P. H., and Morley, J. (2008). Building

secure systems using model-based engineering and ar-

chitectural models. CrossTalk: The Journal of De-

fense Software Engineering, 21(9).

Husemann, D., Steinbugler, R., and Striemer, B. (2004).

Body monitoring using local area wireless interfaces.

US Patent App. 10/406,865.

J. Alves-Foss, W. S. Harrison, P. O. and Taylor, C. (2006).

The mils architecture for high assurance embedded

systems. International Journal of Embedded Systems.

urjens, J. (2002). Umlsec: Extending uml for secure sys-

tems development. In Proceedings of the 5th Inter-

national Conference on The Uniﬁed Modeling Lan-

guage, UML ’02, pages 412–425, London, UK, UK.

Springer-Verlag.

Kocher, P., Lee, R., McGraw, G., and Raghunathan, A.

(2004). Security as a new dimension in embedded

system design. In Proceedings of the 41st Annual De-

sign Automation Conference, DAC ’04, pages 753–

760, New York, NY, USA. ACM. Moderator-Ravi,

Srivaths.

Mouratidis, H., Kolp, M., Faulkner, S., and Giorgini, P.

(2005). A secure architectural description language

for agent systems. In Proceedings of the Fourth In-

ternational Joint Conference on Autonomous Agents

and Multiagent Systems, AAMAS ’05, pages 578–

585, New York, NY, USA. ACM.

MS, A. (2008). Security needs in embedded sys-

tems. Cryptology ePrint Archive, Report 2008/198.

http://eprint.iacr.org/.

Ray, A. and Cleaveland, R. (2006). A software architec-

tural approach to security by design. In 30th An-

nual International Computer Software and Applica-

tions Conference, COMPSAC 2006, Chicago, Illinois,

USA, September 17-21, 2006. Volume 2, pages 83–86.

Ren, J. and Taylor, R. (2005). A secure software architec-

ture description language. In Workshop on Software

Security Assurance Tools, Techniques, and Metrics,

pages 82–89.

Salem, M. O. B., Mosbahi, O., Khalgui, M., and Frey,

G. (2015). Zizo: Modeling, simulation and veriﬁca-

tion of reconﬁgurable real-time control tasks sharing

adaptive resources - application to the medical project

bros. In Proceedings of the International Conference

on Health Informatics, pages 20–31.

Vergnaud, T., Pautet, L., and Kordon, F. (2005). Using the

aadl to describe distributed applications from middle-

ware to software components. In Reliable Software

Technology - Ada-Europe 2005, 10th Ada-Europe In-

ternational Conference on Reliable Software Tech-

nologies, York, UK, June 20-24, 2005, Proceedings,

pages 67–78.

Yoon, E., Lee, W., and Yoo, K. (2007). Secure pap-

based RADIUS protocol in wireless networks. In Ad-

vanced Intelligent Computing Theories and Applica-

tions. With Aspects of Contemporary Intelligent Com-

puting Techniques, Third International Conference on

Intelligent Computing, ICIC 2007, Qingdao, China,

August 21-24, 2007. Proceedings, pages 689–694.

RA2DL-Pool: New Useful Solution to Handle Security of Reconﬁgurable Embedded Systems

111