tos-equipment control interface standard · 5.1.3. job refinement during move 24 5.2. rtg operation...

TOS-EquipmEnT COnTrOlinTErfaCE STandard

This document from the Port Equipment Manufacturers Association (PEMA) proposes a standardised interface between terminal operating systems and

the equipment control systems for container handling equipment.

By developing standard communications protocols, PEMA aims to help reduce the time and cost required to implement and integrate the growing

number of software components now used in container terminal operations.

First published June 2014.

www.pema.org

2 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association

www.pema.org

http://www.pema.org

3TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association

contents 3 LIst of tabLes and fIgures 5

1. IntroductIon 6 1.1 document purpose 6 1.2 background to the project 6 1.3 development and support 6 1.4 disclaimer 6

2. background 7 2.1. terminal operating systems (tos) 7 2.2. container handling equipment (cHe) 7 2.3. equipment control systems (ecs) 7

2.3.1. Real-time position detection systems (PDS) 7

2.4. Yard layout specification and logical positions 8 2.5. Interactions between terminal operating system and cHe-ecs 10 2.6. tos interface standardization 12 3. sYsteM structure 13 3.1. tos and ecs 13 3.2. communication architectures 14 3.3. communication protocols 15 4. standard Interface specIfIcatIon 16 4.1. Job_order (tos > ecs) 17 4.2. Job_status (ecs > tos) 17 4.3. cHe_status (ecs > tos) 17 4.4. status_reQ (tos > ecs) 17 4.5. InVentorY_reQ (ecs > tos) 17 4.6. InVentorY_data (tos > ecs) 18 4.7. geoMetrY_reQ (ecs > tos) 18 4.8. geoMetrY_data (tos > ecs) 18 5. use case eXaMpLes 22 5.1. straddle carrier operation 22

5.1.1. Shuffle moves given by TOS 22

5.1.2. Shuffle moves not given/not given in advance 23

5.1.3. Job refinement during move 24

5.2. rtg operation 25 5.2.1. Truck loading 25

5.2.2. Truck unloading 26

5.3. asc operation 27 5.3.1. Move to stack 27

5.3.2. Move from stack 27

COnTEnTS

First published June 2014

This document is designated S01 in the PEMA publications list

© Port Equipment Manufacturers Association


www.pema.org

appendIX: Message / database structures 29 1. XML, sQL and binary message implementations 29 1.1. XML implementation 29

1.2. SQL implementation 29

1.3. Binary message implementation 29

2. Job_order (tos > ecs) 30

2.1. XML implementation 32



3. Job_status (ecs > tos) 36 3.1. XML implementation 37



4. cHe_status (ecs > tos) 40 4.1 XML implementation 40

4.2 SQL implementation 41

4.3 Binary message implementation 41

5. status_reQ (tos > ecs) 42 5.1. XML implementation 42



6. InVentorY_reQ (ecs >tos) 43 6.1. XML implementation 43



7. InVentorY_data (tos > ecs) 44 7.1. XML implementation 44



8. geoMetrY_reQ (ecs > tos) 45 8.1. XML implementation 45



9. geoMetrY_data (tos > ecs) 46 9.1. XML implementation 46



gLossarY of terMs 48 about tHe autHors & peMa 49

COnTEnTS

http://www.pema.org


LIst of tabLes Table 1. TOS-CHE messages/communication databases 18

Table 2. JOB_ORDER usage 18

Table 3. JOB_STATUS usage 19

Table 4. CHE_STATUS usage 20

Table 5. STATUS_REQ usage 20

Table 6. INVENTORY_REQ usage 20

Table 7. INVENTORY_DATA usage 20

Table 8. GEOMETRY_REQ usage 21

Table 9. GEOMETRY_DATA usage 21

LIst of fIgures Figure 1. Logical names in stack, top view 8

Figure 2. Logical names in stack, side view 8

Figure 3. Logical positions and vessel geometry 9

Figure 4. Typical straddle carrier job instruction and ‘pick/place’ reporting 10

Figure 5. Typical RTG job instruction 11

Figure 6. Job instructions for CHE that do not ‘pick’ or ‘place’ containers 12

Figure 7. TOS, CHE and ECS 13

Figure 8. Individual CHE connection to a TOS 14

Figure 9. TOS connection through a CHE fleet server 14

Figure 10. TOS connection through database 15

Figure 11. Standard interface structure, messages/databases 16

Figure 12. Straddle carrier operation, shuffle moves given by TOS 22

Figure 13. Straddle carrier operation, shuffle moves not given/not given in advance 23

Figure 14. Straddle carrier operation, job refinement during move 24

Figure 15. RTG operation, truck loading 25

Figure 16. RTG operation, truck unloading 26

Figure 17. ASC operation, move from stack 27

appendIX tabLes Table A1. JOB_ORDER message/data-item 30

Table A2. JOB_STATUS message/data-item 36

Table A3. CHE_STATUS message/data-item 40

Table A4. STATUS_REQ message 42

Table A5. INVENTORY_REQ message 43

Table A6. INVENTORY_DATA message 44

Table A7. GEOMETRY_REQ message 45

Table A8. GEOMETRY_DATA message 46

COnTEnTS


www.pema.org

1.1 DOCUMENT PURPOSEThis document from the Port Equipment Manufacturers Association (PEMA) proposes a standardised interface between terminal operating systems (TOS) and the equipment control system (ECS) for container handling equipment (CHE).

The goal is to improve software compatibility between TOS providers, CHE manufacturers, automation suppliers and end users (i.e. terminal operators). Better compatibility will result in reduced costs for development and maintenance of various automation software.

By publishing this open industry standard, PEMA aims to support the terminal industry and its suppliers in the drive to reduce the time and cost required to implement and integrate the growing number of software components now used in container terminal operations.

The standard therefore deals with the contents of the communication between systems and when this content needs to be shared. Currently, there is often misalignment on both, resulting in unnecessarily long implementation times and costs.

It is also hoped that this document can contribute to increased understanding of the processes behind the TOS-ECS interface and how to map these interfaces at a specific terminal.

1.2 BACKGROUND TO THE PROJECTPEMA initiated the standard interface project in 2012. Development was led by a dedicated Working Group on Software Interface Standardisation (SIS) formed as part of the Association’s Technology Committee (TC).

Members of the SIS Working Group included TOS suppliers, equipment manufacturers and providers of terminal process automation and equipment control technology. Terminal operators were also represented.

The genesis for the project was feedback from association members, and the industry at large, that lack of standardisation was impeding the timely and cost-effective adoption of advanced communications

and control technology in container terminals, at a time when various forms of automation were starting to proliferate.

The main project targets were to develop an open standard that would:• Be suitable for various equipment• Be suitable for manned and unmanned

operations• Have enough flexibility to adjust for different

operation disciplines• Cover typical functionalities of various terminal

operating systems• Provide typical options for different

communications architectures• Provide typical options for different protocoll

implementations• Be scalable, with light minimum implementation

The interface project does not try to standardise the operation of the underlying prorietary systems themselves, but rather to provide standardised communication protocols between the various TOS and ECS systems available today.

1.3 future deVeLopMent and supportPEMA intends to develop the interface standard further over time based both on industry feedback, which is greatly encouraged, as well as on changing implementation needs.

For further information on adopting the standard and/or to provide feedback, please in the first instance contact the PEMA Secretariat at [email protected]

1.4 dIscLaIMer

This document does not constitute professional advice, nor is it an exhaustive summary of the information available on the subject matter to which it refers.

Every effort is made to ensure the accuracy of the information, but neither the authors, PEMA nor any member company is responsible for any loss, damage, costs or expenses incurred, whether or not in negligence, arising from reliance on or interpretation of the data.

1| inTrOduCTiOn

http://www.pema.org

mailto:[email protected]


2.1. terMInaL operatIng sYsteMsTerminal operating system software controls the logistics of a terminal, including key functions such as vessel planning, container inventory maintenance, job order creation and gate operations. TOS software is provided by several commercial companies and many terminal operators themselves.

Interfacing software for items such as equipment control systems (ECS) for cranes and other container handling equipment (CHE) and real-time position determination systems (PDS), used for tracking equipment/container moves in the yard stacks, is programmed by several automation providers and CHE manufacturers. These software packages need to communicate correctly with each other.

Currently, the communication protocols are highly vendor-specific. The implementation and maintenance of software is thus time-consuming and costly.

This document therefore proposes a neutral, open standardised interface between TOS and CHE-ECS systems. Better interface compatibility will result in reduced development and maintenance time/cost for various automation software.

The standard is intended to be completely vendor-neutral and has no impact on the selection of a particular technology/equipment provider, or set of providers. However, application-specific interface extensions are included in order to allow for flexibility.

2.2. contaIner HandLIng eQuIpMentIn this document, container handling equipment (CHE) refers to all physical vehicles that move the containers inside a container handling terminal. These vehicles typically include:

