78th Plenary Meeting

SMDG e.V. > 78th Plenary Meeting

The 78th Plenary Meeting took place in Antwerp (Belgium) Hosted by MSC Shared Service Center Belgium from 24 – 26. April 2024.
It was prepended by 2 meeting days of the Critical and Dangerous Cargo Working Group organized by Capt. Dirk van de Velde (MSC).


We are thankful to Capt. Dirk van de Velde and the MSC staff for organising this event.

The Agenda

The agenda includes the schedule for both events: Critical and Dangerous Cargo Working Group and the SMDG Plenary #78.

Download agenda

The Minutes of SMDG Plenary #78

Session / DateDescriptionPresenterSlides
Welcome by SMDG Board
24.04.2024 09:00 – 9:05
Meeting rules, off-limits topics, security note.Ann-Christin Fröhmcke
Co-Chair SMDG Board, CMA CGM

Sönke Witt
Co-Chair SMDG Board, HHLA
Intro SMDG#78
Keynote:
CINS PRESENTATION

24.04.2024
09:15 – 10:00
Marc thanks MSC and the SMDG for the good teamwork.

Presentation of the CINS:
– Analyse incidents declared on voluntary basis.
– Implement safety rules to avoid future incidents.

The reality is:
 Most regulations are based on scientific analysis or sometimes specific incident, but not based on day-to-day business reality.
 Shipping company implementation of the regulation are slow.
 CINS intend to tackle the gap.

Examples given:
 Plastic nurdles: Pollution. Recent incidents, which could have been avoided if the containers had been properly stowed and the information shared with partners.
 Lithium: when “non dangerous” as per IMDG, shipper possibly take less care about the packaging and stowage precautions are not taken care of as they should. This leads to chemical fires, difficult to extinguish.
 VGM: Despite the regulation, many misdeclaration exists.
 Charcoal: Best practices revised recently and will be included in the IMDG in 2 years.

Highlight on the need to have better information sharing, proper traceability to improve the stowage and safety on board.

Q&A section
– Several questions were asked regarding Plastic Pellet regulation, involvement of shippers, measures in carriers, database access.
– An additional comment was raised regarding the SMDG code list Attribute / Stowins / Handling.

Marc Lefebvre
CMA-CGM
CINS Kexnote
SMDG Code Lists – Status (part 1) Terminal Codes, Liner Codes
24.04.2024
10:00 – 11:00
Code List working group status.

Jasmin presented the Liner Code List (including change log and use case).
o Currently 304 entries, with 18 new one last year, 2 changes and 1 deletion.
o Highlight on the fact that the code list depends on business providing the information to the SMDG code list working group to add / change / delete codes.
o Always a need to crosscheck with the concerned Liner when a third party request a code.
o A project is under way to make the data available on a central database and enable an easy access to the repository via API. More info to follow the next day.

