Transcript Dia 1

Using AADL to Model a Protodol Stack
Didier Delanote, Stefan Van Baelen, Wouter Joosen and Yolande Berbers
Katholieke Universiteit Leuven
Contents
•
•
•
•
•
•
Modeling process
Structural aspect
Behavioral aspect
Non-functional aspect
Conclusion
Discussion
2
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
3
Modeling process
•
OSI: Open Systems Interconnection reference model
interface n
protocol n
interface n
layer n
layer n
interface n - 1
protocol n - 1
interface n - 1
layer n - 1
layer n - 1
interface 2
protocol 2
interface 2
layer 2
layer 2
interface 1
protocol 1
interface 1
layer 1
layer 1
entity 1
entity 2
4
Modeling process
•
UDP/IP concrete protocol stack
Transport
layer
interface 4
UDP, ICMP
interface 4
Transport
layer
Network
layer
interface 3
IP, ARP
interface 3
Network
layer
Data link
layer
interface 2
MAC
interface 2
Data link
layer
Ethernet
layer
interface 1
IEEE 802.3
interface 1
Ethernet
layer
entity 1
entity 2
5
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
6
Contents
•
•
•
•
•
•
Modeling process
Structural aspect
Behavioral aspect
Non-functional aspect
Conclusion
Discussion
7
Structural aspect
•
•
Let’s go back for a moment…
Hardware and software description
•
•
hardware, software and composite components
predefined component categories
• execution platform components
Processor
•
Memory
Device
bus
application software components
Process
Subprogram
Threadgroup
Thread
Data
•
composite components
System
8
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
…
…
9
Structural aspect
•
Model layer, socket, queue,… as packages of subprograms
Transport
layer
interface 4
Network
layer
interface 3
Data link
layer
interface 2
Ethernet
layer
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;
-- …
interface 1
-- subprograms
subprogram Init
end Init;
subprogram Bind
features
socket: in parameter Network_Entity;
end Bind;
-- …
end Transport_Layer;
entity 1
10
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
…
11
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?
UDP/ICMP
UDP/ICMP-frame
IP
IP-frame
ARP
Ethernet-frame
Ethernet layer
12
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;
13
Contents
•
•
•
•
•
•
Modeling process
Structural aspect
Behavioral aspect
Non-functional aspect
Conclusion
Discussion
14
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
15
Contents
•
•
•
•
•
•
Modeling process
Structural aspect
Behavioral aspect
Non-functional aspect
Conclusion
Discussion
16
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
…
17
Contents
•
•
•
•
•
•
Modeling process
Structural aspect
Behavioral aspect
Non-functional aspect
Conclusion
Discussion
18
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?
19
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
20
Conclusions
•
Benefits
•
•
•
graphical representation
analysis mechanism
Drawbacks
•
•
same abstraction level as code
similar effort
 can we make it easier to build an AADL model?
21
Contents
•
•
•
•
•
•
Modeling process
Structural aspect
Behavioral aspect
Non-functional aspect
Conclusion
Discussion
22