Sensors and Systems
Breaking News
ModalAIⓇ Launches Next Generation Starling 2 and Starling 2 Max NDAA-Compliant Development Drones
Rating12345SAN DIEGO – ModalAI, Inc. today announced Starling 2...
Draganfly, Doodle Labs, and UXV Technologies Collaborate to Enhance UAV Communication Solutions
Rating12345Innovative Collaboration Between Draganfly, Doodle Labs, and UXV Technologies...
Lynred wins Sentinel-2 NG mission pre-development contract to design advanced multispectral infrared detector
Rating12345Design of new high-resolution imaging device to meet European...
  • Rating12345

thumb)richard_proudthumb_julian_longsonOcean going ships are not presently required to carry tracking devices. But renewed interest in safety and security issues is generating growing interest in knowing where these vessels are located, and which is soon to be required. This poses many challenges because a system needs to be developed that integrates this information internationally, yet, remains sensitive to the needs of individual countries territorial waters and the shipping industry. Vector1 Media editor Jeff Thurston interviewed Richard Proud (left) of ComSine Ltd. and Julian Longson (right) of Pole Star Space Applications Ltd where both companies are developing these applications.

V1: Can you provide a short description about COMSINE and what it is that the company is involved in?

RP: ComSine is an SME based in the United Kingdom, incorporated in 2002 and focussing on two primary areas – mobile satellite communications and spatial information systems, including applications based on GNSS services. With respect to the spatial data we specialise in the application of open standards from the Open Geospatial Consortium (OGC).

In June 2008 we were acquired by 1Spatial, who have been involved in geospatial standards and the OGC for more than 10 years, and continue to focus on mobile satellite communication applications and geospatial information management, particularly in the field of sensor webs (described further below).

V1: Can you be more specific about your applications?

RP: On the satellite communications side of our business, we have developed a range of building blocks that will support the creation of private mobile data networks based on leasing bandwidth capacity from regional satellite operators. These building blocks include baseband processing hardware platforms for user terminals and channel units, and software modules implementing satellite modem signal processing and protocol stacks.

In conjunction with our RF and antenna partners we can offer a suite of end-to-end terminal and network components that will support low cost, low data rate communication services that are ideal for markets such as asset tracking and environmental monitoring.  In addition, through support from the European Space Agency we have also developed a suite of software components to allow construction of user terminals that are compliant with Inmarsat’s omni-class BGAN specifications.

Combining our mobile satcoms expertise with our geographic data interests, we are also involved in the development of products and services that use the OGC’s ‘Sensor Web Enablement’ (SWE) standards. These standards support the integration of environmental information gathered from heterogeneous sensors deployed in remote locations into one sensor network that is accessible via standard web-service-based user access and control. This is a very exciting area for us and perhaps could be the subject of another article in its own right!

In addition, our work in geographic information has also involved the management of Earth observation data and the ability to more easily access it through the application of OGC standards. We have also developed pilot Location-Based-Service (LBS) applications for the leisure marine community and a pilot dynamic routing service for use by satnav and logistics services – both using GNSS.

V1: Can you tell us a bit about your recent announcement in the field of ship tracking?

RP: Obviously at the heart of any tracking application is geographic data – both of the asset being tracked and how it relates to the world around it. These, combined with mobile data communications, are our core interests. The opportunity described in our recent press release is based on the International Maritime Organisation’s (IMO) Long-Range Identification and Tracking (LRIT) Regulation (SOLAS V/19-1), which requires that in general all commercial ships on international voyages should automatically transmit a geographic position report every 6 hours via a satellite communication system to a Data Centre (DC) established by the Flag the ship is registered to.

Other Flags can then request information from a DC on where certain ships are – many countries wish to know who is travelling within their waters; there are obvious practical safety and security reasons for this. We have therefore combined our spatial data analysis skills with our partner’s, Pole Star Space Applications, marine asset tracking expertise, to provide an operational LRIT-compliant service.

V1: Who would this application apply to and what does it involve?

RP: The LRIT regulation is directed toward SOLAS class ships; i.e. commercial ships that are greater than 300 tonnes. It is not relevant for inland water shipping, as it is oriented toward ocean-going vessels on international voyages. Each ship is equipped with a GNSS-based device that provides the ship’s positioning information, which is delivered to the ship’s parent DC via an onboard satellite communication system, such as Inmarsat SAT-C.

Our partner on the work is Pole Star, a company with a long history of providing commercial services for ship tracking. They have created an LRIT-compliant DC service where Flag states not wishing to develop or host their own LRIT DC, can use a ‘virtual DC’ established for them by Pole Star. Our component, the GeoZone Server (GZS), is a key element in the Pole Star DC service and is responsible for management of what is called the ‘Data Distribution Plan’ (DDP) and the checking of ships’ positions against it.

