maritime romas remote operations of machinery and ... · blackout loss of ship-shore comms ecc...

DNV GL © 2018 06 February 2019 SAFER, SMARTER, GREENERDNV GL © 2018

Steinar Låg

06 February 2019

MARITIME

ROMAS – Remote Operations of Machinery and Automation Systems

1

Haugesundkonferansen 6.februar 2019

DNV GL © 2018 06 February 2019

Outline

▪ The ROMAS Project

▪ Some of the work done

– CONOPS – Concept of operations

– HaziD analysis

– IAS Data analysis

▪ Pilot testing

▪ Way forward

2


The ROMAS Project

3


The ROMAS project

▪ ROMAS: Remote Operation of

Machinery and Automation

Systems

–NFR application granted Dec 2016

– Research project 2017-2019

– Total budget 9,5 MNOK

– 50% support from NFR (Maroff)

4

▪ Partners:

▪ Reference partner:


Remote machinery operation: Background and motivation

5

• Fleet wide control from an on-shore ECC• Reduced need for engineers on-board• Improved efficiency & safety• Not as “revolutionary” as remote/autonomous navigation

Idea: Move the Engine Control Room

(ECR) from the ship to a shore-

based Engine Control Centre (ECC)

▪ Shortage of machinery engineers to man ships

▪ Increasingly complex ships, new skills needed

▪ Increased digitalisation & improved ship-shore

connectivity

▪ Automation and remote operations is

increasingly adopted in other industries


ROMAS Work packages

Business & user requirements

Risk & reliability

Operational data analysis

Rules & regulations

Verification & approval

Implementation Piloting & DemoPM &

dissemination

6

H1 H2 H3 H4

H5 H6 H7 H8

▪ Objective: To establish a framework of regulations, rules and

verification methods for remote (shore-based) operations of ship

machinery and automation systems, enabling improved operations

and cost-efficiency without compromising safety of ship operations.


Some of the work done

- CONOPS – Concept of Operations- HazID analysis- IAS data analysis

7


Concept qualification process as per CG-0264 (Class Guideline for Autonomous and remotely operated ships)

8

Decide on

operations and

automation

High-level

design

Detailed

design

Build and

integrate

Commissioning

and test

Review of overall concepts Plan approvalNewbuild

survey

Test

witnessing

DNV GL newbuild process

Operations

DNV GL fleet in service process

FiS

surveys

Test scope

approval

Analyse class

operations

data

CONOPS

Preliminaryrisk analysis

report

Designphilosophy

Detailedvessel design

Detailed riskanalysisreports

Testspecifications

Safetyphilosophy

Verificationand validation

strategy

Maintenance philosophy

TestReports

Configurationmanagement

reports

Off-shipsystems design

Submitter’s activities


Fjord1’s ferry route Molde-Vestnes

10

M/F Korsfjord


Pilot vessel MF Fannefjord

▪ Norwegian flagged Ro-ro ferry built for Fjord1 in 2010

▪ Yard: Gdanska Stocznia Remontowa, Gdansk Poland

▪ Built to DNV class (Vessel ID 28425/D28424)

– 1A1 Car ferry B Clean E0 Gas fuelled R4(nor)

▪ Double-ended ferry design with battery hybrid gas (and

diesel) electric propulsion

11

Highly redundant propulsion system:

▪ 2 azimuth thrusters

▪ Power: 2x Gas + Battery + Diesel


Remote operations concept: ECC side

▪ ECC located in Fjord1’s office in Molde

– Manning: 24x7 by 1 operator (chief engineer)

– Arrangement for additional support (bakvakt)

▪ ECC designed to support 3 ferries

– Similar design & operational profile

– Pilot tests: Just one ferry (MF Fannefjord)

▪ Responsibilities

– Main responsibility for maintenance & operation

– Communication with ship and shore-parties

▪ Equipment

– 2 workstations (~ECR-like)

