The journey of CONTROLS: 10 years

Introduction

We have to go back to 2003, when we started to develop the first emulation model for a container terminal. At that time at ECT Delta terminal (Rotterdam), a replacement of the TOS and Equipment Control System (ECS) were planned. In order to obtain preliminary performance results simulation models both for the TOS and for the ECS were created. However, the scope and accuracy of the simulation models lead us to use them as testing tools as well. As both the TOS and ECS development ran in parallel, both development teams were in need of realistic test tools, and hence we used the decoupled simulation models of TOS and ECS in ‘emulation mode’ as each other’s test tools. This comprehensive way of testing did not exclude the traditional testing of the real TOS and ECS, instead, it accelerated the whole testing process and saved time and money.

This experience triggered us to create a generic emulation product of which we saw a lot of value adding for the maritime industry, where software is mission critical.

Since then, our emulation product CONTROLS has come a long way. More than 50 terminals, over 90 projects, and many implementations of mission critical software – covering 8 different TOS so far - have made use of CONTROLS in some form. It took until early 2006, when our current CONTROLS library was founded. After a few years experimenting with the concept, struggling to get reliable connections to the TOS, a Java-based productized implementation of CONTROLS was created.

Since then, CONTROLS has developed to an environment with in the middle still a terminal emulation model, but now surrounded with many value-adding modules, as described in the timeline below. Also, the scope of using emulation has expanded from a pure test tool, to a tool suite that enables fine tuning of algorithms and parameters in the TOS (and in some cases the ECS), as well as training users of the mission critical software. For the latter purpose, we introduced a Training Manager, allowing to configure complex and nasty situations to be solved by the future system operators.

Not an easy journey

Although we are now proudly celebrating “10 years CONTROLS”, the journey was full of obstacles. As simple as it seems to link a TOS to a model of terminal operations, the complex it turns out to be. Bringing live operations into a lab environment, with the intention to run long (> 8 hours) unattended runs, means the systems have to be able to run for that amount of time in a flawless manner. It also means that the data needs to be solid. Both requirements are not met in reality. Most TOS cannot run without regular attendance of operational staff. Besides, operational data from a terminal environment has only limited quality.

In spite of all these difficulties we did not gave up; quite the opposite. Truly believing in the concept and its high value to the maritime industry we have kept going, implementing all kind of exception handling capabilities that are necessary to handle incorrect data, and incorrect (TOS) software behavior. We found that most TOS are not built to run in an unattended fashion, yet require regular intervention from control room operators, or equipment drivers. Especially when more advanced modes are tested (e.g.  dual cycling, twin-lift or twin-carry) and vehicles start arriving out of sequence (a normal day scenario in reality), the instructions of TOS may become confusing; something our automated test environment needs to be able to deal with.

Timeline

Over the course of the CONTROLS lifetime, the CONTROLS suite has been further expanded. The central theme has been to facilitate the ease of use of emulation. After all, running emulation experiments with the TOS fine tuning parameters of advanced modules, and testing more advanced functionality is not simple at the least! Yet, we intend making it possible for terminals with a dedicated team of analysists to do it on their own, which has been proven to work.

Figure: CONTROLS product timeline

In order to follow an emulation experiment and validate the operation procedure a 3D visualization tool called Replay Animator has been introduced in 2006. This tool gives the possibility either to follow a live experiment or to replay an old experiment. The tool is implemented on top of a gaming engine (OGRE) and provides a beautiful animation.

Typically, a TOS does not generate detailed operational statistics. Therefore, in order to analyze the results of experiments, we introduced in 2007 the KPI tool. The goal of this tool is to create detailed statistical reports that can be analyzed through a large set of statistical charts. The tool contains a comprehensive set of reports such as, equipment productivity, status distribution, travel distance, cycle time, equipment running hours, detailed equipment behavior, filling rate of the yard, and so on.

In order to obtain accurate results, typically a large amount of experiments with different configurations are carried out. Therefore, for efficiency and simplicity purposes we aimed to run these experiments in parallel, and control the configuration and runs from one single place. In order to achieve this goal, a tool called MONITOR has been developed in 2008. The early version of this tool has primarily supported only SPARCS 3.7, latest versions were enriched to support also N4, TEAMS and ZODIAC.

The first step when creating a CONTROLS emulation model, is to create and configure the terminal layout and equipment. We usually obtain from the terminal a CAD file that contains the terminal layout. In early years the creation of the layout for CONTROLS based on the CAD file, took significant time. That triggered us to create a graphical tool that provides an easy way to the user to create and modify the layout and equipment configuration. Therefore in 2009, we launched the Graphical Terminal Editor. Since then the tool enriched significantly providing more and more support for the user, such as 3D preview or export in CAD file.

While the KPI tool provides support to create statistical reports, we needed something different that is able to analyze huge log files produced by CONTROLS. In 2009 the Log Analyzer Tool has been launch which provides great support to analyze the quality of experiments.

In order to carry out a CONTROLS experiment, we need to configure the emulation model and the TOS. As mentioned above, the configuration of the model (layout and equipment) is carried out using the Graphical Terminal Editor. The configuration of the TOS is happening through operational data. The operational data is usually obtained from the terminal by exporting from their production TOS. In some cases however, if there is a new TOS or a specific case that need to be tested the operational data cannot be obtained from the terminal. In this case there is a need to create the operational data by TBA. For this purpose a tool, called Dataset Editor, has been created that supports the creation of operational data. This operation data forms the input for Plan Validation (see below) that can run together with CONTROLS.

As mentioned above, the journey was not easy especially when long unattended runs had to be performed using polluted operational data. This ‘pollution’ is usually corrected in a live operation, but during unattended emulation, this causes failed experiments. In order to improve the efficiency and effectiveness of testing we created a tool that removes those mistakes from the operational data in advance. For this purpose the Cleanup Tool has been introduced in 2012. The tool gets as input the original operation data and by running correction apps it approaches the TOS to support correction of the found mistakes.

Although the Cleanup Tool is doing a very good job, complex planning mistakes, such as clashing cranes, cannot be corrected with the help of Cleanup Tool. These kind of complex planning mistakes require manual intervention and a planner that can correct the mistake. For correcting complex planning mistakes another tool called Plan Verification tool was introduced in 2013. This tool uses the Cleanup Tool as the first step in order to clean the original dataset from basic mistakes and after that runs the planning apps to identify the complex planning issues. The tool creates a detailed report with all found planning issues for the planner that can manually re-plan in the TOS.

The latest tool we have been working and we plan to launch soon is the Plan Validation Tool. This tool goes one step further than the Plan Verification to provide feedback about quality of the operational data. Before running an emulation with CONTROLS and a real TOS based on the operational data cleaned by the Cleanup and Verification Tool, we plan to run a large amount of experiment with CONTROLS and a simulated TOS based on the same operational data. Using this intermediate step we expect to run significantly faster than real time so the user can identify the expected issues in an early phase.

Outlook

In the coming 12 months, we intend publishing a number of case studies around the use of emulation, and in particular CONTROLS and the above mentioned supporting tools. We take the readers around the world, starting in Europe, followed by North America, Latin America, Asia, Oceania, and finally in Africa.

This article has been published in Port Technology Magazine in February 2016.