Tag Archives: automation

Drones

Self-Driving Ships Will Soon Raise the Stakes at Sea

2 Comments

The following article originally appeared on the Kennedy School Review and is republished with permission. Read it in its original form here.

By Cameron Lindsay

While Amazon continues to pilot its fully autonomous drone delivery system, Amazon PrimeAir, an autonomous delivery system millions of times larger is occurring at sea. And whether you are the passenger on-board a cruise ship or you hire a shipping company to transport your belongings overseas, in a few years, you will increasingly be at the mercy of a self-driving ship.

The prevalence of self-driving ships, or in more technical terms, autonomous surfaced vessels (ASV) or unmanned surfaced vessels (USV), which operate either remotely or completely independent of humans, is growing. And while for centuries mariners have sailed in awe of the ocean’s size and reverence of its might, the emergence of the self-driving ship ushers a new era of commercial economic opportunity as well as maritime security risks of miscalculation.

Similar to self-driving cars, most of the technology necessary for the development of a self-driving ship is mature and available at reasonably low cost. Using state-of-the-art computer algorithms within advanced radar, navigation, acoustic, and optical sensor payloads, self-driving ships are expected to operate more efficiently and safely than those operated by humans.

Self-driving ships present the opportunity for the commercial maritime industry to significantly increase profits through the reduction of costs associated with crew salaries, nourishment, fatigue, insurance, and decision bias. As described by the President of Rolls-Royce Marine Mikael Mäkinen, “autonomous shipping is the future of the maritime industry. As disruptive as the smartphone, the smart ship will revolutionize the landscape of ship design and operations.” While Rolls-Royce is vying to build the first autonomous smart ship with Google, other companies like the Norwegian company Yara seek to be the world’s first remote controlled and then totally autonomous electric cargo ship in 2020.

However due to the technical complexity, lack of legal precedent, and political hedging associated with self-driving ships, one can expect the wave that brings higher commercial profits to also lower the propensity for international consensus on their use. Self-driving ships present challenges like those faced by federal and state governments today in implementing safeguards when introducing self-driving cars to the public. Yet unlike self-driving cars, these policies will need to address centuries-old maritime legal constructs, sovereignty protections, and universally established rules for how vessels interact on the high seas. The necessity of these policies to accommodate the commercial interests of ships longer than the height of the Empire State Building and communal practices of family owned fishing trawlers will be a significant challenge to policy makers.

Unlike driving your car on a well-regulated interstate highway system, moving further away from a given nation’s coast corresponds with the transition of sovereign territorial waters to an international patch work of treaty obligations under the United Nations (UN) Convention on the Law of the Sea and regulatory organizations, notably led by the International Maritime Organization (IMO). With its UN mandate to promote safe, secure, efficient, and environmentally sustainable shipping, the IMO has an opportunity to advance maritime safety, security, environmental protections, and economic opportunity through its embrace of technological innovation.

While the impact of self-driving ships will be a severe disruption to the commercial maritime industry, the technology will also punctuate a new era of maritime security strategy. Historically, the vast distance of the warship’s Captain from his state served to strengthen professional restraint while simultaneously weakening the temptation of jingoism. Using a command and control structure analogous to cyber and unmanned aerial vehicles (drones), an artificiality to the context of conflict engagement will exist between state authority and state actor. Development efforts underway today have already produced machines that can replicate some of the functions of fighter pilots and sentries, among others, and it appears inevitable that military system capabilities will continue to expand into areas traditionally the domain of human operators.

Nations seeking to capture a maritime strategic advantage may see the application of self-driving ships as a force multiplier to maritime search and rescue, mine clearance, and offensive operations. Conversely some nations may view the application of self-driving ships as their relief valve to unusually high operational demands resulting in accelerated personnel fatigue and vessel deterioration. When coupled with future advances in sustainable energy sources (solar, nuclear, and lithium-ion battery), self-driving ships will become an attractive investment alternative for global powers in extending their ability to project power by sea. Undoubtedly this regional and global great power competition will heighten the risk of miscalculation and unintentional conflict escalation as evident in the December 2016 seizure of an American unmanned oceanographic survey ship by Chinese naval forces.

