Safety Criteria and Development Methodologyfor the Safety Critical Railway Software

Eui-jin Joung', Se-chan Oh2, Sung-hyuk Park3

, Gil-dong Kim4

I-4 Advanced EMU Research Corps., Korea Railroad Research Institute, KoreaE-mail: ejjoung@krrLre.kr

Fig. I . Application field ofrailway software

Signal room

OperationManagement

Compu ter

-

< <>

Router

Interlocking

JliII .- ItU, 4m",,,,,

Wit Ii'"~ ",,,,,,,, -+t.;::-'r-- - - !t:= = 1

Operation IPanel

TrainOperation

Conso l

Comm.Network

StationEquipment

Wayside & OnboardEquip ment

II. SAFETY CRITERIA FOR RAILWAY SOFTWARE

Railway software safety criteria have to be described not tocontradict other international standards. Railway safety criteriaare sub-regulation of"Railway Safety Acf' in Korea describedin the triangle in the following figure. Several industry

ControlRoom

the safety criteria are suggested to secure the software safetyfor the field ofrailway system. The software used in the safetycritical system has to be examined whether it is properlydeveloped according to the safety criteria and certificationprocess. This paper also suggests a development methodologyfor the railway company to easily apply the criteria to therailway system.

Abstract - The main part of the system is operated by thesoftware. Besides the safety critical system such as railways,airplanes, and nuclear power plants is applied by the software.The software can perform more varying and highly complexfunctions efficiently because software can be flexibly designedand implemented. But the flexible design makes it difficult topredict the software failures. We need to show that the safetycritical railway software is developed to ensure the safety. Thispaper is suggested safety criteria and software developmentmethodology to enhance safety for the safety critical railwaysystem.

The railway system is also safety critical system and thesoftware is widely used in the railway system. For this reason,

I. INTRODUCTION

The digital system performs more varying and highly complexfunctions efficiently compared to the existing analog systembecause software can be flexibly designed and implemented.The flexible design makes it difficult to predict the softwarefailures. Even though the main characteristic of railwaysystem is to ensure safety, nowadays software is widely usedin the safety critical railway system just after evaluation ofsystem function itself. The following accident describes thecriticality of the software safety.Flight SOl, which took place on June 4, 1996, was the first,and unsuccessful , test flight of the European Ariane 5expendable launch system. Due to a malfunction in the controlsoftware, the rocket veered off its flight path 37 seconds afterlaunch and was destroyed by its automated self-destructsystem when high aerodynamic forces caused the core of thevehicle to disintegrate. It is one of the most infamouscomputer bugs in history. The amount of this loss is more thanUS$370 million. This accident was due to specification anddesign errors in the software of the inertial referencesystem.[I]After the accident, the scientists can be recognized thecriticality of the software failure in the safety critical system.We can categorize the causes of software problems as follows.- Vague and unclear specification ofcustomer requirements- Poor communication with customer and other developers- No systematic approach to software development- Little emphasis on software maintenance- Lack ofsystematic and complete software testing- Lack of historical data on software development process- No good way to measure productivity

standards are referenced to deduce the safety criteria not tocontradict industry standards.

l\ILTl\I Announcement(Safety C rlterla for Railway SW)

Detail G nldeline

+ tIndustrial Standard &T echnical G u idebooks

Fig. 2. Categorized standards related to deduce the safety criteria of therailway software

The following figure represents the areas to secure the qualityof railway software and the classification of the relatedstandards. There are three areas related to the software quality,such as domain standards, process related standards, andproduct related standards.

Fig. 3. Categorized standards to deduce safety criteria of railway software

As domain standards, safety related standard of railwaysystem are referenced. There are representatively electricaland electronics standard, IEC 61508, and railway safetyrelated standard, IEC 62278 and IEC 62279. IEC 62278 isdescribed the railway RAMS (Reliability, Availability,Maintainability, and Safety) and IEC 62279 represents therailway software as those transformed from the EuropeanCENELEC standard, EN50128. Of course safety criticalsoftware standards of other domains such as nuclear,aerospace, defense, etc are reviewed to understand thecharacteristics ofsafety critical software.As the process area, there are CMMI (Capability MaturityModel Integration) and ISOIIEC 15504 (so called SPICE:Software Process Improvement and Capability dEtermination)which manage the maturity of the software process. Thefailures due to the software are recognized as the systematicfailure. The inadequate system interface and process between

