A concern commonly raised during discussions around electronic navigation systems is the way that they can contribute toward incidents. The scenarios usually revolve around lack of training and an over reliance on the computer software. In fact several grounding incidents have been directly attributed to this. In each case the ECDIS was not correctly set up for the conditions, presumably because it was not well understood. At the same time other more traditional approaches to navigation such as looking out of the window were being neglected. The inevitable result is a lot of unhappiness.

So what is really going on here? How come a system which is designed to make navigation safer is causing problems instead?

First off, we should probably assert that electronic chart systems are, for the most part, a big benefit. Very basic properties such as accuracy of positioning and ease of chart updating set such systems head and shoulders above paper charts. I can go on with a long list but you probably already know it. So where is the downside? At CherSoft, there are two issues that we are very aware of: first up the screen is not as big or clear as a paper chart, secondly the user interface can act as a barrier. Good software should be mitigating these issues by making optimal use of the screen real estate and by being easy to use. Obviously, if the software is easy to use then training is less of an issue.

But there is another angle to this.

A long time ago when Microsoft Word was a DOS application I was asked about how to set up the page layout. I had never looked at this at all before but I gave it a go and it only took a few minutes to get sorted. The secretary was impressed with my knowledge of Word. Of course I was actually making it up as I was going along but the results were fine so that didn’t matter. I’d never had any training on Word and I did not have a detailed knowledge of its settings. That was not so important because I did know the principles behind it and understood the general approach of the User Interface. My knowledge was to do with the domain rather than the details.

Understanding navigation systems is the core issue. Many systems, particularly the professional, type approved ones, are devilishly difficult to use. This may surprise you. Certainly if you had paid several thousands for a state of the art system then you might hope it would be quite approachable. The trouble is that not only are the User Interfaces, for the most part, quite primitive, but also the mechanisms around obtaining and updating charts tend to be complex. The latter is mostly associated with the dragon of Digital Rights Management. These factors mean that training, of necessity, has to be concerned with a lot of detail.

We think that the navigation system should be easy to use. It should be sufficiently easy to use that someone with knowledge of navigation and some elementary computer skills should be able to use it. I am not going to claim that Nuno™ achieves this yet, but it is what we are aiming for. This still leaves a gap though. It still leaves space for the fatal over-reliance on computers. Perhaps this is more of a cultural thing than a specific training issue. I suspect that the more you know about computers and their weaknesses then the less likely you are to drop unsuitable responsibility on one. Another way of looking at this is to consider that a computer, however clever it appears, is just a tool.

I think there needs to be convergence. The electronic tools should be useful without demanding specific knowledge. At the same time the limits of the tool should be understood at a domain level rather than in terms of the detail. My hope would be that the increasingly computer savvy people driving the ship will be using these tools so that they can spend more time looking out of the window rather than less.

Wouldn’t it be great if you could use Nuno™ for UK waters? Ok, not great for everyone, but pretty good if you happen to be sailing around the UK. So, good news for UK sailors, we’ve got a set of charts for the UK.

After months of intense negotiations with the UK Hydrographic Office we have secured a deal to use ENC charts for UK coastal water. This is the same chart data as would be used by an ECDIS. Now of course Nuno™ is not an ECDIS, if it was then it would be very clunky to use and we’d charge you a fortune. Instead Nuno™ is easy to use and very cost effective. That may sound like vaporous sales talk but consider that this same set of ENC data, 485 cells, would cost you thousands if you bought them for an ECDIS. We are only going to charge you £120 (inc VAT) for all those cells plus the magnificent Nuno™ Navigator application. That has got to count as cost effective.

Here is what the coverage area looks like:

ActiveCaptain has pretty good coverage:

All the usual chart features are there:

The chart data comes with this disclaimer:

"Chart material has been derived in part from data that has been obtained from the United Kingdom Hydrographic office (UKHO). The UKHO does not sponsor or endorse the product and the UKHO and its licensors make no warranties or representations, express or implied, with respect to the product. The UKHO and its licensors have not verified the information within the product or quality assured it. © British Crown Copyright, 2011. All rights reserved.”

Updates will be available every three months or so.

Nuno with UK data will be out in just a week or so. Watch this space.

Lloyd’s List today has heralded a move towards cheaper ECDIS. Most ECDIS are a pretty bog standard PC bolted into a nice case along with some software. It is the software that makes the PC sing and dance. This is what turns an ordinary computer into an ECDIS. This is what the navigator works with and steers his ship by. This is what the training is all about.

