We have to think differently with this set of problems. Relationships among systems, components and networks (arguably, systems, but with different composite behaviors) might be shown in a graph database to illustrate how unexpected connections can impact the whole (to your design plus implementation point). I always default to a position of ‘what do I DO?’ in considering how to address this thorny set of problems. I’m within a couple of weeks of starting experimentation in a graph DB environment to see how we can represent connected data without the baggage of tables.

Network analysis is too far afield for actual use at this time, in my opinion. It may be absolutely required, however, as a test and assessment basis for interoperability verification in highly-automated systems. As we progress toward more autonomous systems on vessels, it could be a parallel path forward to understand behaviors. Combine an asset management / configuration management database built in a graphDB environment with network analysis, and you can now model the entire smart vessel in one place.

We – as a community – have to center efforts on outcomes, not on technical means.
I will forcefully assert that our task is to ensure designers, builders and operators use good engineering methods, sound risk assessment and management techniques, and widely-applied automation monitoring processes and procedures to ensure the eventual ship/crew combinations have the ABILITY to be safe. This applies to regulators, Flag States, port authorities, owners, insurers, cargo carriers, the whole lot – they have to understand the implications of automation.

This gets back to DEPSECDEF’s comments. One must be cognizant of the ownership of data just as one is responsible for custody of physical gear. That means all players in the chain must understand what goes where, who can access what, and what they do in case an unexpected event (unauthorized access, intrusion, human error exposing data, etc.) occurs.