For international maritime bodies, such as the IMO, International Seabed Authority, and International Whaling Commission, self-driving ships offer a low-cost approach for monitoring and reporting nation-state and private violators of maritime conventions. Through member nation financial support, the UN application of self-driving ships could respond to sustained maritime humanitarian crises while depoliticizing involvement and the risk to entrapment by member nations. This may serve as a pretext for the establishment of a sustainable internationally recognized unmanned maritime peacekeeping mission with the capacity to actively investigate illegal fishing off Somalia’s coast, resource exploitation near Fiji, environmentally damaging practices to the Great Barrier Reef, or freedom of navigation within the disputed South China Sea.

However, before the rewards of self-driving ships can be realized, their challenges must be acknowledged, accepted, and addressed through a combination of active diplomacy, smart policy, and visionary thinking.

Cameron Lindsay is a Master in Public Administration candidate at the Harvard Kennedy School and U.S. Navy Politico-Military Scholar. He is a graduate of the United States Naval Academy and Government Affairs Institute at Georgetown University. The views and opinions expressed are the author’s alone and do not represent the official position of the U.S. Navy, U.S. Department of Defense, or U.S. Government.

Featured Image: Autonomous ship concept (Rolls Royce)

Capability Analysis

Information Management and the Future of Naval Aviation

Leave a comment

By Michael Glynn

Aviators and operators hitting the fleet today have reasons to be excited. Naval Aviation is in the process of recapitalizing the fleet with a stable of very capable platforms and sensors: the E-2D carrying the highly advanced APY-9 multifunction radar; the P-8A with a powerful acoustic system and the APS-154 Advanced Airborne Sensor radar; and the EA-18G armed with the very capable ALQ-218 electronic warfare system and Next Generation Jammer.

The advances are not restricted to manned platforms alone. The MQ-4C will enable wide area search and ISR operations, covering hundreds of thousands of square miles during 30 hour flights. The MQ-8C will bring impressive endurance to small deck surface ships. Longer dwell time promises to yield more collection opportunities and push more data to warfighters.

But observers should be cautioned that these new platforms, new sensors, and emerging autonomy won’t necessarily yield higher quality intelligence or more information to commanders. Warfighters today are fighting not to generate enough information, but rather to manage the incredible amounts of data that today’s sensors record and store. The fleet is struggling to keep from being drowned in a sea of data. The battle of the information age is to separate the useful information from the vast amount of meaningless noise.

Our sensors today already develop tremendous amounts of data. How do we store it, access it, make sense of it, and disseminate it? How will we manage this in the future with even more data as unmanned systems become more common? Can autonomy and data fusion be part of the answer? Will our training and intelligence analysis need to change? Let’s examine these challenges in detail.

Large Data Sets, Autonomy, and Data Fusion

The increasing use of unmanned systems will bring longer mission profiles and hence longer windows of time where sensors can collect. This will generate extremely large amounts of information each flight. To put the challenge in perspective, consider a modern maritime patrol aircraft, the P-8A and its partner, the soon to be deployed MQ-4C UAV. On an eight hour mission, a Poseidon will generate up to 900 gigabytes of sensor information. How much more data will the unmanned Triton generate during its thirty hour flights?

Any operator in the fleet will admit that the amount of data gathered by our platforms today far surpasses the bandwidth of our long range communication networks. What happens to data that can’t be transferred off an aircraft during its mission? How best to manage information that may be over a day “time-late” when a UAV lands? What sensor information should be broadcast to operators ashore and what should be saved for post-flight access? These are challenging questions for program mangers, requirements officers, and operators to solve.