– Big screen with fleet view

12


Remote operations concept: Ferry side

▪ Overall manning level (5) remains unchanged

– to comply with requirements for safety manning

▪ Chief engineer replaced by “combiman”

– Qualification: Able Seafarer Engine (“Motormann”)

– Responsibilities:

– Combination of deck- and machinery- work

– Emergency/safety duties acc.to safety plan

– Planned maintenance

– Assist ECC operator when required

– Visual inspections and routine work

– Take local command of technical systems (when required)

– Receive support and guidance from ECC

▪ ECR and Bridge workstations: Backup for ECC

13


Remote operations concept: Monitoring & Control

▪Remote IAS (Integrated Automation

System)

– “hub” for monitoring & control of the machinery

and engineering systems

▪ IAS functional enhancements

– Communication system integration

– Transfer of Command

▪Remote connections from other relevant

ship systems such as:

– Fire / safety systems

– Shiplog – admin / operational

– CCTV

14


Remote operations concept: Communications

▪ The IAS Network onboard is extended to

ECC over a reliable and redundant ship-

shore communication link

▪ Communications

– 2 x 4G modems (Telia and Telenor) + ICE

– “Always on” 2-way voice ECC-Bridge

– VHF at ECC

– Portable communication device to support

troubleshooting

15

Example: DAQRI’s smart helmet (www.daqri.com)

https://www.ice.no/dekning/

http://www.daqri.com/

https://www.ice.no/dekning/


CONOPS: Mapping of Normal operations

16


CONOPS: Identification of abnormal conditions / scenarios

▪ Putting spare ferry into operations

▪ Simultaneous problems on two ferries

▪ ESD (Emergency Shutdown)

▪ Blackout

▪ Loss of ship-shore comms

▪ ECC unavailable

▪ Loss of propulsion

▪ Extreme weather

▪ Evacuation

▪ Etc.

18


HazID analysis

19


Hazid Analysis

▪ Workshop: DNV GL, Fjord1, Høglund, Sjøfartsdirektoratet and Rederiforbundet

▪ Goal: Identify and assess hazards associated with the concept

▪ Input: CONOPS

▪ Output: Hazid Report + Risk sheets

– serving as input for further work

▪ Two steps

– Jan 2018 (v1.0): MF Norangsfjord (workshop)

– Oct-Dec 2018 (v1.1) MF Fannefjord (@ DNV GL)

▪ Limitations: Relative exercise, no formal voting, CONOPS completeness

20

1 2 3 4

Minor Significant Severe Catastrophic

Effect on Human Safety Single or minor

injuries

Multiple or severe

injuries

Single fatality or

multiple severe

injuries

Multiple fatalities

Effect on Ship Local equipment

damage

Non-severe ship

damage

Severe damage Total loss

Frequency F\S 0,01 0,1 1 10

7 Frequent Likely to occur once per month on one ship 1E+1

6 Probable Likely to occur once per year on one ship 1E+0

5 Reasonably

probable

Likely to occur once per year in a fleet of 10 ships, i.e. likely

to occur a few times during the ship's life

1E-1

4 Seldom Likely to occur once per 10 years in a fleet of 10 ships 1E-2

3 Remote Likely to occur once per year in a fleet of 1,000 ships, i.e.

likely to occur in the total life of several similar ships

1E-3

2 Very remote Likely to occur once per 10 years in a fleet of 1000 ships 1E-4

1 Extremely

remote

Likely to occur once in the lifetime (20 years) of a world

fleet of 5,000 ships

1E-5

Severity


Hazid Workshop – risk matrix

21

Risk matrix

Conventional ops Remote ops w/mitigations

Rempote ops

https://dnv-my.sharepoint.com/personal/steinar_laag_dnvgl_com/Documents/Projects/ROMAS/Meetings/2018-01-24 Hazid Workshop/Risk assessment Romas_v0.83.xlsm