The DDP is a dynamic global set of data and rules that define, amongst other things, various geographic areas within which each Flag wishes to monitor ship traffic (e.g. territorial waters, coastal waters, etc.). Flags can set up standing orders, receive information on ships sailing to their ports, establish exclusions that disable reporting of positions to other Flags, etc.. The DDP is a highly complex live digital document and the GZS is responsible for maintaining it, under version control, within a DC. In addition the GZS is then used by its parent DC to perform a range of logic and spatial queries on whether a ship position can be given out to a requesting Flag – based on the rule-set and geographical zones defined in the latest DDP version.

{sidebar id=307}

V1: What technology is involved in this development?

RP: The GZS is a SOAP web service written in Java. It runs under JBOSS and is based on ORACLE database technology. DDP updates are issued to all DCs by the IMO’s DDP server as XML documents, compliant to the IMO’s LRIT schema. The GZS software runs under Linux and is deployed as a Virtual Machine. As well as being integrated into Pole Star’s LRIT DC services, it is also available for separate deployment as part of other third-party LRIT DC implementers who do not wish to worry about the complexity of DDP management. For further details on this, please contact either myself or Mr Julian Longson from Pole Star.

V1: We understand that the U.S. NAVSTAR satellite system will be used in this system, but what about GLONASS and GALILEO, are they involved? Does this mean a GNSS system will be developed?

RP: I believe that the LRIT regulation does not mandate use of any particular GNSS; obviously NAVSTAR/GPS is the most commonly used global system at this time, so the bulk of ship positions handled by a DC will be GPS-based for the foreseeable future. However, in the long term ships equipped with other GNSS receivers, such as Galileo, will also be compliant. Much will depend on the integration of non-GPS receivers with other ship’s equipment, such as satellite communication devices; it is common for these to have GPS tightly integrated with them.

V1: Where does data quality come into this work, since most ships probably aren’t interested in centimetre accuracy? Is EGNOS involved in this work?

RP: Very high positional accuracies for ships at sea in this particular application are not crucial. In other related marine tracking applications that of course may not be the case, for example monitoring of inland water ways, docking, berth management, etc.; although again many of these will still not require centimetre accuracies. I don’t know the precise figures, but many nautical charts are probably not accurate to that level anyway.

As described above, there is no need for EGNOS’s positional accuracy in the LRIT application, although certainly it has a role in those maritime applications where 1-2 metre positional accuracy is important – like navigation in small channels or inland water ways.

V1: What is the role OGC data standardisation or other standardisation efforts play in this work and why is that important?

RP: We do extensively use XML based on the IMO LRIT schema and we use Oracle’s spatial library, but the Pole Star DC and our GZS do not use OGC standards per se as we are not sharing geographic data with third-parties or having to visualise any such data either. However, Pole Star and ourselves are just beginning to engage in discussion about how such standards could play a roll in other asset tracking services offered by Pole Star.

Where OGC standards are used in the LRIT programme is in the upload of polygon definitions by a Flag to the IMO DDP server for inclusion in the DDP – these are required by the IMO to be in GML (‘Geography Markup Language’). This is an open standard for the description and storage of geographic vector data and coverages using XML.

OGC standards set out to promote interoperability in the storage, retrieval and online access to spatial data, including raster and vector digital mapping data, Earth observation data, data from environmental sensors, etc.. The use of these standards is certainly on the increase, with a wide range of open source and proprietary implementations on offer in the marketplace. Again, though, this is another topic in its own right . . . 


V1: Can this work be coupled to other work involving imagery?

RP: Not the LRIT regulation as mandated by the IMO. However, when it comes to giving context to a ship’s position (or indeed any moving asset), the use of imagery from satellites and aeroplanes can be very useful, e.g. to help show where a ship is exactly when it is in port. Some context applications will require frequently updated imagery and some less so – given that the major infrastructural layout of a port doesn’t change over many years. Of course GoogleMaps has been very useful here – the ability to see the real-world spatial context of something of interest anywhere in the world at the click of a mouse button is fantastic (even if sometimes the imagery is a little out of date).

Part of our GSA-funded ‘At-sea Leisure Information Service’ – a pilot LBS for the leisure mariner whilst at sea and based on assuming low bandwidth internet communications between boat and shore (e.g. via satphone) – included the option to request image snap-shots of ports and marinas listed in the sailor’s almanac. This is in addition to notices to mariners, chart updates, safety warnings, weather and tide information, etc..

———————————————————————————

Julian Longson – Business Development Director, Pole Star Space Applications Ltd
Richard Proud – Managing Director, ComSine Ltd

For more information:
ComSine – www.comsine.co.uk
1Spatial – www.1spatial.com

 

Leave a Reply

Your email address will not be published. Required fields are marked *