Using AADL to Model a Protodol Stack

1
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
Modeling process

• OSI Open Systems Interconnection reference model

protocol n
interface n
interface n
layer n
layer n
protocol n - 1
interface n - 1
interface n - 1
layer n - 1
layer n - 1
protocol 2
interface 2
interface 2
layer 2
layer 2
protocol 1
interface 1
interface 1
layer 1
layer 1
entity 1
entity 2
5
Modeling process

• UDP/IP concrete protocol stack

UDP, ICMP
interface 4
interface 4
Transport layer
Transport layer
IP, ARP
interface 3
interface 3
Network layer
Network layer
MAC
interface 2
interface 2
Data link layer
Data link layer
IEEE 802.3
interface 1
interface 1
Ethernet layer
Ethernet layer
entity 1
entity 2
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

• Lets 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

bus
Memory
Processor
Device
Process
Subprogram
Threadgroup
Thread
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

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

interface 4
package Transport_Layer public -- data types
data PDU_Length properties
Language_SupportData_Formatgt Positive end
PDU_Length data Receive_Fifo properties
Language_SupportData_Formatgt Record end
Receive_Fifo -- -- subprograms
subprogram Init end Init subprogram Bind
features socket in parameter
Network_Entity end Bind -- end
Transport_Layer
Transport layer
interface 3
Network layer
interface 2
Data link layer
interface 1
Ethernet layer
entity 1
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?

UDP/ICMP
UDP/ICMP-frame
IP
IP-frame
ARP
Ethernet-frame
Ethernet layer
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_SupportPriority gt 100
• for Application_Task'Storage_Size use 2000
  becomes
• SEIRAMBudget gt 2000.0 B
• Others need to be calculated or measured
• Period gt 5 ms
• Compute_Execution_Time gt 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