Introduction

The ISO 11783 standard contains two elements used to designate a date/time instance or a duration of time. These two elements are AllocationStamp (ASP) and Time (TIM). The first is used to specify a recording of an allocation event and the second is sued to specify the recording of a time event. In addition to specifying a time or time duration each of these elements may optionally specify two geo-locations. The purpose of this document is to provide a high level definition of these ISO elements and to align use case by use case these elements with the ADAPT TimeScope element.

AllocationStamp - ASP

Included by XML elements:

CommentAllocation
DeviceAllocation
ProductAllocation
WorkerAllocation

Includes XML element:

Position

Table D.2 — AllocationStamp attributes

Attribute	XML	Use	Type	Length/range	Comment
Start	A	r	xs:datetime	Max. 29	Time of start. Format: yyyy-mm-ddThh:mm:ss.sss plus an optional time zone indication^a.
Stop	B	o ^b	xs:datetime	Max. 29	Time of end. Format: yyyy-mm-ddThh:mm:ss.sss plus an optional time zone indication^a.
Duration	C	o ^b	xs:unsignedLong	0 to (232-2)	Time between start and stop in number of seconds.
Type	D	r	xs:NMTOKEN	1, 4	Type of the AllocationStamp, possible values: 1 = Planned 4 = Effective (Realized)
Position		o	xs:element		Include up to 2 Position XML elements which represent the position at the start and stop attribute values of the AllocationStamp.
^a The time zone information is introduced in ISO11783-10 version 4. ^b Either Stop or Duration need to be specified in addition to Start to create a finite AllocationStamp XML element

ADAPT TimeScope

AloocationStamp ASP Use Cases

Use Case Type	Use Case Detail	ISO Implementation	ADAPT Type	ADAPT Implementation

Use Case Type

Use Case Detail

ISO Implementation

ADAPT Type

ADAPT Implementation

CommentAllocation CAN

Single Comment from a list allocated at a specific point and time

<CAN A="CCT3" B="CCL13">
	<ASP A="2003-08-20T08:00:20" D="4">
		<PTN A="51.23456" B="13.23456" D="2"/>
	</ASP>
</CAN>

Single FreeCommentText allocated at a specific point and time

<CAN C="bad driving conditions">
	<ASP A="2003-08-20T08:00:20" D="4">
		<PTN A="51.23456" B="13.23456" D="2"/>
	</ASP>
</CAN>

Continuous Comments - Continuous comments are logged in a binary file at

a default rate of 1 hz. ASP.A = the timestamp when the logging

is started and ASP.B is the time-stamp when the logging is stopped.

 A continuous CodedComment is started:
<CAN A="CCT6" B="CCL38">
	<ASP A="2003-08-20T08:00:20" D="4">
	<!—- A = start of continuous comment allocation, comment is active -->
		<PTN A="51.23456" B="13.23456" D="2"/>
	<!—-position at the start of the continuous comment allocation -->
	</ASP>
</CAN>

and about 35 minutes later the same continuous CodedComment is stopped:

<CAN A="CCT6" B="CCL38">
	<ASP A="2003-08-20T08:00:20" B="2003-08-20T08:35:45" D="4">
	<!—-A = start of continuous comment allocation -->
	<!—- B = end of continuous comment allocation, comment is complete -->
		<PTN A="51.23456" B="13.23456" D="2"/>
		<!—-position at the start of the continuous comment allocation -->
	</ASP>
</CAN>

Single Comment allocated globally

DeviceAllocation- DAN

Planned device allocation - The planned device allocation is created by the FMIS

and may or may not completely specify the device. If the exact device is not known

at the time of planning it is common to only specify the device class. Guideline: ASP.A is the timestamp when the plan was created.

		<DAN B="70FE000000000000" A="200A000000000000">
			<ASP A="2003-11-12T08:00:00" D="1" />
		</DAN>

