SUBMARINE CABLE VULNERABILITY

Jack Runfola, President R&R System Solutions

For some time now there have been multiple articles and thoughts on the vulnerability of commercial submarine cable systems. However, submarine cable system vulnerability is not a new subject. In 2005, R&R System Solutions was asked to address a US Homeland Security Conference on submarine cable security. In our presentation, we addressed the vulnerability of cables and landing stations. Most of the world does not pay much attention to these cable systems, nor is most of the world informed about the type of traffic these systems carry. Without going into a lot of detail these communication systems are vital, critical in fact. These systems transport Internet services, social media, financial transactions, news, live TV events, government information and more.

Submarine communication systems are vulnerable to wide variety of damage that could interrupt their transmission. Typically, the most often cause of damage is fishing activity, anchors, natural disasters. However, deliberate damage can be caused in several ways such as cutting the cable by mechanical means or using a diver (if the diver’s life is expendable), or explosives. This will damage a single cable but not shutdown all vital traffic.

The real vulnerability lies at the landing stations. Due to practical economic reasons multiple cable systems can and do use the same landing site. This creates a cable cluster which in turn is vulnerable. Private companies employ security measures, but is this enough?

Although constructed and operated by commercial organizations should governments consider these systems as national assets? If so, then the question becomes if a landing station is sabotaged does this require a military or other government response? Serious question. Means of protection of these systems can be established in territorial waters by using various methods or defense technology but there seems to be no current international agreement on submarine system protection in international waters. The deliberate damaging of a single cable in international waters could represent harassment but not necessarily a threat. But would major damage to multiple systems in a single incident be considered for military or other government action? This is a serious question. Something to think about.

I BOUGHT MY DAUGHTER A T-SHIRT 

Alfred Richardson VP of Technology

It has been a while since we released something on our blog and the thought occurred to me about my daughter’s chosen profession- Program Management. I know the title sounds like a strange topic for a blog in the undersea systems world but bear with me.  Yes, my daughter is a strange person, she chose to become a Program Manager. Yep, one of those people of multi-tasking skills and details.  She is one of “those” people that every program must deal with.  You ever notice that they speak their own language.  Words like waterfall and agile. I thought I knew what a waterfall was, and as far as an agile program you got me there.  They have “terms” for everything. I really like how they describe organizational structures as functional organizations like it is a bad thing.  Ever hear of a projectized organization or a composite organization? Even my spell checker has a problem with the former. And don’t get me started on Program Manager acronyms, we previously wrote a blog about the over use and misuse of acronyms.

