Sammendrag. En kort beskrivelse av et databasert forriglingssystem som blir innført i Norge blir gitt og kravene til sikkerhetsbevisføringen blir beskrevet. Erfaringer som ble gjort da man skulle oppfylle kravene og lærdommer fra prosessen blir skissert.
Sikkerheten av jernbanenettet er avhengig av komplekse systemer for å styre og overvåke jernbanetrafikken på en sikker og pålitelig måte. Et sentralt element er forriglingsanlegg som styrer såkalte utdeler, f.eks. sporveksler, signallamper m.m.. Forrigling betyr her at hvert anlegg må styre sine utdeler i avhengighet av hvordan naboanleggene styrer sine. Dette medfører at anleggene må styre sine utdeler i henhold til spesielle forriglingsregler som skal sørge for at kun sikre kombinasjoner av togruter blir mulig.
Moderne jernbanesystemer gjør utstrakt bruk av datasystemer, og vurdering og sertifisering av slike systemer har blitt tilsvarende komplisert. I tillegg fører den europeiske integrasjonen til et behov for fellesprinsipper og prosedyrer, slik at vurderinger og sertifiseringer fra ett land kan bli overtatt i andre land.
Et steg på denne veien har vært å vedta europeiske standarder for jernbane anvendelser, spesielt CENELEC (pre-)standardene EN 50126 [1], EN 50128 [2] og prEN 50129 [3]. De beskriver prosesser som bør følges for å kunne garantere sikkerheten av en jernbane anvendelse. Men, mens de beskriver rimelig detaljert hva man skal gjøre, er de ikke så klare når det gjelder hvordan. Ref. [1] er toppdokumentet som dekker den totale prosessen for hele jernbanesystemet. Det definerer sikkerhets integritetsnivåer ("SIL") og legger føringer for de mer detaljerte aktiviteter som er beskrevet i ref. [2] og ref. [3]. Det sistnevnte er standarden som definerer aktivitetene for utviklere og leverandører, og den beskriver også kravene som en tredjeparts assessor skal verifisere. Ref. [2] kan anses som den programvare spesifikke varianten av ref. [3].
I denne teksten blir et virkelig tilfelle beskrevet, hvor man ville anvende standardene, og noen av erfaringene som ble gjort underveis. Lærdommen fra denne prosessen vil bidra til å gjøre framtidige sertifiseringer smidigere for samtlige involverte parter.
Jernbaneverket inngikk en avtale med daværende Adtranz Norge om leveranse av EBILOCK 950 systemer til Norge. Adtranz Sverige produserte EBILOCK 950 for et verdensmarked, så en tilpasning til norske forhold ble nødvendig.
I løpet av prosjektet ble konseptet endret noe, og produktet heter nå offisielt CBI950 ("Computer Based Interlocking"). CBI950 bygger på et velprøvd, eldre system som hadde vært i bruk i flere år. CBI950 er en plattform som består av hardvare, generisk programvare og en prosess for å generere applikasjonsspesifikk programvare. Hardvaren består av et datasystem ILC ("Interlocking Logic Computer") for å prosessere forriglingsregler og å styre utdelssystemet OCS ("Object Controller System"). OCS mottar ordre fra ILC for styring av utdelene (f.eks. signaler, veksler osv), sender tilsvarende beskjeder til utdelene og får statusopplysninger tilbake. Statusinformasjonen blir sendt tilbake til ILC for prosessering.
Programvaren i systemet må genereres for hver applikasjon. Den inneholder generisk informasjon om de gjeldende forriglingsreglene og om objekttypene som kan kontrolleres, og spesifikk informasjon om de virkelig tilkoblede objekter, anleggets geografi og topologi. Programgenereringen skjer med utstrakt bruk av automatiske verktøy for å oppnå det nødvendige sikkerhets integritetsnivået for programvaren. For en mer detaljert beskrivelse se ref. [4] og [5].
Tilpasningen av den generiske CBI950 til norske forhold påvirket både hardvare og programvare. For eksempel måtte hardvaren tåle norske miljøforhold, som inkluderer f.eks. temperaturer under 30 kuldegrader. Programvaren måtte tilpasses norske forriglingsregler og til å kunne styre det utstyret som brukes i Norge. Bruksanvisninger og vedlikeholdsmanualer måtte tilpasses den endrede hard- og programvare og bli oversatt til norsk.
Foruten tilpasningene til norske forhold inneholdt avtalen et krav om at CENELEC standardene skulle følges. En konsekvens av dette var at mange av de tekniske dokumentene måtte bli tilpasset kravene i standardene, og alle måtte vurderes. Tilsammen var det over fem hundre dokumenter som ble produsert og vurdert.
CENELEC standardene var pre-standarder da prosjektet tok til i 1997, og selv i skrivende stund er ref. [3] fremdeles en pre-standard. Den gang var det lite eller ingen erfaring med bruk av standardene. Det er faktisk fremdeles svært få prosjekter som forsøker å følge standardene fra begynnelsen av, og erfaringer fra den slags prosjekter blir sjeldent offentliggjort (se imidlertid ref. [6]), så det er smått med veiledning. Kravene til et sikkerhetsbevis var - og er - ikke særlig velkjent. Så før vi ser på problemene som oppstod under prosessen å produsere et sikkerhetsbevis, skulle vi først se på kravene til et slikt sikkerhetsbevis.
Ref. [3] krever at leverandøren skal framlegge et sikkerhetsbevis, kalt "Safety Case", som skal vurderes av en uhildet tredje part før myndighetene skal godkjenne idriftsettelse av systemet. Uttrykket "Safety Case" er kanskje rimelig forståelig for folk med engelsk som morsmål, men erfaringene viser en stor grad av forvirring når europeere med andre morsmål enn engelsk bruker uttrykket!
Ordet "Case" brukes i flere sammenheng. Vi har "uppercase" og "lowercase" for store hhv. små bokstaver, "suitcase" for koffert, "briefcase" for dokumentmappe, "court case" for en rettssak og - "safety case" for et sikkerhetsbevis. I dette tilfelle kommer uttrykket fra konteksten rettssak: der skal aktor og forsvarer presentere hver sin sak ("case") til domstolen slik at dommeren kan felle en dom.
I vårt tilfelle må noen presentere sak for et nytt (eller modifisert) systems sikkerhet slik at "dommeren" - sikkerhetsmyndigheten - kan ta en avgjørelse. Som i ekte rettssaker vil "dommeren" ty til en assessering fra en uhildet, sakkyndig tredje part før han stoler på sitt eget, personlige inntrykk. (Ordet "assessor" betydde opprinnelig "bidommer"!) Det betyr at et "safety case" IKKE er en mappe med sikkerhetsdokumentasjon, det er en bevisføring for sikkerheten, som støttes av dokumentasjonen!
Et av de vanligste problemene med sikkerhetsbevis er at de er for kortfattet. Visstnok tillater standardene bruk av referanser framfor å levere store mengder dokumentasjon for godkjenning, men det er slett ikke tilstrekkelig å bare referere til dokumentene, påstå at all informasjon er der og overlate det til assessoren å lese gjennom alt for å trekke ut den informasjon han trenger.
Selve sikkerhetsbeviset må inneholde nok informasjon til å gi et klart bilde av systemets sikkerhetsegenskaper, og indikere hvor detaljene kan slås opp om dette ønskes. De kapitlene av sikkerhetsbeviset som er beskrevet i ref. [3] må inneholde beskrivende tekst framfor en mer eller mindre komplett liste av referanser. I de følgende avsnittene blir kapitlene av et sikkerhetsbevis nærmere omtalt.
Det første kapitlet i sikkerhetsbeviset er Systemdefinisjonen. Det skal gi en fullstendig og detaljert beskrivelse av systemet som sikkerhetsbeviset skal gjelde. I ref. [3] står:
"Dette skal definere eller henvise til nøyaktig det system/subsystem/utstyr som sikkerhetsbevisføringen gjelder, inklusive utgave og revisjonsstatus for samtlige krav, design og anvendelsesdokumenter."
Dette betyr at systemdefinisjonen skal inneholde:
Dette kapitlet er en rapport som beskriver hva som ble gjort for å sikre at systemet har den ønskede kvalitet gjennom hele sin livssyklus. Dette medfører:
Dette er den tilsvarende rapport for sikkerhetsstyring. Som for kvalitetsstyringsrapporten medfører dette:
Dette er kapitlet hvor sikkerhetsegenskapene av det virkelige systemet beskrives. Det skal beskrive og begrunne hvilke standarder og konstruksjonsprinsipper ble brukt for å oppnå sikkerhet, og hvorfor de var tilstrekkelige. Her skal man identifisere systemets tekniske egenskaper og vise hvordan de ble demonstrert eller bekreftet, f.eks. gjennom testprotokoller, test- og analyserapporter, verifiserings- og valideringsrapporter, sertifikater osv.
Den tekniske sikkerhetsrapporten skal også redegjøre for hvordan man har sikret seg at systemet gjør hva det er ment å gjøre, men også hvordan man har sikret seg at det ikke gjør noe som det ikke skulle gjøre, selv under ugunstige betingelser. Dette vil føre til "sikkerhetsrelaterte anvendelsesbetingelser", dvs betingelser som må være oppfylt hvis systemet skal være sikkert. Til slutt må den fortelle om testene som ble gjennomført for å demonstrere at systemet virkelig er sikkert.
Hvis systemets sikkerhet bygger på sikkerhetsegenskapene av deler eller komponenter, må de tilsvarende sikkerhetsbevisene identifiseres her. I så fall må begrensninger eller applikasjonsbetingelser som står i slike sikkerhetsbevis sammenfattes her, dvs de betingelser som måtte tas hensyn til i det overordnede systemet.
Vær oppmerksom på at dette gjelder også når det finnes en tidligere versjon av systemet, som har et eget sikkerhetsbevis. På denne måten blir det betydelig lettere å produsere et sikkerhetsbevis for et oppgradert system. Fordi det gamle systemets sikkerhetsbevis inneholder all relevant informasjon for den versjonen, behøver kun sikkerheten av endringene bevises.
På samme måte vil bruk av moduler eller komponenter som allerede har sikkerhetsbevis føre til at behovet for detaljerte beskrivelser og bevisføringer kan bli redusert til den tilleggsinformasjonen som trenges for det aktuelle systemet.
I følge ref. [3] skal dette kapitlet "oppsummere bevisene som ble presentert i de forutgående delene av sikkerhetsbevisføringen, og argumentere for at vedkommende system/subsystem/utstyr er tilstrekkelig sikkert, gitt at de spesifiserte anvendelsesbetingelsene er oppfylt." Her kan man for eksempel redegjøre for at de sikkerhetsrelaterte anvendelsesbetingelsene fra de beslektede sikkerhetsbevisene er tatt hensyn til.
Ref. [3], §5.5.1 identifiserer tre forskjellige kategorier for sikkerhetsbevis:
Ideen bak er at et generisk produkt sikkerhetsbevis ("GPSC") skal tale sikkerhetens sak for et produkt, uavhengig av hvordan produktet skal brukes, slik at produktet kan brukes i forskjellige sikkerhetsrelaterte anvendelser. Den generiske applikasjons sikkerhetsbevis ("GASC") vil vise sikkerheten av en applikasjon uten å spesifisere hvilke produkter som skal bli brukt. Det betyr at det vil stille krav til egenskapene som produktene vil måtte ha.
Desverre gjør dette grensen mellom GPSC og GASC litt uklar, fordi et komplekst system som kan bruke "generiske" produkter (og derfor har et GASC) kan selv bli brukt som et produkt i et større, enda kompleksere system. Da blir den "generiske applikasjonen" et "generisk produkt" sett fra den kompleksere applikasjonen.
For eksempel kan en styring for utdeler være en generisk applikasjon, fordi den kan styre forskjellige utdeler uten at man må spesifisere akkurat hvilke utdeler som må brukes. Å bruke en slik utdelsstyring i et forriglingssystem ville gjøre den til et generisk produkt innenfor forriglingssystemet. Men dette skulle ikke påvirke bevisføringen for styringens sikkerhetsegenskaper.
Til slutt skal en spesifikk applikasjons sikkerhetsbevis ("SASC") vise sikkerheten til en gitt kombinasjon av eksplisitt identifiserte produkter i en gitt applikasjon. SASC vil selvfølgelig bygge på de underliggende GPSC'er og GASC, men detaljer rund prosjektering og drift vil få en betydning her. Ref. [3] krever faktisk "separat sikkerhetsgodkjenning ... for design av systemet og for dets fysiske implementering... ", så det må bli to SASC'er:
Ref. [3] krever samme struktur for alle de ovennevnte sikkerhetsbevisene, men innholdet i de forskjellige kapitlene vil være avhengig av hvilken kategori sikkerhetsbevis det handler om.
Sertifiseringsprosessen tok adskillig lengre enn opprinnelig planlagt. Dette var til dels fordi CENELEC standardene ble dårlig forstått, slik at behovet for visse former av dokumentert bevisføring ikke ble skjønt fra starten. Spesielt ble omfanget av nødvendig dokumentasjon undervurdert. Sikkerhetsbevisføringen skal jo støttes av dokumenter for alt som ble gjort og i begynnelsen av prosjektet var det ingen som visste hvor mye dette skulle bli.
I en bedrift som har lang erfaring med å produsere sikre produkter eksisterer dokumentasjonsrutiner som ikke nødvendigvis stemmer overens med det som nyere standarder foreskriver. Disse bedriftsinterne rutiner måtte justeres for å kunne oppfylle kravene i standardene. Dette er en vanskelig og tidkrevende oppgave i et stort konsern og førte til forsinkelser og diskusjoner om hva som skulle produseres og hvilken form det skulle ha. Dette var en læreprosess for alle og kostet tid og penger.
I tillegg til problemene med å forstå standardene og tilpasse rutiner til dem ble noen ytterligere problemer møtt. De var hovedsakelig forårsaket av emner som standardene ikke omtaler. De mest synlige blir omtalt nedenfor.
Som nevnt tidligere er CBI950 en videreutvikling av en eldre versjon av systemet. Dette medførte at de utviklingsprosessene som var blitt brukt ikke tilsvarte det som CENELEC standardene krever. Standardene handterer ikke dette tilfelle: de er myntet på utvikling av nye systemer framfor tilpasning av gamle.
Det var selvfølgelig ikke mulig å gjenta prosessene på en ny måte, så det måtte dokumenteres at de brukte prosessene var likeverdige med det som standardene krever. Det må påpekes her at standardene ikke gjør en bestemt prosess eller livssyklusmodell forpliktende, så denne fremgangsmåte er i samsvar med standardene. Men å produsere den nødvendige dokumentasjon i ettertid kan være en tidkrevende oppgave som kan innebære mye ekstra dokumentasjon ut over den som eksisterte fra før.
CENELEC standardene krever også dokumentasjon at nøkkelpersonale er tilstrekkelig kvalifisert for sine oppgaver. Dette kan bli vanskelig å bevise når nøkkelpersonale blir skiftet ut i løpet av prosjektet, f.eks fordi de har forlatt bedriften eller t.o.m. landet, og den relevante informasjonen ikke lenger er tilgjengelig.
Systemets konsept ble modifisert underveis i prosjektet. Dette skulle gi et bedre resultat, men hadde vidt rekkende konsekvenser på hvorvidt dokumentasjon som hadde blitt produsert tidligere i prosjektet kunne fremdeles bli brukt. En god del allerede vurdert dokumentasjon ble foreldet, og det var ikke alltid så lett å tilordne gammel dokumentasjon den nye strukturen.
I tillegg ble tekniske forbedringer og endringer implementert i delsystemer. Den nødvendige sikkerhetsdokumentasjonen ble produsert som om det berørte delsystemet hadde ingen sammenheng med den tidligere versjonen. Dette betydde at mange dokumenter ble produsert igjen istedenfor å gjenbruke de tidligere versjonenes dokumentasjon og redegjøre for endringene. Dette gav en veldig klar skille mellom produkt versjoner, men medførte en stor mengde tilleggsdokumentasjon med en tilsvarende stor mengde tilleggsassessering!
CBI950 konseptet inkluderer en prosess for generering av applikasjonsprogramvaren. CENELEC standardene behandler ikke hvordan man skal vise at en prosess er sikker. Prosesser skal føre til et produkt, og produktets sikkerhet skal bevises.
I tilfellet CBI950 er prosessen for generering av programvare fundamentalt for den generiske applikasjonen. Baktanken er at en sikker prosess vil føre til sikker programvare. Dette er filosofien bak ref. [2], fordi man vet at det ikke er mulig å tallfeste sikkerhetsegenskapene av programvare. Desverre identifiserer ref. [2] kun "godkjente" prosesser, men den beskriver ikke hvordan en "ny" prosess skulle bli sertifisert.
Den generelle strukturen til et sikkerhetsbevis kan fremdeles bli brukt for en prosess, men mens det er rimelig enkelt å definere systemet (her: prosessen), er det vanskeligere å redegjøre for kvalitetsstyring og sikkerhetsstyring under utvikling av prosessen og de "tekniske" egenskapene av prosessen som vil resultere i sikker programvare.
De tre forangående avsnitt viser at standardene ikke dekker alle aspekter av en virkelig applikasjon. Det er opp til partene i sertifiseringsprosessen, dvs leverandøren, jernbaneadministrasjonen og assessoren, å finne en løsning for de aspekter som ikke dekkes av standardene. Dette burde gjøres i begynnelsen av prosjektet, slik at alle parter vet hvem skal gjøre hva og når.
Modifiseringer underveis er dyre! Standardene ser for seg muligheten til å basere et sikkerhetsbevis på et eller flere "beslektede sikkerhetsbevis", så det er bedre å få sikkerhetsbeviset for det opprinnelige systemet ferdig og så oppdatere sikkerhetsbeviset for endringene, enn å tilpasse et uferdig sikkerhetsbevis til et endrende system.
CENELEC standardene er her for å bli. Selv om ref. [3] i skrivende stund har status "pre-standard" vil den bli vedtatt som standard en dag i ikke alt for fjern framtid. Standardene krever veldefinert, dokumentert bevis for sikkerheten, og hva slags dokumentasjon kreves er kjent i dag. Et godt råd er å begynne å tilpasse dokumentasjonen NÅ. Dette inkluderer ikke bare allerede eksisterende dokumentasjon, men særdeles dokumentasjonen som kommer til å bli produsert i framtid.
Det er tvingende nødvendig å forstå standardene. Å lære hva standardene krever gjennom å skrive et sikkerhetsbevis er ineffektivt og dyrt. Prosessen må være det omvendte: en god forståelse av standardene er nøkkelen til å presentere et godt sikkerhetsbevis.
Til slutt må leverandører være mer oppmerksomme på behovet for å kunne dokumentere historien. Så lenge det er produkter i bruk som ble utviklet lenge før standardene ble vedtatt vil det være et behov for dokumentasjon og arkivering som går langt over de vanlige lovbestemte arkiveringsforpliktelser.
Som nevnt i kapittel 3 skulle et sikkerhetsbevis inneholde informasjon om utgave, revisjon og dato av alle dokumenter. For dette skulle en separat "Liste over Anvendelige Dokumenter" ("LAD") brukes. En slik liste må identifisere samtlige anvendelige dokumenter, ikke bare de refererte, med tittel, dokumentnummer osv og nøyaktig hvilke versjoner skal anvendes. Da er det tilstrekkelig å identifisere den gyldige utgave og revisjon av LAD i sikkerhetsbeviset - for alle andre dokumenter kan man henvise til LAD'en.
Dokumenter arbeidet! Mange leverandører har ypperlige prosedyrer for å produsere sikre og pålitelige produkter. Fordi alle ansatte i bedriften er nødt til å følge prosedyrene, tenker ingen på å dokumentere hvordan og når de gjorde hva. Resultatet er en fullstendig mangel på bevis for den utmerkede måten de har gjort jobben på. Å dokumentere den ser kanskje ut som en haug ekstra papirarbeid, men det er et verdifullt bidrag til sikkerhetsbeviset og også en beskyttelse mot potensielle erstatningskrav årevis etter.
Bruk en hierarkisk produktstruktur. Konseptet med beslektede sikkerhetsbevis betyr at du kan gjenbruke sikkerhetsbevisene fra produkter på et lavere nivå i samtlige komplekse systemer som benytter produktene. Og sikkerhetsbevisene til flere "enkle" produkter er lettere å produsere og handtere enn et eneste sikkerhetsbevis for et stort, komplekst system.
Og til slutt: gi dine folk opplæring i standardene i begynnelsen av prosjektet. Hvis det er meningen at de skal følge standardene fra begynnelsen av, må de kjenne dem i forveien. Når de forstår hva standardene krever vil de være mye mer bevisst hva de må gjøre for å få sikkerhetsbeviset riktig ved første forsøk!