• Rail-mounted gantry cranes, manned and automated (RMG, ARMG/ASC)

• Rubber tyred gantry cranes (RTG)• Ship-to-shore cranes (STS)• Straddle carriers (SC)• Horizontal transport such as automated guided

vehicles (AGV)• Reach stackers (RS)• Llft trucks (LT)

• Terminal tractors (TT)• Hand-held terminals (with some limited

functionality) are also included in scope

CHE may be manually operated or unmanned and operated by a computer and navigation system (e.g. ASCs, AGVs). Viewed at high level, these modes of operation do not differ in principle. However, some differences do exist since human drivers of the vehicles may improvise container moves, while computers do not.

2.3. eQuIpMent controL sYsteMsAll modern CHE are today equipped with a computer system and software controlling the operation of vehicle actuators, etc. In some cases, a group of vehicles share a common software control module, handling for example safety features and intra-vehicle coordination. Typically, automated vehicles operating on the same tracks, such as ASCs, are coordinated by common software.

An equipment control system (ECS) is defined here as the software that monitors and controls all events and processes at equipment level, either for a single CHE or group of CHE. Especially when it comes to coordinating interactions between different types of automated equipment, an ECS is now an essential part of the terminal software landscape.

2.3.1. reaL-tIMe posItIon detectIon sYsteMs Today, CHE are often equipped with a real-time location system, e.g. DGPS, which enables automatic tracking of container moves in container terminal.

Knowing the location of each CHE also enables effective use of the vehicle fleet, for instance minimising travelling distances, empty travelling and waiting time. Position detection systems (PDS) can thus be regarded as belonging to the ECS layer.

In the case of a manned CHE, the dialogue with the TOS was traditionally handled by the driver, who would confirm completed container moves using a keyboard or other similar system. Today, the reporting of container moves is often automatic, handled by the on-board computer of the CHE. The reporting is typically triggered by the turning of the twist-locks. The

2| OvErviEw


www.pema.org

benefit of PDS-based computerised operation is that human reporting errors are avoided. Implementations have also been made to prevent drivers from leaving containers in the wrong positions.

A ‘twistlock-blocking’ feature compares the PDS position to the job order received from the TOS and only allows twistlocks to be released if the position conforms to the plan. PDS and navigation systems are naturally a basic requirement of an unmanned CHE (e.g., ASC, AGV).

Along with the increasing automation development, machine-to-machine (M2M) communication protocols have also become a basic requirement for modern TOS technology. In this document, no separation is made between manned and unmanned CHE regarding the interaction between the TOS and CHE-ECS. Instead, a generalised communication scheme is used.

2.4. Yard LaYout specIfIcatIon and LogIcaL posItIonsIt is common for TOS-ECS communication to refer to container positions using logical names. A logical name is typically a combination of container ‘ground slot’ name and ‘tier number’ (height in stack).

A logical name within yard areas is normally a combination of:• Name of the container block• Row identifier• Bay identifier• Tier number

In a vessel, the logical name is typically a combination of:• Carrier name• Bay identifier• Deck identifier• Stack name• Tier number

figure 1: Logical names in stack, top view

figure 2: Logical names in stack, side view

CHAPTER 2: OVERVIEW CONTINUED

http://www.pema.org


In a train, the logical name is typically a combination of:• Railcar name• Well identifier• Stack name• Tier number

The bay numbers are often coded differently for 20ft and 40ft containers. The 20ft containers may for example use odd numbers, while 40ft containers (occupying two 20ft slots) use even numbers (see Figure 1 and Figure 2 opposite). The naming convention is usually decided by the terminal operator.

Logical names are also used for other locations in the yard, such as the lanes under ship-to-shore (STS) cranes (see figure 3 below), RTG and RMG

truck lanes, exchange slots (SC, ASC), STS lashing platforms and for other well-defined areas in the terminal.

In general, it is assumed that the container’s logical position is represented by a well-defined character string, which the TOS is able to recognise as one of the storage locations for the container and which the PDS is able to decode based on the positioning system measurements.

The relation between logical names and geometrical coordinates is normally assumed to be constant and known by the PDS system. In special cases, explicit geometrical coordinates (xyz) may be used. A logical name can also refer to a vehicle like a terminal tractor,

figure 3: Logical positions and vessel geometry



www.pema.org

e.g. “TT02”, in which case there must be a reliable system for identifying and distinguishing the vehicles from each other.

In some applications it may be necessary to request geometrical xy-locations from the TOS. These applications include automated STS cranes handling vessels or automated RMG cranes handling trains, where the relation between logical names and geometrical coordinates is not known a-priori, since the vessels and trains have variable geometry (see Figure 3 on previous page).

2.5. InteractIons between tHe tos and cHe-ecs

When interacting directly with CHE, the TOS has two main functions:

• To maintain a correct container inventory i.e. record all container moves that are reported by the CHE

• To control (and optimise) the operation of the CHE fleet by giving job orders to CHE. Optimisation can also be performed by ECS software

The first item should be independent of the other i.e. container moves should be recorded even if the moves have not been commanded by the TOS and also if the container moves are executed differently than instructed by the TOS.

Recording container moves is traditionally implemented using so-called ‘pick’ and ‘place’ messages, which are sent by CHE when the twistlocks are operated on a container.

These messages include the name of the actual container slot or other logical position (e.g. STS lane) where the operation was performed. In some applications a pick-message is also used to request a job order for a container that was picked by a driver without a specific job order (e.g. so-called ‘shuffle moves’).

It should be noted that generally a PDS is not able to identify the moved container by itself, but only to specify the position (e.g. container slot) from where the container was picked (see Figure 4 below). This information may be used by the TOS to indirectly

figure 4: typical straddle carrier job instruction and ‘pick/place’ reporting


http://www.pema.org


identify the container. Some dedicated systems may identify the container directly, for instance by using camera-based technology (OCR).

Giving transport orders to the CHE fleet is normally implemented by the ‘job instruction’ or ‘job-list’ messages. A ‘job instruction’ specifies which container will be picked from which location and to which location it should be transported (see Figure 5 below). The location may be for instance a container slot, exchange area, trailer, truck or loading lane under the STS.

‘Job-list’ is a general concept, which means that CHE are given a set of job instructions (instead of just one) and have certain freedom to choose which job to execute first. Job-lists are needed in cases such as when the driver of an RTG is waiting for several trucks/trailers, but it is not known in which order they will finally arrive and be served.

In this case, one of the logical positions may refer to a truck or trailer. A PDS, although able to recognise a pick from a truck lane, is generally not able to identify the individual truck or trailer, at least without the help of an additional recognition system, such as RFID.

If no automatic recognition system is available, the RTG driver may identify the container by ‘activating’ the individual job from the job-list using a dedicated computer screen.

Similarly, job-lists (or work-lists) are typically used for STS cranes. During the discharge of a vessel, for example, real-time pick-reports from the STS (indicating the actual pick-slot) are matched to the job-list and the corresponding jobs thus marked as completed.

Finally, job-lists (or work-lists) may be assigned to the equipment control system (ECS), which may then internally optimise the scheduling of the jobs and selection of the CHE.

Job instructions for terminal tractors (TT) and (non-lift) AGVs are simplified versions of the basic job instruction. Since these CHE do not actively ‘pick’ or ‘place’ containers, the job instruction only includes the logical goal position to where the CHE should move (see Figure 6 on next page).

Intermediate target positions along the trajectory

figure 5: typical rtg job instruction



www.pema.org

may be introduced by the TOS, by giving several job instructions in sequence (e.g. queuing for STS cranes). Alternatively, the ECS may take care of this.

Job instruction execution for equipment such as STS cranes may be modified according to application needs. One such special application is a lashing platform, where the double-twistlocks attached to the container bottom for securing the cargo are installed/removed. If the container lifted from the vessel is placed on a special lashing platform (container landing-position = “lashing platform”), the spreader twist-locks are not necessarily opened before the next job instruction (“move the container to ground”).

2.6. tos Interface standardIsatIonThis initiative aims to standardise the logical communication interface between TOS and CHE-ECS, rather than in any way standardising the operation of TOS or ECS themselves.

The interface is intended to support commonly used concepts and variable practices, thus allowing for flexible implementation in container handling operations.

The following areas are vendor-specific and therefore not in the scope of this standard:

• Driver interfaces (GUI) in CHE• Positioning technology used in CHE• Container identification technology (e.g. OCR)• Trailer/truck identification technology (e.g. RFID)• Internal operation or optimisation algorithms of the TOS

Typical optimisation algorithms of a TOS include items such as:• Deciding the optimal storage positions for containers• Selection of CHE to handle container moves

figure 6: Job instructions for cHe that do not ‘pick’ or ‘place’ containers (tt, agV)


http://www.pema.org


3.1. tos and ecsDue to the number of system providers and developers, there are of course differences between the functionalities of different TOS software.

