ARC-2015-2184R02 Modelling operations – problem statement and proposal

Group Name: ARC#19.3Source: Joerg Swetina, NEC, joerg.swetina@neclab.eu Meeting Date: 2015-10-20Agenda Item: <agenda item topic name>

Problem 1: The Cleaning Robot’s Dilemma• I have 2 <container>s for

– destination X coordinate– destination Y coordinate

• CREATing a new <contentInstance> starts me moving.. (my AE gets notified)– But you cannot “CREATE” the two at the

same time• How do I avoid going first to X and

later to Y ? (and get bitten by the dog)

• Problem to be solved:Write multiple application specific variables into the <AE> resource in a single operation

X

Y

(X/Y)

Problem 2: Light weight variables

• Currently AE specific data ( = variables) are stored in <contentInstance>s of <containers> of the <AE> resource.– This allows multiple instances of data, but

• Is heavy weight• Might not be needed

• Problem to be solvedSpecify how AE specific data ( = variables) can be stored in the <AE> resource with the option to:– allow multiple instances of data of the variable (as currently specified

in the <container> / <contentInstance> mechanism)– allow storing data of a variable in a simple, application defined,

attribute (that can simply be “UPDATE”d).

© 2014 oneM2M Partners<Document number>

3

Problem 3: Associating output to input

• Consider a “multiplier” AE that – Receives values “3” and “4” for two input variables X and Y of the <AE>

resource– multiplies the two input variables … this might take some time …– Returns the result “12” in a variable Z

• In the meantime X and Y may be overwritten with “5” and “6”• Problem to be solved

When the result “12” becomes available in the variable Z:– How to make sure that “12” is the result of multiplying “3” and “4” and

not “5” and “6”?– A single CRUD operation does not allow to write input data into the <AE>

resource and also receive the result output data.

Problem 4: How to avoid interfering with an operation that is ongoing in the AE?• Problem to be solved

– Has the operation been triggered in the AE? Has the AE received the input data from the <AE> resource?

– Has the AE finished sending output data to the <AE> resource?– Has the AE finished the operation and is ready for a new operation

invocation (even when no input- or output data are involved)?

• An operationStatus can provide such information and also can serve as a semaphore for oneM2M entities that want to invoke a new operation

Middle Node

MN-CSE

MN-AE

Mca<AE>

<container>

attributeattribute

<container>

<container>

CRUDN

input / output

data

Communication between AEs (example of a MN-AE sending input data to ADN-AE)

<AE> resource of ADN

ADN-AE

Application Dedicated Node

Mca

Step 1Step 2

… and ADN-AE creating output data that can be retrieved / subscribed by MN-AE

Operation invoking oneM2M entity

Step 3 Step 4

AreaNetwork

nativeDevice

Middle Node

MN-CSE

MN-AE

Mca

IPE

<AE>

<container>

attributeattribute

<container>

<container>

CRUDN

Interworking with non-oneM2M Nodes(example of a MN-AE sending input data to native device via IPE)

<AE> resourceof proxied

device

IPE proxies native Device into proxied

Device

input / output

data

Step 1Step 2

Mca(Non-oneM2M Node – NoDN )

… similarly output data are created / retrieved in the other direction

Operation invoking oneM2M entity

Types of features for operations (I)1. Simple operation setting / reading out a single

variable E.g. CREATE / RETRIEVE <contentInstance> of a

<container> Child resource of the <AE> E.g. UPDATE a particular attribute (e.g for “Reboot”)

Works well for the simplest case but does not allow setting / reading out multiple variables does not allow associating output to input does not allow to keep a status of the operation

Invoking requires just a single CRUD operation

Improvement: light weight variables(application specific attributes)

<AE>

AE specificattribute

<container>

<container>

AE specificattribute…

Needs to have•Name (unique within the <AE> resource)•Value •Type (optional)Can be UPDATEd to trigger action in the AE

<container> / <contentInstance> same as in Rel-1

Note: the Name and Type of an AE specific attribute may also be provided through the information contained in a <semanticDescriptor> child-resource of the <AE>

Types of features for operations (II)2. Simple operation setting / reading out

multiple variables Proposal to create new resource type <operation>

<AE>

AE specificattribute

<operation>

<operation>

AE specificattribute…

AE specificattribute

<container><container>

<container>

Attributes of an <operation> can be UPDATEd at once

Further improvement: references<AE>

AE specificattribute

<operation>

<operation>

AE specificattribute…AE specificattribute

<container>

<contentInstance>Reference to AE Specific attribute

• Name (unique within <operation> resource)

• Value = link to <contentInstance>

• Type (optional)

• Name (unique within <operation> resource)

• Value• Type (optional)

…

1.) CREATE <contentInstance> containing the value of the variable2.) UPDATE <operation> with the reference

Note: the Name and Type of an AE specific attribute may also be provided through the information contained in a <semanticDescriptor> child-resource of the <operation>

Types of features for operations (IIIa)3. Correlated (2…n) input- or output attributes

- no operation state1. The invoking entity or the AE UPDATEs the <operation>

resource:• Values of input attributes or references are set by the invoking

entity.• Values of output attributes or references are set by the AE.

2. UPDATE by the invoking entity triggers the action in the AE(AE either gets notified on the UPDATE or polls the <operation>)

3. As a result attributes within the <operation> are correlated.

Types of features for operations (IIIb)3. (0…n) input attributes and correlated (0…n)

output attributes _with_ operation state– Similar to previous but <operation> contains a standardized operationState

attribute.– Invoking entity sets operationState to

"Operation_Initiated“ during UPDATE– When AE was triggered and possibly

received input (step 2 in figures5 and 6) the CSE [or AE ???] sets operationState to "Operation_Ongoing“

– When the action of the AE is finished (andthe AE had its last UPDATE of the output)the AE sets the operationState to "Operation_Ended“

– Only when Operation_Ended“ the CSE allows an invoking entity to UPDATE the <operation> resource again.

– Further operationState values (communication errors…) are possible

<operation>

AE specificattribute…

operationState

Reference to AE Specific attribute…

Types of features for operations (VI)4. Stack of <operation> instances

– Multiple instances of an <operation> can be put on a stack.– Depending on the capabilities of the AE the individual <operation>s could be

handled sequentially or in parallel by the AE.

<operationStack>

0..1description

0..n<operation>

0..1maxNofInstantiations

<subscription>

0..1<semanticDescriptor>

0..n

0..1 ontologyRef

Proposal• Introduce light weight variables (application specific

attributes) and references (slides 9 and 11)

• Introduce a new resource type <operation>• Introduce a new resource type <operationStack>• Specify service flows for <operation> (slides 12 and 13)

• Specify the operationState attribute and its minimal number of states: "Operation_Initiated“, "Operation_Ongoing“, "Operation_Ended“

… comments welcome !!!