Systemsäkerhet i ett marint ledningssystem

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

2. Korvett typ Visby Översikt: http://www.fmv.se/index.asp?K=005003&L=SE Sprängskiss: http://www.fmv.se/images/eng_o.pdf

3. Ledningssystemets HW-arkitektur Andra system, t.ex. vapensystem, sikten, sensorer, gyron, navigeringssystem, lucksystem, etc. Ledningssystemet I/O-enheter Servrar Nätverk Konsoler 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”

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!

6. Analysresultat Hazard ID: 1/PHL:002-10 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>

7. KomponentsäkerhetsanalysSub-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

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)

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

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