Mark presented the Terminal Code List (including its scope, use cases and emphasize on the SMDG recommendation #7and UN/CEFACT Recommendation #16)
o Currently 1114 terminals are covered.
o Publication of TCL on SMDG website and API, collaboration with BIC geofencing project
o New requests for Straits and Canals are coming and there is still a question mark if and how those should be covered or not. The UN/LOCODE Advisory Board has formed a sub working group to handle this from UN/LOCODE perspective.

Q&A section
From Shipping Lines:
– Requested codes for Berth and Maersk bunkering points. However, both cases are out of scope currently.
– Requested Codes for pilot stations. Not covered currently due to the undefined range (Geofencing issue). The working group and DCSA are open to discuss this point.


Jamin Drönner
EUROGATE

Mark Lim
EDI EXPERT
SMDG Liner CodesSMDG Terminal Codes
SMDG Code Lists – Status (part 2) Attribute | Stow Instruction | Handling codes
24.04.2024
11:30 – 11:40
Code List working group status.
Chair changed from Sönke WITT to Kai STANISLAUS.

Code List working group status.
Chair changed from Sönke WITT to Kai STANISLAUS.

– Explanation on Attribute / Stowins / Handling Codes
o New format of the document, including an example (Flexitanks).
o New entries and change log in the list included online.
o New request for attribute EXC / EXN certified reefers to be clarified.

Q&A section
– Audience show interest to know more about EXC/EXN. Working group is still in phase of collecting information.
Explanation on Attribute / Stowins / Handling Codes
o New format of the document, including an example (Flexitanks).
o New entries and change log in the list included online.
o New request for attribute EXC / EXN certified reefers to be clarified.
Sönke Witt
Co-Chair of SMDG, HHLA

on behalf of Kai Stanislaus
DAKOSY
Code lists Handling, Stowage Inst, Attributes
BIC + SMDG Geofence Project
24.04.23
11:40 – 12:30
Explanation of the Bic facility code, its complementarity to the SMDG Terminal Code List, and the importance of geofencing for IoT devices.

Ø 3 keys steps:
– UN/CE FACT Geofence White Paper
– Geofence Review Platform
– Geofence review panel

Currently scaling up through collaboration with SMDG (Global), IANA (North America), CisCo (Italy), BSCS (Germany). But looking for more support, especially in Mexico, Singapore, but also other areas.
Success stories:
– Evergreen (requested to their partners),
– CMA CGM (provided own geofencing),
– Hapag Lloyd (provide local expert).

David encourages participation from carriers and terminals/depots, to implement geofences, request for, and support to validate geofences, as this is mutually beneficial for all parties.
A demo was presented on the resubmission and review process of the Geofencing.
All the information is available via API pull or push.

Q&A section
– A question was raised regarding the location gates, which are not pin pointed but are however taken in consideration.
The schedule of the next review sessions is available on the BIC website.
David Roff
BIC
Geofences
New SMDG MIGs for COxxxx Container Messages Based on D.22B repository
24.04.2024
13:30 – 14:00
Robert presented the new MIG regarding the new D22B for all COxxxx messages.
Recap about container messages (COxxxx).
The new MIG are currently under review process.

Notable changes include:
– COPARN change: GID segment is not to be used anymore.
– Seal Length changed from 10 to 35.
– Integration of the CODE list of SMDG within the MIG (instead of IM4).
– Align with Protect regarding EMS


Further DMR changes has been requested:
– EQD equipment status “storage” and RFF for block stowage reference (when approved by UN/CEFACT)

Q&A section
Some questions raised regarding to
– Draft status
– Challenge in terminal to manage COPARN for RFF to cancel.
– Plans for BAPLIE, MOVINS
– Expect a summary list of the differences.

Robèrt Roestenburg
RWG

Paul Wauters
EDI EXPERT

D.22B Container Messages
BAPLIE | MOVINS update
24.04.2024
14:00 – 14:30

Jost presented advantages of the BAPLIE 3.1:
– Differentiation Stowage position and Equipment
– More DG description
– Include non-standard equipment.
– Empty Flat Rack / Bundles
– Breakbulk
– Slot ownership
– Lost slots management
– Extra data for safety reasons (segregation / weight limits…)
– Addition of the ATT code (end of misuse of the FTX segment)

Benefits of the new version BAPLIE 3.1 are described here:
Advantages of BAPLIE Version 3
No update of the MIG for BAPLIE.
Jost requested for more people to join the MOVINS group which will develop a new MOVINS version. If you are interested in joining this group, please email to Jost.

Q&A section
– Backward compatibility:
New version backward compatible. Mostly a question of maintenance.
– Global request position paper by Shipping Lines to request BAPLIE 2.2 and 3.1 to terminal is in planning at the SMDG.
– Question of which terminal can do which versions: this would be a request on terminal and terminal software providers.
– It was proposed by carriers that shipping lines write a joined letter to terminals to request usage of BAPLIE 3.1 (preferred) or 2.2 version.

Jost Müller
SMDG
BAPLIE Version 3
VGM Recap after 8 years
24.04.2024
14:30 – 15:30
Robert explained the history of VGM regulation and VERMAS:
– Incident of 2007 MSC NAPOLI capsizing led to new regulation. 2014 VGM regulation was approved, to be applied in 2016.

– VERMAS was developed from 2015 and published by SMDG in April 2016 and approved by UN/CEFACT.

8 years later:
Nowadays, most VGM come to the terminal in the COPRAR load.
Overall, no real issue on terminal side, aside from the occasional re-weighing.

Open discussion: What about the other parties?
– Shipping Lines:
o Received but the accuracy remains unsure.
o Role of the terminal: sharing bad experience: terminal would need to raise an alarm in case of over-weight container, while lifting the container.
o Check that VGM between tare and max payload.
o Different process depending on the terminals.
o Many shippers reporting the VGM to the carrier by the VERMAS.

– Marine top tier project is studying the reasons of containers lost at sea. Mis stows and mis declared weight are highlighted. Looking for more data to analyse.
– Terminals:
o Some apply a no VGM no entry, sometimes the VGM is managed by a local legal entity, sometimes not.
– Question was raised about an eventual cooperation with weighing bridge association. This is not in place but could be set up.
– It was mentioned that SOLAS regulation originally suggested only 1 weight method, but then the second method was added due to lobby pressure. It was suggested to collect all issues to raise them to the IMO.

Robèrt Roestenburg
RWG
VGM recap
Feeder Group
24.04.2024
16:00 – 17:00
This working group presented its work, related to the transhipment, especially between main liners and third-party feeders.
Started with the SMDG meeting of 2022 in Helsinki. New members are always welcome.

Many stakeholder to coordinate: Feeders Operator, Shipping Lines and Terminal.
There is a need to find efficient communication and process to manage the changes, including via API / EDIs.
A white paper was published and distributed for comments to all participants of the SMDG.

Concepts which are important:
– Vessel schedules
– Unique identification of Port calls
– Exchange of feeder data.

New concepts:
– introduction of unique connection ID to ease communication.
– Stable connections
How to determine the risk of a connection
– This would help to provide a better transparency / visibility to all parties.

A business case was explained for better understanding.

Next steps:
– Develop a standard for identification of Unique Connection ID.
– Develop a definition of stable connection.
– Improve the white paper.

Q&A section
– The subject was positively received by the audience,
– Change management may be an issue.

No final date to release the white paper has been advised yet.
Robèrt Roestenburg
RWG

Sönke Witt
Co-Chair of SMDG, HHLA

Jasmin Drönner
EUROGATE

Thor Baungaard
EDI EXPERT


Transshipment White Paper
NEXT DAY
Welcome by the SMDG Board
25.04.2024
09:00 – 09:05
Meeting rule, off-limits topics, security note.Ann-Christin Fröhmcke
Co-Chair of SMDG, CMA CGM

Sönke Witt
Co-Chair of SMDG, HHLA
Keynote:
T-Mining Secure container release

25.04.2024
09:05 – 09:30
T-Mining, Antwerp based company, provides electronic solution for Delivery Order releasing.

Nico briefed the development of deliver order: From D/O on paper, 2010, replaced by PIN code, exchanged by COREOR EDI or email. However, faced with risk of PIN-code fraud. 2020, block chain token, came to Secure Container Release, which brough advantage and benefit for security and reliability.

SCR adopted in some big Shipping lines and terminal since 2020, connected to lot of consignees and freight forwarders.

Peter from MSC SSC introduced the usage in the company: adaptable solution to other port, full traceability within the system.
Make sure user don’t have access to the release data, restriction on user level, full tracing of user action.
High level of encryption in MSC systems, restricted access, decentralized release information. EDI COREOR goes via T-Mining / PORTBASE to customer / trucker.

Q&A section
– How is the process when trucker change. SCR could cover thanks to blockchain.
– Possibility to extend usage in deep-sea ports as well as inland ports.

Nico Wauters
T-Mining

Peter Pauwels
MSC
T-Mining Presentation
UN/CEFACT and SMDG collaboration – including Q&A
25.04.2024
09:30 – 10:30
Sue Probert:

Presentation of UN/CEFACT
Started with UN/EDIFACT
Over 1600 volunteer expert
Global in scope.
Deals with Trade facilitation and eBusiness.
Works with several organizations (see ppt)
Volunteer work.
What changed over the years is that now we speak about sustainability, but overall, the goal remained the same.
You can’t move goods if countries do not have an international transport contract system, including incoterms.

History:
Started in 1994, bringing 3 documents, and now provides data models.

The UN/CEFACT aims to harmonize the terminology across all the actors of the supply chain, on a multimodal perspective.

History of maritime standards:
Started with eBL in 1996,
250 code lists (incl. SMDG code lists)
Example of work on Maritime single window and transcaspian digital corridor.

Hanane Becha:

There is a global need for more traceability is expected, not only on the goods, but also the packaging.

Working a lot with other UN organisations.
Collaboration with SMDG:
SMDG endorsed by the UN/CEFACT.

History:
UNTDED created since 1970: Dictionary of data elements useable. Syntax Neutral
Support EDIFACT, but also JSON / XML.
Making sure necessary data is shared across the multimodal chain.
Support many conventions and technologies.

Example of the smart containers: started on the white paper of 20 page to explain what / why / how of the smart containers then proceeded with the business requirement specifics, the generic message structure (data element choice) and finally choose syntax (EDI, API).

Piergiorgio Licciardello:

The vision on future of EDI.
Introduced the GS1 and asked the question “Is EDI dead?”.

In total 46 EDIFACT messages with more than 130,000 users.
With each new tech come out -Internet, XML, SOAP APIs, blockchain, JSON, REST APIs, EDI is declared as dead.

Clarified that EDI is not a technology, it’s a requirement. API and EDIFACT are not competing technologies.

There should not be a no need to change what works.
Without need to replace, coexistence is the key. If the data if well framed, transforming a format to another one with AI is easy.

 Problem: Data model: example about item dimensions
UNTDED: length / width not defined properly.
GS1 definition provided, but different use case = different definition.
 Conclusion: acuter technology will continue to be relevant; data model interoperability is the key to the future.

Q&A section

Couple of questions raised to discuss why EDIFACT survived, pros and cons for both views.
It was highlighted that new generation prefer explicit data elements modelling.

Sue Probert
SEPIAeb Ltd & UN/CEFACT

Hanane Becha
DigitalTrade & UN/CEFACT

Piergiorgio Licciardello
GS1 & UN/CEFACT
UN/CEFACT Intro

UN/CEFACT Hanane Becha

UN/CEFACT Vision of furture EDI
HPDX platform presentation by Hutchison Ports ECT Rotterdam
25.04.2024
11:00 – 11:35
Boudewijn connected online.
HPDX- Hutchison ports is a data exchange platform.
Data unity: every terminal needed EDI translator, needed to centralize.
In addition, different TOS were to be considered.
Started 5 years ago in Sweden at HPH terminal, now in 23 terminals, in all continents.
As it is a data driven business, combining EDIs and APIs and applying set of rules was necessary.
Same validations are performed for EDI and API.
Started to manage the EDI, and then added API (following DCSA API standards).

 Status summary 4 phases:
– EDI translation to nGen XML,
– Reference data validation
– order processing,
– data monitoring by terminal, exception handling.

 Advantage of this centralization model:
– Standardization,
– modular setup,
– central validation of reference data,
– supporting multiple technologies EDI and API,
– easier connectivity option for customers and platforms.

Q&A section
Question raised from shipping lines about how to connect to the central platform directly.
The key is to have a good approach on both sides, involving the Shipping Lines’ HO.

Question from DCSA to terminals regarding the operational vessel schedule: What are the key difficulties for the different shipping lines.
The main answer was that IFTSAI is challenging, for example different definitions exist for different data.
As well the timing of receiving the information, frequency of updating.
It was also mentioned that the unique reference number implementation is in scope of all shipping lines.

Boudewijn de Kievit
Hutchison Ports ECT Rotterdam
SMDG Code Lists to API Presentation by the API workgroup including Q&A
25.04.2024
11:45 – 12:10
Ann-Christin introduced the background on how working group was formed.
2023 came a request from MSC to have all code list SMDG in API.
Some work was required for this, and a team was set up from SMDG and 3 biggest shipping Lines to work on the subject.

Pedro:
Need to connect Shipping Lines’ Master Data management to SMDG code lists.
Currently Excel file only was available,
which is complex to manage for the IT.

Jasmin:
Current situation for Liner code, is that its managed manually via excel and checks performed before adding a code (Liner / terminal code).

Sevak:
The team came up with a new solution, GitHub, to develop and contribute, ensure data is available accordingly to modern technological standards.

Rabab:
In this new version, changes are registered, new requests logged. It is also transparent and open.
An API layer was to be built on top of this. A data model was built to facilitate the creation of a swagger, including, Liner code, its status, validity, and other optional information for the change log. Several optional filtering options.

Sara:
Data model was inspired by the DCSA data model and created in mind to have a consistency with the future API build for SMDG.

Mark:
Terminal Code list is available, Liner code list is in progress. Future list may be added.

Q&A section

Question raised about how to host and maintain the API, how is the collaboration with BIC. However, all is not clear yet, discussion is ongoing. BIC expressed the will to support. Some other parties also showed interest to join the working group.

Ann-Christin Fröhmcke
Co-Chair of SMDG, CMA CGM

API Experts from MSC, MSK & CMA CGM
(Mark, Jasmin, Pedro, Sevak, Rabab, Sara, Cedric)

SMDG Code Lists via API
Invitation Empties and M&R workgroupMSC requested for other carriers to join the Empties and M&R workgroup by contacting Stefano.
Scope is for off dock depot, take the opportunity to develop our systems, to manage all business case of repairing cleaning container.
In 1989 WESTIM was created but it is just a protocol. Then UN/CEFACT DESTIM message was created in 1997but nothing new happened since.
4 members were interested.

If you are interested to join the M&R group, please email to Stefano.
Stefano Ottonello
MSC
Vessel Schedule – Panel discussion: Terminals, Mainliners, Feeders, PCS, Standardisation bodies
25.04.2024
13:30 – 14:45
Michael:
IFTSAI is managed by SMDG since long time, Michael oversees it.
 The goal of the IFTSAI is to transmit information about vessel schedule.
– Connecting vessel can be included.
– Each receiver can have different requirements.
Example of Rotterdam explained.

 SMDG current situation:
– IFTSAI MIG was published in 2005,
– 6 enhancements since, but new MIG still pending,
– In parallel, DCSA developed the OVS API
– New enhancement pending

Kristina:
DCSA, created 5 years ago by 9 carriers, provides API to the whole industry for free.
Provided an overview of the DCSA standards to date, which includes a Schedule API.
Vessel schedule split between commercial schedule and operational schedule.

OVS API scope:
This API is about the Operational Vessel Schedule.

Long term schedule (12 / 14 weeks ahead), Coastal Schedule (at the time of the last call of previous rotation), including changes and exception like phase in/out, delay, omit.

The Universal Service Reverence (USR) and Universal Voyage reference (UVR) are not yet provided by shipping lines, but should include planned, Estimated and Actual events.
The OVS API reuses the SMDG Liner and SMDG Terminal codes in the model.

USR: SR+5 numeric digit + 1 check character. Example: SR12345X
UVR: 2 digits for the year, 2 for sequence number, 1 character for the direction.
Example: 2438W

The USR deployment is making progress but will take time until full market coverage.
Services are all mapped but need to be requested if not mapped yet, especially for the feeders.

Q&A section
Regarding Multiple terminal call at same port, the standard covers this point by using the SMDG Terminal Code in addition to the UN/LOCODE for the port.

It was confirmed that you can provide the internal voyage reference in addition to the UVR.

Panel discussion on vessel schedule was held with Robert, Rabab, Thor, Shriram (PSA)


From the terminals:
The timeliness/frequency and accuracy of the data is important. Requirement is 2 weeks before arrival, the 3 days before arrival, and half an hour after any change.
The UVR/USR number is welcome and should be used for all communication.

Additional highlight was on the promotion of the IFTSAI “light”.

From the shipping Lines side:
Feeder communication is only 7 days in advance, then update 3 times a day. 3 days before arrival the schedule changes a lot. IFTSAI here is a good point, especially for connections planning.
It was noted that time API doesn’t solve all, but instead show the issues more rapidly. You need the data completeness. For example, missing the SMDG code makes the API fails, but also no input no API. It may also require internal process update.

Data is shared to the terminal, but there is no feedback from the terminal regarding the data quality.

In addition, the API/IFTSAI needs to be deployed globally to help everyone.

In case of local port visit ID, it’s also important that this info is transmitted by the terminal to the carrier.

A more general comment was made that Local agencies aren’t aware on Shipping Lines side of the system capabilities and process, to which it was reverted to always include the HO of the Shipping Line to get better expertise.
It was also requested to take the move count in account in the IFTSAI/API, however this should be part of the Consolidated Booking Forecast, which is currently planned by the DCSA.

Michael Schröder
Hapag-Lloyd

Kristina Jumelet
DCSA

Robèrt Roestenburg
RWG

Thor Baunsgaard
SMDG

Rabab Hayek
CMA CGM
Panel Discussion Schedules
Terminal Performance Reporting (TPFREP)
25.04.2024
15:30 -16:20
Information in TPFREP (terminal performance report)
Who is using:
– CMA
– MSK
– ZIM
– MSC
– HLC

TPFREP purpose: Terminal performance report to Vessel Operator / CO-loader, after ATD, incl. productivity data and equip movement summary.
Versions available: 3.1/D00B, 4.0/D11B, 4.1/D18A.
Benefits for terminal and for shipping line.
V4.1 published 2021, summary of changes and enhancements was presented.

Wishlist for next V4.2: Twin lift, dual action crane operations, shortshipped containers with reason.

Introduced SMDG working group: current members, welcome for more to join.

There is a pending request to standardize the TPFREP via excel.
Worldwide terminal 100 via EDI, 300 via excel.

Q&A section
There was a question on why excel format even exists. The reality is terminal TOS can’t do TPFREP. Then it’s easier to send excel. Possible that terminals aren’t aware of TPFREP functionality in TOS, so it’s always good to check.
However, SMDG does push for EDI deployment.

It was clarified that the pilot performance is not covered.

Proposal on Standardized Terminal Performance Metrics.

Shipping volume increases very fast, but Infrastructure does not, so efficiency need to improve.

To compare terminal performance.
SMDG draft contains 19 KPIs for example Cargo operation time, gross working time per vessel, crane intensity, etc.

Question to the audience, what is your opinion on developing standardized metrices for terminal performance?

Comment:
– Key is whether terminal is willing to adopt.
– From carrier: lost time, end up with no conclusion,
– debate on twin lift,
– From carrier: suggest adding crane split. Willing to standardized so to adjust in contract,
– From DCSA: implementation should be driven by terminals themselves instead of carriers, expect terminals to contribute,
– Carriers may have different requirements with more/less preference, so standardization is needed.
– PSA: some terminal may not comply. as good reference as starting point.
– From EMC: Terminal Convenience Restow, suggest adding safety restow as it became more and more, however, what is safety restow, definition is not clear, dispute on which party bears charge.

Michael Schröder
Hapag-Lloyd
SMDG#78 TPFREP
DCSA touchpoints with SMDG
25.04.2024
16:30-16:55
DCSA NEXT STEPS:
No standard without use of them.

Highlight on the cooperation with SMDG:
– same goals, same members, same scope, but working together.

 Development of 2024
DCSA has new partnership with PIL.

Last 5 years now:
Over 120M API call for track and trace
More than 100 stakeholders agreed on using EB/L.
Target is to increase external partnership.

 Focus 2024 on adoption:
Commercial schedule available and many trade partner asking for implementation.
Schedule and EB/L mainly.
Next:
New versions of vessel schedules, booking and EB/L.
Repository renewed, incl. Glossary of terms, business process, etc.


Mees van der Wiel
DCSA
Touchpoints DCSA SMDG
Final Recap and closing of the Plenary Meeting
25.04.2024
1655-17:10
Recap of the plenary

Feedback:
COSCO: Impressed by all the work done over the last week, learnt a lot, met a lot of people. Hopefully becoming member of the SMDG. Thank you to all the attendees.

Ann-Christin and Sönke:
Learnt a lot, lots of good exchanges.
Both expressed their thanks to the host and members.
Closing of the event.
Sönke Witt
Co-Chair of SMDG, HHLA

Ann-Christin Fröhmcke
Co-Chair of SMDG, CMA CGM

Download the Minutes as PDF