30 mitigations identified

30 mitigations

Training (2)

Design (13)

Procedure (15)

22


30 mitigations identified

Training(2)

• Machinery training (Combiman)

• Safety training (Combiman)

Design(13)

• UPS for IAS & Comms

• Descriptive Battery Alarm

• Alarm limits adjusted for remote operations

• Alarms with priority/criticality

• Sufficient IAS integration

• Additional ICE modem

• Comms outage alarm

• Walkthrough of all essential sensors

• Visual surveillance (CCTV) at ECC

• Redundancy of comms modems

• VHF at ECC

• Sufficient UPS, broadband and security at ECC

• Additional sensors or inspection tools for gas system

Procedures(15)

• Avoid simultaneous overhaul of two engines/generators

• Procedure for ECC-Bridge communication

• Procedure for handling comms loss

• Procedure for spare ferry to be put into operations

• Procedure for ECC handling for simultaneous problems on two ferries

• Procedures/criteria for taking the ferry out of service

• Procedure for transferring command from ECC to Bridge

• Procedure for ECC support in severe weather conditions

• Updated procedures for remote/ECC-operations

• Procedure for handling water ingress

• Procedure for fire handling

• Procedure for bilge handling

• CBM (Condition Based Maintenance)

• Updated procedure for gas system

• Updated procedure for battery system

23


Hazid Results

Conventional ops ROMAS ops w/mitigations

24

Increased risk

• 6.6 Communication failure

• 6.7 ECR/ECC outage

Reduced risk

▪ 2.2.1 Battery (ESS) Alarm availability

▪ 2.3.2 Too many alarms for ECC operator

▪ 2.3.3 Alarm information not detailed enough

▪ 6.4 Unplanned Maintenance & Repair

▪ 6.13 Fire incident

▪ 6.14 Environmental emissions


IAS data analysis

25


Could be

automated?

Analysis of historic IAS data – to understand the alarm picture and existing operations and practices

ALARM

Does it

trigger

work ?

Does it trigger

maintenance

or repairs?

Is safety

affected ?

Could be done

remotely?

On-board or in

port?

Skills & tools

needed ?

Countermeasures?

Affecting

manning levels?


Data sources

▪ IAS logs – events and alarms

▪ AIS data – position, speed, operational mode

▪ Historic maintenance logs

▪ Chief engineer’s log book

27MF Fannefjord MF Norangsfjord


IAS-log: Need for filtering..... (Norangsfjord 2016)

Alarmer + Eventer [126100]

Alarmer (alle statuser) [28166]

Nye alarmer (status 5) [1773]

Ex DG Stop/Start & THR Stop [1555]

Pivot System-Alarmer[661]

EkskludertMaintenance & Repair [540]

Ex Other [250]

28

Eventer: ikke

behov for

håndtering

Kun

hørbare alarmer

Overgangsalarmer

rel til DG start/stop

og THR stop

Oppfølgingsalarmer for

samme system (2 min)

Alarmer fra M&R 19.-23.

September

• Koble på landstrøm

• Tester og feilsøk

• REPEAT og FIRE Alarmer

~ 345 per dag

~ 0,7 per dag


COMMON alarms

29


Handling of routine work (planned maintenance)

▪ 2017 : 1434 records

▪ Mapped into categories

– Currently carried out by Service Personell

(external)

– Could be carried out by Service Personell

(external)

– Requires local precence of Chief Engineer

– Could be carried out by other crew (e.g.

Combiman)

– Could be remotely operated

– Could be automated/skipped

30


IAS data analysis – key findings

▪ Better system integration needed

– Standalone systems, local panels, lack of operator-focus

▪ Alarm improvements are needed

– Too many «nuisance alarms» – need for cleaning up and reduce volume

– Context/mode awareness and suppression of non-essential alarms

– Descriptive alarm texts - get rid of “COMMON Alarms”