How do you reduce the price of software? There is a simple equation in industry that says you cannot sell things for less than the cost of manufacture. Well you can, but not as a long term proposition. In general the idea of any manufacturing business is that you get some raw materials, make something from them and then sell the product so that you can cover your costs and maybe make some profit.

Making cheap software then, how can you cut the costs? There are three broad areas of cost in manufacturing:

• premises, infrastructure and plant
• sales and marketing
• raw materials

Nothing too special about the premises. Any half decent office will do. Infrastructure is the usual raft of management, accountants, office cleaners, human resource experts and other essentials. Plant pretty much comes down to computers and an Internet connections.

Marketing is essential. If nobody knows about you then it can be quite hard to sell.

So far there is nothing unusual, by which I mean that these considerations apply to pretty much any industry to a greater or lesser extent. The way you control costs on this stuff is conventional and well understood.

However when we get to sales things start to get a little more interesting. Cost of sales for software? Just about zero. There was a time when we would put a CD in a pretty box with a thick manual but we’ve just about grown out of this now. Nobody ever read the manual, the box would end up in the bin and having installed the CD you would often find out that the first thing you needed to do was to download an update. So most software is supplied directly these days and that costs nothing, approximately. The server sits there supplying copies of the software and whether is sends out to 10 or 10,000 users really makes little cost difference. In fact really all that business with the boxes and CDs still didn’t add any significant overhead. Low cost of sales means that there are some big bonuses in selling large volumes of licenses. When we talk about selling software we are really talking about selling licenses to use a copy of the software and this is really cheap to do.

The raw materials for software are people. More specifically people’s brains. The rest of the person is needed as support infrastructure. You need good people to write good software. It is not easy. You need good people and you need time. To build a brick wall faster you can put more builders on the job. Put more programmers on a project and it will often backfire. I have not just made this up, the principle was established over 25 years ago.  Employing clever software engineers is expensive. Very expensive. In fact this is where the bulk of your manufacturing costs are. For a typical software house as much as 90% of their total costs will be wages. People really are the raw material in this industry and in terms of quality, you get what you pay for.

So how can we cut costs? The only cost area that will make and significant difference is the programmers.

Option one. Make the programmers more productive. Shouting, threatening and beating is not very effective (I’ve tried). Providing good tools and using modern project management techniques is much better. Even so there is still a limit. These approaches should be part of a modern software company already so there is not much scope for cutting costs here.

Option two. You could try going for cheaper programmers. This does not work very well. Typically you end up with badly designed software which takes twice as long as you hoped to develop. It is difficult to use, looks rubbish, nobody likes it, there are bugs, it crashes and it is very difficult to maintain. None the less this approach is tried from time to time – you may have encountered some of this software.

Option three. Stop development. If the software does its job and there is no real requirement for further features then this is very effective. Your development costs will be massively reduced and with the minimal cost of sales you will be able to ship software at bargain basement prices.

In the ECDIS world option three has got to look very tempting. Making the software better is very expensive and don’t forget that each new release needs to go through a type approval phase. More expense. Is this a good idea? Well with some 50,000 vessels that will need to fit ECDIS only 5% or so actually have it (ECDIS Revolution Conference). At the same time a much larger proportion have some sort of ECS (not to be used for navigation). This suggests that although they like the electronic navigation bit they are not so keen on the actual ECDIS. Why not? Many possible reasons but my point is that the forthcoming legislation is going to force them to buy a piece of kit that they don’t want. So what would you do? Buy the cheapest solution that gets a tick in the box maybe.

It all comes down to price. A global market of 50,000 is not really all that big for a software product that takes many man-years of work to create. It is going to be hard to claw those costs back. The change in the regulations mean that ECDIS will compete on price and very little else. This will effectively freeze ECDIS development. Option three. You have a type approved solution, it ticks the box and the lower the price the more you will sell.

So, just maybe, we are going to arrive in 2018 with a modern vessel using software written in 2008 based on a display standard from 1998. Yep, it’s going to be 20 years out of date. Just think how good the sat nav in your car was 20 years ago.

There is a lot of talk about ECDIS training at the moment. In the next few years ECDIS will become mandatory for quite a wide range of commercial vessels. Clearly having this kit on board is of little use if nobody knows how to use it and so the requirement for training is becoming prominent.

