How to integrate a port's VTMS with its command and control centre

What is a VTMS, and what does it contain?

A VTMS is the system behind a port's Vessel Traffic Service (VTS). The VTS is the service. The VTMS is the sensors, network, software and consoles the service runs on. Indian port documents use VTMS and VTMIS (Vessel Traffic Management Information System) for the same thing. The legal basis is SOLAS Chapter V Regulation 12, which lets governments set up a VTS where the volume of traffic or the degree of risk justifies it, together with IMO's Guidelines for Vessel Traffic Services, adopted as Resolution A.1158(32) on 15 December 2021.

DGLL's 2023 expression of interest (EoI) describes the three services a VTMS provides in a notified area. An Information Service makes sure essential information reaches the ship in time for decisions on board. A Traffic Organisation Service prevents dangerous traffic situations from developing. A Navigational Assistance Service supports decision-making on board and monitors its effects. The same EoI lists the components below.

The people matter as much as the kit. IALA, the International Association of Marine Aids to Navigation and Lighthouse Authorities, publishes the international standards for VTS. Its Recommendation R0103 covers training and certification of VTS personnel, R0127 covers VTS operations, and R0128 (Edition 5.0, December 2022) frames the functional and performance requirements for VTS systems and equipment. A VTS operator is a trained, qualified professional. An ICCC operator usually is not.

• Radar, often both X-band and S-band. Paradip's 2023 work order lists one of each.
• Automatic Identification System (AIS) base station, which receives the identity, position and voyage data ships broadcast
• Environmental, or hydro-meteorological, sensors: wind, visibility, tide and current
• Electro-optical equipment: daylight and thermal cameras on pan-tilt-zoom (PTZ) units
• Radio direction finders, which show the bearing of a vessel transmitting on VHF
• VHF radio communications, with recording
• Data processing and tracking servers, which fuse sensor data into one track per vessel
• The human-machine interface, decision support tools and external information exchange
• VTMS operator and supervisor consoles, networking equipment and servers

What does a port command and control centre contain, and why is it a different room?

A port ICCC, often called a CCC or Port Command Centre, covers the land side and the port as a business. Maritime India Vision 2030 (MIV 2030), the Ministry of Ports, Shipping and Waterways' 2021 plan, describes a state-of-the-art Port Command Centre 'handling feeds from CCTV, VTMS, etc. for video surveillance, emergency response activities and port operations management', as part of its Enterprise Business System programme for major ports.

Typical ICCC sources are perimeter and berth CCTV with video analytics, gate automation with RFID and number-plate recognition, access control, fire alarm and firefighting systems, power SCADA, GIS, and links to business systems. In India the business link is the Port Community System. MIV 2030 records that PCS1x was operational in 19 port communities across 27 stakeholder types, carrying vessel-related messages between ports and customs.

The two rooms answer different questions. The VTS asks: is every vessel in the VTS area moving safely right now? The ICCC asks: is the port secure, are its gates and berths working, and is anyone responding to the incident? IALA calls services outside the VTS that use its data 'allied or other services'. Its Guideline G1102 lists the port administration and harbour master, police, customs, terminal operators, pilots and tug companies among them. A port ICCC is one of these consumers.

What data should flow from the VTMS to the ICCC?

IALA Guideline G1130 (Edition 2.0, December 2022) lists the types of VTS data that can be exchanged with allied or other services. For the first two, voyage data and traffic image data, it points to R0145, the IVEF service, as the appropriate standard. G1130 also splits data by timing: real-time data that changes in seconds, and non-real-time data that changes over minutes, including static and historical records.

For most ports the useful set is small. The ICCC needs to know which vessel is where, what it is carrying in broad terms, and when the VTS raises something that needs a land-side response.

• Traffic image: position, course, speed and identity of each tracked vessel. This is IVEF TRACK and VESSEL data.
• Voyage data: destination, ETA, draught and dangerous-goods category. IVEF VOYAGE data. R0145 warns that this is entered by hand on board or in the VTS and may be wrong.
• Selected VTS alarms passed on as events: a vessel entering a restricted zone, an anchor drag, a vessel near a berth under maintenance. The VTS decides which alarms leave the room.
• Weather and tide readings, useful for crane wind limits and cargo operations
• Berth and pilotage schedule, usually from the port operations or berth-planning system rather than from the VTMS itself
• Camera cueing information, so a land-side camera can be pointed at a vessel of interest (see the CCTV section below)
• In the other direction: incident reports from the ICCC that the VTS should know about, such as a fire on a berth or a security alert at a jetty

What should not flow, and who stays in control?

Control of vessel traffic should not move to the ICCC. Resolution A.1158(32) defines the VTS provider as the entity authorised by the Government or competent authority to provide vessel traffic services, inside a formally declared VTS area. It says nothing in the Guidelines changes the master's ultimate responsibility for safe navigation. Instructions to ships come from qualified VTS personnel over VTS channels. A screen in another room should not be able to issue them.

