Opdracht · Smart Maintenance at SeaActief

SMAS Failsafe scenario’s and redundancy systems

Faalscenario’s, failsafes en redundantie voor het onbemande SMAS-schip

Project
Smart Maintenance at Sea (SMAS)
Student
Marisol Batista Patterson
Bouwt voort op
MCC Component Library & Source List
Context

Achtergrond

SMAS ontwikkelt een autonoom, snel varend schip zonder bemanning aan boord, met geïntegreerde drone-in-a-box voor inspectie en vrachtlevering aan offshore windturbines. Aansturing gebeurt vanuit twee Mission Control Centers (Eemshaven en Emden).

In de vorige opdracht is de MCC Component Library opgesteld. Die bevat 28 logische componenten in vier architectuurlagen, afgeleid uit vijf operationele scenario’s. Drie daarvan beschrijven situaties die misgaan: communicatieverlies tijdens een missie (S2), mislukte dronelancering (S3) en verslechterend weer tijdens een missie (S4). Die analyse keek vanuit het MCC: welke functie heeft de operator nodig. Wat het schip zelf moet kunnen, welke failsafes aan boord nodig zijn en welke systemen dubbel uitgevoerd moeten worden, is nog niet uitgewerkt. Security is bewust buiten de component library gehouden en wordt in een aparte fase behandeld.

Lees de MCC Component Library
Doel

Doel

Vanuit de faalscenario’s bepalen welke eisen dit stelt aan het schip, de drone-installatie en de communicatieketen, zodat het MCC-ontwerp en de specificatie van het schip op elkaar aansluiten.

Hoofdvraag

Welke technische eisen, failsafes, redundantie en observatiemiddelen zijn nodig om het onbemande SMAS-schip veilig te laten functioneren wanneer een operationeel scenario misgaat?

Zes deelvragen

Onderzoeksvragen

01

Verdieping bestaande scenario’s

Werk S2, S3 en S4 uit vanuit het schip in plaats van vanuit het MCC. Beschrijf per scenario de oorzaak, hoe het schip het detecteert, wat het schip zelfstandig doet als er geen verbinding met het MCC is, en in welke eindtoestand het schip terechtkomt (safe state). Leg expliciet vast wat er gebeurt bij combinaties, zoals weersverslechtering tijdens linkverlies met een drone in de lucht.

02

Aanvullende scenario’s

Vul de set aan met scenario’s die nog ontbreken. De startlijst S6 tot en met S16 is uit te breiden of te schrappen na onderbouwing. Beschrijf de nieuwe scenario’s in dezelfde stapstructuur als de component library, zodat nieuwe of gewijzigde MCC-componenten direct herleidbaar zijn.

03

Eisen aan het schip

Leid per scenario af wat het schip moet hebben of kunnen. Denk aan sensoren, actuatoren, autonome besluitvorming aan boord, compartimentering, brandbeveiliging, noodverlichting en markering, positiebepaling en ankeren of drift-gedrag. Formuleer eisen toetsbaar (meetbare waarde, conditie, reactietijd) en koppel elke eis aan het scenario en de stap waaruit hij volgt.

04

Failsafes: voorkomen en schade beperken

Maak per scenario onderscheid tussen preventieve maatregelen (kans verkleinen) en mitigerende maatregelen (gevolg beperken). Gebruik hiervoor een bow-tie-analyse of FMEA. Bepaal per failsafe of die aan boord, in het MCC of in de drone moet zitten, en wat het schip doet als meerdere failsafes tegelijk actief worden. Neem bestaande failsafe-logica van PX4 en ArduPilot mee als referentie voor de drone, en regelgeving en classificatierichtlijnen voor op afstand bestuurde en autonome schepen (onder meer IMO MASS Code en DNV-CG-0264; stand van zaken nagaan) voor het schip.

05

Redundantie

Stel een redundantiematrix op voor alle kritieke systemen en classificeer elk systeem. Onderbouw iedere keuze met scenario, gevolg en kosten of gewicht. Besteed aandacht aan common-cause failures: twee systemen die dezelfde voeding, kabelroute of antenne delen zijn niet redundant.

06

Communicatie en observatie