There is also a growing trend towards automation, introducing driverless CHE in ports. Driverless operation requires dedicated software to implement all the actions and decisions (such as navigation, traffic rules and deadlock resolution) previously executed by humans. As a result, driverless operations require a layer of additional functionality between the CHE on-board control software system (e.g. PLC) and the TOS software.

This layer is sometimes called ‘middleware’ and forms a part of the equipment control system (ECS). ECS is defined here as the software that monitors and controls all events and processes at equipment level. PDS/RFID systems may be considered as a part of ECS.

Figure 7 below illustrates the concept of ECS and

middleware. In some cases, the TOS is directly connected, via parallel communication links, to individual CHE. In some cases, especially for automated CHE, special software is needed for functions such as route planning, deadlock resolution and safety features.

Some functions are normally identified with the TOS:• Maintaining a container inventory of the yard• Creation of transport orders• Planning the yard positions for containers• Vessel and rail planning• Gate appointments

However, there are other functions which are sometimes implemented by the ECS, or by the CHE driver when equipment is manned:• Scheduling the order and time of transport• Selection of CHE to execute a particular transport order• CHE sequencing• Decking for ‘shuffle’ containers

The purpose of this standard is to support these

3| SYSTEm STruCTurE

figure 7: tos, cHe and ecs


www.pema.org

different alternatives without giving any preference between them.

3.2. coMMunIcatIon arcHItecturesThe physical transmission path between the CHE-ECS and TOS layers may be implemented in various ways. This includes wireless (e.g. WLAN) and cabled segments (e.g. LAN, serial connection RS-232).

The architectural solutions found in existing systems may be divided in two categories: MESSAGING and DATABASE architectures. MESSAGING architectures have themselves been implemented in two ways. Either a CHE has an individual connections to the TOS, or the TOS connects through a CHE fleet server (ECS).

Figure 8 describes connecting individual CHE directly to a TOS via a proper communication link. In this case, due to the architecture, the TOS always decides which CHE will execute the container move and middleware is non-existent.

Figure 9 describes connection through a dedicated CHE fleet server. In this case it would be possible that the CHE fleet server (ECS) decides and optimises which CHE will execute the container move.

Figure 10 describes the TOS connection through a database. In this case there may be several job instructions waiting for execution in the database. It is thus possible that the ECS controlling the CHE fleet will decide and optimise the ordering and timing of job execution.

While the first two architectures describe the interaction between TOS and CHE-ECS as “message-passing”, this third option is implemented in practice by read/write request to a common database (e.g. SQL/ ODBC).

The ownership of the databases (TOS/ECS) should be agreed during project planning phase, and related system recovery and resiliancy facilities addressed.The purpose of this standard is to support all these

figure 9: tos connection through a cHe fleet server

figure 8: Individual cHe connection to a tos

CHAPTER 3: SYSTEM STRUCTURE CONTINUED

http://www.pema.org


architecture alternatives without giving any special preference between them.

3.3. coMMunIcatIon protocoLsThis standard separates interface technology types (protocols) from the data to be shared. Chapter 4 first describe the logical contents of the messages/databases. Later, different interface technology types to implement data sharing are introduced.

The communication protocols may include various low-level transmission layers (e.g. TCP/IP). It is assumed in the following standard that a

physical transmission path and necessary low-level transmission protocols exist for data transfer between the ECS and TOS, possibly providing built-in error-detection and re-transmission mechanisms. Especially, if the communication link between CHE and TOS/ECS is temporarily lost, CHE shall store and later re-transmit all ‘pick’ and ‘place’ events.

The transferred data may be in form of ASCII-characters or binary data. Three alternative implementations based on XML, SQL and binary messages are defined.

figure 10: tos connection through a database

CHAPTER 3: SYSTEM STRUCTURE CONTINUED


www.pema.org

4| STandard inTErfaCE SpECifiCaTiOnIn order to enable scalable and yet light minimum implementation, many of the specified transactions and features are optional. In order to implement this standardised interface, users need to:• Define which optional transactions are used. These options are listed in Tables 2 -9 • Define the logical naming convention used in the port/terminal (see Chapter 2.4)• Define which optional fields of the selected messages/transactions are used (see Appendix)

There are three options for physical communication architecture:

1. Individual connections to the TOS2. Connection through a CHE server3. Database connection

As outlined in Chapter 3, the choice of communication architecture does not affect the logical message/ database contents. However, some ECS functionality (e.g. free choice of CHE) may be disabled.

The PEMA standard covers three defined options for communication protocols:

1. XML messages

2. Database interactions3. Binary messages

Please see Appendix for more details. The choice of protocol does not affect functionality or logical contents.

A minimum implementation of this interface is intentionally light. For instance, only three messages/interactions are required for a minimum straddle carrier operation:• Job order (JOB_ORDER(1)), Table 2 (p.18)• Pick container (JOB_STATUS(4)), Table 3 (p.19)• Place container (JOB_STATUS(9)), Table 3 (p.19)

The user may start with minimum implementation and check if this satisfies all the operating scenarios while enabling all the functionalities provided by the TOS. In cases where some features are not covered by the minimum implementation, the user may add pre-defined optional messages as needed.

The goal of the specification is to provide equal data structures for the three communication architectures presented in Chapter 3.2. Table 1 messages (p.18) are thus equivalent to databases of the same structure.

figure 11: standard interface structure, messages/databases

http://www.pema.org


The generic messages/communication databases are specified below. The messages and databases are further illustrated in Figure 11 opposite.

While there is a direct correspondence between the three first messages and communication databases of Table 1 (p.18), the database containing yard container inventory is internal to the TOS. It is normally thus only accessible through a messaging-type of interface (INVENTORY_DATA, GEOMETRY_DATA).

The basic messages and databases are briefly described in the following chapters. The exact structures of messages/ databases are specified in the Appendix.

4.1. Job_order (tos -> ecs)The JOB_ORDER message/ database is used by the TOS to command new transport orders or cancel transport orders previously given.

Depending on the application, shuffle-move orders are issued by TOS immediately (e.g. ASC) or only after a request from CHE (e.g. RTG). A re-try of a job order may be commanded, in case job execution failed (e.g. ASC).

The following general job order types may be used in different applications:• New job order (inc. move orders for TT and AGV)• Cancel or replace job orders• Shuffle move (in case not sent originally)• Re-try of (failed) job, especially in automatic operations

The job orders may be directed to specific CHE, or the CHE may be not specified, depending on the application. It is possible to create job-lists by issuing several job orders in sequence, either to a specific CHE (e.g. RTG job-list) or to a job ‘pool’, to be freely selected by CHE (ECS). Double-trolley STS cranes are treated as two independent CHE i.e. both trolleys receive their own job orders.

4.2. Job_status (ecs ->tos)The JOB_STATUS message/database is used by CHE to report the execution of given jobs.

The job status report includes items such as:

• Start/finish of a specific job, activation of a job (e.g. RTG driver chooses job from job list; shuffle moves possibly needed)• Approaching pick/ place position• Container pick/place action, container identification e.g. with OCR• Request place position for picked container (e.g. shuffle move)• Container landed (e.g. for lashing or OCR platforms), twistlocks still closed, to be moved further• Error in job order or execution

The various alternatives listed above are not needed in all applications, or their status information may be combined. In some applications, for instance straddle carriers, the minimum reporting of container pick and place may be sufficient.

The actual pick and place positions may be different than in the corresponding JOB_ORDER. This is possible especially in manual operation or during tele-operated moves in automatic operation.

JOB_STATUS messages can be issued by CHE without a corresponding JOB_ORDER. This situation happens for example when manual CHE drivers make improvised container moves.

4.3. cHe_status (ecs -> tos)The CHE_STATUS message/database is used by CHE to report their general status, regardless whether they are executing a job at that time. The status functionality can be used for reports such as:

• ‘Heartbeat’ function (if regular heartbeat is desired for monitoring)• CHE location and availability information• Request for a new job order (if new orders are not sent automatically)

4.4. status_reQ (tos -> ecs)The TOS may use this command to actively request the status of a CHE.

4.5. InVentorY_reQ (ecs -> tos)This message is used by CHE-ECS to request stack population (container count) in a specified logical position in the yard, on a vessel or train. This information

CHAPTER 4: STANDARD INTERFACE SPECIFICATION CONTINUED


www.pema.org

may be used by ECS for safety checking, trajectory planning or navigation support.

4.6. InVentorY_data (tos -> ecs)This message reports current stack population (container count) in a specified position in yard, vessel or train to the CHE-ECS. This information may be used for safety checking by the ECS, trajectory planning or navigation support.

4.7. geoMetrY_reQ (ecs -> tos)Used by CHE-ECS to request geometrical data for

vessels and trains, where the knowledge of logical names and their relation to xy-coordinates is not known a-priori.