So, this got me to thinking about the program mangers I worked with and for over the years.  They were nice people, well most of them, with a slightly different look at life. Ever hear the expression, “We never have the time to do it right but always seem to find the time to do it over again.” In today’s software world they have tools to track just about everything.  A few of these tools are Gantt charts (devised in 1910 by a man called Gantt), Pert charts (Program Evaluation Review Technique, developed by the Navy in 1950), and maybe something to do with Scrum. (Isn't that a Rugby formation?). The use of Program Managers created what we at R&R refer to as Project Quality Management. That is, they are the central person most responsible for creating an organization’s profit on a specific project or projects. Although some may disagree, the organization’s responsibility is to provide the Program Manager with the tools that provide the highest potential for success.  In short, the organization should be working for the project manager and in turn the project manager works for the organization by providing the fuel to keep the organization fed, i.e. Profit.

Being a Program Manager is not easy. As the saying goes, back in the day I was first trained as a Program Manager by AT&T and then several years later by the US government; both had the same message -learn how to do more with less.  Because in reality a program needs more output with less people, less time, and less money. After all organizations do not have an unlimited source of funding.

Program Managers have a tough job working with engineers, management suppliers, and customers.  As we also provide program support R&R’s estimate is that about 90% of the issues that must be resolved are internal and only about 10% is customer based. Herding cats maybe less stressful.  So, in closing, let me say be nice to your Program Manager. 

And what did the t-shirt say?   PROGRAM MANAGER   BECAUSE MIRACLE WORKER ISN'T AN OFFICIAL JOB TITLE, YET!

You Can’t Teach Experience.

Al Richardson, VP of Technology

I’m sure that all the readers know Murphy’s Law, if anything can go wrong, it will and does. And probably most of you have had one or more instances where it has happened to you personally or on a project. There are books written on the subject of project management, quality management and from time to time I read one or two of them to determine what might have changed, if anything. In the process of reading one of these books I came across one saying that caught my eye -

Horner’s Five-Thumb Postulate: Experience varies directly with equipment ruined.

Let me take a little poetic license and instead of saying equipment ruined, you might say schedules missed, programs over budget, cables faulted by sea creatures, etc. If you have been in the business long enough, things have gone wrong. So why is this important?  Currently R&R System Solutions is under contract to “teach” cable design, mechanical/electrical/optical performance, etc..   Providing cable system training is one of our favorite business services. The list is almost endless on what can be taught. The easier elements are wire size, insulation thickness, fiber strain, weight in sea water, bending stiffness, etc.  Also, knowing or teaching what questions to ask customers, checklists, lessons learned etc. is a critical part of the training.  As there is no current medical cure for ignorance and to use the cliché- You Can’t Teach Experience may also apply. Most, however, don’t believe that experience can’t be taught. You can teach the lessons of experience but you cannot normally teach the actual experience of a given situation. You can be a teacher, a mentor, a coach, but there remains one thing that seems to elude the education process, actual experience.

Let’s take Calculus as an example. A few years back I had the “opportunity” to teach Calculus to a group of seniors in a high school.  I spent a semester imparting knowledge but not a lot of teaching.  You can show students the methods of integration, parts, substitution, partial fractions, etc. but you can’t “teach” them when to use the methods.  And that is the key to know when to use the methods taught or related by more experienced personnel.

The same can be said for cable engineering.  It is extremely hard to teach what R&R defines as Cable System Engineering. This is the life history of a cable.  Everything from the first set of requirements, through design, through manufacture, through testing, through deployment, and finally ending up in service.  Cable System Engineering is everything the cable comes in contact with, every interface, every environmental concern, everything. Years and years of working on ships, in cable plants, and behind a desk has taught me one very important thing; You Can’t Teach Experience.

In the end, the learning experience reflects upon monies lost or gained for a company and the stability of a workforce. Experience is what is needed to recognize where the best solution may lie.

Mom, Kelp Ate My Cable

Mom, Kelp Ate My Cable!

Al Richardson, VP Technology

Yes, it really did, as strange as it may seem. One could understand underwater Zombies maybe, but Kelp? Who would ever consider Kelp as a threat to a cable.  Let me explain.  The other week during one of R&R’s status meetings we wandered off topic and started discussing the weird and not so weird causes of cable faults. As a company and as individuals our experience in design, fabrication, testing, and installation is hard to beat. Over the years we have seen some pretty “interesting” reasons why cables have faulted.  Everything from Southwestern Jack Rabbits and Dungeness Crabs just to name a couple. One of the more interesting reasons one would not expect is Kelp.

Here is how it happened.  During the field testing of a very small powered optical cable known as the 132 cable (the diameter is 0.132”) a study was performed on how the cable would behave on the sea bottom. I had the assignment to deploy the cable over various bottom conditions and observe the cable status and performance. An area was found where there was sand, mud, rock, gravel, and yes, Kelp on the bottom. After deployment and initial observations by divers, all was well. After a week went bye I set up an inspection schedule and departed for home.  Then two months into the one-year test, I received a call at my office.  I was told ‘the Kelp ate your cable’.  Right, sure it did. It took a bit to convince me. When we did the inspections, analysis the facts did show that Kelp was the main contributing factor to the fault.  As one learned, at the various stages during the life cycle of Kelp, it floats.  If you have a very small cable in a Kelp bed, you run the risk of the Kelp bringing the cable to the surface where the prop of a boat engine, or by some other surface means, the cable can break. And that’s what it did!

Who knew? Now, I do.  Who knew about underwater marching sand dunes? Who knew that a small tsunami could take out a shore landing? Who knew that a skate would unbury a cable to take a bite out of it?  Who knew, well R&R System Solutions does and has had the pleasure (as the Chinese say) of “living in interesting times ” involving undersea cable.

Final Program Quality

Al Richardson, VP & Head of Technology Requirements

In our previous blogs R&R has addressed program and quality items to point out where a program has a better chance of success. Like most, R&R System Solutions defines Program Quality as how well a program operates in delivering its product or service on time and within budget meeting all the requirements.  We measure it by;

1.      The program’s ability to develop and manage all requirements
2.      The programs use of Lessons Learned and checklists
3.      The effectiveness of peer inspections / reviews
4.     The techniques and procedures for validation and verification

There is no doubt that excellent program quality needs excellent program management.  Program planning to risk management and everything in between needs to be of a high quality.  And even with everything in place, things can still go wrong. If you are familiar with Murphy’s Law and then you should know about Otoole’s Law. Otoole’s law states that ‘Murphy was an optimist’.

Let us share a quick story of the ½ inch bolt.

At one time there was a requirement for the rapid deployment of a very small electro-optical cable. The design teams started and things progressed smoothly for quite some time. Designs were created, checked, re-checked, fabricated and tested. All was good.  All the elements were assembled and off to the sea trial we went. D-day for deployment came and within minutes after the system was deployed, it failed!  A bit of head scratching and everything was checked and re-checked again.  Assembly instructions and deployment procedures were re-reviewed.  As built books examined, quality records were investigated and nothing came immediately to light. Finally, after several inspections, the cause was determined to be none other than the ½ inch bolt. Yup, one little old ½ inch bolt.

In the design, a ½ inch bolt was specifically called for in various places. The bolt needed to be of various lengths in various places and you guessed it, a long bolt was used in a place where a short bolt was required.  The longer bolt extended into the cable pack and ripped the jacket causing water to penetrate the cable and the cable shorted to sea. As a result, checklists were updated and a new item was added to Lessons Learned.

As you have read in previous blogs, from the color of the jacket, from sharks, skates, and rays, from Lessons Learned, from misused acronyms, to the ½ inch bolt and beyond even the best planning cannot always anticipate what can occur.  Our experience has taught much.  While R&R has not seen everything in the world of undersea programs, we have experienced and seen a lot!

The Corners of the Box

Al Richardson VP & Head of Technology

Requirements? Let me share with you a short story.  Currently R&R is working with a customer that has an “interesting” set of requirements.  They would like a certain amount of power, a certain minimum breaking strength, and they would like the cable to float.  Let’s examine these items for a second.  Power- copper works and copper sinks, strength- steel works and steel sinks, floats- some insulation floats but I bet there is a requirement for maximum size.  Yes, there is a max size requirement and now we are in a box. In fact, we are deep in the corner of the box where the edges of the requirements meet.

We have all heard that the customer is always right so we labor away attempting to design the perfect design. Take it from me, the customer is not always right and in many instances, the user had / has very little input into the requirements. Sometimes what you see in a Request for Quote or Request for Proposal doesn't make sense. Sometimes the partially conflicting requirements may be as simple as min / max size versus min / max strength.  Sometimes they may be as subtle as strength / size / hydrogen generation (that was a fun design.) Either way, you can end up in the corner of the box with seemingly no way out.

There is a way out and you can do it without appearing arrogant.  Arrogant in this case is defined as you knowing more about the customers’ needs and telling them that.  Most of the time you don’t know which user requirements are really important and which are just there to fill in a blank. How do you tell the difference?  The answer is simple, you ask.  You ask in a way that shows concern for the customer.  Concern for the customers’ needs, time, and money. Sometimes it works, sometimes not. Either way you gain a better understanding of the customer and the customer may have a greater respect for your organization.

R&R is in that situation right now and we are working with the customer.  Will it work out?  Maybe, maybe not.  Since we are engineers, nothing is impossible.  It just takes a little longer and maybe costs more money to get out of that corner.

Do It Right the First Time

Sometime during the testing phase of your project, if not latter, a defect, an error is found. The project is put on hold until the problem(s) are corrected. Now you are behind schedule and possibly over budget.  You hear the staff saying, “We never have time to do it right but always seem to have time to fix it.” I’ve said it as an engineer and heard it numerous times as a manager. It got me wondering what is there in the program quality tool box that could help this all too common situation.  Engineers will want to take forever and program managers will want it yesterday, tomorrow if you are lucky.

The answer, peer inspections.  These are sometimes called reviews, audits, or walk through. It doesn't matter what they are called.  It matters that you have them and they are set up and done correctly.  I will use the term inspection as it sounds more formal and that is just what it needs to be, formal. Having inspections in the development phase allows for rapid design with the knowledge that errors and defects will be caught before anything is built.

There are 3 main parts of the inspection;

1)      Set up – Possibly the most critical step. Picking the participants for the inspection will lead to success or failure. Giving the participants preparation time with the inspection material is also critical

2)      Conduct the inspection – Seems simple enough and if you have a good inspection leader, it is. Once again I like what CMMI® says about inspections. “The focus of the peer review should be on the work product in review, not on the person who produced it.”  

3)      Review the results – This should be easy but it isn't.  The easy part, errors and defects have been found and can be corrected before time and money is spent on fabrication.  The hard part, inappropriate use of the inspection data. You want to know how to stifle inspections and cause the process to be abandoned? Have some manager, functional or program, start to use the results in performance evaluation.  And that is just one inappropriate use I have seen.

Inspections are not to be the end all to Program Quality, but without them, your chances of doing it right the first time are slim and none.