Systemsäkerhet i ett marint ledningssystem

Transkript

1 Systemsäkerhet i ett marint ledningssystem SaabTech Systems levererar sitt ledningssystem till korvett typ Visby och till moderniseringar av korvetter av typ Stockholm/Malmö Detta program bestående av flera projekt kallas CETRIS SaabTech är underleverantör till FMV som är huvudleverantör SaabTech är en av många leverantörer i CETRIS 1

2 Korvett typ Visby Översikt: Sprängskiss: 2

3 Ledningssystemets HW-arkitektur Andra system, t.ex. vapensystem, sikten, sensorer, gyron, navigeringssystem, lucksystem, etc. Ledningssystemet I/O-enheter Servrar Nätverk Konsoler 3 Varje burk ovan innehåller kraftfulla PC-datorer, vissa med dubbla processorer --- OS är för närvarande Windows NT

4 Multiple Function Console (MFC) med vapenpanel 4

5 Riskkälleidentifiering och preliminär analys För varje huvudfunktion (t.ex. vapensystem) identifiera vilka olyckshändelser som skulle kunna inträffa! (nivå 1) För varje sådan möjlig olyckshändelse identifiera vilken/vilka av vårt systems funktioner och/eller komponenter som kan orsaka aktuell olyckshändelse! (nivå 2) Med aktuell information klassa riskkällans risknivå baserat på konsekvens och sannolikhet! 5

6 Analysresultat Hazard ID: 1/PHL: Accident: The gun fires in the wrong direction Cause: The gun fires in the wrong direction due to error when comparing the gun tell back angles and reported tell back angles Analysis: <More details about when and why this could happen> Risk Classification: <Severity, Probability and Risk Class> Recommendations: Requirements: <List of associated Safety Requirements> Verification: <test, review, etc.> Status: <Open, Closed, Verified or N/A> 6

7 Komponentsäkerhetsanalys Sub-System Hazard Analysis (SSHA) Komponenter som är direkt relaterade till de riskkällor som identifierats analyseras noggrannare ifall risken är av betydelse Syftet är att se om den tekniska lösningen är acceptabel med hänsyn till att komponenten är säkerhetsrelaterad En felmodsanalys görs på komponenten med fokus på gränssnittsdata och tillståndsdata hos komponenten Komponenten analyseras utgående från den riskkälla som den är relaterad till Särskilt fokuseras på de data som bedöms som säkerhetsrelaterade I denna analys kan man ofta behöva titta på händelsekedjor med flera komponenter involverade 7

8 Komponentsäkerhetsanalys, forts. För varje problem som hittas i komponentsäkerhetsanalysen så skrivs en rekommendation för förbättring av komponenten Vid en slutlig genomgång av rekommendationerna bestäms om komponenten skall ändras eller ej Ändringen initieras genom att en problemrapport SPR registreras (SPR = System Problem Report) 8

9 Verifiering Alla krav som skapats inklusive alla säkerhetskrav verifieras i ordinarie acceptanstest (acceptanstest = kravverifieringstest) Alla beslutade åtgärder som har legat till grund för slutgiltig riskklassning måste vara utförda Särskilt intressanta skyddsmekanismer kan behöva egna testfall som måste utföras 9

10 Några grundprinciper Säkerhet kan aldrig byggas på en programvara / ett datorsystem eftersom programvara och datorsystem har alldeles för låg tillförlitlighet Programvara och datorer är att betrakta som mycket otillförlitliga i samband med systemsäkerhetsarbete Säkerhet måste bygga på diversitet och redundans och helst på skyddssystem/reservsystem baserade på något annat än programvara (mekanik och/eller elektronik) Att ett enkelfel kan leda till en olyckshändelse är aldrig acceptabelt 10