IALA's G1102 sets the test for any link: the interaction should not affect the integrity of the services concerned, and 'VTS data input and output should not interfere with the VTS operational task.' Where data given to another stakeholder could change a vessel's behaviour, G1102 says both sides should co-ordinate so the vessel gets one unambiguous message. In practice that means three rules for a port.

• Read-only by default. The ICCC subscribes to the VTS picture. It does not write tracks, change alarm settings or edit vessel records in the VTMS.
• No VHF transmit from the ICCC on VTS working channels. The ICCC can listen to recorded audio after an incident if the port's procedures allow it.
• Camera control has a priority order. The VTS operator outranks the ICCC on any camera the VTS relies on. A vendor will rarely raise this unless the RFP does.
• Raw radar video normally stays inside the VTMS. It is heavy, it needs VTS software to interpret, and the ICCC does not need it to act.
• VTS tracks are not proof of position. R0145 notes that track data comes from fused, noisy sensors and is the best-effort representation of the true situation, not necessarily the truth itself.

How does IVEF actually work?

IVEF is a client-server service. The ICCC, as the client, connects to an IVEF server on the VTMS side and sends a Login message. If the server accepts it, the client sends a Service Request that sets three things: which objects (an area, or a filter such as ship length over 50 m), which information (track, vessel, voyage), and when (once on request, at a fixed rate, or each time the track updates). The server then streams Object Data messages. Ping and Pong messages act as a heartbeat. If the link drops, the client must log in again.

The server enforces what each client may see. R0145 says the server applies client-specific restrictions set by the data provider, held in a user database. This is how a VTS can give the ICCC a full picture of the port area while giving a shipping agent only its own fleet. Messages are XML. R0145 recommends TCP/IP for transport, TLS or SSL for encryption and ZLIB for compression, because 'the IVEF Service by itself has no provisions for data compression and encryption.' Its built-in authentication is a shared secret, which R0145 says can be replaced by certificates.

Three cautions. First, R0145 is Edition 1.1, first issued in June 2011 with editorial corrections in September 2020. IALA's 2023-2027 work programme includes reviewing it, with a revised Recommendation, a new Guideline and possibly an S-210 product specification as the output. Second, an IVEF claim on a datasheet does not prove two products interoperate, so require a joint test. Third, R0145 assumes both ends share a common UTC time reference, and recommends GNSS or NTP time at server and client.

Which standards apply to a VTMS-ICCC link?

No single standard covers the whole link. Each layer has its own, and the RFP should name them layer by layer.

Which integration level should a port choose?

Choose the lowest level that meets the ICCC's operating procedures. Each step up adds interfaces to test, people to train and paths an attacker can use. Most ports should start with data plus selected alarms, and add camera sharing once procedures for camera priority are agreed.

How should CCTV and slew-to-cue work between the two rooms?

Slew-to-cue means a camera swings to a target chosen on the map. Inside the VTMS this is standard. IALA Guideline G1111-6 on electro-optical systems describes a camera that, through integration with VTS target tracking, keeps a designated vessel at or near the centre of the screen while it is in range. G1111-6 also says camera control is from the VTS operator workstation.

Across two rooms, the same feature needs rules. The ICCC may want to point a VTS camera at a vessel near a berth fire. The VTS may want a berth camera to confirm a vessel's identity. Write a priority table into the RFP. VTS control wins on VTS cameras. ICCC control wins on land-side cameras. A takeover times out and returns the camera to its preset. Every move is logged with user and time.

Sharing video does not mean sharing the camera network. Pass streams through the video management system (VMS) at the boundary, and avoid putting VTS cameras on the ICCC's flat CCTV network. Day and thermal cameras on one PTZ unit are common. Specify which stream, day or thermal, the ICCC receives.

How should cyber security and network segregation be handled?

Treat the VTMS as operational technology and the ICCC as the more exposed system. IMO's MSC-FAL.1/Circ.3/Rev.4 defines OT as computer-based systems that control or monitor physical processes, and says OT should be segmented from IT systems, protected from Internet-facing systems and given appropriate protection tools. It also lists ship-port interfaces among the systems to assess. IALA's G1130 adds that VTS systems traditionally ran in closed environments and now need to share data, which calls for authentication and authorisation of external users, secured transmission such as a VPN, controlled access and audit trails.

Indian port specifications already reflect this. Paradip's 2023 VTMIS equipment list has separate DMZ, LAN and WAN network units, plus biometric access and CCTV for the command room, server room and power room. A demilitarised zone (DMZ) is a buffer network where the IVEF server or gateway can sit, so the ICCC never touches the VTMS core.

