Iranian AIS “spoofing”?

Recent reports (here, here and here) say that Iranian tankers are transmitting “false” AIS data in order to try to evade sanctions on trade. Reading the press reports, it’s kind of confusing what is actually being “spoofed” and whether they are even referring to AIS. This article from Reuters (linked through the always-informative gCaptain) says “AIS” but the description is more appropriate to LRIT: “sending incorrect satellite signals that confuse global tracking systems” and “Large vessels must transmit their identity and location to other ships and coastal authorities using an automatic satellite communication system.”  There’s a bit of confusion in the article beyond what actual tracking system is being used. One quote implies the ship’s GPS can falsify its identity: “a ship could get its Global Positioning System (GPS) to give false data, including pretending to be another vessel.” GPS only provides position data, not identity. It is either the AIS equipment or LRIT system on board that provides identity (which as correctly noted in the article is input by the crew and can be fairly easily altered). The article includes a false statement: “However, another piece of identification data, the IMO [number], can’t be changed, and that, too, is sent with every message on position, which enabled vessel-tracking experts to detect that signals came from two different ships.” The IMO number can indeed be changed in the AIS static and voyage-related message (not the position report, which doesn’t include the IMO number). So it’s just as “spoofable” as the MMSI, vessel name, dimensions and all the other information that is manually entered in the AIS.

This article uses the term “AIS” and says “…Iranian tankers [are] sending false AIS signals and somehow being in two places at the same time” but there is little more information. If “being in the same place at the same time” due to duplicate MMSIs being transmitted is suspicious behavior, then there are a lot of suspicious vessels out there. Many vessels are transmitting bogus MMSIs in their AIS messages, unintentionally either through laziness (entering “123456789,” “111111111” or something else rather than the actual MMSI), honest mistake (transposing or forgetting to enter digits), or a fault with the AIS equipment itself (the infamous 1193046 is the default MMSI for a certain type of unit that is reset when the unit is power cycled.).

Both of these articles are written from the perspective of external (i.e. shore-based) systems that collect data and create vessel tracks. From nearby vessels it is not a huge safety issue (except if vessels are attempting to hail each other to make passing arrangements and one of the vessels’ name is falsified). It is also readily apparent the information is incorrect when the vessels are in sight.

To a certain extent, this incident validates an argument made in the early days of Maritime Domain Awareness (MDA). Many were arguing that LRIT, AIS and other tracking measures were redundant and that only one or two capabilities should be focused upon. Others argued that with multiple systems, there was more opportunity for “bad guys” to make errors – e.g., “spoof” an incorrect MMSI but neglect to change the IMO number to match it (as appears to be the case here). This actually makes detecting spoofing easier, as such anomalies would stand out (unless of course it’s so complicated that every vessel, legitimate or not, can’t help but make mistakes).

In any event it is clear that AIS is no panacea, and that those unfamiliar with the technology and its use can easily misunderstand the implications of incorrect data – whether intentionally transmitted or otherwise. It’s good to see that the potential “spoofing” was detected and there ought to be additional efforts dedicated to analysis of AIS data – in conjunction with other information – to detect problems, sinister or otherwise. Finally, as AIS technology matures and “next generation” AIS is developed, security and data integrity need to be addressed, as Kurt Schwehr has noted. I hope to look into this some more in future blog posts.

Week in Review – 03-09 December 2012

Main focus and events this past week:

• 03 Dec 12: CMTS e-Nav IAT chairman’s meeting – discussed upcoming meetings and efforts following e-Navigation 2012 conference
• 04 Dec 12:(1)  NTSB GIS conference – interesting gathering to present uses of GIS in transportation safety in all modes. Unfortunately missed Maritime portion on Wednesday morning; but hope to catch up through archived webcast. (2) LOMA coordination and governance meeting.
• 05 Dec 12: Federal Initiative for Navigation Data Enhancement (FINDE) meeting – Regular meeting of interagency group working to harmonize Government navigation data standards. Promising reports on efforts, including prototype establishment of industry reporting portal and provision of various web services for navigation information.
• 06 – 07 Dec 12: Various e-Nav and AIS work, including participation in phone conference to discuss work needed to get transmission of weather data via AIS in Alaska set up. Interesting public-private partnership opportunity between Marine Exchange of Alaska, National Weather Service and USCG.

The week ahead:

• 10 Dec 12: Work on a blog post or two, preps for CMTS, USACE, USCG and RTCM meetings. Oh and this as well as other holiday preparations!
• 11 Dec 12: CMTS Bagel Breakfast, e-Nav IAT and WG meetings. Also working with USCG on a joint article for the IALA Bulletin on transmission of various navigation data via AIS in the US inland waterways system.
• 12 Dec 12: RTCM SC123 meeting. Briefing to USACE Chief of Ops on LOMA status and requested support.
• 13 Dec 12: USCG-USACE AIS coordination meetings; RTCM SC121 meeting to adjudicate comments on SC 12100.0 standard “For creation and qualification of application-specific messages.”
• 14 Dec 12: This and catch up from the rest of the week; hopefully also get a batch of Altbier brewing.

On the horizon:

• 17-20 Dec 12: RIS and e-Nav work in Mobile, AL and Vicksburg MS
• 24-28 Dec 12: Holidays!
• 14-17 Jan 13: TRB annual meeting
• 29-31 Jan 13: e-Navigation Underway conference

Post-Sandy weather review

I started this post the day after Hurricane Sandy brushed past, but had forgotten about it. Perhaps it will be of interest even though it’s a bit out of date.

Here are a few pieces of information I had my hands on over the past couple of days as Sandy went by. I have a weather station and had my eyes glued to it as the storm came through.

Some weather station plots for the days prior to and just after the storm:

