1 / 22

Using AADL to Model a Protodol Stack

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. Modeling process. Network architecture

steve
Download Presentation

Using AADL to Model a Protodol Stack

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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 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 interface 4 UDP, ICMP interface 4 Transport layer Transport layer interface 3 IP, ARP 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. Data A A System ADL ADL 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 bus Memory Processor Device Process Subprogram Threadgroup Thread

  9. Structural aspect

  10. Structural aspect • Model layer, socket, queue,… as packages of subprograms interface 4 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: inparameter 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. Behavioralaspect • Example subprogram Create_Socket features Domain : inparameter Domain; Con_Type : inparameter Connection; Protocol : inparameter Protocol; Socket_Handle : outparameter 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

More Related