The argument assumes that the ECDIS cannot be used adequately without appropriate training. This is probably not a bad assumption because the usability of commercial ECDIS software tends to range from difficult to verging on impossible. This may surprise you. Expensive software doing an important job on what may be a large and very expensive vessel. Surely it should be designed to be easy and straight forward to use? Oddly enough this is often not the case. There are several reasons for this:

· The standards, specifically ISO61174, does not lend itself to useable software. This is the performance specification for ECDIS. It is over ten years old and is very detailed. Naturally it is based on ideas and technologies that were prevalent ten years ago. Ten years is a very long time in the computer world – we are talking pre-Windows 2000. What is more at the time the standard was written there was not much around in terms of marine navigation systems and chart data. So rather than drawing on best practices and experience the standard needed to present a vision of how the committee thought that navigation software was supposed to be. Now I don’t actually know how the committee was chosen but I would guess that there were very few computer usability experts amongst the members. Even if there were then they were faced with an impossible job no matter how good their crystal ball was.

· So designing ECDIS compliant software that is also usable is difficult in the first place but it gets worse. Given a realistic situation of limited budgets and resources the focus of the development effort tends towards compliancy issues. Usability is a secondary issue since unless the ECDIS can be certified as compliant with the standards it cannot be sold as an ECDIS.

· Actually getting the software certified is a time consuming and expensive business. I am talking many months and thousands of dollars here. It is not trivial. Once the software is certified then it cannot really be changed without being re-certified. This situation does not lend itself to the sort of on-going development necessary to make genuinely user friendly software. In fact it does not lend itself to any sort of development at all. One of the more popular ECDIS systems around at the moment is actually based on Windows NT4. Remember that? Yes, an improvement over NT3.51 but still a tad short of sparkling when it comes to usability considerations.

· Ship owners are a tight fisted bunch. They typically they will not spend a penny more than necessary on equipment so as long as it meets the regulations. At which point it is usually the cheapest system will do. I am not saying this is wrong, running a ship is a fantastically expensive business, but it does tend to make for comparisons based on simple cost rather than other factors. A particular company’s software may be easier to use but if it is more expensive than its rivals then it will be hard to sell.

Hopefully you are getting the picture now. In an attempt to make ECDIS ‘correct’ and sufficiently similar between all implementations the international regulatory bodies have completely shot themselves in the foot. They have created an environment where the bulk of the development effort and costs are aimed purely at achieving ECDIS compliance and all other considerations fall by the wayside.

S-100 is the chart data standard intended to replace S-57 at some point in the future. The groups working on this have recognized that a typical ECDIS can be a bit tricky to use. They have also noted that each ECDIS tends to be tricky in a different way so they have come up with a solution called ‘S Mode’. The basic idea is that every ECDIS has a button which will set it into S Mode. In this mode the controls, menu options, settings and so on will be exactly the same irrespective of which company made the ECDIS. This is such a beautifully naïve notion. It says ‘we’re a bit scared of this software so let’s make it all the same’. Of course any company developing ECDIS will implement S Mode and probably stop there. Where is the incentive and budget to do anything more? Where is the competitive edge? It all boils down to cost, how else do you differentiate systems that all look and feel the same? And so we arrive at a dead end which ensures training will always be required.

There is only one way to make software more usable and that it to allow software developers to experiment. They have to try out ideas and find out what works. It is very difficult. In fact it is amazingly difficult but we are making progress. There is still ample scope for improvement but at the same time I feel no need at all for a training course in how to use my iPhone. I doubt that many of the millions of iPhone users do. By comparison my last car, which was a few years old, had an early mobile phone in it (this is back in the days when ‘mobile’ actually meant ‘semi-portable’) and no, I could not actually make the first phone call without consulting the manual. That phone and the ECDIS performance standards come from the same era.

Nuno does not come with any training courses. This is not a declaration of irresponsibility but because we don’t think it needs one. It is not technically an ECDIS but it will do pretty much anything that an ECDIS can do and in most cases it will do it a lot better.

ENC supports two types of symbology for buoys and beacons. These two symbol sets are referred to as ‘traditional’ and ‘simplified’.

Traditional symbols look a lot like those you would find on a paper chart. These are internationally agreed and some of them have been in existence for over a hundred years. So they are pretty familiar. They are used on all paper charts and as a consequence on all electronic raster charts. Excellent description of these symbols here.