Effective device allocation - After the task is loaded in the MICS the planned device allocation is completed by identifying the actual device to be used. The TC modifies the original DAN.A and DAN.B to specify the actual device and may optionally define a point location of the event. The TC should also change ASP.D = "1" to ADP.D ="4" and also add ASP.B = timestamp when the allocation is discontinued. Guideline question: Should the TC modify the original planned DAN or create a new DAN? If the original is modified should ASP.A (planned) = ASP.A (effective)? NOTE: The 2015-1-14 FDIS states that a new DAN should be created.

		Lookup	Value
Self Conf	TRUE
Industry Group	2	2	Agriculture and Forestry Equipment
Device Class Instance	0
Device Class	5	5	Fertilizers
Reserved	0		Equipment for applying mineral and/or organic fertilizers
Function	128	128	Fertilizer Rate Control
Function Instance	0		Control of the rate of product placed on or in the soil
ECU Instance	0
Manufacturer Code	102	102	AGCO GmbH & Co. Marktoberdorf, Germany
Identity Number	1067011

....................................................................................................................................

		<DAN B="70FE000000000000" A="0348D00C00800AA0">
			<ASP A="2003-11-12T08:00:00" A="2003-11-12T08:05:00"D="4" />
		</DAN>

WorkerAllocation -WAN

Planned worker allocation - Indicates the worker(s) that are planned to execute the task. These may be in addition to the "Responsible Worker" referenced in the TSK. In planned allocations ASP.A = the timestamp when the plan was created.

...........................................................................

<WAN A="WKR1">
   <ASP A="2003-0820T08:00:00" D="1" />
</WAN>

Effective worker allocation - The actual worker(s) allocated to a task. ASP.A is the start time of the allocation and ASP.B is the end time of the allocation. Guideline - If ASP.B is null then it is assumed that end time is the task end time.

<WAN A="WKR1">
   <ASP A="2003-0820T08:00:00" B="2003-0820T08:06:00" D="4" />
</WAN>

ProductAllocation - PAN

Effective product allocation - Allocates a crop input product (single or mixture) to a application task and a specific device.

PAN.A: A product identifier.
PAN.B: The hexadecimal form of the DDI that describes how the product is applied.
PAN.C: Quantity value. In a transfer product allocation this indicates how much product is being transferred; otherwise not specified.
PAN.D: Transfer mode.
PAN.E: Device element involved in the product allocation.
PAN.F: Value presentation ID. THis specifies how the numbers involved are to be shown to a user.

PAN has child elements of time ASP (Allocation stamp)

ASP.A = timestamp at the start of the allocation and
ASP.B = timestamp at the end of the allocation. Guideline - If ASP.B is null then it is assumed that end time of the product allocation is the task end time.
ASP.D = Specifies what the time means; a value of 4 indicates "effective".

.......................................................................................................

<PAN A="PDT2" B="004B"C="20000" E="DET3" F="VPN1">
	<ASP A="2003-11-12T08:00:00" D="4"/>
</PAN>

Effective product transfer allocation - A specified product is transferred from one vehicle to another. For example from a combine to a grain cart. The ASP element may also contain 1-2 geo-referenced points.If one point is included it is the location at the start of the event if two points are included the second is the location at the end of the event. Guideline - If two points are included the first ASP.A = the timestamp of the start of the transfer event and ASP.B = timestamp of the end of the transfer event.

.........................................................................................................

<PAN A="PDT2" B="004B"C="20000" D="2" E="DET3" F="VPN1">
	<ASP A="2003-11-12T08:00:00" D="4">
		<PTN A="54.588945" B="9.989209" D="3"/>
	</ASP>
</PAN>

Time - TIM

Included by XML elements:

Task
TimeLog

Includes XML elements:

Position
DataLogValue

Table D.47 — Time attributes