4.8. geoMetrY_data (tos -> ecs)This message is used to report vessel or train geometry. When the GEOMETRY_REQ command is received, the geometrical coordinates of all ground slots in a vessel or train are reported with their corresponding logical names. Several GEOMETRY_DATA messages are thus generated, one for each ground slot.

Type Description Required Optional Trigger

1 New job order • Decided by TOS

2 Cancel job order • Decided by TOS

3 Cancel all job orders for this CHE • Decided by TOS

4 Replace job order • Decided by TOS

5 Shuffle move •JOB_STATUS(2) or

JOB_STATUS(4) or

JOB_STATUS(6)

6 Re-try (failed) job •Decided by TOS,

after failure report

JOB_STATUS(11)

Message DatabaseTOS

writesTOS

readsCHE/ECS

writesCHE/ECS

reads

JOB_ORDER JOB_ORDER • •JOB_STATUS JOB_STATUS • •CHE_STATUS CHE_STATUS • •STATUS_REQ • •INVENTORY_REQ • •INVENTORY_DATA • •GEOMETRY_REQ • •GEOMETRY_DATA • •

table 1: tos-cHe messages/communication databases

table 2: Job_order usage


http://www.pema.org



1 Start of job (e.g. ASC) • CHE started job execution

2 Activate job (e.g. RTG) • CHE selects a job from job list

3 Approach pick (e.g. SC) •CHE approaches a predetermined

zone (e.g. row)

4 Container picked •See note 1

CHE picks up a container

5Container identification

(e.g. STS OCR) •Picked container is identified.

Identity can also be reported with

“Pick container”

6Place position request

(e.g. RTG shuffle move) •CHE picks up a container

with no target known

7Approach place

(e.g. SC) •CHE approaches a predetermined

zone (e.g. row)

8Container landed

(e.g. on lashing/OCR platform) •Spreader landing pins activated

(but twist-locks still closed)

9 Container placed •See note 1

CHE places down a container

10Job finished

(e.g. ASC, AGV or TT)•

See note 2

CHE finished job execution (e.g.

AGV arrive at goal location)

11Error in job execution

(e.g. ASC or AGV) •E.g. logical name not known

or container not found

table 3: Job_status usage

Note 1: Message no 4 (‘Container picked’) and message no 9 (‘Container placed’) are for CHE that actively pick and place containersNote 2: Message no 10 (‘Job finished’) is required for other CHE (TT, AGV)

table 3 notes



www.pema.org


1 Status by heartbeat • Sent at regular intervals

2 Status by TOS request • STATUS_REQ

3New job order request

(e.g. SC) •

CHE is ready for new job order.

New orders can also be sent

automatically e.g. after

JOB_STATUS(9), (“place”).


1Request status of a particular

CHE • Decided by TOS


1 Request stack population • Decided by CHE


1Stack population data at

specified logical position • INVENTORY_REQ

table 4: cHe_status usage

table 5: status_reQ usage

table 6: InVentorY_reQ usage


table 7: InVentorY_data usage

http://www.pema.org



1 Request vessel geometry data • Decided by CHE

2 Request train geometry data • Decided by CHE


1Geometry data of vessel or train

(N messages) • GEOMETRY_REQ


table 8: geoMetrY_reQ usage

table 9: geoMetrY_data usage


www.pema.org

5.1. straddLe carrIer operatIon

5.1.1. straddLe carrIer sHuffLe MoVes gIVen bY tos

This sequence describes a situation where container “T” is retrieved by a straddle carrier (SC) from the stack and loaded, for instance onto a truck. Since container T is under another container, “S”, the topmost container, has to be moved first (shuffle move).

In this implementation, the TOS sends the shuffle move instruction first and specifies the exact landing location for container “S”.

In this implementation, only one job command at a time is sent to the SC, and the next command is sent immediately after the SC has placed the previous container. No additional acknowledgement of job finish is issued. No additional request for a new job order is issued.

5. uSE CaSE ExamplES

figure 12: straddle carrier operation, shuffle moves given by tos

http://www.pema.org


5.1.2. straddLe carrIer sHuffLe MoVes not gIVen / not gIVen In adVance

This is basically the same situation as in 5.1.1. However, here the TOS is not specifying the place location for the shuffle container “S”. Typically, the driver will then decide the location freely.

The new actual location for container “S”, however, must always be reported to the TOS.

Optionally, the TOS may also issue a place location for container “S” when the container is picked by the SC.

figure 13: straddle carrier operation, moves not given / not given in advance

CHAPTER 5: STRADDLE CARRIER OPERATION USE CASE CONTINUED


www.pema.org

5.1.3. straddLe carrIer Job refIneMent durIng MoVe

In some TOS implementations, the job order may be refined when straddle carriers approach the target location.

This is especially useful in situations where several SCs are stacking containers on top of each others, but it can not be predicted which SC will arrive first at the target slot location. In this situation, the target Tier number, for instance, may be decided at the last possible moment.

CHAPTER 5: STRADDLE CARRIER OPERATION USE CASE CONTINUED

figure 14: straddle carrier operation, job refinement during move

http://www.pema.org


5.2. rtg operatIon

5.2.1. truck LoadIngIn RTG operations, several job orders may be issued at the same time (job list), since there may be several trucks entering through the terminal gate simultaneously and it is not known in advance which of them will reach the stack first.

The execution of the job at the RTG is therefore triggered by the arrival of the truck at the stack. At this stage, it may be necessary to inform the TOS which truck has arrived i.e. which job should be processed first (job “activation”). This may be required in situations such as that described by Figure 15, where the truck requests container “B” and a shuffle move has to be generated for the topmost container “A”.

Alternatively, in some implementations, shuffle moves (i.e. location for container “A”) are decided by the RTG driver and the TOS only needs to record the new position for container “A”. The original job order for container “A”, however, must be re-issued because of the changed slot position.

figure 15: rtg operation, truck loading

CHAPTER 5: RTG OPERATION USE CASE


www.pema.org

5.2.2. truck unLoadIng

In the RTG truck unloading process, shuffle moves are not needed and the operation is more straightforward. However, it is necessary to inform the TOS which job is processed, so that the identity of the moved container is correctly declared to the TOS.

This can either optionally be done by the “activation” message, or this information could also be incorporated in the “pick” message. An optional re-planning for container “A” place position may be necessary if the original place positions of containers “A” and “B” were on top of each other.

figure 16: rtg operation, truck unloading

CHAPTER 5: RTG OPERATION USE CASE CONTINUES

http://www.pema.org


5.3. asc operatIon

5.3.1. MoVe to stackDespite the dfferent layout of yard equipment such as end-loading ASCs and RTGs, the operation sequence can be similar to Chapter 5.2.2. In ASC applications, however, additional status reporting may be required (see Chapter 5.3.2 and Table A2).

5.3.2. MoVe froM stackMoving containers out from an ASC stack may follow the same sequence as in Chapter 5.2.1. However, the shuffle moves may often be planned in advance by the TOS and the sequence described in Figure 17 may be implemented. Additional optional status reporting is also illustrated. Please note that it is not always possible to plan the shuffle moves in advance (see Chapter 5.2.1).

CHAPTER 5: ASC OPERATION USE CASE

figure 17: asc operation, move from stack


www.pema.org

http://www.pema.org


1. XML, sQL and bInarY IMpLeMentatIonsIn order to enable flexible utilization of the standard interface, implementation for three different communication protocols are defined. These are:• XML message implementation• SQL database implementation• Binary message implementation

1.1. XML IMpLeMentatIonXML messages are defined in XML schema format. Some fields in the XML message are mandatory, while other fields are optional (minOccurs = “0”). The following common XML-types are defined to support XML-implementation:

<xs:simpleType name =“contsizeType”> <xs:restriction base=“xs:string”> <xs:enumeration value=”none”/> <xs:enumeration value=”20ft”/> <xs:enumeration value=”40ft”/> <xs:enumeration value=”45ft”/> <xs:enumeration value=”2x20ft”/> <xs:enumeration value=”USER_DEFINED_1”/>… <xs:enumeration value=”USER_DEFINED_N”/> </xs:restriction></xs:simpleType>

<xs:simpleType name= “containeridentificationType”> <xs:restriction base=“xs:string”> <xs:enumeration value=”not_identified”/> <xs:enumeration value=”identified_by_driver”/> <xs:enumeration value=”OCR”/> </xs:restriction></xs:simpleType>

1.2. sQL IMpLeMentatIon

SQL data tables are defined for database implementation. New table elements are inserted using SQL “INSERT INTO” command. Existing table elements are modified using the SQL “UPDATE” command.

Obsolete table elements are removed using SQL “DELETE” command. Only one party will write a particular table (see Table 1). This party is also responsible for creation of the corresponding table using SQL “CREATE TABLE” command, and for deletion of obsolete data items (such as executed job orders).

