\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={FMEA and Fault Tree based Software Safety Analysis of a Railroad Crossing Critical System},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2011-05-06 (revised: 06 May 2011)}
\def\TheID{\makeatother }
\def\TheDate{2011-05-06}
\title{FMEA and Fault Tree based Software Safety Analysis of a Railroad Crossing Critical System}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{Ben Swarup  Medikonda}

             \author[2]{P. Seetha  Ramaiah}

             \author[3]{Anu A.  Gokhale}

             \affil[1]{  Department of Computer Science and Systems Engineering Department of Technology Andhra University}

\renewcommand\Authands{ and }

\date{\small \em Received: 29 March 2011 Accepted: 24 April 2011 Published: 6 May 2011}

\maketitle


\begin{abstract}
        


Software for safety-critical systems must deal with the hazards identified by safety analysis in order to make the system safe, risk-free and fail-safe. Certain faults in critical systems can result in catastrophic consequences such as death, injury or environmental harm. The focus of this paper is an approach to software safety analysis based on a combination of two existing fault removal techniques. A comprehensive software safety analysis involving a combination of Failure Modes and Effects Analysis (FMEA) and Fault Tree Analysis (FTA) is conducted on the software functions of the critical system to identify potentially hazardous software faults. A prototype safety-critical system - Railroad Crossing Control System (RCCS), incorporating a microcontroller and software to operate the train on a track circuit is described.

\end{abstract}


