Task Model: How does a coordinator know the type of the collaborators during the binding phase?

[robot-ranger]

Lets say a coordinator publishes a task and has transitioned to the binding phase, looking for a collaborator to participate. Lets say the coordinator has selected a collaborator and is going to update the asset to reflect the collaborator selection.

How does the coordinator know the type of the collaborator during the binding phase, in order to accurately update the asset?

Is it inferred by the task requirements, assuming only collaborators with capability would enter binding phase?
Is it sourced from the device model?
Some other logic?

[shaurabhsingh]

As per the multi device interaction model (informative in the model) that we demoed in 2018, the "Task" Asset would list the "types" of collaborators required to execute the said task. The devices that fit the "type", which is determined based on capabilities (atleast was the case for the demo), can commit/bind to the task.

Task model itself has two concepts: TastArchetype, and Task which is an instance of the archetype. Task would include information like current state and actively involved Collaborators. Examples of TaskArchetype can be found here: https://github.com/mtconnect/ros_mtconnect_2/blob/master/simulator/src/taskArchetype/LoadCnc.xml

Model: https://model.mtconnect.org/#Diagrams___19_0_3_68e0225_1622718458287_713497_1203

[robot-ranger]

I see, so the original asset as posted to the agent includes <CollaboratorType> before the binding phase and before being updated to reflect the selected, bound, collaboratorId?

But the coordinator just takes the devices that attempt to bind as matching that type? There is no verification?

[wsobel]

We did not have verification in the prototype. These are the questions/requirements we need for the standard and production use of the technology.

[robot-ranger]

Right. On one hand, we could verify from the device model, maybe collaboratorType could be added as an attribute of <Device>.

On the other hand, we could simply assume that any device who bids/goes to 'preparing' in attempt to bind to a task knows themselves and knows they can complete the task (or not in which case they wouldn't attempt to bind) . Putting the ownus on the collaborator to only bid on tasks they can complete.

If it turns out that the collaborator cannot accomplish the task, I suppose the task would fail at some point.

Imo, I like adding collaboratorType to the device model some how. Maybe I the future there is more discrete types that can accomplish a task. Maybe HUMAN is a type, enabling 'collaboration' between human and robotic workforce? Or maybe ROBOT gets split into 6_AXIS_ROBOT and CARTESIAN_ROBOT etc

[wsobel]

The self-aware machine was the original intent of the model. They will not accept the task if they cannot complete it. This includes checking if they have the tooling and capabilities to meet the requirements. If not, don't try; otherwise, say you can participate. It can scale to the whole shop and include manually operated machines and someone assessing the requirements and responding on the machine's behalf.

Machine type can also be a capability, automatic, 5 axis mill, 6 axis robot, degrees of freedom, tool chain, etc. The machine should be aware of its capabilities and its location relative to other devices. Meaning it should be aware of reachability to other devices.

[robot-ranger]

The self-aware machine was the original intent of the model. They will not accept the task if they cannot complete it. This includes checking if they have the tooling and capabilities to meet the requirements. If not, don't try; otherwise, say you can participate. It can scale to the whole shop and include manually operated machines and someone assessing the requirements and responding on the machine's behalf.

Machine type can also be a capability, automatic, 5 axis mill, 6 axis robot, degrees of freedom, tool chain, etc. The machine should be aware of its capabilities and its location relative to other devices. Meaning it should be aware of reachability to other devices.

OK, I'm cool with that. I like the idea of device sovereignty.

In the 2018 model demonstration, were task assets first posted to the agent specifying collaborator type required, but without collaboratorId? (to be updated later after binding?)

[wsobel]

I don't remember, will have to look through the notes. @shaurabhsingh may be able to remember better than I can, he's younger. :-)

[shaurabhsingh]

The model demonstration was hard coded to accept from a specific set of devices. We did not verify the collaborator type and/or its capabilities.

Theoretically though, the device/coordinator would publish the Task with the required collaborator type/s. Upon receiving interest from a device/collaborator, the coordinator would verify the capabilities, evaluate trustworthiness and so on and accept the collaborator request to bind and thereafter update the Task asset with the specific ids.

[robot-ranger]

As it is right now, Specification configuration type doesn't seem well suited to enum-type config parameters. It seems analogous to SPC style specifications instead of discrete parameters. Could we add a Tasks configuration element? This could include capabilities like you mention as well

[robot-ranger]

Or maybe it's called Collaboration configuration type, it configures the devices' "collaboration model" ?

[shaurabhsingh]

Collaboration configuration does make sense. But we also need to define a Device's Capabilities which ideally should be separate from Collaboration configuration. Collaboration could refer to these Capabilities.

[robot-ranger]

Would this be a <Configuration> of the <Interfaces> component? Like this?

<Device uuid="" id="" name="machine_1">
	<Components>
		<Interfaces id="_interfaces" name="Interfaces">
			<Configuration>
				<Specifications>
					<Specification type="REACH" originator="MANUFACTURER" id="_reach" units="MILLIMETER">
					  <Nominal>1200</Nominal>
					</Specification>
				  </Specifications>
				<Collaboration type="ROBOT"/>
			</Configuration>
			<DataItems>
				<DataItem id="_task_id" type="TASK_ID" category="EVENT"></DataItem>
				<DataItem id="_bind_state" type="BINDING_STATE" category="EVENT"></DataItem>
			</DataItems>
			<Components>
				<DoorInterface id="_doorReq" name="Door Req">
					<Description>Door Requests</Description>
					<DataItems>
						<DataItem id="_doorSrvc" type="INTERFACE_STATE" category="CONDITION"></DataItem>
						<DataItem id="_doorSrvcEvent" type="INTERFACE_STATE" category="EVENT"></DataItem>
						<DataItem id="_doorOpenReq" type="OPEN_DOOR" subType="REQUEST" category="EVENT"></DataItem>
						<DataItem id="_doorCloseReq" type="CLOSE_DOOR" subType="REQUEST" category="EVENT"></DataItem>
					</DataItems>
					<References>
						<DataItemRef idRef="_doorState" />
					</References>
				</DoorInterface>
			</Components>
		</Interfaces>
	</Components>
</Device>

IDK, I still associate "specifications" as something that can change over the lifetime of the device; ex "reach" on the other hand is intrinsic and constant characteristic of the device regardless of interface(s). I think of it more like metadata of the device.

[shaurabhsingh]

We can add Capability as a configuration type instead of using Specification.

[wsobel]

That would be cleaner to have Capability as a Configuration. It really is not a specification.

[robot-ranger]

I agree.

1. do we all agree on a 'collaboration' configuration as well, which would configure the collaborator type, for future binding verification?

2. these configurations would be applied to the interface component, correct? (configurations are for components, not devices, right?)

[shaurabhsingh]

It does make sense. we need to flesh out the models first though.

Collaboration config I do see defined for the Interface Component but we should be able to define Capabilities for any Component in the device model.

The Collaboration Configuration should be able to refer to these capabilities