Both systems also fall under CERT-In's directions of 28 April 2022. Listed cyber incidents must be reported to CERT-In within 6 hours of noticing them, ICT logs must be kept for a rolling 180 days, and system clocks must be synchronised to NIC or NPL time servers or a source that does not deviate from them. The clock rule helps integration too: IVEF and G1130 both depend on accurate time stamps for sequencing, recording and replay.

• IVEF server or gateway in a DMZ. No direct route from the ICCC network to radar, AIS or VHF equipment.
• Firewall rules that allow only the agreed ports, protocols and source addresses, reviewed at acceptance
• TLS on the IVEF link, with certificates rather than shared passwords where both products support it
• Separate accounts per client system, with IVEF filters limiting each to its area and data
• Logs from the gateway and both systems sent to the port's security monitoring, kept for 180 days
• Patch and vulnerability management for the gateway, written into the maintenance contract

What is happening with VTMS integration in India?

DGLL's EoI of 6 November 2023 is the national driver. DGLL already runs the National AIS (NAIS) network of 87 base stations and a VTS in the Gulf of Kutch. Before issuing the EoI, DGLL asked each major port whether its VTMS had IVEF provision as per IALA, and for the make, model and year of its radar, AIS, VHF and IT equipment. The EoI records that the 12 major ports replied. It proposed interface units at each of the 12 major ports and a planned VTMS at Port Blair to ensure IVEF compatibility, with feeds carried over the NAIS network to DGLL's National Data Centre in Mumbai. From there the integrated feed would go to the National Maritime Domain Awareness (NMDA) Centre and the Mercantile Marine Domain Awareness Centre of DG Shipping, with a web-based feed for at least 30 user agencies. Bidders were asked for 3 years' warranty, 7 years' comprehensive maintenance, and OEM spares and software upgrades for 10 years. The EoI states it does not commit DGLL to proceed.

Port projects show the same direction. On 3 March 2023 Paradip Port Authority issued a work order, on nomination, to the National Technology Centre for Ports, Waterways and Coasts (NTCPWC) at IIT Madras for an indigenous VTMIS with five years' maintenance, at an estimated Rs 15.49 crore plus GST and other charges. Equipment was put at Rs 6.73 crore. The scope covers X-band and S-band radar, an AIS base station, VHF with recording, a meteorological station, tracking and database servers, 350 TB of storage, a video wall and command-room security.

At Visakhapatnam, PIB reported on 14 July 2025 that a Rs 15.83 crore VTMS had been operational since 10 July 2025. It uses a radar feed from the Indian Coast Guard, integrates AIS, radar and CCTV monitoring of all craft within port limits, and supplies data to the NMDA Centre in Noida in what the release calls 'IVTS format'. In November 2025 PIB reported that NTCPWC's indigenous VTMS was in service at Vizhinjam International Seaport, Kerala, citing OEM-independent interfacing of radar and voice data and full government control of source code.

For buyers asking who supplies VTMS to major ports, one route on the public record is nomination to NTCPWC, as at Paradip, instead of an open tender. The route changes what is left for others to build. Paradip's work order leaves civil works and MEP (mechanical, electrical and power supply) works with the port, with NTCPWC giving advice. Those are the works around the command room and its power, which a port then buys separately.

What should an RFP for VTMS-ICCC integration say?

The RFP should define the interface, the authority boundary and the test, in that order. Datasheet claims of 'IVEF compliant' or 'ICCC ready' mean little without them.

• Interface control document: an IVEF service profile per client (area, objects, data items, update rate), every event message, every video stream, with versions
• Authority statement: VTS operators keep control of vessel traffic, VHF and VTS cameras. The ICCC link is read-only unless a named function says otherwise.
• Camera priority table, takeover timeout, return-to-preset and logging for every shared camera
• Alarm list: exactly which VTS events go to the ICCC and which ICCC events go to the VTS, with who owns the response
• Network design: DMZ gateway, firewall rule set, TLS, separate accounts, and no direct ICCC route to sensors
• Time: both systems synchronised to NIC or NPL time, and a maximum allowed offset at the boundary
• Availability: what keeps working in each room if the link or the other system fails. The VTS must run normally with the ICCC down.
• Acceptance test: a joint interoperability test between the actual VTMS and ICCC products, including link loss, reconnection, overload and wrong-login behaviour
• Data retention and access: how long shared tracks, video and alarms are kept, who may replay them, and the audit trail
• Maintenance: one named party responsible for the interface across both vendors' updates for the whole contract

How Ahuva approaches port command centres

Ahuva has built command and control centres since 2015, when it delivered its first, for the Visakhapatnam Port Authority, with integrated security systems across the port estate. Its ICCC scope covers centre design, video walls, consoles and AV, and the integration of CCTV, GIS, IoT, SCADA and analytics, with incident management.