human and machine, and between hardware and software isinducing the systematic failure. To avoid the failure, welldefined process has to be prepared and the process has to bealso assessed whether it controls the software errors. Thestandards referred in the process areas give us the guide toevaluate the process maturity level.As the product area, there are ISO/IEC 9126 which defines thesoftware quality characteristic and ISO/IEC 14598 whichcovers the quality evaluation of software products. While thestandards of the process area are suggested in the assumptionthat high qualified software is coming from the well definedprocess, the standards of the product area are just focusing thesoftware artifact itself If there is no error detected during thesoftware test in each lifecycle steps, we consider the softwarehas desirable quality in the related test. The standards referredin the product area are described the software qualitycharacteristic that have to be ensured the software quality, andthe evaluation procedure to assess the software quality. [2-8]The following figure represents the framework of safetycriteria for the safety critical railway software.

Safety Cr ite ria for Safety-Cr ilical Railway Sott ware

I .~ 'I SW safety inl egril y level IQu:.:;or Qu ality assU'"anc eI (3) Configu ration mM agemert I

Development plan~ Requirement

lIlI!ll.llJllLl Designd'v ' lopment(6) Impl em entati on

Maintenance

tV&Vplan

~Unit lest

~Requirement V&V ~ SW integration lest

guideline for OesignV&V --. IU! HWISW integration lest:all Implementation V&V (4) System lest(6) TestV&V

Maintenance V&V

tSorety p an

~Requirement safety analysis

gu ldelln, for Design safety analysis~ Implementation safety

(6) analysisTest safety analvsis

Fig. 4. Framework of safety criteria for safety critical railway software

The safety criteria suggested in this paper are classified to thefive areas such as support, development, verification &validation (V&V), test and safety. The criteria of thedevelopment, V&V and safety are listed according to thelifecycle respectively. The test criteria will be adoptedfollowing to the activity of V&V and safety analysis. Thesupport criteria are related to the other criteria and control allthe management activities.All of the criteria will be used as guidance to the company todevelop the railway software. The criteria with red characterin the figure 4 are used for the assessment organization.Each article is composed of the article, description and theevidence describing related standards and regulations. [9]The following figure represents the safety criteria according tothe software lifecycle. There are one safety criteria and 23detail guidelines.

---TM'

nC..ty:ul ysi s• _ oo .--.' _

IEC 62278, 62279EN 50129IEEE standard

Observa nce of the relate d

interna tional standard s

Renectlon or the chara cter

of Safet y-critical SWSW developer's needs

consideration

in railway

Process

Requirement analysis

Ll--.,·-bJ'-"'- bJ-···-....,.10 "." I!' __I"

'-=="--=- ' -=::'--=~ '-=="-=--_ M _ . . _ M- - -

K"R I~~~ K~~ I __ '".. .l ,__~

SUPPO R T

EJ~

Qllality

C'afic=~R-ac~"""1

H.m'AAal,...k"sWSUrty

t...lr cn."lA...1

1.'....1:0.....

I_tyua.l,.., ..

V&Vplu.

JU..llino_IIt

.........J!'!. .._.

Ulti, tSWlAlocnti t

SWlHWo."Cn li..

._. ~'!."""l ••

••

•REQ.

Hl &A

PL A NSAfETY

CRITERIA forRA ILWAYSW

NANC E

Fig. 7. References to derive railway software development methodology

Fig. 5. Framework of safety criteria along to the software Iifecycle

Fig. 6. Safety certification procedure for applying the software safety criteria

Fig. 8. Framework ofdevelopment methodology for the safety critical railwaysoftware

1) Planning establishment2) Requirement specification3) Design4) Module design5) Implementation6) Integration7) Integration ofhardware and software

The following figure shows the software developmentmethodology for the safety critical railway software. The stepsof this methodology are seven steps and each step isinterconnected with V&V and safety analysis process.

The examples of the process document for the requirementspecification and design are described in Figure 9. The processdocument represents the role and activity among those whoresponsible for development, V&V and safety. It alsospecifically describes the input and output documents and thedetail activity for each step.

The figure 8 shows the framework of software developmentmethodology for the safety critical railway software and thefigure 9 shows the examples of process document in thismethodology. The process documents of the railway softwareare composed of the following seven steps.

IndependentSafety

Assessment

("inistryofland, Transport

and "aritileAffairs)

;~,~:;~:~/I//~~,rTf:; ~t : '(;,

Project Manager 4) Correcti oo

