SUBJECT
Fields | Type | Description | Purpose |
|---|---|---|---|
ID (identifier) | M | jobinstruction | GRAMMAR |
Subject Name | M | JobInstruction | GRAMMAR |
Subject Type | M | Process | GRAMMAR |
Also known as | O | workinstruction | TIC Description |
Definition | M | A job instruction is a collection of orders (something) that a source (system/someone) tells to subjects (system/someone/something/equipment) to do to an object (system/someone/something/equipment) in a coordinated way. | TIC Description |
Further Detail | O | Job Instruction includes any type of action and objects to be performed in the terminal, not only “move cargo”. It applies to actions like inspections, reefer plugin, re-allocation of equipment, recharge, repairs, maintenance, etc. The information on a job instruction is usually built over time. Basic information in which order it has to be done, the starting point and the Order object. Other information like the end position of the Order, the nominated subject that has to perform the Order and other details, could be added in later stages and can be updated/modified over time. Order vs Job Instruction vs Job Instruction List: “Order” (order) includes only one action (to do) to one object (i.e. plug in a reefer container, move a container from yard position A to yard position B) “Job Instruction” (jobinstruction) is a collection of Orders to the same object. These orders could be executed by different subjects but always over the same object. Orders are included in the same job instruction because they must be performed in a coordinated way (i.e. move a container by several machines from position A to final position C, repair a machine by several teams). In the simplest case, jobinstruction includes only one order (i.e. move a container from yard position A to yard position B as for above example). “Job Instruction List” (jobinstructionlist) is a collection of Job Instructions, that may comprise different objects and be executed by different subjects (i.e. list of reefer jobs to be performed in one area, list of yard moves to be executed, containers inspection list). Job instruction list are usefull when an execution sequence is required. In case several orders must be execute in a tight coordination (one subject works with another subject over the same object) then the orders should be part of the same jobinstruction and not a list. For example, when a container is discharged from a vessel to the yard, there will be an order for the STS to discharge from the vessel position to a position under the crane, and as a second step, an horizontal transport will execute the order to move the container from the position under the crane to a yard or transfer position. More orders to different or same subject could be still needed, until the container reaches the final planned position within the Job Instruction. “Job Instruction Pair” (jobinstructionpair): if several job instructions need to be coordinated because they are to be done simultaneously by the same subject over two different objects then the link must be indicated. I.e an STS twin move of 2x20' containers (2 objects → 2 orders but one subject). Job Instruction Start and End events:  jobinstruction.creation event happens in the moment that the id is assigned to the jobinstruction, so it has a way to identify itself. It could have only the basic info but needs it own identity. Usually it will include the action to be performed and the object but not the subject, when and where. jobinstruction.active status is "True" only when it is available for the source which has generated it (system/someone). The first time it is available would generate the starttimestamp event. jobinstruction.assigned status is "True" only when the subject in charge of doing the action is defined. The first time at least one order subject is defined would generate starttimestamp event. It may happen that the subject changes several times or even disappears then the jobinstruction.assigned.status would be false. jobinstruction.dispatched: (status) when at least one order subject has the specific order to do to an object. The first time at least one order is sent (dispatched) to a subject, it would generate starttimestamp event. jobinstruction.acknowledged (status) when the subject acknowledged it got the order. In most of the cases, dispatched and acknowledged happens at same time or within a very small time difference. It would generate starttimestamp (event) the first time the subject acknowledged it received the order. jobinstruction.start event happens when it is first dispatched jobinstruction.execution status is “true” between jobinstruction.start and jobinstruction.end jobinstruction.order.start event happens when the first of: the subject already has the jobinstruction dispatched and started the work (che.cycle.start or equivalent) or when the jobinstruction is “dispatch” = jobinstruction.start and the subject is waiting for instructions but ready to perform any job (che.idle or similar) jobinstruction.inprogress status is “True” between the first jobinstruction.order.start and the last jobinstruction.order.end jobinstruction.order.end event happens when the subject already has the jobinstruction “dispatch” and ends the specific object and action work (che.cycle.end or equivalent). jobinstruction.order.cancel: (event) is when the subject refuses or the source cancels the order. jobinstruction.end event happens when the last jobinstruction.order.end Job Instruction types: Action type (jobinstruction.type): is a closed list (could be extended)
Order Type (jobinstruction.typeaction): Cargo Move:
Service task:
Job Instruction objects (jobinstruction.object): jobinstruction.object
Job Instruction subject (jobinstruction.order.subject): Is the one that executes the order. As a job instruction can have many subjects this concept metadata is under “order”. | TIC Description |
Required Information | M | SUBJECT, CONCEPT; OBSERVED PROPERTY and VALUE | TIC Description |
SUBJECTS | tos; |
| |
CONCEPT |
| Id; loading; discharging; useful; unuseful; paid; unpaid; handling reason; start; end; active; inactive; idle; working. |
|
Related standards | O | TEU definition; Container definition; ISO 8601 | TIC Description |
Related TIC 4.0 definition | O | https://tic40.atlassian.net/l/cp/LeNbivFL https://tic40.atlassian.net/l/cp/k6Z2YJww https://tic40.atlassian.net/l/cp/PJ1TDr1z https://tic40.atlassian.net/l/c/3pujAL8E https://tic40.atlassian.net/l/c/0X0Ad1XR CHE | TIC Description |
Example | M | see below diagrams and drawings | TIC Description |
Example in the context of the grammar | M |  | DATA MODEL |
Link to one or more operational processes | M | Loading/unloading; gate operations, rail operations. | TIC Description |
Search tags | M | Technical | |
Version / Date | M | 2022.005 / 01.09.2022 | Technical |
Internal TIC Version | M | 20220727 | Technical |
M = Mandatory
O = Optional
Diagrams
(optional) add some process diagram which concept belongs
Created by | Edited by | Review / Approve | Published |
Gabriella Meduri | 01.09.2022 |