ADAPT - ISO ASP - TIM Use Cases

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 TypeUse Case DetailISO ImplementationADAPT TypeADAPT 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.

  LookupValue
Self ConfTRUE  
Industry Group22Agriculture and Forestry Equipment
Device Class Instance0  
Device Class55Fertilizers
Reserved0 Equipment for applying mineral and/or organic fertilizers
Function128128Fertilizer Rate Control
Function Instance0 Control of the rate of product placed on or in the soil
ECU Instance0  
Manufacturer Code102102AGCO GmbH & Co. Marktoberdorf, Germany
Identity Number1067011  


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

		<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 TypeDefinition
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 DownStarts 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

 

LevelMICS supported TimeTypesDescription
1. Minimal  4. EffectiveMinimum 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

  1. 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.
  2. 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.
  3. Totals (DataLogValues) are taken from the chronologically last finite TIM element of the task.
  4. 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 TypeUse Case DetailISO ImplementationADAPT TypeADAPT Implementation
TIM - planned