Bepaal wat de operator in het MCC in elk scenario moet kunnen zien en horen, en welke middelen daarvoor nodig zijn.

  • Communicatie: welke verbindingen zijn nodig (bijvoorbeeld 4G/5G offshore, LEO-satelliet, VHF/AIS, point-to-point radio), welke data over welke link gaat bij normale werking en bij degraded mode, en welke minimale bandbreedte en maximale latency per datastroom acceptabel zijn. Bepaal de prioritering van datastromen wanneer bandbreedte beperkt is.
  • Camera’s: stel een cameraplan op met positie, doel en type — vaste EO-camera’s voor 360° uitkijk, PTZ-camera’s, thermische (IR) camera’s voor nacht en mist, camera’s in de drone box en op het lanceerplatform, en camera’s in machinekamer en accuruimte. Geef per camera de benodigde resolutie, framerate, codec en bitrate, en de omgevingseisen (IP-klasse, zoutnevel, trillingen, verwarming en ruitenwisser).
  • Vermogen: stel een vermogensbudget op voor alle camera’s en communicatieapparatuur, uitgesplitst naar normaal bedrijf, piek (verwarming, PTZ-beweging, IR-belichting) en noodbedrijf op noodvoeding. Neem PoE-klasse per camera op (802.3af 15,4 W, 802.3at 30 W, 802.3bt 60/90 W) en bepaal hoe lang de kritieke observatie- en communicatieketen op noodvoeding moet blijven werken.
S6 — S16

Startlijst aanvullende scenario’s

Uit te breiden of te schrappen na onderbouwing.

#Scenario
S6Uitval voortstuwing of stroomvoorziening (blackout) op zee
S7Brand aan boord, waaronder thermal runaway van drone- of scheepsaccu’s
S8Harde landing of crash van de drone op het dek of in de drone box
S9Aanvaringsrisico met vaartuig of drijvend object, inclusief schepen zonder AIS
S10GNSS-verlies, jamming of spoofing
S11Waterinname, kapseizen of stabiliteitsverlies
S12Drone raakt turbine of blad tijdens inspectie
S13Vrachtverlies of vastlopen van de lier tijdens levering
S14Uitval van beide MCC’s of van de MCC-to-MCC-verbinding
S15Slecht zicht (mist, nacht) tijdens transit of lancering
S16Onbevoegde persoon of object aan boord (aan de haven of op zee)
Classificatie

Redundantieklassen

KlasseBetekenis
N+1 / dubbelUitval leidt direct tot onveilige situatie; geen acceptabele degraded mode
Graceful degradationUitval is op te vangen met een ander systeem of beperkte functionaliteit
EnkelvoudigUitval heeft geen directe veiligheidsimpact; missie kan worden afgebroken
Producten

Op te leveren

ProductInhoud
ScenariocatalogusUitgewerkte faalscenario’s S2 tot en met S16 (of gemotiveerde selectie) in stapstructuur
EisenlijstToetsbare eisen aan schip, drone-installatie en communicatie, herleidbaar naar scenario en stap
Failsafe-overzichtBow-tie of FMEA per scenario, met locatie van de failsafe (schip, drone, MCC)
RedundantiematrixClassificatie per kritiek systeem met onderbouwing en common-cause-analyse
Communicatie- en cameraconceptLinkarchitectuur, datastromen met prioriteit, cameraplan, bandbreedte- en vermogensbudget
Update component libraryNieuwe of gewijzigde MCC-componenten die volgen uit de nieuwe scenario’s
Buiten scope

Afbakening

Security (authenticatie, encryptie, intrusion detection) valt buiten deze opdracht. Waar een faalscenario een securityoorzaak kan hebben, zoals GNSS-spoofing, wordt het gevolg en de failsafe uitgewerkt en de oorzaak doorgezet naar de securityfase. Het ontwerpen of dimensioneren van de scheepsromp en voortstuwing zelf valt buiten scope; het gaat om de eisen die de scenario’s daaraan stellen.

SMAS — Smart Maintenance at Sea

Vragen over deze opdracht?

Neem contact op met Zernike CollabSpace of bekijk de overige opdrachten binnen het SMAS-project.