After a terminal signs on the dotted line, TOS vendors pretty much take control, eventually delivering a box of tricks for a handful of facility staff to put through its paces.<\/p>\n
Stefan Wiech of Hamburg Port Consulting says: \u201cThis kind of testing can come down to putting one container through the TOS, a crane checker manually entering the number on a remote, then the RTG or straddle carrier is watched as it picks it up. Nothing like normal conditions.\u201d<\/p>\n
Although a certain amount of manual testing is necessary, relying entirely on this approach avoids looking at the cats-cradle of systems that usually characterises a terminal’s IT: \u201cWhat we advise is, test for integration, early on.\u201d<\/p>\n
Mr Wiech has seen productivity unexpectedly drop in more than one terminal because the test team only focused on the TOS and not it’s multiple interactions with autogate, handling equipment orders and, in the case of automated terminals, the ASCs: \u201cSome terminals even get good results from their single tests but find the combination doesn’t react well on go-live.\u201d<\/p>\n
Simply allowing TOS vendors to deliver new releases without running realistic scenarios is asking for trouble says Yvo Saanen of TBA. \u201cA terminal needs to be keeping an eye on the vendors,\u201d he says. \u201cUnfortunately, quite often the vendors leave the bugs for the terminals to find.\u201d<\/p>\n
Both he and Mr Wiech agree that running an emulation, which allows the user to push the TOS around without the risk of impacting real operations, is the only way to properly evaluate what’s happening – and plan for the future. Mr Wiech adds: \u201cIf you have a greenfield terminal you may be aiming at 3m teu a year but of course you start off with smaller volumes, 200,000 or 300,000 teu for the first year or two… will the TOS be capable of handling your target figure?\u201d He explains that running an emulation check can tell you this \u201cand also point out where the bottlenecks will be\u201d.<\/p>\n
<\/b><\/p>\n
Reality check<\/b><\/p>\n
Both HPC and TBA have done a lot to create something that mimics reality. \u201cEvery point the terminal needs input, we have provided a simulation, for example manned straddle carriers pick up and ‘read’ the work order, then ‘drive’ the container to its target position. It simulates interventions by the drivers and even simulates the twistlock handling,\u201d says Mr Wiech. The models even incorporate realistic downtime rates for the handling equipment. Getting hold of solid input data is always a challenge, so HPC’s emulation can firstly be run as a recorder to pick up the data from a live shift; this can then be tailored to cover all necessary variations.<\/p>\n
These emulations can be anything from basic to all-singing: TBA’s CONTROLS is on the ‘sophisticated’ end of the scale: it has a whole library of different driving and operational behaviours, and it includes container, stack, interchange zones and multiple parameter settings, plus to date, it’s been integrated with eight different TOS\u2019.<\/p>\n
It can be used for more than the commissioning stage, helping to grow the operation as even progress can open up holes for productivity to slip through; for example, stack changes may yield benefits, but would equipment pooling then be as efficient? Without an emulation to carry out dry runs, there’s no effective way to evaluate the cascade of combinations.<\/p>\n
But, not everybody wants everything. John New was part of the TOS migration in MSC Terminal Valencia (MSCTV): \u201cWhen you start to look at ways of testing the TOS there’s such a range, at the bottom there’s testing individual messages routed to individual modules, at the other end you have very in-depth emulations which you can even train on, but you can spend huge amounts on these. And in MSCTV we wanted to find a midway point.\u201d<\/p>\n
He adds, for example, that though HPC’s system was not as configurable as some of the other, larger offerings it came at a fraction of the cost and MSCTV concluded there was functionality that it simply didn’t need.<\/p>\n
<\/b><\/p>\n
Basics first<\/b><\/p>\n
In the end it came down to some basics: the terminal needed to be able to evaluate configuration changes and, given its ambitions for the future, the system’s scalability and performance: \u201cMSCTV is already at around the 1.5m teu volume level already, so we made sure that the TOS was future proofed to handle the 2m teu level,\u201d he says.<\/p>\n
Alongside this, the terminal also wanted to stress test not just the TOS, but the CPU, database, servers and backup failover modes by ramping up the input to mimic intense scenarios. After all, as Mr New says, it’s when operations reach a peak that you really want to be sure they work.<\/p>\n
However, as many people know to their cost, when it comes to software one mend can spring holes somewhere else: so MSCTV also needed a way to see if the latest software patch was enhancing, or hindering, operations. To this end, a dataset \u201clike a snapshot of the terminal\u201d provides a baseline to check the TOS operation against, as part of the quality assurance plan. After each patch or update, this dataset is run through the system.<\/p>\n
\u201cYou could immediately distinguish performance changes and see whether the TOS was hitting its contracted targets,\u201d says Mr New. \u201cIt does give you a very good idea of the quality of the software.\u201d<\/p>\n
<\/b><\/p>\n
Breaking point<\/b><\/p>\n
Not all TOS vendors are enamoured with the idea of someone trying to \u2018break\u2019 their system, says Mr Saanen: \u201cWe had a great many issues, especially in the beginning, as some TOS vendors argued certain problems would only occur in emulation. But then on two occasions a terminal was forced into an eight hour or more shut down by something that the emulation had already identified but that had been ignored.\u201d<\/p>\n
Of course, emulation will point out issues that might only crop up every so often. \u201cEmulations can cover a lot in one run, and of course the issues don’t occur immediately, maybe only arising after a busy six hour shift.\u201d<\/p>\n
But, according to Mr Saanen, vendors should be grateful for the feedback: \u201cIt’s an additional way of accepting a system. Next to finding bugs, you can also determine how a TOS performs, a terminal can say, ‘you promised this, but I’m only getting that’, so it’s a valuable tool.\u201d<\/p>\n
In terms of timeline, each emulation varies, but it seems that getting it in at the earliest, ‘stable’ moment is a good idea; CONTROLS for example, is ready to test or tune in four to six months – though the workload is TBA’s as it carries out integration, configuring and validation of the model.<\/p>\n
Mr New’s experience is reassuring; he says since MSCTV\u2019s TOS had well documented interfaces, the framework required low input from the operations team who were busy with TOS user acceptance testing and training. \u201cApart from the kick-off meeting, the set up and configuration was done remotely from Hamburg by HPC.\u201d<\/p>\n
Practice at the sharp end<\/strong><\/p>\n Training is central to a terminal’s efficiency, says Yvo Saanen of TBA, \u201cas typically the users will only make use of a very small proportion of the TOS’ capability\u201d. He estimates this figure could sometimes be as \u201cas low as 10%\u201d.<\/p>\n While a similar TOS roll-out is often carried out across different terminals to save on duplicated time and effort, flying in more experienced people from other terminals to pass on their expertise may not have the desired effect, says Mr Saanen, \u201cas the more senior users can have the most outdated approach\u201d.<\/p>\n However, even during normal running it’s almost impossible to evaluate the effectiveness of various personnel because no two operations are ever alike; he says this state of affairs results in very little best practice sharing \u201calthough the differences, for example in load planning, can amount to double the efficiency\u201d.<\/p>\n So, an emulation model, according to Mr Saanen, could keep an eye on more than bugs; it could even tune the TOS, as \u201ca level, comparable and repeatable scenario\u201d as a good way to make visible a whole range of hitherto buried skill sets.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":" TOS development remains a dark art for most terminals, but it needn\u2019t be explains Stevie Knight<\/p>\n","protected":false},"author":8,"featured_media":4083,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[41],"tags":[],"sponsor":[],"class_list":["post-4082","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-bulk-handling"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.portstrategy.com\/coastlink\/wp-json\/wp\/v2\/posts\/4082","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.portstrategy.com\/coastlink\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.portstrategy.com\/coastlink\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.portstrategy.com\/coastlink\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/www.portstrategy.com\/coastlink\/wp-json\/wp\/v2\/comments?post=4082"}],"version-history":[{"count":1,"href":"https:\/\/www.portstrategy.com\/coastlink\/wp-json\/wp\/v2\/posts\/4082\/revisions"}],"predecessor-version":[{"id":4084,"href":"https:\/\/www.portstrategy.com\/coastlink\/wp-json\/wp\/v2\/posts\/4082\/revisions\/4084"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.portstrategy.com\/coastlink\/wp-json\/wp\/v2\/media\/4083"}],"wp:attachment":[{"href":"https:\/\/www.portstrategy.com\/coastlink\/wp-json\/wp\/v2\/media?parent=4082"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.portstrategy.com\/coastlink\/wp-json\/wp\/v2\/categories?post=4082"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.portstrategy.com\/coastlink\/wp-json\/wp\/v2\/tags?post=4082"},{"taxonomy":"sponsor","embeddable":true,"href":"https:\/\/www.portstrategy.com\/coastlink\/wp-json\/wp\/v2\/sponsor?post=4082"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}