Attribute	XML	Use	Type	Length/range	Comment
Start	A	r	xs:datetime	Max. 29	Time of start. Format: yyyy-mm-ddThh:mm:ss.sss plus an optional time zone indication ^a.
Stop	B	o ^b	xs:datetime	Max. 29	Time of end. Format: yyyy-mm-ddThh:mm:ss.sss plus an optional time zone indication ^a.
Duration	C	o ^b	xs:unsignedLong	0 to (232-2)	Time between start and stop in number of seconds.
Type	D	r	xs:NMTOKEN	1 to 8	Type of the recorded time, possible values: 1 = Planned 2 = Preliminary 3 = Preparation 4 = Effective 5 = Ineffective 6 = Repair 7 = Clearing 8 = Powered Down ^c
Position		o	xs:element		Include up to 2 Position XML elements which represent the position at the start and stop attribute values of the Time.
DataLogValue		o	xs:element		Includes a list of XML element DataLogValue
^a The time zone information is introduced in ISO11783-10 version 4. ^b Either Stop or Duration need to be specified in addition to Start to create a finite Time XML element. ^c This token is introduced in ISO11783-10 version 4.

Table G.1 — Time Type definitions

Time Type	Definition

Time Type	Definition
2. Preliminary	Time spent on preparing on the farm site, travelling to the field and preparing at the field. “Preliminary” time starts as soon as a Task is activated and stops when either “Effective” work or another time type is started on a Task. When recording of this specific timetype is not available, this time would fall under the “Ineffective” timetype.
4. Effective	Effective work covers the activities absolutely and directly required to fulfill the process of the work. “Effective” time of a Task starts when the main work of a Task started and contains the time spent on the main work. This timetype is the minimal requirement for the MICS to provide.
5. Ineffective	Is the time when the main/effective work of a Task is not active. The “Ineffective” time can be used between periods of “Effective” time.
6. Repair	Is the time allocated to repair work during a Task. When recording of this specific timetype is not available, this time would fall under the “Ineffective” timetype.
7. Clearing	Starts as soon as the “Effective” work is stopped for the last time during a Task and stops when the Task is stopped. When recording of this specific timetype is not available, this time would fall under the “Ineffective” timetype.
8. Powered Down	Starts as soon as the machine on which the time registration operates is powered down. When recording of this specific timetype is not available, this time would fall under the “Ineffective” timetype.

Table G.2 — Time Registration Levels

Level	MICS supported TimeTypes	Description

Level	MICS supported TimeTypes	Description
1. Minimal	4. Effective	Minimum requirement is to provide a Time recording with only this timetype for a Task. The sum of all effective Time XML elements in a Task is the total working time of that Task.
2. Intermediate	2. Preliminary 4. Effective 5. Ineffective 6. Repair 7. Clearing 8. Powered Down	Detection of main work allows for automatic recording of timetypes 2, 4, 5, and 7. The detection of main work may use work status information from the devices allocated to a Task. Timetype 6 may require operator entry and timetype 8 may be recorded automatically based upon information broadcasted on the implement bus.

Time - TIM Use Cases

PT9 Conformance Test Rules on interpreting TIM elements

Of an infinite TIM element only the attribute Start is considered. Embedded DataLogValues are ignored.
Details: if an infinite TIM element is the first within the task, it's Start is taken as start of the task. If an infinite TIM element is the last within the task, it's Start is taken as Stop of the task.
Background: the timestamp of the DataLogValues isn't defined. Furthermore the real life samples showed, that these values more often than not are corrupt.
Infinite TIM elements are not expanded to the next TIM element within the task.
Details: if a finite TIM element follows on the infinite TIM element is not expanded and given a duration.
Background: in case of a surprise shutdown at the end of the day and resume of the task on one of the next days the duration would have nothing to do with the real duration of the task.
Totals (DataLogValues) are taken from the chronologically last finite TIM element of the task.
TIM elements shall not overlap
Again: in focus are TIM elements with TIM.D <> "1" only.

Looking at the real life samples samples shows that there is no solution that would extract the best duration and DataLogValues in any situation. We tried to optimize for 'minimize error', 'simplicity of implementation' and 'reproducable, testable behavior'.

Use Case Type	Use Case Detail	ISO Implementation	ADAPT Type	ADAPT Implementation

Use Case Type	Use Case Detail	ISO Implementation	ADAPT Type	ADAPT Implementation
TIM - planned

ADAPT - ISO ASP - TIM Use Cases