Upload
others
View
9
Download
0
Embed Size (px)
Citation preview
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
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
4 TOS-Equipment Control Interface Standard | 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
2.2. SQL implementation 33
2.3. Binary message implementation 34
3. Job_status (ecs > tos) 36 3.1. XML implementation 37
3.2. SQL implementation 38
3.3. Binary message implementation 39
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
5.2. SQL implementation 42
5.3. Binary message implementation 42
6. InVentorY_reQ (ecs >tos) 43 6.1. XML implementation 43
6.2. SQL implementation 43
6.3. Binary message implementation 43
7. InVentorY_data (tos > ecs) 44 7.1. XML implementation 44
7.2. SQL implementation 44
7.3. Binary message implementation 44
8. geoMetrY_reQ (ecs > tos) 45 8.1. XML implementation 45
8.2. SQL implementation 45
8.3. Binary message implementation 45
9. geoMetrY_data (tos > ecs) 46 9.1. XML implementation 46
9.2. SQL implementation 46
9.3. Binary message implementation 47
gLossarY of terMs 48 about tHe autHors & peMa 49
COnTEnTS
5TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
6 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
7TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
8 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
9TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
CHAPTER 2: OVERVIEW CONTINUED
10 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
CHAPTER 2: OVERVIEW CONTINUED
11TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
CHAPTER 2: OVERVIEW CONTINUED
12 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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)
CHAPTER 2: OVERVIEW CONTINUED
13TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
14 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
15TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
16 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
17TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
18 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
CHAPTER 4: STANDARD INTERFACE SPECIFICATION CONTINUED
19TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
Type Description Required Optional Trigger
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
CHAPTER 4: STANDARD INTERFACE SPECIFICATION CONTINUED
20 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
www.pema.org
Type Description Required Optional Trigger
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”).
Type Description Required Optional Trigger
1Request status of a particular
CHE • Decided by TOS
Type Description Required Optional Trigger
1 Request stack population • Decided by CHE
Type Description Required Optional Trigger
1Stack population data at
specified logical position • INVENTORY_REQ
table 4: cHe_status usage
table 5: status_reQ usage
table 6: InVentorY_reQ usage
CHAPTER 4: STANDARD INTERFACE SPECIFICATION CONTINUED
table 7: InVentorY_data usage
21TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
Type Description Required Optional Trigger
1 Request vessel geometry data • Decided by CHE
2 Request train geometry data • Decided by CHE
Type Description Required Optional Trigger
1Geometry data of vessel or train
(N messages) • GEOMETRY_REQ
CHAPTER 4: STANDARD INTERFACE SPECIFICATION CONTINUED
table 8: geoMetrY_reQ usage
table 9: geoMetrY_data usage
22 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
23TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
24 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
25TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
26 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
27TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
28 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
www.pema.org
29TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
30 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
CONTAINER_ID_4 (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
31TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
FIELD DESCRIPTION TYPE
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
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
32 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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>
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
33TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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);
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
34 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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;
0x0200 uint16 HEIGHT_2;
0x0400 uint16 HEIGHT_3;
0x0800 uint16 HEIGHT_4;
0x1000 uint16 WEIGHT_1;
0x2000 uint16 WEIGHT_2;
0x4000 uint16 WEIGHT_3;
0x8000 uint16 WEIGHT_4;
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;
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
35TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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;
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
36 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
www.pema.org
3. Job_status (ecs > tos)
FIELD DESCRIPTION TYPE
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
IDENTIFICATION_2 How was container identified ?Not identified, identified by driver, OCR or equivalent
CONTAINER_ID_3 (Quad-lift) STRING
IDENTIFICATION_3 How was container identified ?Not identified, identified by driver, OCR or equivalent
CONTAINER_ID_4 (Quad-lift) STRING
IDENTIFICATION_4 How was container identified ?Not identified, identified by driver, OCR or equivalent
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
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
37TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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>
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
38 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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);
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
39TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
Flag Req Field Comment
0x01 Req uint16 JOB_ID;
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
0x40 char CONTAINER_ID_1[20]; ASCII padded with spaces
0x80unsigned char IDENTIFICATION_1;
0 = not identified
1 = identified by driver
2 = OCR or equivalent
0x0100 char CONTAINER_ID_2[20]; ASCII padded with spaces
0x0200unsigned char IDENTIFICATION_2;
0x0400 char CONTAINER_ID_3[20]; ASCII padded with spaces
0x0800unsigned char IDENTIFICATION_3;
0x1000 char CONTAINER_ID_4[20]; ASCII padded with spaces
0x2000unsigned char IDENTIFICATION_4;
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;
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
40 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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>
FIELD DESCRIPTION TYPE
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
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
41TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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;
Flag Req Field Comment
0x01 Req uint16 CHE_ID;
0x02 Req uint16 JOB_ID;
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;
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
42 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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;
FIELD DESCRIPTION TYPE
CHE_ID ID of the CHE INTEGER
Flag Req Field Comment
0x01 Req uint16 CHE_ID;
5. status_reQ (tos > ecs)
table a4: status _reQ message
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
43TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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;
FIELD DESCRIPTION TYPE
CHE_ID ID of the CHE INTEGER
SLOT_ID Ground slot nameLogical name (slot, area, vessel, train)
Flag Req Field Comment
0x02 uint16 CHE_ID;
0x04 Req char SLOT_ID[20]; ASCII padded with spaces
table a5: InVentorY_reQ message
6. InVentorY_reQ (ecs > tos)
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
44 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
www.pema.org
7. InVentorY_data (tos > ecs)
table a6: InVentorY_data- message
FIELD DESCRIPTION TYPE
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;
Flag Req Field Comment
0x01 Req char SLOT_ID[20]; ASCII padded with spaces
0x10 Req unsigned char HEIGHT;
0x20 uint16 HEIGHT_MM;
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
45TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
8. geoMetrY_reQ (ecs > tos)
table a7: geoMetrY_reQ message
FIELD DESCRIPTION TYPE
REQUEST TYPE1 = Vessel geometry data2 = Train geometry data
INTEGER
CHE_ID ID of the CHE 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;
Flag Req Field Comment
0x01 Req unsigned char REQUEST_TYPE;
0x02 uint16 CHE_ID;
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
46 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
www.pema.org
9. geoMetrY_data (tos > ecs)
table a8: geoMetrY_data message
FIELD DESCRIPTION TYPE
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
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
47TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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;
Flag Req Field Comment
0x01 Req unsigned char DATA_TYPE;
0x02 Req char SLOT_ID[20]; ASCII padded with spaces
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
APPENDIX: MESSAGE/DATABASE STRUCTURE CONTINUES
48 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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
49TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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]
50 TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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”
51TOS-Equipment Control Interface Standard | Port Equipment Manufacturers Association
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