\keywords{Software safety, safety-critical systems, software faults, software safety analysis.}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 \par
Introduction safety-critical system is one that has the potential to cause accidents. Software is hazardous if it can cause a hazard i.e. cause other components to become hazardous or if it is used to control a hazard. Software is deemed safe if it is impossible or at least highly unlikely that the software could ever produce an output that would cause a catastrophic event for the system that the software controls. Examples of catastrophic events include loss of physical property, physical harm, and loss-of-life. Software engineering of a safety-critical system requires a clear understanding of the software's role in, and interactions with, the system \hyperref[b0]{[1,}\hyperref[b1]{2]}. a) Software-induced failures in real-life Computers are increasingly being introduced into safety-critical systems and, as a consequence, have been involved in accidents. Some well known incidents are the massive overdoses given by the computer-controlled radiation therapy machine Therac-25 \hyperref[b2]{[3]} with resultant death and serious injuries, during the mid-eighties; European Space Agency's Ariane 5 rocket explosion \hyperref[b3]{[4]} during lift-off in June 1996, and SeaLaunch rocket failure \hyperref[b4]{[5]} during lift off in March 2000. Recent examples include the following: on 7 October 2008, Qantas Flight 72 from Singapore to Perth made an emergency landing following an inflight accident featuring a pair of sudden uncommanded pitch-down manoeuvres that resulted in serious injuries to many of the occupants. The Australian Transport Safety Bureau (ATSB) said that incorrect information from the faulty computer triggered a series of alarms and then prompted the Airbus A330's flight control computers to put the jet into a 197-metre nosedive  {\ref [6]}.\par
All these examples indicate that accidents still take place despite all the measures taken to prevent them. Since complete elimination of unforeseen hazards is not always possible, what we need is a fail-safe design which, in the event of a failure, allows the system to fail in a safe way, causing no harm or at least the minimum level of danger. To meet the fail-safe requirements, rigorous safety analysis is required to identify potential hazards and take corrective measures during the entire system development life cycle.\par
There are many software fault removal techniques in literature. The most frequent classification is by differentiating between static and dynamic techniques \hyperref[b5]{[8]}. Different authors focus on probabilistic based approaches (like the Markov modeling method), or statistical, approaches like statistical testing, software reliability models \hyperref[b6]{[9]}. However most of the fault removal techniques are non-probabilistic. In some standards, static techniques require formal methods and proofs based on mathematical demonstrations. Other standards and literature classify these techniques in functional and logical terms \hyperref[b7]{[10]} or by just mentioning functional testing like in \hyperref[b8]{[11]} or structural testing, like in \hyperref[b9]{[12]}.\par
None of the fault removal techniques like algorithm analysis, control flow analysis, Petri-Net analysis, reliability block diagrams, sneak circuit analysis, event tree analysis, FMEA and FTA can be considered apt and complete in all respects, when used in isolation. A way out of this is to analyse how to combine individual techniques so that the fault removal process is significantly improved. One of the most effective combinations is FMEA+FTA. The literature \hyperref[b6]{[9,}\hyperref[b7]{10]} already mentions that FTA technique can be associated effectively with other practices like FMEA. Their greatest advantage is in combination with each other. FMEA concentrates in identifying the severity and criticality of failures and FTA in identifying the causes of faults. FMEA technique is a fully bottom-up approach A and FTA has a fully complementary top-down approach. Moreover, these two techniques are directly compatible with system level techniques.\par
In this paper, we propose a system-level approach to software safety analysis for critical systems that combines two existing fault removal techniques -FMEA and FTA to identify and eventually remove software faults at successive software development phases. We have applied our safety approach to a model railroad crossing control system to validate its effectiveness.\par
We also compare how the safetyspecific software development of a critical system is distinct from the traditional non-safety-specific software development.\par
The rest of this paper is organized as follows: section 2 describes the Railroad Crossing Control System (RCCS). Section 3 applies the safety analysis using SFMEA and SFTA techniques to RCCS. Section 4 addresses the hardware and software development issues of RCCS. Section 5 presents an analysis of the experimental results and section 6 concludes the discussion. 
\section[{II.}]{II.} 
\section[{Railroad Crossing Control System (RCCS)}]{Railroad Crossing Control System (RCCS)}\par
Crossing gates on a full-size railroad are controlled by a complex control system that causes the gates to be lowered to prevent access to the crossing shortly before a train arrives and to be raised to allow access to resume after the train has departed. RCCS is a prototype, real-time, safety-critical railroad crossing control system composed of several software-controlled hardware components. 
\section[{a) RCCS Interfaces}]{a) RCCS Interfaces}\par
The main interfaces of the microcontroller, which hosts and runs the embedded software, are shown below in Figure  {\ref 1}. The main inputs to the microcontroller are signals from the 7 sensors on the track, the 2 gates at the railroad intersection, the trackchange lever, and the 3 signal lights. The main outputs of the micro-controller are control signals for the train, Gate1 Gate 2, track change lever, signal lights, LCD display. The values of these output signals are determined using different algorithms combining the input signals that are constantly updated and read by the software. 
\section[{Figure 1. External interfaces of RCCS microcontroller}]{Figure 1. External interfaces of RCCS microcontroller}\par
The main functionality of RCCS is listed in Table  {\ref 1}.  
\section[{Table 1. RCCS System Functions -Key Areas}]{Table 1. RCCS System Functions -Key Areas} 
\section[{Safety Analysis of RCCS}]{Safety Analysis of RCCS}\par
The safety analysis of RCCS software functions takes place in three sequential steps.\par
? Software Failure Mode and Effects Analysis (SFMEA) This analysis is performed in order to determine the top events for lower level analysis. SFMEA analysis will be performed following the list of failure types. SFMEA will be used to identify critical functions based on the applicable software specification. The severity consequences of a failure , as well as the observability requirements and the effects of the failure will be used to define the criticality level of the function and thus whether this function will be considered in further deeper criticality analysis. The formulation of recommendations of fault related techniques that may help reduce failure criticality is included as part of this analysis step. ? Software Fault Tree Analysis (SFTA) After determining the top-level failure events, a complete Software Fault Tree Analysis shall be performed to analyse the faults that can cause those failures. This is a top down technique that determines the origin of the critical failure. The top-down technique is applied following the information provided at the design level, descending to the code modules . SFTA will be used to confirm the criticality of the functions (as output from SFMEA) when analyzing the design and code (from the software requirements phase, through the design and implementation phases ) and to help:\par
-Reduce the criticality level of the functions due to software design and / or coding fault-related techniques used ( or recommended to be used) -Detail the test-case definition for the set of validation test cases to be executed. 
\section[{? Evaluation of Results}]{? Evaluation of Results}\par
The evaluation of the results will be performed after the above two steps in order to highlight the potential discrepancies and prepare the recommended corrective measures. 
\section[{a) SFMEA Analysis of RCCS}]{a) SFMEA Analysis of RCCS}\par
The SFMEA, a sample of which is shown in the Table \hyperref[tab_0]{2} below presents some software failure modes defined for RCCS. The origin and effects of each failure mode are analyzed identifying the top level events for further refinement, when the consequence of this failure could be catastrophic for this system. Three top events were singled out for further analysis of failure mode Gate not closed as train is passing through railroad intersection. 
\section[{b) SFTA Analysis of RCCS}]{b) SFTA Analysis of RCCS}\par
The fault tree is a graphical representation of the conditions or other factors causing or contributing to the occurrence of the so-called top event, which normally is identified as an undesirable event. A systematic construction of the fault tree consists in defining the immediate cause of the top event. These immediate cause events are the immediate cause or immediate mechanism for the top event to occur. From here, the immediate events should be considered as sub-top events and the same process should be applied to them. All applicable fault types should be considered for applicability as the cause of a higher level fault. This process proceeds down the tree until the limit of resolution of tree is reached, thereby reaching the basic events, which are the terminal nodes of the tree. Figure  {\ref 2} shows the sample fault tree for the top event Gate Not Closed at the railroad intersection. 
\section[{c) Recommendations to Design and Coding}]{c) Recommendations to Design and Coding}\par
From the safety analysis we have conducted, the major critical events that might occur and the corresponding safety properties the RCCS software has to implement, and which are controlled by the embedded software in the microcontroller are listed below. 
\section[{Figure 2. Software Fault Tree sample for top event}]{Figure 2. Software Fault Tree sample for top event}\par
Gate Not Closed at the railroad intersection\par
? The software shall make sure that the 2 gates on either side of the railroad intersection operate correctly -ie. opening and closing the gates, at the proper time. The consequences of failure to do so are very severe, since it can result in the train and road traffic collision, leading to death. ? The software shall make sure that the train changes its path from the outer track circuit to the inner track circuit by correctly operating the track change lever at the right time. Failure to do so can have severe consequences leading to collision with another train that may be stationary on the outer track. ? The software shall prevent the running operation of the train if it detects that the gates at the intersection have not been fully closed. ? The software shall prevent the running operation of the train, if the train engine detects any physical obstacle just ahead of it, either at the mid-section of the railroad intersection or at any point on the track path, just ahead of the engine. Failure to do so can lead to collisions.\par
? The software shall the running operation of the train if a Red signal is displayed in the Signal Light alongside the track. Failure to do so can lead to accidents. ? The software shall prevent the running operation of the train if the train engine is not able to confirm that a green signal has been given to it, to resume running after a previous red signal to stop running. ? The software shall bring the running train to a halt at the location designated as railway station platform, on the track, after every cycle of operation around the track. Failure to do so can cause collision with another train that is passing just ahead on the same track. IV. 
\section[{RCCS Development}]{RCCS Development}\par
RCCS hardware and software development is described in this section. Train: The train is powered by a power supply relay.\par
When the power is initially switched on, the train begins movement along the track when the metallic wheels of the train receive power. The train comes to a halt at the position where the power to the tracks is switched off.\par
Sensors: These are used to detect the location of the train on the tracks. Altogether RCCS employs seven sensors. Two pairs of sensors detect the train position before and after the gates. A set of two sensors relate to track change where the track splits into two directions. One sensor gives the train position with reference to the platform, which is the starting point of the train movement. Information from each of the sensors is passed to controller. The safety-specific version of RCCS controller program used the same techniques as the non-safety version with the addition of the following safety-specific analysis: preliminary hazard analysis, and design-level hazard analysis, FMEA and FTA analyses. These techniques target the specification and designs. The goal here is to determine if the inclusion of these methods reduces the number of latent safety-critical faults relative to non-safety specific methods.\par
The software safety-based development involves preliminary software hazard analysis, which among other things identifies software hazards, ie. the states in the software that can lead to an accident. Without identifying the hazards, we have little assurance that the hazards will not occur. Therefore, preliminary software hazard analysis is an important first step in verifying safety-critical software systems. Once the hazard list exists, the verification process can continue by applying several static and dynamic verification techniques. Static techniques include failure modes and effects analysis (FMEA), and fault-tree analysis (FTA).\par
After static verification, software engineers must dynamically verify the software's safety (ie. safety testing). Safety-critical testing of RCCS can be done by separating the code into two risk groups. Group one includes hazards that are catastrophic or critical. Group two includes hazards that are marginal or negligible. More testing effort should be spent on those code sections dealing with hazards related to group one.\par
V. 
\section[{Experimental Results \& Analysis}]{Experimental Results \& Analysis}\par
In view of the comprehensive safety analysis, and specification and implementation the safety properties during RCCS design and development, the expected result was that safety-specific RCCS development would produce a software system with fewer latent safety-critical faults than traditional nonsafety specific techniques alone. This is due to the belief that the safety-specific techniques will prevent safetycritical faults in the specifications and designs that the traditional techniques have a tendency to miss. Figure \hyperref[fig_4]{4} shows the RCCS laboratory prototype developed in the lab.\par
During the operation of RCCS, the safetyspecific development version of RCCS clearly demonstrated the fulfillment of the safety properties. For example, if the gate at the railroad intersection is not closed at all, or partially closed, as the train is about to pass through the intersection, the controller software makes the train come to a halt. Only after confirming that the gate is fully closed does the software allow the train to pass through the railroad intersection. On the other hand, in the non-safety version of RCCS, the controller software allows the train to pass through the intersection without confirming whether the gate is actually closed or not, assuming that the gate function will operate without failure, leading to a major accident.\par
Likewise, in the safety-version of RCCS, when the train is changing its track route from the outer loop to the inner loop, the software first confirms whether the track change lever is fully activated and operational. If the track lever is stuck halfway through and the rails connection to the inner loop is incomplete, the software makes the train come to a halt. In the case of the nonsafety version, the software allows the train to change route without confirming the health status of the track lever, leading to an accident. The safety version also demonstrated a preliminary check of the internal health of all the RCCS subsystems -the gates mechanism, track lever operation, sensors, signal light LEDs, displaying the health status on the LCD display panel.  
\section[{Conclusion}]{Conclusion}\par
This paper discussed a FMEA and Fault Tree based approach to software safety analysis for critical systems. A comprehensive software safety analysis involving a combination of FMEA and FTA techniques was conducted on the software functions of the critical system to identify potentially hazardous software faults. The safety properties of the prototype railroad crossing control system were identified as part of the safetycritical requirements. These safety requirements were incorporated in the design and development of a railroad crossing control system (RCCS). We also briefly compared safety-specific and non-safety specific techniques at developing RCCS. The non-safety version of RCCS broadly focused on achieving the functional behavior of the system. The safety-specific version clearly demonstrated that the software safety properties identified in RCCS specification were fully met in the working system.\begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_0}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-3.png}
\caption{\label{fig_1}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-4.png}
\caption{\label{fig_2}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3}\includegraphics[]{image-5.png}
\caption{\label{fig_3}Figure 3 .}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{4}\includegraphics[]{image-6.png}
\caption{\label{fig_4}Figure 4 .}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2} \par 
\begin{longtable}{P{0.10790155440414508\textwidth}P{0.3038860103626943\textwidth}P{0.1343264248704663\textwidth}P{0.05284974093264248\textwidth}P{0.2510362694300518\textwidth}}
\tabcellsep \tabcellsep \tabcellsep Sever-\tabcellsep Prevention\\
Failure\tabcellsep Possible\tabcellsep Effect\tabcellsep ity of\tabcellsep And\\
Mode\tabcellsep Causes\tabcellsep \tabcellsep risk\tabcellsep Compensati\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep on\\
\tabcellsep a) sensor not\tabcellsep Train\tabcellsep \tabcellsep \\
Gate not\tabcellsep detected by s/w\tabcellsep collision\tabcellsep \tabcellsep Software first\\
closed\tabcellsep b) gate motor\tabcellsep with\tabcellsep \tabcellsep checks the\\
as train\tabcellsep mechanism is\tabcellsep passing\tabcellsep \tabcellsep working\\
is\tabcellsep defective\tabcellsep road\tabcellsep Critical\tabcellsep status of\\
passing\tabcellsep c) s/w gives\tabcellsep traffic\tabcellsep \tabcellsep gates each\\
through\tabcellsep wrong\tabcellsep leading to\tabcellsep \tabcellsep time the train\\
\tabcellsep command\tabcellsep accidents\tabcellsep \tabcellsep is about to\\
\tabcellsep d) s/w gives\tabcellsep \tabcellsep \tabcellsep cross the\\
\tabcellsep right command\tabcellsep \tabcellsep \tabcellsep gates\\
\tabcellsep at wrong time\tabcellsep \tabcellsep \tabcellsep \end{longtable} \par
 