In the same vein, the large data set generated by sensors today offers the possibility of using analytics to sift through them and draw conclusions. However, this will only happen if managers design suitable architectures to extract the data post-flight, store it, and make it available to customers. We will discuss this concept later.

A second broad trend worth mentioning is automation and the ability to use technology to parse the data. Algorithms in modern sensors allow these systems to automatically capture, store, and disseminate information. Legacy surface search radars required an operator to manually plot a contact, log its position on paper, and update the position as time went by. Modern surface search radars can automatically identify, assign track numbers, and update tracks of dozens, if not hundreds of contacts, and promote certain tracks to datalinks such as Link 16. The track information is also recorded on-board and available for post-mission download, analysis, and storage.

The benefits of automation and data storage don’t end there. Today’s platforms either already do or will soon employ data fusion engines that merge complimentary information from multiple sensors to produce a higher-fidelity view of the battlespace. These systems will identify a surface contact by radar and overlay an electronic line of bearing signal that arrives from the same direction as the radar contact. The fusion engine will recognize the radar signal is coming from that ship and by analyzing the parameters of the signal might be able to provide a possible identification of the type of vessel. The system will then merge the radar contact and the electronic emission into a single track and promote it automatically to a datalink.

The capability of our sensors and our ability to store the data they produce is improving rapidly. Unless we think about how we collect and process this data, we risk not being able to capitalize on the capability. Let’s examine some actions we can take to prevent the technological advances from outpacing our ability to control them.

Recognizing the Challenge

Our warfighters and intelligence professionals need to examine the process by which they collect, store, process, and disseminate information. We need to match technology with roles a computer can accomplish and utilize our manpower where the skills of a human are most needed. Too often, our warfighters are employed in roles to which they are poorly suited.

In parts of the fleet, an observer can find operators plotting the locations of ships in paper logs when mission systems are recording the same information and storing it with far greater fidelity and fewer errors. These mission systems scale easily, plotting not one track history, but thousands. The same observer could find aviators submitting message traffic to meteorological commands listing environmental measurements at one location when the aircraft they just flew recorded similar measurements at dozens of locations spread over hundreds of miles. The observer could also find an intelligence officer spending their time preparing a PowerPoint brief for a commander instead of analyzing the information brought home by crew.

Humans are excellent at recognizing patterns and drawing conclusions from data. When it comes to tasks like plotting and updating radar contacts or transcribing information in a log, a machine wins every time. Yet we can find numerous cases in which we ask humans to “beat the machine” and conduct a rote task when the technology exits to automate the process. We need to train our operators to adopt a “sensor supervisor” approach and use technology to automate post-mission product creation.

Action Ahead

Are we making wise use of the billions of dollars spent on collection platforms if we don’t examine our own information processing requirements? When we bring new sensors to the fleet, are we process mapping to determine how best to analyze and disseminate the data they collect? Do we even know what types of information our systems are collecting? In all of these cases, Naval Aviation as an organization can get better.

Leaders in Naval Aviation and the Information Dominance Corps have several solutions that can be implemented. The first is to examine and implement a “pull” based system of information portals where collection platforms can post data and customers of all types can access it. Currently, the fleet relies on a “push” model where a unit is assigned to accomplish a collection task, and then information is reported back to stakeholders. Under a “pull” system, information would be posted to IP accessible portals where any authorized user can discover the information and utilize it for their analysis purpose. This is a far more efficient system, prevents stovepipes, and will enable next generation “big data” analytics efforts including applications in the Naval Tactical Cloud.

Next, information analysis and dissemination need to be viewed as a key part of the kill chain and performed so as to optimize mission effectiveness. Is a trained intelligence analyst better suited to sifting through ambiguous data and drawing conclusions about adversary behavior or best used building PowerPoint slides? Software today can be easily adopted to automatically generate post mission message traffic, briefing slides, and other products. This allows human capital to be reallocated into value-added efforts.

