Om konceptfasen beskriver problemdomänen (eng. problem domain), syftar systemdefinitionsfasen till att påbörja beskrivningen av lösningsdomänen (eng. solution domain). Men EN 50126 ställer också krav på att man i denna fas definierar RAM- och säkerhetsorganisationen för systemet och tar fram RAM- och säkerhetsplanerna. (Säkerhetsplanen går vi inte in närmare på här, då fokus ligger på RAM-arbetet.)
Egentligen är systemdefinitionsfasen ingen distinkt livscykelfas utan det standarden beskriver här är tre leverabler som ska tas fram och vad de ska innehålla. För RAM-plan och säkerhetsplan skriver man uttryckligen att om vissa delar av innehållet inte finns tillgängligt så tidigt i livscykeln så kan man fylla på med den informationen senare.1 Motsvarande skrivning finns inte för systemdefinitionen. Men i standarden står det att man ska välja en livscykelmodell för sitt ”system under consideration” och att den modellen ska ta höjd för möjligheten till iterationer i och mellan faser.2 Det betyder de facto att systemdefinitionen, liksom alla leverabler som kravställs i EN 50126, är levande dokument – inte bara de som explicit beskrivs som sådana i standarden! Vi tar helt enkelt fram en systemdefinition baserat på för stunden tillgänglig information och uppdaterar den efterhand som ny information blir tillgänglig.
Skillnaden mellan livscykelfaser och processer/aktiviteter är att indelning i livscykelfaser syftar till att leda verksamheten på ett effektivt sätt. Fasövergångar syftar till att fatta beslut; ex.vis beslut om att påbörja utveckling, beslut om att sätta igång produktion, beslut att driftsätta ett system och beslut att avveckla systemet. De är beslutspunkter då man fastställer att tillräcklig information finns framme för att ta nästa steg, som ofta handlar om att göra en investering, etablera en organisation eller att tillsätta mer personal. Processer och aktiviteter, däremot, kan löpa över flera (alla) livscykelfaser men med olika tyngd i olika faser.3 En klassisk bild – den s.k. ”sega råtta-bilden” – av detta, som illustrerar väl hur olika aktiviteter löper med olika tyngd över flera faser, finns i Rational Unified Process (RUP).4 Man itererar alltså inte mellan olika faser. Endast i undantagsfall kan man tvingas göra om och gå tillbaka till en tidigare fas. Däremot kan man uppdatera leverabler och då måste man hålla koll på vilka andra (senare) leverabler som påverkas av en sådan uppdatering.
Olika livscykelmodeller (faser) och utvecklingsmodeller (processer/aktiviteter) passar bra för olika typer av system. För ett mjukvarusystem, där utvecklings- och produktionsmiljö är samma sak, kan en agil process vara lämplig och en livscykelmodell med stegvis införande av mer och mer funktionalitet, likt RUP. För ett mekaniksystem, där utvecklingen sker i en cad-miljö och där det krävs en stor investering i produktionsanläggning kanske en sådan livscykelmodell inte är den lämpligaste.
EN 50126 beskriver enbart en systemdefinition, en RAM-plan och en säkerhetsplan per system. Man har perspektivet ”ett system, ett projekt, en livscykel”. Men system och projekt har olika livscykler. Och över systemets livscykel är flera aktörer inblandade; en projektorganisation hos kunden ansvarar för upphandling av en systemleverantör som i sin tur utvecklar och installerar systemet, när systemet är levererat ansvarar kundens driftorganisation för den dagliga driften och underhållsplaneringen, en upphandlad underhållsleverantör sköter det trafiknära fordonsunderhållet, andra gör större revisioner, underhållsleverantörerna byts ut under systemets livslängd, osv. Det måste finnas en tydlighet i vem som gör vad av de olika aktörerna, respektive aktör måste planera sina respektive åtaganden under systemets livscykel. Enligt EN 50126 ska RAM-planen överenskommas mellan kund och leverantör. För säkerhetsplanen står det att den ska leva över systemets hela livscykel och att det därför är nödvändigt att definiera relationerna mellan de olika inblandade intressenterna.
Om man inte tänker till finns det en uppenbar risk för att ansvaret för olika aktiviteter och leverabler blir otydligt definierat eller missas i kontrakt mellan olika parter. Risken för otydlighet gäller framförallt fram till dess att systemet har gått in i driftfasen. Fram till dess kan det finnas väldigt olika uppfattning om i vilken fas man befinner sig. Kunden kanske uppfattar att man skriver kontrakt med leverantören medan man är i konceptfasen, medan leverantören tycker att man i princip redan är framme i tillverkningsfasen och endast ska sätta lite parametrar. Eller tvärtom, kunden tycker att man är i designfasen fastän kontraktskraven är alltför fluffiga för att kunna utgöra underlag för designarbetet.
Det gäller därför att tänka till hur man lägger upp arbetet och fördelar ansvaret.
Systemdefinition
Systemdefinitionen i EN 50126 beskrivs huvudsakligen ur ett ”black box”-perspektiv, den beskriver systemet utifrån dess funktioner och gränsytor utan att gå in på systemets realisering. Den ska även beskriva driftprofil, förutsättningar och villkor för drift och underhåll samt överväganden som behöver göras ur livslängds- och logistikperspektiv. Det kan ex.vis röra sig om att man behöver ta hänsyn till kringliggande/överordnade systems underhållsintervall, möjligheter till framtida (eventuellt redan kända behov av) systemuppgraderingar, behov av byggnation av nya underhållsfaciliteter eller reservdelslager, etc.
Vad gäller driftprofil så är det värt att notera att det inte räcker att referera till en driftprofil i en standard. Om vi t.ex. tittar på driftprofilen som beskrivs i ERTMS Subset 091, så står det tydligt att om driftförutsättningarna för systemet skiljer sig signifikant ifrån de antaganden som gjorts i Subset 091 så finns det en risk att systemets säkerhetsmål inte nås även om utrustningen uppfyller alla säkerhetskrav i standarden.5 Driftprofilen måste i detta fall i sin slutliga utgåva därmed analyseras till samma detaljnivå som man gjort i Subset 091.
Vidare ska systemdefinitionen innehålla beskrivning av systemets gränsytor; miljö (klimat, höjdnivå, elmiljö, etc.), gränsytor mot andra tekniska system, mot människor (användare, underhållspersonal, m.fl.), gränsytor mot andra aktörer, t.ex. utbyte av information mellan fordon och infrastruktur. Här kan användningsfall (use cases), aktivitetsdiagram, sekvensdiagram och tillståndsdiagram vara användbara beskrivningsmetoder.
CSM-RA ställer ju också krav på en systemdefinition. Är det då samma systemdefinition som EN 50126 beskriver? Ja, om vi håller oss till tekniska system är de två systemdefinitionerna åtminstone väldigt nära. Men CSM-RA har enbart fokus på risker, så för att systemdefinitionen vi pratar om här ska vara användbar för att även kunna titta på tillgänglighetsaspekten gäller det att inte glömma bort de så viktiga drift- och underhållsaspekterna som beskrivits ovan.
Här gäller det också att tänka till hur man lägger upp ansvaret. Kanhända att systemdefinitionen som kunden initialt tar fram inte ger den detaljinformation som leverantören behöver? Det är bra om det klargörs i kontraktet hur samarbetet ska gå till och vem som i så fall ska ansvara för att uppdatera systemdefinitionen, likväl som andra systemdokument.
RAM-plan
RAM-planen syftar till att planera de RAM-aktiviteter som ska genomföras. Som för alla planer är de knutna till en viss organisation och dess åtagande. En upphandlande organisation kan inte detaljplanera leverantörens arbete och på motsvarande sätt kan inte en leverantör ta ansvar för aktiviteter utanför dennes åtagande. Idén om en enda RAM-plan för systemet är därmed felaktig. Ett lämpligt upplägg kan vara att kunden har den överordnade RAM-planen och att respektive leverantör tar fram planer för sina respektive åtaganden.
I RAM-planen beskriver vi hur den generella RAM-processen beskriven i tidigare blogginlägg anpassas för detta specifika projekt. Mängden nya analyser som behöver göras beror bland annat på hur mycket nyutveckling projektet innehåller, hur mycket befintliga data som finns att tillgå och hur mycket av underhållslösningen som redan existerar. RAM-planen fylls sedan på med mer information efterhand som systemlösningen växer fram.
EN 50126 anger fyra huvudområden som RAM-planen ska innehålla: ledning av RAM-arbetet (management), samt de tre egenskaperna tillförlitlighet (R), tillgänglighet (A) och underhållsbarhet (M). Man har inte med framtagningen av underhållslösningen i beskrivningen av RAM-planens innehåll. RAM-planen bör därför utökas så att hela processen för RAM-arbetet täcks in.
Slutsats: Denna “livscykelfas” i EN 50126 beskriver kraven på tre leverabler (systemdefinition, RAM-plan och säkerhetsplan) som börjar tas fram tidigt i systemets livscykel men uppdateras efterhand. Ur ett RAM-perspektiv är driftprofilen och systemets interaktion med omliggande system (inklusive människor) samt de överväganden som behöver göras ur livslängds- och logistikperspektiv viktiga delar i systemdefinitionen för det fortsatta arbetet.
[1] EN 50126, kap. 7.3.2.2 och 7.3.2.3
[2] EN 50126, kap. 6.5.1
[3] Se t.ex. http://trevorknelson.com/2014/12/08/project-life-cycle-vs-process-groups/
[4] Se t.ex. https://en.wikipedia.org/wiki/Rational_Unified_Process#/media/File:Development-iterative.png
[5] Se ETCS B3 R2, Subset 091, paragraf 10.1.1.2 (https://www.era.europa.eu/content/set-specifications-3-etcs-b3-r2-gsm-r-b1_en)