Using AADL to Model a Protodol Stack

warmersafternoonNetworking and Communications

Oct 23, 2013 (3 years and 9 months ago)

77 views

Using AADL to Model a Protodol Stack

Didier Delanote, Stefan Van Baelen, Wouter Joosen and Yolande Berbers

Katholieke Universiteit Leuven

2

Contents


Modeling process


Structural aspect


Behavioral aspect


Non
-
functional aspect


Conclusion


Discussion

3

Modeling process


Network architecture


set of layers and protocols


Layer


collection of services


offered to higher layers, using services from lower layers


Service


set of operations


implemented using protocols


Protocol


format and semantics of messages


specific to one layer

4

layer 1

layer 2

layer n
-

1

layer n

layer 1

layer 2

layer n
-

1

Modeling process

protocol n

interface n

interface n

layer n

protocol n
-

1

interface n
-

1

interface n
-

1

protocol 2

interface 2

interface 2

protocol 1

interface 1

interface 1

entity 1

entity 2


OSI: Open Systems Interconnection reference model

5

Modeling process

UDP, ICMP

interface 4

interface 4

Transport
layer

IP, ARP

interface 3

interface 3

MAC

interface 2

interface 2

IEEE 802.3

interface 1

interface 1

entity 1

entity 2

Network
layer

Data link
layer

Ethernet
layer

Transport
layer

Network
layer

Data link
layer

Ethernet
layer


UDP/IP concrete protocol stack

6

Modeling process


Use AADL to model UDP/IP protocol stack


What requirements should this model conform to?


High
-
level


Implementation independent


Structured


Precise


Significant level of detail


Unambiguous


Complete


Functional properties


Non
-
functional properties

7

Contents


Modeling process


Structural aspect


Behavioral aspect


Non
-
functional aspect


Conclusion


Discussion

8

Structural aspect


Let’s go back for a moment…


Hardware
and

software description


hardware, software and composite components


predefined component
categories




execution platform components




application software components






composite components


Processor

Memory

Device

bus

System

Process

Subprogram

Threadgroup

Thread

Data

9

Structural aspect

Ada

AADL

package

package

hardware + application

system

application

process

task

thread

procedure

subprogram

function

subprogram

subprogram parameter

subprogram parameter

function call

subprogram call

type

data component





10

Structural aspect

interface 4

Transport
layer

interface 3

interface 2

interface 1

entity 1

Network
layer

Data link
layer

Ethernet
layer



Model layer, socket, queue,… as packages of subprograms

package

Transport_Layer

public


--

data types


data

PDU_Length


properties


Language_Support::Data_Format=> Positive;


end

PDU_Length;



data

Receive_Fifo


properties


Language_Support::Data_Format=> Record;


end

Receive_Fifo;


--





--

subprograms


subprogram

Init


end

Init;




subprogram

Bind


features


socket:
in

parameter

Network_Entity;


end

Bind;


--



end

Transport_Layer;

11

Structural aspect


No generic software component in AADL


Model protocol types as data components


So how to model…


a protocol layer


a software cache


a software fifo


a socket




12

Structural aspect


Packages represent logical grouping of component declarations


AADL packages and Ada packages are similar


Can we use packages to introduce structure in the model?

ARP

IP

UDP/ICMP

Ethernet layer

UDP/ICMP
-
frame

IP
-
frame

Ethernet
-
frame

13

Structural aspect


Problem: packages are no more than grouped declarations


no representation in model


no semantic requirements that enforce package structure


nested packages not allowed


package

Application

public

--
public part of package


--

Processes

------------

process

UDPIPdriver

end

UDPIPdriver;



end Application;

14

Contents


Modeling process


Structural aspect


Behavioral aspect


Non
-
functional aspect


Conclusion


Discussion

15

Behavioral

aspect


Example


subprogram

Create_Socket


features





Domain :
in

parameter

Domain;


Con_Type :
in

parameter

Connection;


Protocol :
in

parameter

Protocol;


Socket_Handle :
out

parameter

Valid_Handle;


end

Create_Socket;



Allow to model method interfaces


Calls in thread implementation


Behavior of subprogram


modeled with behavior annex

16

Contents


Modeling process


Structural aspect


Behavioral aspect


Non
-
functional aspect


Conclusion


Discussion

17

Non
-
functional aspect


Add properties to analyze system for non
-
functional properties


Some properties are easy to model


pragma Priority (100);

becomes


Language_Support::Priority => 100;



for Application_Task'Storage_Size use 2000;

becomes


SEI::RAMBudget => 2000.0 B;



Others need to be calculated or measured


Period => 5 ms;


Compute_Execution_Time => 1 ms .. 2ms;



Analyses depending on available properties


Schedulability analysis


Resource allocation analysis




18

Contents


Modeling process


Structural aspect


Behavioral aspect


Non
-
functional aspect


Conclusion


Discussion

19

Conclusions


Goals


High
-
level


Implementation
-
independent


Structured


Precise


Significant level of detail


Unambiguous


Complete


Functional properties


Non
-
functional properties





is it possible to achieve these goals?

20

Conclusions


Goals


High
-
level


Implementation independent



rather implementation dependent


Structured



packages, components and subprograms


Precise


Significant level of detail



using language compliance annex, behavior annex,…


Unambiguous



close to implementation


Complete


Functional properties





structure, behavior and interfaces


Non
-
functional properties





model or measure

21

Conclusions


Benefits


graphical representation


analysis mechanism



Drawbacks


same abstraction level as code


similar effort



can we make it easier to build an AADL model?

22

Contents


Modeling process


Structural aspect


Behavioral aspect


Non
-
functional aspect


Conclusion


Discussion