Learning lessons

19 April 2018
1280px-us_navy_010730-n-6234s-004_uss_carl_vinson_cvn_70_underway.jpg

In many businesses, it’s common, when something goes wrong, to look back and uncover the lessons learned. What could we have done different/better? It can be no less instructive, though, to apply the same process to successes: what did we learn, and how can we leverage that in the future?

We were recently writing up a case study on work we did with the US Navy, and how we deployed our Ethernet switches across the fleet. You can find the case study here.

So: what did we learn?

Warships are big

In particular, they might need the sort of cable runs which are normally used in public places – cities, rather than offices. For the switches, this meant that most of the cable runs are fiber rather than copper – and sometimes very long range fiber. Aircraft carriers are shockingly big!

Warships are noisy

Here, our problem isn’t the sonic problems (although sailors don’t love having to wear ear protection). What we’re talking about is electrical noise – EMC, EMI all that sort of stuff. Massive problems are caused by electrical power and signalling all over the ship. Once again, this tends to lead to the use of fiber optic cables.

Warships are complex

The sort of cable runs required to go from any one point on a ship to some central point - where the control systems tend to be – can be very convoluted. Cabling tends to be forced into ducting which seems to be an afterthought of the ship design engineers. Then: watertight bulkheads also create extra problems, meaning cables are not easily changed.

Legacy systems are important

Many of the sensor devices and so on take many years to be qualified and are then seen as trusted, reliable solutions. So: being able to connect to and interwork with these is vital in fitting new systems into these ships.

Equipment doesn’t change very often

A refit of a Navy ship is a major deal – these systems have got to be designed to last. Even if some of the components can be changed, the cable runs (especially in submarines) are probably never going to be ripped out and replaced.

No one-size-fits-all

Because of all the complexity of cabling on board ships, our hardware designers developed a range of Ethernet switch products (the RM921 family) which could support many different types and combinations of copper and fiber cables. These allow all the various new and legacy systems and cabling types to connect together and communicate – and since they are managed switches, all that communication can be monitored and controlled appropriately.

Warships shake

Shock and vibration is important in ships, as it is in all the mil/aero market – but in different ways. For many ships systems, the shock and vibration levels are not nearly as taxing as they are in ground combat vehicles. So, we could design solutions to Level 3, rather than Level 5 in our scale of what some people think of as “rock and roll”.

The Navy is very hierarchical

The definition of roles and responsibilities and how they are performed by a specific Navy rank is carefully planned, and not easily changed. One nice, simple feature we added to help this was creating a specific login in our OpenWare switch management software which allows that user to see all the status and statistics on the switch. This can allow that person to diagnose problems (something like a broken cable) but does not allow them to change any of the configuration. Typically, changing the configuration would fall to a more senior rank.

VME is still greatly loved

The Versa Module Europa (VME) bus and board form factor has been around for a long time. Indeed, by some measures, it will be 40 years old next year. But, for many Navy applications, there is a great deal of respect for the VME form factor. It has passed the test of time, and is still the default for many Navy designs. There must be quite a few people out there thinking: “If it ain’t broke, don’t fix it!”

Fast failover really matters

Redundant cable runs are common in most data networks, and feature the ability to ‘fail over’ from one cable to another when something goes wrong. We have developed a ‘Failover Groups feature which allows for customer-specific specific handling of these kind of problems. For things like warships, these cable runs tend to be one on each side of the ship. The thinking might be that if you get holes blown in both sides of the ship at the same time, your problems are probably bigger than just communications loss!

Co-operation works

Much of our early experience in developing switches for Navy application was in the early years of OpenWare, and we had wonderful co-operation with engineer-to-engineer conversations with our lead customer. This worked very well for us to understand their needs, and for them to understand our solutions. For many months, we’d have very frequent email exchanges and weekly conference calls. We were also able to deliver OpenWare enhancements in a regular set of incremental steps – and this was many years before ‘agile development’ was fashionable.

Beware of acronyms

Another Navy customer had us puzzled some years back. We got their proposed network diagram and on it was a reference to “AFT nodes”. To us, as network protocol engineers, the “*FT” would imply some sort of file transfer protocol – but AFT seemed like a new one. We puzzled over this for quite some time until someone realized that, on ships, “AFT” was the opposite to “FORE” - i.e., it meant nodes up the back of the ship, rather than the front!

So, with all these lessons learned, the RM921 and related switches proved to be very popular with many customers whose end users are the Navy. We’ve shipped many thousands of these products, and they are in active duty in hundreds of warships with a number of navies around the world.

Now, the challenge is for us to find new opportunities to leverage what we learned.

 

 

Image created by an employee of the US Navy and, as a work belonging to the US government, is in the public domain.

John Thomson

John Thomson has been working on software for over thirty years, having done a degree in Computing Science in the early 80s at Glasgow University. His focus has always been networking, in particular Local Area Networks, including years working on international standards for protocols - back in the early days of the Open Systems Interconnection (OSI). Having worked for a number of multinational companies (both large and small) he has been with Abaco (or its predecessors) since 2000, and leads the team of software people working on OpenWare – our Ethernet switch management suite. The OpenWare team is based in Edinburgh and California.

 

He and his wife took a career break for five years in the early 1990s, and were heavily involved in relief and development work (with Unicef and others) in Ulaanbaatar, Mongolia. He still claims to remember enough of the Mongolian language to ask for some very interesting foodstuffs!