(Raj Iway Industry I3) Tecmlcaldl scusslon

MUM

III. RAILWAY SOFTWARE DEVELOPMENT METHODOLOGY

The development methodology of safety critical railwaysoftware is made to provide specific procedure to thedeveloper. This methodology is composed of procedure,templates and techniques. The procedure documents showeach development step. The template documents are a kind ofreferenced format of input and output which are defmed in theprocedure documents. The technique documents will be usedifthe more technical contents are required.

The safety criteria also describe the railway software safetymanagement procedure. The suggested safety criteria will beused for the developer and assessor in the following figure.The project manager develops safety related software, andthen applies the software to the MLTM for certification .MLTM is a government organization, so that the request istransferred to safety review group. The group is act as anauditor. If some technical review is required, the review istransferred to an Independent Safety Assessment (lSA)organization. The ISA acts as an assessor. The safety reviewgroup and ISA review several documents and evidencescoming from project manager. After review, all the results aresubmitted to the MLTM. Finally the system review panelmakes decision for certification and MLTM send the decisionto the project manager.

RequIrementSpeciflcatlon orga.nlzation V&Vorganizatlon Safety orga.nlzatlon

(5'f;~fI'I R!QJ~~1 S~{t1 c ~l':f\ Sr~t~m SM {[SP'D-CJjs« Sftl~ PI~nl

-~"---2SWOiM'fOP"J1«"I P!~1 ISP.D,02ISW Yt.v~

~ISR-T.Olr-w ~~:J>f~SPo!':It[!h:1l r!'..-m~ ~ISIl:"".c...,...t~,Lfl'el{oK>~",l~ SRV·,SW Req. Anenment ISR$.1 S'IJ ~q , S ;to:(1 A ~ ~~~ roe nl II .- SR Y· 1. 1S'N1l~_AJ1"'~~SRO·' SWR,q.Specification SRV.I 2 kt~ rl.;c, AJl~I~~~

S>l D- l , lsw r ~~~ [lEo;{f1»OOSRY·U Trm ~bIIC~AJ1 "'Y' ls

SRO·1 2w.-S*'r W1lI'~nJylr"RIOehnrkfl

SR0-1 3 E rI~m~lIrh;t1~($~nltlc ~tI1ll

SRD-1 4SW OpQf~hon 1iQ~1 "p·~..ooI';Wrfrt"'o:rl.Rf~S:llt>'rle<lAcb~"Il'\~ Ot}(~~biYI

SRO· 1 5Cofl:;~~rL De'SUill '" tee-e-e

SRD-16SW~"CNo<~IfI~ ~lOutrlPhlllSR O·11 TI ~I R tq-J rC1rnJ"t ~cnpb::tl ssV.~ S'NRlq te st S90cif>: ~IIOIl t-SRo.18 R.QIJ~ SW Al\.I,11$

~.{}.mJSlo"'''-fll ~:n~r"~ .Ilt, [)Olp,:WIl..q J I~'It!.1"~":<, Iit~

I SR0.2 TI~~Hbllcr lIl:llrtlr. ~""

c;.~M~ ~~r,_4!r_ ISR5-2 SWSBfelyRtotutd ISRV-JVt,VRepolt DGCun'lo('nlttlon ~- Oocum.mt~ lon. [ SIl:.t<-OJPHlv fl~ (Jd~t9U31;;'V"N"N'V~

Design staff V&V stan Safety stan~.rE'Q.l~rE'm~1S soecracencn. system sa e v requremen scecaceuco . System architecture desigl dOOJmenl$, SoN 1[SP-0-041 SW Safely plan }eivelopmenlplan docurrene}

[SP-o~v&vP!an [SO-'-1') SW~~ri;k~I".SD D 1 Defll1ing SWstJuct.Jre

design. docLmffl1s ____SO 0-1 . 1Oisl,ngulstllng SW structure - ~ SD V- )SW _ I SO S-1 SW desi'71eerew essessrrent I

elementsSO 0·1 .2 Ois~nguishing SWstrueture SOY- l _ l l~i S I-andjnterfacaSO 0-1 .3 Grasping COTSrestrkted So Y-12Traceabilrtyanalysi

mailer sSO 0- 1.4 Grasping e>lisling SW restrcted

mailersSO 0-1 .5 Distinguishing SW dellelopment

sfrategy a-ld development lecmi ql.ES

[So -O-OI JSW~:t:~re specification JSO v-2 1.nspe~,~ ~n. 01

~[SO-T-02] SWdesig tecmcoes Inlegrallonlestsoecmcaton

I SO 0-2 Defining SW desjgn specificalio~ II[SO-O-02] SW desir ececnceuoe

ISO 0-3 WrrtingS~ inlegration test /1 I SOV- 3 PrE'parng V&V rePJ+-- I SO S-2 Prepa'inq SWsafely log Ispecification

[TE-O-Ol ](SW integi liOntest) specification [SP-O-03] V&V! eports (SW desig'l) [SA-0-03 SW Safely log

Fig. 9. Examples ofprocess document for the safety critical railway software

Generally those who are responsible for V&V do the role ofsafety additionally. System verifier and validater review thesoftware safety in the view ofquality management. Otherwise,for the railway system which considers safety as an importantfactor, the role of safety is divided from that of V&V. Thesafety documents developed by company are transferred to theacquisition organization or the third independent safetyassessment organization to review the adoption with therequired safety criteria.

N . CONCLUSIONS

This paper suggests the software safety criteria to improve thesoftware quality and also suggests the developmentmethodology for the safety critical railway software. Themethodology is composed of procedure document, templatedocument, and technique document to help the criteria easilyapply to the safety critical railway software.To apply uncertain software to the safety critical system suchas railway, nuclear, aerospace, defense, etc, safety has to bedrastically inspected. Each safety critical systems prepare theirquality assurance system according to the each systemcharacteristic. In case of the railway software it needs theaccess of the process view point and product view point todevelop the good qualified software and secure safety. In theview of improvement of process maturity, it is to be followedthe various procedures and process suggested in the CMMIand ISO/IEC 15504 (SPICE) to secure the software quality. Itimproves the maturity of software development organization.

And in the product view, it is considered the process whichimproves the software quality as development and verificationby the formal method or conducting the test according to thetest case derived in the early stage of development. Thisproject suggests the software safety criteria considering theprocess to improve the software quality in the view point ofprocess and product.

REFERENCES

[II http://en.wikipedia .orglwiki/Ariane_5]light_501[2] IEC 62278, "Railway application - The specification and demonstration

ofdependability, reliability, availability, maintainability and safety(RAMS)", March, 2002

[3] IEC 62279, "Railway application - Software for railway control andprotection system", June, 2002

[4] CENELEC EN50129, "Railway application -Safety related electronicsystems for signaling", April, 2000

[51 ISOIIEC 15504 "Information Technology-Process Assessment-Part 1-5"[61 ISOIIEC 12207 "Information Technology- Software lifecycle processes"[7] ISOIIEC 9126 "Information Technology-Software Quality

Characteristics and Metrics-Part 1,2,3"[8] ISOIIEC 14598 "Information Technology-Software Product Evaluation­

Part 1-6"[91 EJ Joung, "Development of Safety Criteria and Frameworks for

Railway Software" 4th year report, KRRI, 2008.

V. BIOGRAPHIES

Eui-jin Joung is currently with the Advanced ElectricMultiple Units Research Team of Korea RailroadResearch Institute, Gyeonggi-do, Korea. He receivedthe M.S., and Ph.D. degree in electrical engineeringfrom Chungnam National University, Korea. Hisresearch interests include safety critical railwaysoftware, software test, software process, safetyanalysis, and train control system.

Se-chan Oh received the M.S. degree in department of Information andCommunication Engineering from Gwangju Institute of Science andTechnology (GIST), Korea. Currently, he is with the Advanced ElectricMultiple Units Research Team of Korea Railroad Research Institute,Gyeonggi-do, Korea.

Sung-hyuk Park received the M.S. degree in department of MechanicalEngineering from Sungkyunkwan University, Seoul, Korea, in 2008. He iscurrently with the Advanced Electric Multiple Units Research Team of KoreaRailroad Research Institute, Gyeonggi-do, Korea.

Gil-dong Kim received the M.S. and Ph.D. degree from Myongji University,Seoul, Korea, in 2003. He was a researcher of Shinkansen Inverter lab. inToshiba, Japan. Currently, he is a head of team and with the AdvancedElectric Multiple Units Research Team of Korea Railroad Research Institute,Gyeonggi-do, Korea. His research interests include VVVF propulsion system,advanced electric train design and energy storage system.