1.3. bInarY Message IMpLeMentatIonBinary message formats are defined using c-language syntax. Hardware-independent data types (char, uint16, uint32) are defined to ensure compatibility between different computer platforms.

Binary messages are framed (0xff/0xfe) and 16 bit crc-checking is used. The 16 bit crc-bytes are calculated according to CRC-16-ANSI standard (polynomial 0x8005).

In order to keep the messages compact, most of the fields in the binary messages are optional. The message

appEndix:mESSagE / daTabaSE STruCTurES


www.pema.org

lengths may thus be variable. Message length is indicated by “msg_len“field in the message header (total length in bytes). The optional fields which are included in the messages are indicated using a “flag_field” bit mask in the message header. It is thus possible to include any combination of the optional fields. However, the order of the fields is fixed.

When the low-level communication protocol does not provide error checking message re-transmission, acknowledge messaging can be used. A common acknowledge message is defined as follows:

typedef struct{ char start_of_message; //0xff unsigned char msg_len; //7 (bytes total) unsigned char msg_type; //0=acknowledge unsigned char msg_number; //running number char crc_msb; char crc_lsb; char end_of_message; //0xfe} ACK_MSG

An acknowledge message shall be sent for each received actual message using the same “msg_number“ in the reply. If the sender does not receive the acknowledge message, the actual message is re-transmitted for N times.

2. Job_order (tos > ecs)

FIELD DESCRIPTION TYPE

JOB_ID Running number LONG INTEGER

JOB_TYPE

1 = New job order

2 = Cancel job order

3 = Cancel all job orders for this CHE

4 = Modify job order

5 = Shuffle move

6 = Re-try (failed) job

INTEGER

CHE_ID Specifies the CHE, optional INTEGER

CONTAINER_ID_1 Container ID STRING

CONTAINER_ID_2 (Twin-lift) STRING

CONTAINER_ID_3 (Quad-lift) STRING


CONT_SIZE Container size, twin- or quad-lift STRING

HEIGHT_1 Container height (mm) INTEGER

HEIGHT_2 (Twin-lift) INTEGER

table a1: Job_order - message/data item

APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES

http://www.pema.org



HEIGHT_3 (Quad-lift) INTEGER

HEIGHT_4 (Quad-lift) INTEGER

WEIGHT_1 Container weight (Kg) INTEGER

WEIGHT_2 (Twin-lift) INTEGER

WEIGHT_3 (Quad-lift) INTEGER

WEIGHT_4 (Quad-lift) INTEGER

FROM_SLOT Pick-position, not used for AGV or TT movesLogical name (slot, area, truck,

vessel, train)

FROM_XUsed in case logical position not defined (mm) , not

used for AGV or TT movesINTEGER

FROM_YUsed in case logical position not defined (mm) , not

used for AGV or TT movesINTEGER

TO_SLOT Place-position (or goal position for AGV, TT)Logical name (slot, area, truck,

vessel, train)

TO_X Used in case logical position not defined (mm) INTEGER

TO_Y Used in case logical position not defined (mm) INTEGER

BLOCKING Twistlock-blocking on, off

ORDER_TIME Order creation/update time Date and time

PRIORITY Job priority, optional INTEGER

START_EARLIEST Earliest starting time, optional Date and time

FINISH_LATEST Latest finish time, optional Date and time

TRUCK_ID_FROM Truck license plate or ID STRING

TRUCK_TYPE_FROM Internal/ external/ other type INTEGER

TRUCK_LENGTH_FROM Chassis length (for automatic truck handling) INTEGER

TRUCK_HEIGHT_FROM Chassis height (for automatic truck handling) INTEGER

TRAILER_LOC_FROMContainer(s) location on trailer

(e.g. ISO Bay scheme)INTEGER

TRUCK_ID_TO Truck license plate or ID STRING

TRUCK_TYPE_TO Internal/ external/ other type INTEGER

TRUCK_LENGTH_TO Chassis length (for automatic truck handling) INTEGER

TRUCK_HEIGHT_TO Chassis height (for automatic truck handling) INTEGER

TRAILER_LOC_TOContainer(s) location on trailer

(e.g. ISO Bay scheme)INTEGER



www.pema.org

2.1. Job_order (tos > ecs) XML IMpLeMentatIon

<?xml version=”1.0”?><xs:schema><xs:element name=”JOB_ORDER”> <xs:complexType> <xs:sequence> <xs:element name=”JOB_ID” type=”xs:integer”/> <xs:element name=”JOB_TYPE” type=”xs:integer”/> <xs:element name=”CHE_ID” type=”xs:integer” minOccurs=”0”/> <xs:element name=”CONTAINER_ID_1” type=”xs:string”/> <xs:element name=”CONTAINER_ID_2” type=”xs:string” minOccurs=”0”/> <xs:element name=”CONTAINER_ID_3” type=”xs:string” minOccurs=”0”/> <xs:element name=”CONTAINER_ID_4” type=”xs:string” minOccurs=”0”/> <xs:element name=”CONT_SIZE” type=”xs:contsizeType”/> <xs:element name=”HEIGHT_1” type=”xs:integer” minOccurs=”0”/> <xs:element name=”HEIGHT_2” type=”xs:integer” minOccurs=”0”/> <xs:element name=”HEIGHT_3” type=”xs:integer” minOccurs=”0”/> <xs:element name=”HEIGHT_4” type=”xs:integer” minOccurs=”0”/> <xs:element name=”WEIGHT_1” type=”xs:integer” minOccurs=”0”/> <xs:element name=”WEIGHT_2” type=”xs:integer” minOccurs=”0”/> <xs:element name=”WEIGHT_3” type=”xs:integer” minOccurs=”0”/> <xs:element name=”WEIGHT_4” type=”xs:integer” minOccurs=”0”/> <xs:element name=”FROM_SLOT” type=”xs:string”/> <xs:element name=”FROM_X” type=”xs:integer” minOccurs=”0”/> <xs:element name=”FROM_Y” type=”xs:integer” minOccurs=”0”/> <xs:element name=”TO_SLOT” type=”xs:string”/> <xs:element name=”TO_X” type=”xs:integer” minOccurs=”0”/> <xs:element name=”TO_Y” type=”xs:integer” minOccurs=”0”/> <xs:element name=”BLOCKING” type=”xs:boolean” minOccurs=”0”/> <xs:element name=”ORDER_TIME” type=”xs:dateTime” minOccurs=”0”/> <xs:element name=”PRIORITY” type=”xs:integer” minOccurs=”0”/> <xs:element name=”START_EARLIEST” type=”xs:dateTime” minOccurs=”0”/> <xs:element name=”FINISH_LATEST” type=”xs:dateTime” minOccurs=”0”/> <xs:element name=”TRUCK_ID_FROM” type=”xs:string” minOccurs=”0”/> <xs:element name=”TRUCK_TYPE_FROM” type=”xs:integer” minOccurs=”0”/> <xs:element name=”TRUCK_LENGTH_FROM” type=”xs:integer” minOccurs=”0”/> <xs:element name=”TRUCK_HEIGHT_FROM” type=”xs:integer” minOccurs=”0”/> <xs:element name=”TRAILER_LOC_FROM” type=”xs:integer” minOccurs=”0”/> <xs:element name=”TRUCK_ID_TO” type=”xs:string” minOccurs=”0”/> <xs:element name=”TRUCK_TYPE_TO” type=”xs:integer” minOccurs=”0”/> <xs:element name=”TRUCK_LENGTH_TO” type=”xs:integer” minOccurs=”0”/> <xs:element name=”TRUCK_HEIGHT_TO” type=”xs:integer” minOccurs=”0”/> <xs:element name=”TRAILER_LOC_TO” type=”xs:integer” minOccurs=”0”/> </xs:sequence> </xs:complexType></xs:element></xs:schema>


http://www.pema.org


2.2. Job_order (tos > ecs) sQL IMpLeMentatIon

CREATE TABLE JOB_ORDER( JOB_ID int, JOB_TYPE int, CHE_ID int, CONTAINER_ID_1 varchar(255), CONTAINER_ID_2 varchar(255), CONTAINER_ID_3 varchar(255), CONTAINER_ID_4 varchar(255), CONT_SIZE int, -- 0 = none -- 1 = 20ft -- 2 = 40ft -- 3 = 45ft -- 4 = 2x20ft -- 5… = user defined HEIGHT_1 int, HEIGHT_2 int, HEIGHT_3 int, HEIGHT_4 int, WEIGHT_1 int, WEIGHT_2 int, WEIGHT_3 int, WEIGHT_4 int, FROM_SLOT varchar(255), FROM_X int, FROM_Y int, TO_SLOT varchar(255), TO_X int, TO_Y int, BLOCKING Boolean, ORDER_TIME timestamp, PRIORITY int, START_EARLIEST timestamp, FINISH_LATEST timestamp, TRUCK_ID_FROM varchar(255), TRUCK_TYPE_FROM int, TRUCK_LENGTH_FROM int, TRUCK_HEIGHT_FROM int, TRAILER_LOC_FROM int TRUCK_ID_TO varchar(255), TRUCK_TYPE_TO int, TRUCK_LENGTH_TO int, TRUCK_HEIGHT_TO int, TRAILER_LOC_TO int);



www.pema.org

Flag Req Field Comment

0x01 Req uint16 JOB_ID;

0x02 Req unsigned char JOB_TYPE;

0x04 uint16 CHE_ID;

0x08 Req char CONTAINER_ID_1[20]; ASCII padded with spaces

0x10 char CONTAINER_ID_2[20]; ASCII padded with spaces

0X20 char CONTAINER_ID_3[20]; ASCII padded with spaces

0X40 char CONTAINER_ID_4[20]; ASCII padded with spaces

0x80 Req unsigned char CONT_SIZE; 0 = none

1 = 20ft

2 = 40ft

3 = 45ft

4 = 2x20ft

5… = user defined

0x0100 uint16 HEIGHT_1;




0x1000 uint16 WEIGHT_1;




0x010000 Req char FROM_SLOT[20]; ASCII padded with spaces

0x020000 uint32 FROM_X;

0x040000 uint32 FROM_Y;

0x080000 Req char TO_SLOT[20]; ASCII padded with spaces

0x100000 uint32 TO_X;

0x200000 uint32 TO_Y;

0x400000 unsigned char BLOCKING; 1=on, 0=off

0x800000 uint32 ORDER_TIME; seconds from 1.1.2000,00:00

2.3. Job_order (tos > ecs) bInarY Message IMpLeMentatIon

typedef struct{ //uint16: 16-bit unsigned integer, big-endian //uint32: 32-bit unsigned integer, big-endian //uint64: 64-bit unsigned integer, big-endian char start_of_message; //0xff unsigned char msg_len; //variable unsigned char msg_type; //1=JOB_ORDER unsigned char msg_number; //running number uint64 flag_field; //specifies which message fields are present char VARIABLE_FIELDS[N]; //see table below char crc_msb; char crc_lsb; char end_of_message; //0xfe} JOB_ORDER;


http://www.pema.org


0x01000000 unsigned char PRIORITY;

0x02000000 uint32 START_EARLIEST; seconds from 1.1.2000,00:00

0x04000000 uint32 FINISH_LATEST; seconds from 1.1.2000,00:00

0x08000000 char TRUCK_ID_FROM[20]; ASCII padded with spaces

0x10000000unsigned char TRUCK_TYPE_FROM;

0x20000000unsigned char TRUCK_LENGTH_FROM;

0x40000000unsigned char TRUCK_HEIGHT_FROM;

0x80000000unsigned char TRAILER_LOC_FROM;

0x0100000000 char TRUCK_ID_TO[20]; ASCII padded with spaces

0x0200000000 unsigned char TRUCK_TYPE_TO;

0x0400000000unsigned char TRUCK_LENGTH_TO;

0x0800000000unsigned char TRUCK_HEIGHT_TO;

0x1000000000unsigned char TRAILER_LOC_TO;



www.pema.org

3. Job_status (ecs > tos)


JOB_IDID of the job executed0 = No job order for this move

LONG INTEGER

CHE_ID ID of the CHE executing the job INTEGER

JOB_STATUS

1 = Start of job2 = Activate job3 = Approach pick4 = Container picked5= Container identification6 = Place position request7 = Approach place8 = Container landed9 = Container placed10 = Job finished11 = Error in job execution

INTEGER

ERROR_CODE Error code, if job in error INTEGER

FROM_SLOT Actual pick positionLogical name (slot, area, truck, vessel, train)

TO_SLOT Actual place positionLogical name (slot, area, truck, vessel, train)

CONTAINER_ID_1 (If known) STRING

IDENTIFICATION_1 How was container identified ?Not identified, identified by driver, OCR or equivalent

CONTAINER_ID_2 (Twin-lift) STRING






CONT_SIZE Container size, twin- or quad-lift STRING

PICK_TIME Time of container pick, optional Date and time

PLACE_TIME Time of container place, optional Date and time

FINISH_TIME Finish time, optional Date and time

CHE_LOCATION CHE location Logical name (slot, area)

CHE_X Used in case logical position not defined (mm) INTEGER

CHE_Y Used in case logical position not defined (mm) INTEGER

table a2: Job_status message/data-item


http://www.pema.org


3.1. Job_status (ecs > tos) XML IMpLeMentatIon

<?xml version=”1.0”?><xs:schema><xs:element name=”JOB_STATUS”> <xs:complexType> <xs:sequence> <xs:element name=”JOB_ID” type=”xs:integer”/> <xs:element name=”CHE_ID” type=”xs:integer”/> <xs:element name=”JOB_STATUS” type=”xs:integer”/> <xs:element name=”ERROR_CODE” type=”xs:integer” minOccurs=”0”/> <xs:element name=”FROM_SLOT” type=”xs:string”/> <xs:element name=”TO_SLOT” type=”xs:string”/> <xs:element name=”CONTAINER_ID_1” type=”xs:string” minOccurs=”0”/> <xs:element name=”IDENTIFICATION_1” type=”xs: containeridentificationType “ minOccurs=”0”/> <xs:element name=”CONTAINER_ID_2” type=”xs:string” minOccurs=”0”/> <xs:element name=”IDENTIFICATION_2” type=”xs: containeridentificationType “ minOccurs=”0”/> <xs:element name=”CONTAINER_ID_3” type=”xs:string” minOccurs=”0”/> <xs:element name=”IDENTIFICATION_3” type=”xs: containeridentificationType “ minOccurs=”0”/> <xs:element name=”CONTAINER_ID_4” type=”xs:string” minOccurs=”0”/> <xs:element name=”IDENTIFICATION_4” type=”xs: containeridentificationType “ minOccurs=”0”/> <xs:element name=”CONT_SIZE” type=”xs:contsizeType”/> <xs:element name=”PICK_TIME” type=”xs:dateTime” minOccurs=”0”/> <xs:element name=”PLACE_TIME” type=”xs:dateTime” minOccurs=”0”/> <xs:element name=”FINISH_TIME” type=”xs:dateTime” minOccurs=”0”/> <xs:element name=”CHE_LOCATION” type=”xs:string” minOccurs=”0”/> <xs:element name=”CHE_X” type=”xs:integer” minOccurs=”0”/> <xs:element name=”CHE_Y” type=”xs:integer” minOccurs=”0”/> </xs:sequence> </xs:complexType></xs:element></xs:schema>



www.pema.org

3.2. Job_status (ecs > tos) sQL IMpLeMentatIon

CREATE TABLE JOB_STATUS( JOB_ID int, CHE_ID int, JOB_STATUS int, ERROR_CODE int, FROM_SLOT varchar(255), TO_SLOT varchar(255), CONTAINER_ID_1 varchar(255), IDENTIFICATION_1 int, -- 0 = not identified -- 1 = identified by driver -- 2 = OCR or equivalent CONTAINER_ID_2 varchar(255), IDENTIFICATION_2 int, CONTAINER_ID_3 varchar(255), IDENTIFICATION_3 int, CONTAINER_ID_4 varchar(255), IDENTIFICATION_4 int, CONT_SIZE int, -- 0 = none -- 1 = 20ft -- 2 = 40ft -- 3 = 45ft -- 4 = 2x20ft -- 5… = user defined PICK_TIME timestamp, PLACE_TIME timestamp, FINISH_TIME timestamp, CHE_LOCATION varchar(255), CHE_X int, CHE_Y int);


http://www.pema.org




0x02 Req uint16 CHE_ID;

0x04 Req unsigned char JOB_STATUS;

0x08 unsigned char ERROR_CODE;

0x10 Req char FROM_SLOT[20]; ASCII padded with spaces

0x20 Req char TO_SLOT[20]; ASCII padded with spaces


0x80unsigned char IDENTIFICATION_1;

0 = not identified

1 = identified by driver

2 = OCR or equivalent







0x4000 Req unsigned char CONT_SIZE; 0 = none

1 = 20ft

2 = 40ft

3 = 45ft

4 = 2x20ft

0x8000 uint32 PICK_TIME; seconds from 1.1.2000,00:00

0x010000 uint32 PLACE_TIME; seconds from 1.1.2000,00:00

0x020000 uint32 FINISH_TIME; seconds from 1.1.2000,00:00

0x040000 char CHE_LOCATION[20]; ASCII padded with spaces

0x080000 uint32 CHE_X;

0x100000 uint32 CHE_Y;

3.3. Job_status (ecs > tos) bInarY Message IMpLeMentatIon

typedef struct{ //uint16: 16-bit unsigned integer, big-endian //uint32: 32-bit unsigned integer, big-endian //uint64: 64-bit unsigned integer, big-endian char start_of_message; //0xff unsigned char msg_len; //variable unsigned char msg_type; //2=JOB_STATUS unsigned char msg_number; //running number uint64 flag_field; //specifies which message fields are present char VARIABLE_FIELDS[N]; //see table below char crc_msb; char crc_lsb; char end_of_message; //0xfe} JOB_STATUS;



www.pema.org

4.1. cHe_status (ecs > tos) XML IMpLeMentatIon

<?xml version=”1.0”?><xs:schema><xs:element name=”CHE_STATUS”> <xs:complexType> <xs:sequence> <xs:element name=”CHE_ID” type=”xs:integer”/> <xs:element name=”JOB_ID” type=”xs:integer”/> <xs:element name=”CHE_STATUS” type=”xs:integer”/> <xs:element name=”ERROR_CODE” type=”xs:integer” minOccurs=”0”/> <xs:element name=”CHE_LOCATION” type=”xs:string” minOccurs=”0”/> <xs:element name=”CHE_X” type=”xs:integer” minOccurs=”0”/> <xs:element name=”CHE_Y” type=”xs:integer” minOccurs=”0”/> <xs:element name=”TECHNICAL_STATUS” type=”xs:integer” minOccurs=”0”/> </xs:sequence> </xs:complexType></xs:element></xs:schema>


CHE_ID ID of the CHE INTEGER

JOB_IDJob ID, if there is a job in execution. JOB_STATUS gives more information on work status0 = No job in execution

LONG INTEGER

CHE_STATUS

0 = Not available1 = Available2 = Available, requesting new job3 = In error

INTEGER

ERROR_CODE Error code if CHE in error INTEGER

CHE_LOCATION CHE location Logical name (slot, area)

CHE_X Used in case logical position not defined (mm)

CHE_Y Used in case logical position not defined (mm)

TECHNICAL_STATUS Vehicle-specific technical status (when needed) INTEGER

4. cHe_status (ecs > tos)

table a3: cHe_status message/data-item


http://www.pema.org


4.2. cHe_status (ecs > tos) sQL IMpLeMentatIon

CREATE TABLE CHE_STATUS( CHE_ID int, JOB_ID int, CHE_STATUS int, ERROR_CODE int, CHE_LOCATION varchar(255), CHE_X int, CHE_Y int, TECHNICAL_STATUS int);

4.3. cHe_status (ecs > tos) bInarY Message IMpLeMentatIon

typedef struct{ //uint16: 16-bit unsigned integer, big-endian //uint32: 32-bit unsigned integer, big-endian //uint64: 64-bit unsigned integer, big-endian char start_of_message; //0xff unsigned char msg_len; //variable unsigned char msg_type; //3=CHE_STATUS unsigned char msg_number; //running number uint64 flag_field; //specifies which message fields are present char VARIABLE_FIELDS[N]; //see table below char crc_msb; char crc_lsb; char end_of_message; //0xfe} CHE_STATUS;




0x04 Req unsigned char CHE_STATUS;

0x08 unsigned char ERROR_CODE;

0x10 char CHE_LOCATION[20]; ASCII padded with spaces

0x40 uint32 CHE_X;

0x80 uint32 CHE_Y;

0x0100 uint32 TECHNICAL_STATUS;



www.pema.org

5.1. status_reQ (tos > ecs) XML Implementation

<?xml version=”1.0”?><xs:schema><xs:element name=”STATUS_REQ”> <xs:complexType> <xs:sequence> <xs:element name=”CHE_ID” type=”xs:integer”/> </xs:sequence> </xs:complexType></xs:element></xs:schema>

5.2. status_reQ (tos > ecs) sQL IMpLeMentatIon

N/A

5.3. status_reQ (tos > ecs) bInarY Message IMpLeMentatIon

typedef struct{ //uint16: 16-bit unsigned integer, big-endian //uint32: 32-bit unsigned integer, big-endian //uint64: 64-bit unsigned integer, big-endian char start_of_message; //0xff unsigned char msg_len; //17 (bytes total) unsigned char msg_type; //4=STATUS_REQ unsigned char msg_number; //running number uint64 flag_field; //specifies which message fields are present char VARIABLE_FIELDS[N]; //see table below char crc_msb; char crc_lsb; char end_of_message; //0xfe} STATUS_REQ;





5. status_reQ (tos > ecs)

table a4: status _reQ message


http://www.pema.org


6.1. InVentorY_reQ (ecs > tos) XML IMpLeMentatIon

<?xml version=”1.0”?><xs:schema><xs:element name=”INVENTORY_REQ”> <xs:complexType> <xs:sequence> <xs:element name=”CHE_ID” type=”xs:integer” minOccurs=”0”/> <xs:element name=”SLOT_ID” type=”xs:string” /> </xs:sequence> </xs:complexType></xs:element></xs:schema>

6.2. InVentorY_reQ (ecs > tos) sQL IMpLeMentatIon

N/A

6.3. InVentorY_reQ (ecs > tos) bInarY Message IMpLeMentatIon

typedef struct{ //uint16: 16-bit unsigned integer, big-endian //uint32: 32-bit unsigned integer, big-endian //uint64: 64-bit unsigned integer, big-endian char start_of_message; //0xff unsigned char msg_len; //variable unsigned char msg_type; //5=INVENTORY_REQ unsigned char msg_number; //running number uint64 flag_field; //specifies which message fields are present char VARIABLE_FIELDS[N]; //see table below char crc_msb; char crc_lsb; char end_of_message; //0xfe} INVENTORY_REQ;



SLOT_ID Ground slot nameLogical name (slot, area, vessel, train)


0x02 uint16 CHE_ID;

0x04 Req char SLOT_ID[20]; ASCII padded with spaces

table a5: InVentorY_reQ message

6. InVentorY_reQ (ecs > tos)



www.pema.org

7. InVentorY_data (tos > ecs)

table a6: InVentorY_data- message


SLOT_ID Ground slot name Logical name (slot, area)

HEIGHT Number of containers stacked on this ground slot INTEGER

HEIGHT_MM Stack height (mm) INTEGER

7.1. InVentorY_data (tos > ecs) XML IMpLeMentatIon

<?xml version=”1.0”?><xs:schema><xs:element name=”INVENTORY_DATA”> <xs:complexType> <xs:sequence> <xs:element name=”SLOT_ID” type=”xs:string”/> <xs:element name=”HEIGHT” type=”xs:integer”/> <xs:element name=”HEIGHT_MM” type=”xs:integer” minOccurs=”0”/> </xs:sequence> </xs:complexType></xs:element>

</xs:schema>

7.2. InVentorY_data (tos > ecs) sQL IMpLeMentatIon

N/A

7.3. InVentorY_data (tos > ecs) bInarY Message IMpLeMentatIontypedef struct{ //uint16: 16-bit unsigned integer, big-endian //uint32: 32-bit unsigned integer, big-endian //uint64: 64-bit unsigned integer, big-endian char start_of_message; //0xff unsigned char msg_len; //variable unsigned char msg_type; //6=INVENTORY_DATA unsigned char msg_number; //running number uint64 flag_field; //specifies which message fields are present char VARIABLE_FIELDS[N]; //see table below char crc_msb; char crc_lsb; char end_of_message; //0xfe

} INVENTORY_DATA;



0x10 Req unsigned char HEIGHT;

0x20 uint16 HEIGHT_MM;


http://www.pema.org


8. geoMetrY_reQ (ecs > tos)

table a7: geoMetrY_reQ message


REQUEST TYPE1 = Vessel geometry data2 = Train geometry data

INTEGER


8.1. geoMetrY_reQ (ecs > tos) XML IMpLeMentatIon

<?xml version=”1.0”?><xs:schema><xs:element name=”INVENTORY_REQ”> <xs:complexType> <xs:sequence> <xs:element name=”REQUEST_TYPE” type=”xs:integer”/> <xs:element name=”CHE_ID” type=”xs:integer” minOccurs=”0”/> </xs:sequence> </xs:complexType></xs:element></xs:schema>

8.2. geoMetrY_reQ (ecs > tos) sQL IMpLeMentatIon

N/A

8.3. geoMetrY_reQ (ecs > tos) bInarY Message IMpLeMentatIon

typedef struct{ //uint16: 16-bit unsigned integer, big-endian //uint32: 32-bit unsigned integer, big-endian //uint64: 64-bit unsigned integer, big-endian char start_of_message; //0xff unsigned char msg_len; //variable unsigned char msg_type; //7=GEOMETRY_REQ unsigned char msg_number; //running number uint64 flag_field; //specifies which message fields are present char VARIABLE_FIELDS[N]; //see table below char crc_msb; char crc_lsb; char end_of_message; //0xfe} GEOMETRY_REQ;


0x01 Req unsigned char REQUEST_TYPE;

0x02 uint16 CHE_ID;



www.pema.org

9. geoMetrY_data (tos > ecs)

table a8: geoMetrY_data message


DATA TYPE1 = Vessel geometry data2 = Train geometry data

INTEGER

SLOT_ID Ground slot name Logical name (slot, area)

TOTAL_SLOTS Total number of ground slots in vessel or train INTEGER

CURRENT_SLOT Number of this ground slot INTEGER

X_COORDINATE (mm) relative to smallest X value INTEGER

Y_COORDINATE (mm) relative to smallest Y value INTEGER

Z_COORDINATE (mm) relative to smallest Z value INTEGER

CONT_SIZE Container sizes allowed in slot STRING

9.1. geoMetrY_data (tos > ecs) XML IMpLeMentatIon

<?xml version=”1.0”?><xs:schema><xs:element name=”GEOMETRY_DATA”> <xs:complexType> <xs:sequence> <xs:element name=”DATA_TYPE” type=”xs:integer”/> <xs:element name=”SLOT_ID” type=”xs:string”/> <xs:element name=”TOTAL_SLOTS” type=”xs:integer” minOccurs=”0”/> <xs:element name=”CURRENT_SLOT” type=”xs:integer” minOccurs=”0”/> <xs:element name=”X_COORDINATE” type=”xs:integer” minOccurs=”0”/> <xs:element name=”Y_COORDINATE” type=”xs:integer” minOccurs=”0”/> <xs:element name=”Z_COORDINATE” type=”xs:integer” minOccurs=”0”/> <xs:element name=”CONT_SIZE” type=”xs:string” minOccurs=”0”/> </xs:sequence> </xs:complexType></xs:element></xs:schema>

9.2. geoMetrY_data (tos > ecs) sQL IMpLeMentatIon

N/A


http://www.pema.org


9.3. geoMetrY_data (tos > ecs) bInarY Message IMpLeMentatIon

typedef struct{ //uint16: 16-bit unsigned integer, big-endian //uint32: 32-bit unsigned integer, big-endian //uint64: 64-bit unsigned integer, big-endian char start_of_message; //0xff unsigned char msg_len; //variable unsigned char msg_type; //8=GEOMETRY_DATA unsigned char msg_number; //running number uint64 flag_field; //specifies which message fields are present char VARIABLE_FIELDS[N]; //see table below char crc_msb; char crc_lsb; char end_of_message; //0xfe} GEOMETRY_DATA;


0x01 Req unsigned char DATA_TYPE;


0x04 uint16 TOTAL_SLOTS;

0x08 uint16 CURRENT_SLOT;

0x10 uint32 X_COORDINATE;

0x20 uint32 Y_COORDINATE;

0x40 uint32 Y_COORDINATE;

0x80 char CONT_SIZE[20]; ASCII padded with spaces



www.pema.org

glOSSarY Of TErmS

TERM ABBREVIATION DESCRIPTION

Automated guided

vehicleAGV

Unmanned vehicle for transporting containers, traditionally a

flat-bed vehicle

Automatic stacking

craneASC Unmanned crane for stacking containers in the terminal yard

Container handling

equipmentCHE Vehicles and equipment used to handle containers

Differential GPS DGPS Satellite positioning device

Equipment control

systemECS

Software that monitors and controls all events and

processes at equipment level

Horizontal transportSystem for transporting containers from STS to stacking

area. May be e.g. TT, SC, AGV

Middleware Software layer between TOS and CHE control system

Optical character

recognitionOCR

Camera vision technology for automatic identification of

numbers, characters and images

Position detection

systemPDS Navigation system for measuring CHE position in real-time

Programmable logic

controllerPLC Computer in CHE

Radio frequency

identificationRFID Technology for automated identification and tracking

Rail mounted gantry

craneRMG

Rail-mounted crane for stacking containers in the terminal

yard

Rubber tyred gantry

craneRTG

Rubber-tyred crane for stacking containers in the terminal

yard

Shuffle moveName for moving a container that is stacked on top of the

actual container requested (usually a short move)

Straddle Carrier SC Mobile CHE used for carrying and stacking containers

Ship-to-shore crane STS Crane for transferring containers between vessel and quay

SQL SQLStructured Query Language, programming language

designed for managing data held in a relational database

Terminal operating

systemTOS

Main software application that plans and monitors the

operational functioning of a terminal

Terminal tractor TTTractor unit paired with chassis for the movement of

containers around the terminal

Tier The height (1…N) of the container in a stack of containers

XML XMLExtensible Markup Language, for encoding documents in

a format that is both human-readable and machine-readable

http://www.pema.org


abOuT ThE auThOrS & pEmaABOUT THE AUTHORSThis document was researched over a 2-year period by members of the Working Group on Software Interface Standardisation (SIS) established under the auspices of PEMA’s Technology Committee.

Many industry members, both inside and outside PEMA, have been involved in the development of this standardisation initiative. Particular thanks are due to SIS Working Group Chair Kari Rintanen of Konecranes.

SIS Working Group members included representatives from ABB, APM Terminals CES, APS Technologies, Banner Engineering, Cargotec/Kalmar, IDENTEC SOLUTIONS, ISL, Navis, Siemens, smart-Tecs, TBA and TMEIC, Vahle, VISY, among others. PEMA thanks all group members for their significant contribution to this project.

ABOUT PEMAFounded in late 2004, the mission of PEMA is to provide a forum and public voice for the global port equipment and technology sectors, reflecting their critical role in enabling safe, secure, sustainable and productive ports, and thereby supporting world maritime trade.

Chief among the aims of the Association is to provide a forum for the exchange of views on trends in the design, manufacture and operation of port equipment and technology worldwide.

PEMA also aims to promote and support the global role of the equipment and technology industries, by raising awareness with the media, customers and other stakeholders; forging relations with other port industry associations and bodies; and contributing to best practice initiatives.

MEMBERSHIP OF PEMAPEMA membership is open to:• Manufacturers/suppliers of port equipment• Manufacturers/suppliers of port equipment

components• Suppliers of technology that interfaces with or

controls the operation of port equipment• Consultants in port and equipment design,

specification and operations

Please visit www.pema.org for more information or email the PEMA Secretariat at [email protected]

PEMA CONSTITUTION & OFFICESPEMA was constituted by agreement dated 9 December 2004 as a non profit making international association (association internationale sans but lucratif /internationale vereniging zonder winstoogmerk) PEMA is governed by the Belgian Law of 27 June 1921 on “associations without a profit motive, international associations without a profit motive and institutions of public utility” (Articles 46 to 57).

Company Number/ Numéro d’entreprise/ Ondernemingsnummer 0873.895.962 RPM (Bruxelles)

The Registered Office of the Association is at: p/a EIA, rue d’Arenberg 44, 1000 Brussels, Belgium

The Management and Finance offices of the Association are at: Via Balestra 27, Lugano CH-6900, Switzerland

Administration support is undertaken by the Secretariat at: Suite 5, Meridian House, 62 Station Road, London E4 7BA, United Kingdom. Tel +44 20 3327 0577Email [email protected]

http://www.pema.org

mailto:info%40pema.org?subject=PEMA%20OCR%20Information%20Paper

mailto:info%40pema.org?subject=PEMA%20OCR%20Information%20Paper


www.pema.org

“the mission of peMa is to

provide a forum and public

voice for the global port

equipment and technology

sectors, reflecting their critical

role in enabling safe, secure,

sustainable and productive

ports, and thereby supporting

world maritime trade”

http://www.pema.org

PEMA – Port Equipment Manufacturers Association

peMa was constituted by agreement dated 9 december 2004 as a non profit making international association (association internationale sans but lucratif /internationale vereniging zonder winstoogmerk).

the association is governed by the belgian Law of 27 June 1921 on “associations without a profit motive, international associations without a profit motive and institutions of public utility” (articles 46 to 57). company number/ numéro d’entreprise/ ondernemingsnummer 0873.895.962 rpM (bruxelles)

registered office: p/a eIa, 44 rue d’arenberg, b-1000 brussels, belgium

president and finance offices: Via s. balestra 27, cH-6900 Lugano, switzerland

secretariat offices: suite 5, Meridian House, 62 station road, London e4 7ba, uk. tel +44 20 3327 0577 | email [email protected]

full (voting) peMa membership is currently open to:• Manufacturers and suppliers of port and terminal equipment• Manufacturers and suppliers of components or attachments for

port equipment• suppliers of technology that interfaces with or controls the

operation of port equipment• consultants in port and equipment design, specification and

operations

associate membership (non-voting observer status) is open to individuals, corporate entities, academic institutions, business associations, national, european or international associations and other interested entities at the discretion of the peMa board.

ww

w.p

ema.

org

- J

une

201

4

www.pema.org

mailto:info%40pema.org?subject=PEMA

www.pema.org

tos-equipment control interface standard · 5.1.3. job refinement during move 24 5.2. rtg operation...

Documents