– Categorisation of alarm criticality – to enable prioritisation

▪ Increase automation – minimise manual operations

– However, automation will call for new alarms..

– Sensor quality and self-diagnostics

▪ Need for supporting offline analysis

– Historical IAS logs

– Digital engine log

31

Total

BILGEBLACKOUTBOILERBUS_COMMUNICATIONDEADDG1DG2DG3DG4FOFWHYD. AGGMBSMSBNODEPUBLIC ADDRESSSEWAGESLUDGESTART AIRTHR1THR2UPS


Pilot testing campaign

32


Pilot test program 1Q 2019

▪ M/F Fannefjord as pilot vessel

▪ ECC in Molde (Fjord1’s premises)

▪ Based on previous work: CONOPS, Hazid and IAS data analysis

– NOTE: Subset implemented for Pilot testing

▪ In between test phases:

– Analysis of logs, documenting and assessing experiences. Making adjustment to equipment in ECC and

on-board the ship, as well as operational procedures.

33


Hazid: 30 mitigations identified

Training(2)



Design(13)


• Descriptive Battery Alarm









• VHF at ECC



Procedures(15)
















34


Mitigations implemented for pilot testing (implemented, partly implemented)

Training(2)



Design(13)


• Descriptive Battery Alarms









• VHF at ECC



Procedures(15)
















35


+ new features identified in pilot planning (implemented, partly implemented)

Training(2)



Design(13)


• Descriptive Battery Alarms









• VHF at ECC



Procedures(15)
















36

• IAS Command transfer functionality

• IAS alarm history “resynchronisation”

• Shiplog integration (ticket/adm system)

• Voice communication ECC-Bridge

• Comms system health monitoring

• Digital engine log book

• Big Screen Fleet view in ECC

• ESS/battery integration

• Fire system integration


ECC BIG screen layout

AIS

Fleet Sta

tus

CCTV

ECC implementation by Høglund – Big Screen


ECC Implementation by Høglund – Fleet Status

▪ Persons On Board:

– Automatically updated from

Shiplog.

– Can easily be expanded with

other info e.g. dangerous cargo

– Time saver during emergencies


Pilot test scope

▪ Normal operations

▪ Test cases

– Abnormal cases & failures

– Functional tests

– Ship-to-shore comms failures

– IAS – Comms interworking

– New ECC & IAS functionality

39

Nr Test type Scenario

1 AbormalPutting spare ferry into

operation

2 AbormalOperational problems on two

ferries simultaneously

3 Abormal DG auto-stop

4 AbormalUnplanned Maintenance &

Repair.

5 Abormal Black-out.

6 AbormalLoss of ship-shore

communications

7 Abormal ECC unavailable.

8 AbormalLoss of propulsion or

manoeuvring capability.

9 Abormal Extreme weather

10 Abormal Evacuation

11 Abormal Mob boat operation

12 AbormalWater ingress / Loss of

stability.

13 Abormal Fire alarm / fire incident.

14 AbormalEquipment down for

maintenance


Pilot test program 1Q 2019

Dry-run P0 Tønsberg 5/12 Test P1: Molde 23/1

40


Way forward

41


Way forward

▪ Continue and complete pilot campaign

▪ Document and share learnings

42

▪ Use learnings for future operations and development of new products & services

– “Remote Ready” IAS system [Høglund]

– Rules, RPs and TQ/AIP programs [DNV GL] and regulations [NMA]

– Consider commercial deployment for new ferries [Fjord1]


SAFER, SMARTER, GREENER

www.dnvgl.com

Thank you for the attention!

43

Steinar Låg

[email protected]

Phone: +47 95236838

Read more about ROMAS in DNV GL’s Research Review 2018:https://www.dnvgl.com/research/review2018/featured-projects/romas-remote-operations-machinery-automation.html

https://www.dnvgl.com/research/review2018/featured-projects/romas-remote-operations-machinery-automation.html