Introduction
The forthcoming release of SmartTAS includes a major new enhancement over previous releases of the software. The features are collectively named “Truck and Trailer”; and they fundamentally affect how vehicles are represented within the software.
Previous Functionality
The releases prior to 18.3.3 there was a simple model of a vehicle in the software. The vehicle was considered a discreet, singular entity with a number of compartments for holding products. The registration number of the vehicle identified it completely. The number and size of compartments is assumed to always be the same for a given registration number.
The model although simple doesn’t work well when it comes into contact with the real world. Most road vehicles that are likely to be encountered by a terminal automation system in the 2020’s consist of a tractor unit and a trailer. The tractor unit can pull any trailer, which means that one day that vehicle could have a trailer with 3 compartments and the next day a trailer with 6. Our old simple model required a site’s operators to edit the vehicle details each time the vehicle arrived at site with a different trailer.
Truck and Trailer
The work MHT Technology have undertaken in 2022 has changed this simple model to allow a vehicle to be represented as a truck with zero or more trailers. By modelling the ability of trucks and trailers to be exchanged, the details of the trailer’s compartments can be decoupled from the registration plate of the vehicle pulling it. In the example above instead of re-entering vehicle details the truck and trailer are combined to create a whole vehicle. This combination could be made by the driver using the SmartTAS kiosk, or by the operator at the gate house using the SmartTAS client software. It is possible that vehicles can be configured automatically through interactions with a ERP system. Though this ability is governed by the type and configuration of the systems involved to be able to state this categorically.
The world is messy
During the designing of the truck and trailers feature, the software engineers explored the freedoms that new model offered. The first direction for exploration was to explore the variety of road tankers that are in use around the world and to build in support for these:
- Fixed body tankers, here the vehicle and its compartments cannot be separated (at least not without resorting to cutting tools)
- Fixed body tankers with a trailer, the engine has some fixed compartments, but additional capacity can be added using a trailer.
- Road trains, why limit the vehicle to one trailer? The Australians famously don’t.
All these road vehicle configurations are now supported by SmartTAS.
…and got even messier
With thoughts of Australian Road Trains in their heads the developers turned to consider non-road going transport. What about rail and water? The model nomenclature changed slightly, but the ideas expressed in the truck and trailer schema held.
By simply changing the terminology, the software can support terminal automation operations where products are received and despatched, by rail, road or water.
|
|
The motive force |
Carrying Device |
|---|---|---|
Generic Term |
Engine | Loading Part |
Road |
Truck | Trailer |
Inland Water |
Tug | Barge |
Rail |
Locomotive | Railcar |
…just when you thought it couldn’t get any messier
One facet of loading vehicles that we have encountered time and again is when drivers arrive at site with incomplete documentation or identification. In the perfect world of computers, missing pieces of data normally results in red boxes on forms and the user grumbling that the computer is not letting them proceed because it is obstinately requesting they enter the post code in the correct format. In the world where you are trying to shift critical supplies with the minimum of friction a lost RFID card causes havoc.
One way sites can get round the issue is to allow a site’s operator to facilitate the loading of the truck. This was poorly supported by MHT Technology terminal automation software and the work on supporting trucks and trailers allowed us the opportunity to fix that.
Facilitated Loading
The terminal automation software’s primary aim is to record the transaction that occurs when liquids are moved between a vehicle and fixed storage. Typically, the information that is collected from the bay incorporates the identity of the person on whose authority the liquids are transferred, and the identity of the vehicle involved. This information is commonly printed on the Bill of Lading, which is subject to legal requirements if, for instance, the products are hazardous (ADR regulations).
- What if a site operator’s identity is used to authorise operations at the bay instead of the driver’s?
- What if a site’s yard tractor takes the trailer to the bay?
In 18.3.3 these questions are answered by ‘Facilitated Loading’, which allows the driver and vehicle engine to be changed after the filling of the trailer. As ever the immutability of the data recorded at the loading bay is maintained, but now the documentation required for the driver to carry his load to its destination can be easily prepared.
Conclusion
With the release of 18.3.3 the features offered by SmartTAS and the facilities they afford MHT Technology’s customers makes for an efficient terminal operation. The previous features such as Vehicle Queuing and self-service Kiosk have been adapted to work with the new transport model. If you have any questions please contact us.