\caption{\label{tab_0}Table 2 .}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{}
\end{longtable} \par
 
\caption{\label{tab_1}?}\end{figure}
 			\footnote{May©2011 Global Journals Inc. (US)} 			\footnote{May©2011 Global Journals Inc. (US)} 			\footnote{May©2011 Global Journals Inc. (US)} 			\footnote{May©2011 Global Journals Inc. (US)} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Leveson and Turner (1987)]{b2}\label{b2} 	 		‘An investigation of the Therac-25 accidents’.  		 			N G Leveson 		,  		 			C S Turner 		.  	 	 		\textit{IEEE Computer}  		March 1987. 26  (7)  p. .  	 
\bibitem[DO-178B/ED-12B Software Considerations in Airborne Systems and Equipment Certification (1992)]{b9}\label{b9} 	 		\textit{DO-178B/ED-12B Software Considerations in Airborne Systems and Equipment Certification},  				 (RTCA, EUROCAE)  		December 1992.  	 
\bibitem[EN50128 Railway Applications: Software for Railway Protection and Control Systems. CENELEC]{b8}\label{b8} 	 		\textit{EN50128 Railway Applications: Software for Railway Protection and Control Systems. CENELEC},  				 	 
\bibitem[Gray (2000)]{b4}\label{b4} 	 		 			Dale M Gray 		.  		 \url{www.asi.org}  		\textit{Frontier Status Report \#203},  				19 May 2000.  	 
\bibitem[Herman ()]{b7}\label{b7} 	 		 			Debra S Herman 		.  		\textit{Software Safety and Reliability Basics:", (ch.2), Software Safety and Reliability: Techniques, Approaches, and Standards of},  				2000. Key Industrial Sectors Wiley-IEEE Computer Society Press.  	 
\bibitem[Ieee Std]{b10}\label{b10} 	 		 			Ieee Std 		.  		\textit{Standard Glossary of Software Engineering Terminology},  				610 p. .  	 
\bibitem[Ieee Std 1012 ()]{b5}\label{b5} 	 		 			Ieee Std 1012 		.  		\textit{IEEE Standard for Software Verification and Validation Plans},  				1986.  		 			The Institute of Electrical and Electronics Engineering, Inc. USA 		 	 
\bibitem[
			N
		 ()]{b6}\label{b6} 	 		\textit{Leveson Safeware: System Safety and Computers},  		 			N 		.  		1995. Addison-Wesley.  	 
\bibitem[Knight ()]{b1}\label{b1} 	 		‘Safety Critical Systems: Challenges and Directions’.  		 			John C Knight 		.  	 	 		\textit{Proceedings of the 24 th International Conference on Software Engineering (ICSE)},  				 (the 24 th International Conference on Software Engineering (ICSE)Orlando, Florida)  		2002.  	 
\bibitem[Lutz ()]{b0}\label{b0} 	 		‘Software Engineering for Safety: a Roadmap’.  		 			Robyn R Lutz 		.  	 	 		\textit{Proceedings of the Conference on The Future of Software Engineering},  				 (the Conference on The Future of Software EngineeringLimerick, Ireland)  		June 04-11, 2000. p. .  	 
\bibitem[Tribble ()]{b11}\label{b11} 	 		‘Software Safety Analysis of a Flight Guidance System’.  		 			Alan C Tribble 		.  	 	 		\textit{Proceedings of the 21st Digital Avionics Systems Conference (DASC'02)},  				 (the 21st Digital Avionics Systems Conference (DASC'02)Irvine, California)  		Oct. 27-31, 2002.  	 
\bibitem[Gleick (1996)]{b3}\label{b3} 	 		\textit{The New York Times Magazine},  		 			James Gleick 		.  		1st December 1996.  	 
\end{bibitemlist}
 			 		 	 
\end{document}
