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

Network 0.1 Case Study

How to Model an Embedded Network Domain

Leon Starr

Model Integration, LLC.

Rev 0.2 2

The same problem over and over

Measurement

Medical

Avionics

Vehicles

Rev 0.2 3

Protocol State Charts

Rev 0.2 4

Problems with explicit protocol models

Easy and intuitive to buildEasy 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

Rev 0.2 5

Protocol proliferation

J1939 ARINC 739-A

CAN TCP/IP

DICOM

Industry Standard ProtocolsProprietary Protocols

Tunneling / Transition / Legacy

App-hardware specific

<company acronym>_LINK

OrganicMixed domain

Rev 0.2 6

How to simplify?

Protocol A

Application

Communication

Protocol C Protocol DProtocol B

Step 1 – Study

7

Rev 0.2 8

Read the spec

ARINC 739A-1

Rev 0.2 9

Network <-> Model Translator

Rev 0.2 10

Transport interactions

Rev 0.2 11

Finite set of normal interactions

Pattern 1: Send data to display on the CRT

Pattern 2: Initiate communication

Step 2: Domain chart

12

Rev 0.2 13

Network layers (or domains?)

Rev 0.2 14

Will this work?

Application

Communication

Datalink

Step 3 – Model something

15

Rev 0.2 16

The abstraction goal

No protocol specific command or field names in any model element (class, attribute, relationship, state, action language)

Rev 0.2 17

Abstracting packet structure

Rev 0.2 18

Modeling sequence

1. Model receive path by itself2. Model send path by itself3. Realize that send path is pretty complicated

(variable size messages, recovery, restart, synch)

4. Model 3 – Split out Communication and Packet domains

Rev 0.2 19

Improved domain chart

Communication handles multi-word message structure, connections, channels, etc.

Packaging packs data into and extracts data from individual packets.

Rev 0.2 20

Modeling sequence

5. Unite send and receive paths by generalizing common elements

6. Model the communication domain7. Bridge it all together, compile, etc.

Packet Identification

21

Rev 0.2 22

Packets arrive

Data Link services:

::DL_Packet Arrived (Packet_ID)Field_value = DL::Extract (Packet_ID, Position)

Rev 0.2 23

Identification

Rev 0.2 24

Identification

Rev 0.2 25

Optimized IDing

Rev 0.2 26

ID model

Packet Extraction

27

Rev 0.2 28

Build the message

Rev 0.2 29

Extraction

Bridge Summary

30

Rev 0.2 31

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)

Rev 0.2 32

Bridge to Communication

From Communication

Send Message (Name, Arg1, Arg2, Arg3)

To Communication

Received Message (Name, Arg1, Arg2, Arg3)

Rev 0.2 33

Communication Side

Channel Opened

Message (Name, Arg1, Arg2, Arg3)

Open / Close Channel

ConnectData

Channel Opened (Size) Disconnected

Data ReceivedResend

To

From

Sending

34

Rev 0.2 35

Variable length messages

High level coordination is needed when all goes well…

… AND when it doesn’t.

Rev 0.2 36

Communication level concepts

Connection

Channel PackagePredefined

Dynamic

Knows how to send all of its components, resending as necessary.

Opens and closes itself.

Requests and establishes itself.

Rev 0.2 37

How to fill out a packet

Rev 0.2 38

Supplying the data

Next steps

39

Rev 0.2 40

What’s next?

Finish the model Write up a case study and publish You want it earlier…?

1.0

Embedded

Network

$$no problem.

Rev 0.2 41

xtUML Resources

Leon StarrModel Integration, LLChttp://[email protected]

M O D E L I N T E G R A T I O N L L C