1. Network 0.1 Case Study How to Model an Embedded Network Domain Leon Starr Model Integration, LLC.

2. Rev 0.2 1 The same problem over and over Measurement Medical Avionics Vehicles

3. Rev 0.2 2 Protocol State Charts

4. Rev 0.2 3 Problems with explicit protocol models Easy and intuitive to build Easy to explain to net experts Lots of model content cut and paste, drag and draw Works for only one protocol Changes require recompilation and testing Generates lots of code Requires endless testing Not object oriented

5. Rev 0.2 4 Protocol proliferation J1939 ARINC 739-A CAN TCP/IP DICOM Industry Standard Protocols Proprietary Protocols Tunneling / Transition / Legacy App-hardware specific _LINK Organic Mixed domain

6. Rev 0.2 5 How to simplify?

7. Step 1 – Study 6

8. Rev 0.2 7 Read the spec ARINC 739A-1

9. Rev 0.2 8 Network Model Translator

10. Rev 0.2 9 Transport interactions

11. Rev 0.2 10 Finite set of normal interactions Pattern 1: Send data to display on the CRT Pattern 2: Initiate communication

12. Step 2: Domain chart 11

13. Rev 0.2 12 Network layers (or domains?)

14. Rev 0.2 13 Will this work?

15. Step 3 – Model something 14

16. Rev 0.2 15 The abstraction goal No protocol specific command or field names in any model element (class, attribute, relationship, state, action language)

17. Rev 0.2 16 Abstracting packet structure

18. Rev 0.2 17 Modeling sequence  Model receive path by itself  Model send path by itself  Realize that send path is pretty complicated (variable size messages, recovery, restart, synch)  Model 3 – Split out Communication and Packet domains

19. Rev 0.2 18 Improved domain chart Communication handles multi-word message structure, connections, channels, etc. Packaging packs data into and extracts data from individual packets.

20. Rev 0.2 19 Modeling sequence  Unite send and receive paths by generalizing common elements  Model the communication domain  Bridge it all together, compile, etc.

21. Packet Identification 20

22. Rev 0.2 21 Packets arrive Data Link services: ::DL_Packet Arrived (Packet_ID) Field_value = DL::Extract (Packet_ID, Position)

23. Rev 0.2 22 Identification

24. Rev 0.2 23 Identification

25. Rev 0.2 24 Optimized IDing

26. Rev 0.2 25 ID model

27. Packet Extraction 26

28. Rev 0.2 27 Build the message

29. Rev 0.2 28 Extraction

30. Bridge Summary 29

31. Rev 0.2 30 Bridge to Data Link From Data Link Packet Arrived (Packet_ID) To Data Link Pack data (Value, Packet_ID, Position) Data_item = Get data (Packet_ID, Position) Send (Packet_ID) Release (Packet_ID)

32. Rev 0.2 31 Bridge to Communication From Communication Send Message (Name, Arg1, Arg2, Arg3) To Communication Received Message (Name, Arg1, Arg2, Arg3)

33. Rev 0.2 32 Communication Side Channel Opened Message (Name, Arg1, Arg2, Arg3) Open / Close Channel Connect Data Channel Opened (Size) Disconnected Data Received Resend To From

34. Sending 33

35. Rev 0.2 34 Variable length messages High level coordination is needed when all goes well… … AND when it doesn’t.

36. Rev 0.2 35 Communication level concepts Knows how to send all of its components, resending as necessary. Opens and closes itself. Requests and establishes itself.

37. Rev 0.2 36 How to fill out a packet

38. Rev 0.2 37 Supplying the data

39. Next steps 38

40. Rev 0.2 39 What’s next?  Finish the model  Write up a case study and publish  You want it earlier…? 1.0 Embedded Network $$ no problem.

41. Rev 0.2 40 xtUML Resources Leon Starr Model Integration, LLC http://www.modelint.com leon_starr@modelint.com M O D E L I N T E G R A T I O N L L C