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.
Stefan Wiech of Hamburg Port Consulting says: “This 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.”
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: “What we advise is, test for integration, early on.”
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: “Some terminals even get good results from their single tests but find the combination doesn’t react well on go-live.”
Simply allowing TOS vendors to deliver new releases without running realistic scenarios is asking for trouble says Yvo Saanen of TBA. “A terminal needs to be keeping an eye on the vendors,” he says. “Unfortunately, quite often the vendors leave the bugs for the terminals to find.”
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: “If 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?” He explains that running an emulation check can tell you this “and also point out where the bottlenecks will be”.
Reality check
Both HPC and TBA have done a lot to create something that mimics reality. “Every 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,” 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.
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’.
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.
But, not everybody wants everything. John New was part of the TOS migration in MSC Terminal Valencia (MSCTV): “When 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.”
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.
Basics first
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: “MSCTV 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,” he says.
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.
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 “like a snapshot of the terminal” 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.
“You could immediately distinguish performance changes and see whether the TOS was hitting its contracted targets,” says Mr New. “It does give you a very good idea of the quality of the software.”
Breaking point
Not all TOS vendors are enamoured with the idea of someone trying to ‘break’ their system, says Mr Saanen: “We 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.”
Of course, emulation will point out issues that might only crop up every so often. “Emulations 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.”
But, according to Mr Saanen, vendors should be grateful for the feedback: “It’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.”
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.
Mr New’s experience is reassuring; he says since MSCTV’s TOS had well documented interfaces, the framework required low input from the operations team who were busy with TOS user acceptance testing and training. “Apart from the kick-off meeting, the set up and configuration was done remotely from Hamburg by HPC.”
Practice at the sharp end
Training is central to a terminal’s efficiency, says Yvo Saanen of TBA, “as typically the users will only make use of a very small proportion of the TOS’ capability”. He estimates this figure could sometimes be as “as low as 10%”.
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, “as the more senior users can have the most outdated approach”.
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 “although the differences, for example in load planning, can amount to double the efficiency”.
So, an emulation model, according to Mr Saanen, could keep an eye on more than bugs; it could even tune the TOS, as “a level, comparable and repeatable scenario” as a good way to make visible a whole range of hitherto buried skill sets.