In a similar manner, Naval Aviation should examine how we can train our aviators and operators to best employ their sensors. We should expose our young aviators and sensor operators to concepts of information management early in their training. Understanding the strengths and weaknesses both of the human sitting in the seat and the sensor system will go far to optimize our collection platforms. This will allow operators to let machines do what they do best, and apply human minds to the analytical tasks they are best suited for.

Conclusion

The platforms and sensors being introduced to the fleet are very capable and will grow more so with intelligent management of the data they produce. Let us write and think about how best to manage the information our warfighters gather as they prepare to deter and win the conflicts of tomorrow.

Lieutenant Glynn is a naval aviator and member of the CNO’s Rapid Innovation Cell. The views expressed in this article are entirely his own.

This article featured as a part of CIMSEC’s September 2015 topic week, The Future of Naval Aviation. You can access the topic week’s articles here. 

Future Tech, New Initiatives

Innovation Files: Automated Plan of the Day (autoPOD)

5 Comments

There’s been a big uproar lately about innovation in the Navy throughout message boards and the blogosphere – what is innovation, what it’s not, and what method Big Navy should be taking to jumpstart innovation among the fleet, if any at all.  LT Jon Paris and LT Ben Kohlmann, both of whom are very involved in the conversation, had a great discussion about the topic on CIMSEC’s Sea Control Podcast, hosted by LT Matt Hipple.  LT Paris followed up with an excellent blog post.  While there are some contrasting views, it seems like one thing that’s agreed upon is that the deckplate innovation already occurring in the fleet sometimes doesn’t make it “up and out” or isn’t as publicized as it should be.  In that capacity, LT Hipple, and some members from the CNO’s Rapid Innovation Cell, offered a challenge to start publishing examples of innovation in the fleet.  I’ve decided to take this up head on in a series of “Innovation Files”.

Nearly every command has a “Plan of the Day” (POD) – a widely distributed one-page agenda with at least the current and following days’ schedule of events.  Depending on the command, certain PODs are very long and many regularly contain dozens of events per day, some at overlapping times.  Early on, I noticed a couple glaring inefficiencies particular to my command.  First was the process – A yeoman would be specifically assigned to “do the POD” for the day, a duty rotated among the junior yeomen that nobody wanted.  This task started by opening the previous day’s POD, changing the date, piling through various e-mails and files on the shared drive, and then writing the new daily schedule by hand.  After an hour or two, it would get routed up to the ship secretary, personnel officer, admin officer, training officer, operations department, various department heads, command master chief (CMC), and some others before finally getting to the XO.  Every position in the chop chain had their own changes and events to add, and it required the yeoman to literally go around the ship looking for each of these people, and then going back and correcting the changes for each correction or addition.  It wasn’t uncommon to print in excess of 15 POD drafts before the final revision.  As you can imagine, POD duties were an all-day event, and since the POD needed to be finalized and signed by the next day, it kept everybody around well into the evening.

After much thought, the XO, personnel officer, and I agreed on a plan to create a public calendar on Microsoft Outlook to streamline the POD process.  However, PODs have a very specific format, and Outlook can print nothing close to the format.  For example, asterisks had to be next to times if the event was to be announced on the 1MC, events had to be in bold lettering if the CO was attending, and everything had to fit on the page in two neat columns.  It wasn’t as simple as hand-copying every single event into the old POD format though; the daily schedule constantly changed throughout the day, and there was no process in place to ensure if any late additions or modifications in Outlook were included in the POD.  This, along with other human errors, severely complicated the process, and made it essentially as inefficient as the old method.  If only there was a better way!