Simplified symbols appear on ENC vector charts and were invented along with the ECDIS standard. Technically they are described in the S52 standard which dates from sometime prior to 1996 and is currently at edition 6.0 (March 2010). The DNC vector format also has a set of simplified symbols but these are different again.

In comparison the traditional symbols are more pictorial, more detailed and more descriptive than the simplified set. You might have guessed this from the name. An obvious question is why do these exist at all? The paper chart symbols are time server, proven, reliable and readily recognizable by anyone familiar with a chart. The simplified symbols are rendered (drawn on the screen) using just straight lines. This may have been easier to see on the coarse resolution monitors that were typical of 15 years ago.

Here are the symbols for a Lateral starboard hand conical  buoy with a Quick Green light.

Is one of these clearer than the other?

They both convey the same information so why invent a new standard? Actually this is a bit of a trick question because on a paper chart the buoy would be drawn solid black indicating it was green or black. ENC does not use filled symbols so the term ‘traditional’ needs to treated somewhat liberally. Why no fills? I am not sure but I would guess that the reasoning is that it might obscure something important underneath. So why doesn’t this happen on paper charts? Probably because the cartographer (chart compiler) makes sure that everything is drawn just so. It is hard for a computer to be suitably discriminating.

There are 58 traditional symbols but only 38 simplified ones.

So something has to go.

Here is a Pillar buoy with a ball on top. Long flashing white light. The Ball indicates safe water.

The traditional symbol shows you what the buoy looks like. It is a pillar with a ball on top. The simplified symbol just uses a red circle to indicate safe water. Maybe with an electronic chart you also have good positioning and so you are less concerned with visually identifying the actual buoy and more interested in that you are in safe water? Of course you can always inspect the properties of the buoy to find out what shape it is. Whatever the reasoning is I find it is not clear cut and certainly not an obvious justification for learning an additional set of symbols. You are going to need to know the paper chart symbols even if you prefer simplified on your ECS.

So which symbol set is best and why?

It seems to me that if you choose to use the simplified symbols then there should be a clear cut reason as to why they are better. The traditional symbols are familiar. Paper charts are not about to go away. Using a different symbol set means more learning and more chances to get it wrong. Why are there two symbol sets? Most ECDIS/ECS allow a choice for the display. Surely one of these sets is better than the other and that should be the end of it.

So what do you think? I’d really like to hear some opinion as to which you prefer to use and why. Does one set stand out better than the other? The simplified symbols use blocks of color which do not normally appear on a paper charts. So they certainly look different but is that necessarily an improvement? Were the originators of vector charts just showing off? The data is carefully set up so that information about an object and the way an object is drawn are quite separate. If you were so inclined you could create a whole different set of symbols and render the same chart data quite differently. Maybe this feature was so ‘clever’ that they just could not resist using it for something. What do you reckon?

Commercial shipping has a requirement to carry up to date official charts. Traditionally these have been paper charts. Every few weeks a chart agent will visit the vessel bringing new charts and also updating the charts on board. Updating consists of adding pencil annotations, overlaying bits of tracing paper and even pasting on a small, new pieces of chart. This is all tedious and time consuming so it is easy to see the appeal of digital charts and automated updating. However commercial vessels cannot simply switch over the digital charts. The official part of the requirement is important.

After quite a lot of wrangling and discussion between the International Hydrographic Office (IHO), other international ship controlling bodies, various national Hydrographic Offices, chart producers, equipment manufacturers and an assortment of other interested parties some standards emerged. S-57 was designed as a standard for transferring data between hydrographic offices but it got co-opted for sending charts to ships using a product specification called ENC. There are some other S-57 products such as AMLs and AIO but these came later. S-63 was designed as the license enforcement and encryption layer. Unfortunately this was published with errors in it which are still propagating issues today. S-52 was an attempt to decouple the presentation (symbol) for an object from the data representation. This started quite well but then got terribly complicated so that now S-52 is almost like a small programming language in itself. In consideration of the overall system requirements ISO61174 was produced. This describes equipment and software performance standards and is the main standard against which equipment is tested. A navigation system, hardware and software, which complies with all these standards is known as an ECDIS (Electronic Chart Display and Information System). An ECDIS can be used , with some qualifications, on a commercial vessel to satisfy the chart requirement.