You can see very clearly when the storm came through by the various plots – deep “valley” in barometric pressure (new record low for my station – 961.59mB) and a peak in rain rate and wind speed. Curiously, there wasn’t a wind speed record set – it may be that we were on the “good” side of the storm, or it may be that my anemometer was malfunctioning – I replaced it a few days later.

I use Lightsoft Weather Center (LWC) software; unfortunately the developer got very ill and no longer supports the software. It still works fairly well, but I may need to replace it as it ages.

GRIB weather data (as presented on MacENC)

I don’t know much about GRIBs, and my area of interest in weather data is usually much smaller  than their resolution provides, but with the size of Sandy it really shows a good overview of the forecast conditions.

And below is some history for comparison: a few scans of old weatherfax sheets from a ship I was aboard in the mid-1990s in Alaskan waters. We frequently had strong non-tropical storms. Sandy’s lowest pressure was 943 mB; the lowest I recorded during Sandy was 961.59 mB.

Here’s a wicked looking 964 mB low from October 1995 (I think – may have been 1994?)

And here’s a 946 from December 1995(?)

This may have been the one where we holed up in Lost Harbor, Akun Island near Akutan Harbor and anchored in a sheltered bay where we saw sustained 80-knot winds. These storms are very different than hurricanes – “cold core” vs “warm core” and tend to come through in “trains” across the North Pacific.

A visit to the Ballard Locks

When I was in Seattle a couple of weeks ago (but not for this) I had the opportunity to visit the Ballard Locks again. This year was special, as they had the main chamber dewatered. After visiting the beautiful Administration building and the control tower, I was able to climb down into the main lock chamber and check it out.  Here are a few photos from the visit:

The foyer of the Administration building. Looks good now; it was even nicer last year when it was decorated for the holidays.

The dewatered main chamber as seen from the control tower. The gulls are enjoying dining on all the exposed sea life.

The east end of the main chamber has a saltwater barrier on the floor; it’s buoyant and normally angled up (you can see the scrape marks on the far wall) and acts to keep heavier saltwater out of Lake Union and Lake Washington.

View of the empty chamber from the chamber floor. Note the filling ports ont he left and right – there is a man-sized entrance just out of sight to the right that we went through and saw the filling tunnel. There is a cable on the floor in the center of the chamber; apparently that was lost or discarded by a tug and tow sometime since the last dewatering.

A couple of views from inside the filling tunnel – hard to see anything, as it was dark in the tunnel (duh) and the flash didn’t help. The first image is looking at the end of the tunnel where the water comes in from the upstream side; the lower one is one of the filling ports from the inside – this is the man-sized port that we walked through to get from the chamber into the tunnel.

Lots of aquatic life was exposed in the dewatered lock. Pretty much all underwater surfaces were covered with barnacles; sometime several inches deep. Part of the maintenance is to scrape them off – very laborious work. There were a lot of fish and crabs – you can see a crab pot that was lost in the chamber in one of the photos; perhaps you can make out some of the fish including flounder that blend in very well with the bottom.

A view of the locks from the south side. The lock grounds are almost entirely open to the public and are very well-maintained. The locks and fish ladder (just out of view to the right in this photo) are the second most popular tourist site in Seattle (after the Space Needle). I definitely recommend a visit!

Thanks to the guys at the locks (and I hope you get your LOMA unit installed soon!)

e-Navigation, ECDIS and iPhone maps data errors

I delayed updating my iPhone 4s to iOS 6 as I had heard complaints about the new Maps app. Apparently Apple has created their own and gone away from the original Google Maps-based app. However, my compulsion to keep my software updated overruled my reluctance, and I upgraded and found it wasn’t that bad. The car-GPS-like directions are pretty cool, and I haven’t had some of the problems I had feared, such as lack of points of interest. I haven’t used it too much, so we’ll see how it works once I travel some more and use it in places I’m unfamiliar with to try to find things.

One problem I have noticed (that is a real howler IMHO) is the misidentification of a place that is fairly well-known and documented (see image at right). “East Patomic Park” is how it shows up in the new Maps app; right next to the “Potomac River.”

I’m really scratching my head how this could happen, as it’s not a new park – it’s spelled correctly on the USGS topographic map (image below) which was compiled in 1965 (and updated in 1983, though not the park). I thought most digital map data was taken from these sources as well as drawn from public map databases, such as those maintained by USGS, NOAA, Census and others.

For what it’s worth, here’s what the same area looks like in Google Maps (since I don’t have the old Maps app anymore):

So, what does this have to do with e-Navigation and ECDIS (the supposed topic of this blog, or this post, at least)? Well, I think it illustrates one of the main challenges that will be faced in the implementation of e-Navigation. One would think that relatively minor issues such as this would have been worked out by now – the locations haven’t changed in many years, electronic maps have been around for a couple of decades at least, and with the ability to cross check multiple data sources errors like this shouldn’t last long. But they still do, apparently.

This should cause concern for those who seek to implement e-Navigation. End users (navigators, VTS officers, dispatchers, regulators, etc.) need to rely on the information that is being presented to them. They way to do this is through a well-thought out data architecture that needs to include common data formats and identification of authoritative sources. The authoritative sources, or “data stewards,” need to ensure the data they are responsible for is correct and there is a means for flagging incorrect data and pushing updates in a prompt manner.

Much easier said than done, I know, but fortunately there are concerted efforts to tackle this problem. Internationally, the e-Navigation Architecture is a key part of IMO e-Navigation development. In the US, the Federal Initiative for Navigation Data Enhancement (FINDE) is working on US-specific data architecture efforts. This is the least “sexy” work there is in e-Navigation, however I contend it is the most important. Since the definition of e-Navigation is “harmonized [management and exchange] of navigation information,” the integrity of that information is of paramount importance.