autoPOD-1Introduce the automated POD (autoPOD).  We decided to devise a macro app on top of Microsoft Publisher, a computer publishing tool, to automatically translate events on Outlook into the same easy POD format everyone was used to seeing.  Macros are essentially programs, coded in easy-to-learn VBA (Visual Basic for Applications), that are built on top of application documents (in this case Publisher’s and Outlook’s) meant to automate tasks within these programs.  Because of this attribute, it gets around IT policy requirements, which prohibit the introduction of specific executable programs not pre-approved by SPAWAR.  Microsoft Publisher was chosen over Word because it’s specifically designed to manipulate documents with multiple dynamic text boxes.  Through an appropriate script reference, the app asks the user permission to reach out to any designated public Outlook calendar.  Then all the user has to do is click one button, and it automatically inserts the daily schedule into the POD publication – complete with dates, events, headers, etc.  The layout is easily manipulated by different codes inputted into the appointment screen on Outlook.  For example, for an event to appear “bold”, which indicates the CO is attending, an actual Outlook invitation for that appointment is sent to the CO, which is then designated on the user interface with a specific user name.

autoPOD-2

Along with events, the app supports all sorts of informational headers put in by different users through Outlook tags – for example, the operations officer puts in the appropriate command duty officers and duty sections, and the quartermasters put in sunrise and sunset times into Outlook.  The app supports time structures displayed as “All Day” or “TBD”, and all types of recurring events.  Different permissions (ie: read only, add, or modify/delete) can be granted to different users to modify the Outlook Calendar, and the program is set up for an administrator to view when and who is putting in the events, so it’s not possible to sneak a last minute evolution for the next day without the XO and CMC knowing.

AutoPOD was eventually customized for several other tasks.  By request, we built an automated Plan of the Week (POW) 10-day printable outlook on top of Microsoft Excel for the Planning Board for Training (PB4T), which mimics the POD format each day, for planning purposes.  Other ships had a weekly or monthly outlook summary with important events listed on the back of their POD, and autoPOD was customized for these commands as well, using the “priority” attribute to determine if the item should be displayed on a weekly summary.  We have continuously refined AutoPOD to accommodate every ships’ POD format, meaning there will be little, if any, visible change to the Sailor.  For example, there are options to autoPOD-3modify the font, size, and width for the time and subject columns.  Additionally, it’s designed to be plug-and-play – all contained in one publisher file – so it can be used immediately and without any complicated installation procedures.  Detailed documentation is provided on how to install the program and manipulate the schedule via Outlook.

It is worth noting that the initial concept of autoPOD was not received well in its early stages.  For example, the yeomen were used to a certain way of doing things, and didn’t want to move over from Word to Publisher.  Despite comprehensive training, some department heads and department lead chief petty officers continued to send e-mails to admin with their events, instead of deconflicting and scheduling it themselves in Outlook.  However, after much dedication and patience, everyone slowly acclimated.  The new system is now second nature, and it’s hard to think of how life even functioned in the past.

To date, autoPOD has been distributed to over a dozen ships, across several waterfronts.  It has undoubtedly made the POD process less frustrating, and has saved countless manhours and time, from the junior yeoman who can produce a POD in minutes, to the XO who no longer has to micromanage the process.  Unfortunately, we recently hit a bump in the road when asked to set up the app on a ship that finished an extensive shipwide IT refresh known as a Consolidated Afloat Networks and Enterprise Services (CANES) installation.  At the time, CANES strictly restricted ships from creating and using shared calendars, along with other security settings that prevented the app from working properly.  A workaround is in progress, but it illustrates a point that has been brought up in the recent discussions – many Navy policies and procedures are around for valid reasons, but often come at the expense of productivity and innovation.  It’s essential to collaborate between the fleet and appropriate project managers / designers / policymakers to figure out an optimal mix.

Zachary Howitt is a proud American, Naval Officer, and Tech Entrepreneur. He is a designated operations analysis subspecialist and has served in two warships forward-deployed to Yokosuka, Japan. His opinions and views expressed in this post are his alone and are presented in his personal capacity. They do not necessarily represent the views of U.S. Department of Defense, the U.S. Navy, or any command.