Unfortunately the ECDIS standards are quite old. S-57 was frozen in 1996 and ISO61174 dates from 1997. Now old, as such, is not necessarily a bad thing, but these standards prescribe the behavior and performance of computer equipment which had not even been invented at the time. They are standards based on a prediction of what the future would be like. As such they are not a bad guess but are still well short of the mark when it comes to contemporary approaches towards interacting with computers. Nuno Navigator is not an ECDIS. At CherSoft we have developed software for ECDIS. In fact we have quite a long history of this. However in Nuno Navigator we have taken the best features of ECDIS, the bits that actually work, and brought them into a thoroughly modern and genuinely user friendly environment. Nuno Navigator is classified as an ECS (Electronic Charting System) rather than an ECDIS. It is not really intended for commercial vessels.

Globally the whole business of updating charts is in a bit of a mess at the moment and probably will be for a while. Most national hydrographic offices are fairly well set up for maintaining their paper portfolios. This is no great surprise as some of them have been in this business for a century or more. However with the advent of electronic charts a lot of things have to change. The whole production process needs to be reorganized (not cheap) and some of the basic ways of thinking about charts have to change.

Raster charts are commonly produced as facsimiles of the paper charts. In a simplistic system they are literally scanned from the paper originals. This can give rise to inaccuracies for a range of reasons not least of which are distortions in the paper and non-linearity in the scanner. Scanning at a resolution appropriate to the electronic chart can cause a rather jagged appearance which is most noticeable in diagonal lines and known as aliasing. The raster chart has far fewer dots (pixels) than the corresponding paper chart and this can compromise appearance. A better production method is to create the raster image from the same electronic chart images used to drive the paper printing process. There are still some issues here with re-projection which need to be handled correctly but in general this is a cleaner and more accurate process. It also allows image processing such as anti-aliasing which gives a better visual impression when the electronic chart is displayed.

In either production technique the updating of the raster charts follows on more or less naturally from the time served paper chart update process. It is then common for the vector charts to be produced from the raster data, more or less indirectly from the paper chart production mechanism. At the end of the update chain are the third party chart producers who copy the official data sets and repackage them in a variety of ways. Quite naturally these are the last types of charts to get updated.

But this is all changing because this is not a good way to handle vector data and vector data is the future. It is a separate issue as to why vector charts are the future or whether it is the right future but for now it definitely is the future. The IHO and other august bodies are committed to this and substantial funds are being invested. This matters because creating vector data from paper charts is just not a good way of doing things.

In the vector world everything is an ‘object’ like a light or a depth contour or a traffic lane. Each object has ‘attributes’ like the color red or a certain depth. Each object also has a position (the ‘vector’) so it is represented as a point, a line or an area. These objects can be quite readily managed in a simple database but the natural way of organizing them is to tie them more directly to the raw survey data. So when a report is received that a new wreck has been found it is just entered into the database – no intervening chart required.

Vector charts are now a cinch to produce. A cell is just a collection of all the objects in a given geographical area. The problem of actually displaying the chart data is palmed off to the ECDIS or ECS. Paper charts and raster charts are a bit more problematical because the traditional role of the cartographer has been taken out of the loop. Have you ever wondered why a modern chart display simply just does not look as good as a paper chart? Well this is why, there is no longer a cartographer involved to lay out the chart and make it look ‘just so’. Instead we have a dumb computer, and they are all dumb, attempting to reproduce the sort of work that takes a human many years of training and experience. It just doesn’t work so well.

Now to be fair the automated vector to raster production processes are getting better but none the less there is still a complete role reversal. The raster chart becomes a second class citizen to the vector chart and the paper chart ends up at the bottom of the pile. Instead of being the primary focus for updates it becomes the last. There are undoubtedly many advantages with vector charts and with paper charts generated from vector databases. However, for the foreseeable future, they are never going to match the visual quality of the charts that have become standard fare for the mariner for many years.

Last in the chain will always be the third party chart producers. Fortunately as their update feeds become predominantly more electronic (just another output from the database) then these updates should become more timely. Ultimately they should be able to match the official charts for accuracy.

Just now we are in a great transition phase. Some hydrographic offices are pushing ahead with vector only systems while others just deal with traditional paper charts. Most are somewhere in between and possibly a bit unsure of which way to go or how it is all going to shake out. Meanwhile the mariners can look forward to improved electronic charts coverage and more rapid updating. They can also anticipate charts which do not look so good and which, in some cases, are going to cost more. Maybe this is just a classic engineering compromise.