Uncertainty, elicitation of experts opinion, and human failures: Challenges for RAM analysis of ERTMS

Transcription

1 Uncertainty, elicitation of experts opinion, and human failures: Challenges for RAM analysis of ERTMS M. Sallak 1, W. Schön 1, S. Destercke 1, D. Berdjag 2, F. Vanderhaegen 2, and C. Simon 3 Abstract This paper has two main objectives. The first objective is to summarize the requirements for RAM (Reliability, Availability, and Maintainability) parameters of European Rail Traffic Management System (ERTMS) defined in the railway standards. The second objective is to highlight major issues, when dealing with ERTMS, which are not treated or clearly defined in the railway standards. Indeed, the RAM parameters definitions do not take into account all types of uncertainty in failure data and human failures, and do not propose specific methods to obtain failure data from experts opinion. In this work, a number of methods have been proposed to deal with these issues. I. INTRODUCTION This paper collects and summarizes a number of considerations on problems and challenges of current RAM (Reliability, Availability, and Maintainability) evaluation of railway signaling systems when considering the European Rail Traffic Management System (ERTMS). The focus on RAM evaluation of ERTMS is with respect to the railway standards [1], [2], [3]. The main international standard for train control and command systems is the ERTMS. Originally designed for European Union countries, ERTMS has now become a global standard used by several other non-european countries, such as China, Australia, Brazil, and Mexico. ERTMS is not adopted in North America, where Canadian and US countries use the Positive Train Control (PTC). ERTMS has two components, the first component being ETCS (European Train Control System), which is a standard for train control systems, and the second component being the Global System for Mobile communications-railways (GSM-R), which is an international wireless communications standard for railway communication and applications. ERTMS/ETCS has three levels. ERTMS/ETCS Level 1 and ERTMS/ETCS Level 2 are widely applied in the world. ERTMS/ETCS Level 3 is currently under development. These different levels are distinguished by the different Trackside and On-board ETCS equipment and different technologies of information transmission. The railway standards [1], [2], [3] define the procedure for *This work was carried out and funded by the French National Research Agency, through the project ANR-13-JS RECIF. 1 M. Sallak 1, W. Schön 1, and S. Destercke 1 are with the Compiegne University of Technology (UTC), Heudiasyc CNRS UMR 7253, Compiegne, France. sallakmo@utc.fr 2 F. Vanderhaegen and D. Berdjag are with the LAMIH UMR CNRS 8201, Valenciennes, France. 3 C. Simon is with the CRAN UMR 7039 CNRS, Nancy university, Vandoeuvre, France. verification and validation of railway systems. The System Requirements Specification (SRS) [3] developed by the European Railway Agency (ERA) defines the system requirements for the ERTMS/ETCS. This specification often offers multiple solutions on how to implement a specific function. It therefore contains both mandatory and optional requirements. The Chapter 3 of the Functional Requirements Specification (FRS) [2] specifies the system principles and specifications of ETCS/ERTMS applied to software used in On-board and Trackside subsystems. The RAM requirements specification for ERTMS are defined in the RAMS requirement specification - Chapter 2 [4] developed by the ERTMS User Group. These RAM requirements are based on the requirements defined in the CENELEC EN50126 [1] and adapted to the ERTMS/ETCS FRS defined by the UNISIG [2]. This is a major issue when dealing with such systems since, the RAM parameters definitions do not take into account uncertainty in failure data and human failures, and do not propose specific methods to obtain failure data from experts opinion and graphical models which are well adapted for the RAM evaluation of ERTMS. In this work, we focus on the problems and challenges relates to the representation and modeling of all types of uncertainty in failure data of ERTMS components, to the the construction of components failure parameters from experts opinion considering epistemic uncertainties (e.g. imprecision in opinions), to the modeling of human behaviour by considering human errors and the subsequent behavior deviation and intentional misbehaviors. This paper is organized as follows: in section 2, the historic introduction of ERTMS/ETCS in railway standards, the definition of its architecture and environment are provided, highlighting some the major achievement and transformation occurred through the last years. In section 3, the RAM requirements specification for ERTMS/ETCS, the failure conditions, and the steps for conformity of ERTMS/ETCS to the RAM requirements are recalled. This introduces the way for the presentation of current issues and challenges in RAM evaluation of ERTMS in section 4. Finally, section 5 summarizes the issues and indicates some solutions to help facing theses challenges. II. ARCHITECTURE AND ENVIRONMENT OF ERTMS/ETCS The European Railway Traffic Management System (ERTMS) is a major industrial project developed by 8 UNIFE (Association of the European Rail Industry) members: Alstom Transport, Ansaldo STS, AZD Praha, Bombardier

2 Fig. 1. ERTMS/ETCS Level 1 Transportation, Invensys Rail Group, Mermec, Siemens Mobility, and Thales. It was also supported by the European Union (EU), railway stakeholders and the GSM-R industry. By the end of 2012, more than km of railway tracks and 7500 vehicles are either already running or being equipped with ERTMS in 38 countries around the world. ERTMS has two basic components: European Train Control System (ETCS) which is an automatic train protection system (ATP) to replace the existing national ATP-systems. GSM-R which is a radio system for providing voice and data communication between the track and the train, based on standard GSM using frequencies specifically reserved for rail application with certain specific and advanced functions. The architecture and the environment of the ERTMS/ETCS are defined in the FRS [2]. A. ERTMS/ETCS Levels ERTMS/ETCS has three levels. ERTMS/ETCS Level 1 (Fig. 1) is superimposed on the existing signalling system. The transmission of information from the track to the trainborne system is totally dependent on balises which are installed in the track. The driver controls the train according to the lineside signals. In ERTMS/ETCS Level 2 (Fig. 2), the information is transmitted by radio. The authority and track description are displayed directly in the cab for the driver, so lineside signals are no longer needed. Balises are used as positioning beacons to help the train to determine its position via sensors. In ERTMS/ETCS Level 3 (Fig. 3), the train integrity checking is done by the train itself, so track circuits are no longer needed. Balises are used to update position information and transmit position and integrity data back to the interlocking via GSM-R. B. Architecture of ERTMS/ETCS Due to the nature of the required functions, the proposed architecture of ERTMS/ETCS system defined in [2] has two sub-systems: On-board sub-system. Trackside sub-system. Figure 4 represents the architecture of the ERTMS/ETCS. The interfaces in brackets are not required for interoperability. Fig. 2. ERTMS/ETCS Level 2 Fig. 3. ERTMS/ETCS Level 3 1) Trackside subsystem: Depending of the ERTMS/ETCS level, the trackside sub-system can be composed of: Balises: are electronic beacons or transponders placed between the rails in order to send messages from trackside to the on-board sub-system and are based on existing Eurobalise specifications. Each balise transmits a telegram and the combination of all telegrams defines the message sent by the balise group. Lineside electronic unit: generates telegrams to be sent by balises on basis of information received from external trackside systems. Radio Block Centre (RBC): is a computer-based system that elaborates messages to be sent to the train on basis of information received from external trackside systems and on basis of information exchanged with the onboard sub-systems. Radio communication network (GSM-R): is used for the bi-directional exchange of messages between on-board sub-systems and RBC or radio infill units. Euroloop: operates only on ERTMS/ETCS Level 1 lines. It provides signalling information in advance as regard to the next main signal in the train running direction. Radio infill unit: operates only on ERTMS/ETCS Level 1 lines. It provides signalling information in advance as regard to the next main signal in the train running direction.

3 control systems. C. ERTMS/ETCS environment The environment of ERTMS/ETCS system is composed of: the train, which will then be considered in the train interface specification; the driver, which will then be considered via the driver interface specification; other onboard interfaces. external trackside systems (interlockings, control centres, etc.), for which no interoperability requirement will be established. III. RAM REQUIREMENTS SPECIFICATION FOR ERTMS Fig. 4. UNISIG ERTMS/ETCS reference architecture The RAM requirements specification for ERTMS are defined in the RAMS requirement specification - Chapter 2 [4]. To define RAM requirements, the classification of failure condition for ERTMS/ETCS is defined as follows [4]: 2) On-board sub-system: Depending of the ERTMS/ETCS level, the on-board sub-system can be composed of: The ERTMS/ETCS on-board equipment: is a computerbased system that supervises the movement of the train to which it belongs, on basis of information exchanged with the trackside sub-system. It is composed of: Kernel which comprises the whole Eurocab, the interface equipment with the GSM-R, the data transmission equipment with Eurobalise, Euroloop and Euroradio, and the interface with the lineside signalling systems (interlocking, signals) and other on-board systems (braking systems). BTM (Balise Transmission Module) which is an interface used to receive telegrams from balises and to provide power to balises. RTM (Radio Transmission Module) which provides a bidirectional interface with the Trackside system via a mobile terminal. DMI (Driver Machine Interface) or MMI (Man Machine Interface) which provides a bidirectional interface with the train driver. It displays information and instructions to the driver, and the driver reacts to them. TIU (Train Interface Unit) which provides a bidirectional interface with the train-borne equipment. Odometer which measures train speed and distance since last balise. In order to control train movement, the kernel has to interface with odometer. The on-board part of the GSM-R system: The GSM Radio system is neither developed nor standardized within the frame of the FRS [2]. Specific transmission modules for existing national train Immobilising failure: In the ERTMS/ETCS context, Immobilising Failures are failures which cause two or more trains to be switched in on sight mode. Service failure: In the ERTMS/ETCS context, service failure cause the nominal performance of one or more trains to be reduced and/or at most one train to be switched in on sight mode. Minor Failure: A failure that results in an unscheduled maintenance. For each type of failure, RAMS requirement specification - Chapter 2 [4] defines the required dependability parameters such as reliability, availability, failure rate, Mean Time To Failure (MTTF), Mean Time Between Failures (MTBF), Mean Down Time (MDT) and Mean Time To Repair (MTTR). Table I summarizes some RAMS requirements of ERTMS. The conformity of ERTMS/ETCS to the RAM requirements is performed in 4 steps: The identification of the mission Profile. The definition of RAM Requirements. The definition of criteria of RAM V&V. The definition of requirement for the ERTMS/ETCS RAM programme. A. Mission Profile identification The mission profile of ERTMS/ETCS introduces the conditions corresponding to the accomplishment of the system mission. The mission of the ERTMS/ETCS is to supervise the movement of trains for each application level, and to ensure their safe. It should be noted that the considered system for the RAM requirement is composed of the ERTMS/ETCS which equipped the train and the ERTMS/ETCS trackside and lineside equipment encountered during 1 hour of trip in the worst case.

4 B. Definition of RAM Requirements The ERTMS/ETCS RAMS Requirements Specification [4] provides the RAM requirement for the whole ERTMS/ETCS and the 3 subsystems: Onboard, Trackside and Lineside. Because no experiences are at present recognizable in European Railways at an acceptable experience level, there is no related data on GSM-R in this specification. For instance, in Table I, we summarize the RAM requirements for the ERTMS/ETCS. C. Definition of criteria of RAM V&V (Verification and Validation The RAM V&V is based on the evaluation of the RAM Demonstration Test results or, where testing is not applicable for practical or economical reasons, of the documental proof of the fulfilment of RAM targets, in order to establish the compliance with the System RAM Requirements. Particularly, the acceptance criteria are conditioned to the adequacy of the RAM Validation Report, issued by the Validation Team, which purpose is to document the success, or the unsuccess, of the Reliability Demonstration Tests or of the documental proof, where applicable, as stated in the ERTMS/ETCS Test Specification. D. Definition of requirement for the ERTMS/ETCS RAM programme The ERTMS/ETCS RAM Programme is a set of activities to be performed along the ERTMS/ETCS Lifecycle for ensuring that the RAM Requirements stated for the system are fulfilled at each development phase. The RAM Programme aims to identify the system RAM Requirements and the activities of analysis, verification and demonstration, to be developed by the subjects responsible for performing activities related to one or more ERTMS/ETCS Lifecycle phases, for ensuring the compliance with the above requirements. IV. MANAGING UNCERTAINTY IN SOURCES OF ERTMS COMPONENTS FAILURE DATA Components failure data is indispensable in any RAM analysis of ERTMS. Indeed, all RAM assessments of ERTMS begin with the process of estimating the failure rates of components which illustrate the relative frequency of components failures. A. Sources of ERTMS components failure data When considering ERTMS, the source of failure data can be put into two categories: ERTMS components specific data: We can distinguish two basic subgroups. The first one is when component failure data are obtained directly from source available in the used railway signalling systems such as logbook, maintenance orders, work orders, etc. However, usually we don t have enough failure data of the ERTMS components used in the railway signalling system. The second one is when using components generic data and we update it with ERTMS specific information. Experts opinion: In this category, we can consider single expert opinion and aggregation of several experts opinion. B. Generic Failure data ERTMS components and software are mainly composed of electric and electronic components. Several methods were defined for the estimation of such components failure rates. The constant failure rate and exponential failure distribution was the unique method defined for describing the useful life of electronic components [5] in the 1980 s. However, this model was not adapted to the integrated circuits. The MIL- HDBK-217 [5] was updated to take into account technology advancement several times until Then, the 217-FN2 handbook [6] proposed the estimation of failure rates of microcircuits and semiconductors components. The Telcordia methodology [7] was developed in 2001 by Bell Communication Research for the components used in telecommunications industry. The software PRISM [8] was developed by Reliability Analysis Center in the 1990 s and was released in July It introduced the application of Bayesian methods with empirical data to obtain a prediction at the system level when studying components such as resistors, capacitors, diodes, etc. The total component failure rate is composed of operating conditions, non-operating conditions, temperature cycling, solder joint and electrical overstress. C. Experts opinions When not enough or no ERTMS component failures data are available to have statistical estimates of failure rates, as can happen when using new components, experts opinions are often used as estimates. The uncertainty of such opinions (which may concern an aleatory variable) is of epistemic and subjective nature, as it emanates from the expert. Such opinions are widely used in complex systems or in highly reliable systems for which failure seldom occurs, such as railway ones. According to Hokstada et al. [9], the three main steps for the use of expert opinions are Preparation: Choosing experts and defining the questions. Elicitation: Performing the interview. Calculation: Evaluation and aggregation. While in the probabilistic case there exist many tools to perform each step [10], this is not necessarily the case when considering other models. Indeed, elicitation techniques largely remain to be tested, when they exist, as well as evaluation and aggregation tools (some results exist, but they remain either preliminary or untested on practical cases). One challenge is therefore to build benchmark or to perform elicitation campaign focusing on other models, so that their interest can be properly assessed. Another interesting challenge is to see how recent advances in machine learning focusing on user elicitation can be transposed to expert elicitation problems: indeed, while expert elicitation is usually understood as a one-shot exercise aiming at eliciting uncertainty in a generic way (i.e., without a specific final goal in mind), user elicitation is usually performed in a step-wise manner, with the will to optimize the procedure with respect to specific goals.

5 Availability targets Operational availability, due to all the causes of failure, shall be not less than Operational availability, due to hardware failures and transmission errors, shall be not less than The minimum tolerable availability, related to hardware IMMOBILISING failures, shall be The minimum tolerable availability, related to hardware SERVICE failures, shall be The minimum tolerable availability, related to hardware MINOR failures, shall be Reliability targets The Mean Time To ReStore (MTTRS) of the Onboard Equipment (ONB) is 1,737 hours, the appropriate value for ensuring that the Onboard Equipment standstill time is less than 4 hours in the 90% of the unscheduled repairs, assuming exponentially distributed repair time The Mean Time To ReStore (MTTRS) of the Trackside Centralised Equipment (TRK) is 0,869 hours, the appropriate value for ensuring that the Trackside Equipment standstill time is less than 2 hours in the 90% of the unscheduled repairs, assuming exponentially distributed repair time The Mean Time To ReStore (MTTRS) of the Trackside Distributed Equipment (LNS) is 1,737 hours, the appropriate value for ensuring that the Trackside Equipment standstill time is less than 4 hours in the 90% of the unscheduled repairs, assuming exponentially distributed repair time Immobilising Failures The Mean Time Between Immobilising hardware Failures MT BF I ONB, defined for Onboard equipment, shall be not less than The Mean Time Between Immobilising hardware Failures MT BF I T RK, defined for Trackside Centralised equipment, shall be not less than The Mean Time Between Immobilising hardware Failures MT BF I LNS, defined for Lineside Distributed equipment, shall be not less than Service Failures The Mean Time Between Service hardware Failures MT BF S ONB, defined for Onboard equipment, shall be not less than The Mean Time Between Service hardware Failures MT BF S T RK, defined for Trackside Centralised equipment, shall be not less than The Mean Time Between Service hardware Failures MT BF S LNS, defined for Lineside Distributed equipment, shall be not less than Minor Failures The Mean Time Between Minor hardware Failures MT BF M ONB, defined for Onboard equipment, shall be not less than The Mean Time Between Minor hardware Failures MT BF M T RK, defined for Trackside Centralised equipment, shall be not less than The Mean Time Between Minor hardware Failures MT BF M LNS, defined for Lineside Distributed equipment, shall be not less than Maintainability targets Maximum standstill time tolerable for the 90% of the unscheduled repairs of onboard equipment: 4 hours Maximum standstill time tolerable for the 90% of the unscheduled repairs of trackside centralised equipment: 2 hours Maximum standstill time tolerable for the 90% of the unscheduled repairs of trackside distributed (lineside) equipment: 4 hours TABLE I RAM REQUIREMENTS OF ERTMS D. Representation of uncertainty in ERTMS components failure data The estimation of failure data of components used in railway signalling systems is essential for RAM evaluation. However, this implies that we have sufficient knowledge about the natural variability of the failure phenomena, which is not always the case. The fact that background knowledge is not always enough has brought the reliability community to make the distinction between two types of uncertainties: aleatory and epistemic. The former represents the uncertainty due to the natural variability of a random failure phenomena and the latter comes from the lack of knowledge [11]. However, this is not the only framework proposed in the literature. In [12], uncertainty is defined in a three dimensional orthogonal space: fuzziness, incompleteness and randomness (FIR). Based on different positions on this orthogonal space, he further defines some other natural language characterizations of uncertainty like ambiguity, confusion, conflict, dubious, etc. In [13], the term ambiguity is used to describe the uncertainty about the probability due to a lack of knowledge that could be reduced. Dubois and Prade [14] consider that all types of uncertainty are of an epistemic nature. Nonetheless, he recognizes that uncertainty can come from the natural variability of a random phenomena or from lack of knowledge. Regardless of which framework of classification you chose, it is considered that uncertainty due to a lack of knowledge (epistemic uncertainty) deserves a different treatment than uncertainty due to a natural variability (aleatory uncertainty) [15], [16]. Some authors claim that classical probability theory does not make a clear distinction between epistemic and aleatory uncertainties in the way they are represented, i.e., both of them are described with a probability distribution. Thanks to this fact, several alternatives framework have been proposed in the literature. These frameworks have the advantage of representing aleatory and epistemic uncertainty in a distinct way [17]. The most common theories that are used from these alternatives are: imprecise probabilities [18], belief functions theory [19], [20] and possibility theory [21]. E. An ERTMS component example Let us consider the RBC which is a computer-based system. Its unavailability is critical. In the case of the RBC failure this would be lead to an immobilizing failure. According to the standard [2], its unavailability should not be greater than The standards do not impose constraint on the architecture or on the maintenance policies. A reference architecture of the RBC must exhibit a high level of redundancy. For example, it can be composed of: 3 commercial CPU cards with dedicated memory.

6 RBC Components Precise Failure Interval Failure rate λ per h 1 (95% CI) rate λ per h 1 CPU Cards 10 7 [10 6, 10 7 ] FPGA 10 8 [10 7, 10 8 ] Bus 10 5 [10 4, 10 5 ] Power supply 10 5 [10 4, 10 5 ] TABLE II FAILURE RATES OF RBC COMPONENTS A redundant FPGA based on voting on CPU outputs (a TMR architecture). 3 redundant power supplies. A redundant system BUS. A GSM-R and WAN are components chosen as COST (Commercial of the shielf). In the case of the RBC failure, all the trains under its supervision are compelled to brake and proceed in a staff responsible mode. The reference values of component reliability parameters of RBC are chosen from the data-sheets of commercial devices and are listed in Table II. The datasheets are usually based on values computed from generic failure data given in [5], [6], [7], [8]. However, in some reliability database, the failure rates are given in terms of intervals according to each Confidence Intervals (CI). Thus, other uncertainty theories such as imprecise probabilities [18] could help us to face with these kind of problems. V. HUMAN MODELS IN ERTMS ERTMS defines several operational procedures performed by human. Past experiences show that train drivers, signallers and controllers have the highest impact on the RAM parameters of railway signaling systems. Unfortunately, the human errors are not considered in the railway standard. However, we are convinced that human factors and particularly the human operators errors should be taken into account in RAM assessment of ERTMS. Human behavioral models, qualitative or quantitative, are used as a support to automated study of task handling by human operators. From a performance viewpoint, considering task achievement success or failure, human behavior is classified as normal or abnormal. Two abnormal behaviors are considered: human errors and the subsequent behavior deviation and intentional misbehaviors. In the following both deviations are referred as human errors. Human reliability evaluation techniques rely on behavioral models for human error risk assessment. Human reliability may be associated to technical reliability, and as such is defined by the potential capacity of the human operators to achieve successfully allocated tasks, considering actual conditions and respecting constraints like limited task time. Different variation of this definition exist in the literature [22], [23]. For instance, the human reliability concept is sometimes confused and assimilated to technical availability, i.e. the capacity of human operators to be ready to work on achievement of allocated tasks, considering conditions and constraints. While this can be true in some situations, the global postulate is wrong, since tasks allocated to technical systems can be different from what is expected from a human operator. Moreover, related to the human reliability, the technical maintainability can be associated to the capacity of the human operator to recover their own erroneous tasks or to maintain their own knowledge. Those characteristics do not apply to technical components for which the RAMS concept does not consider the possible evolution of their knowledge and the possibility to knowingly deviate from task related directives and prescriptions. Smart technical systems are not considered here. Human operators, on the other hand, are able to decide to modify a given prescribed tasks, to create new tasks or to cancel tasks. Therefore, a generic human reliability should be the capacity of human operators: to achieve correctly allocated tasks, in given conditions, during an interval of time or at a given time. to cancel knowingly any additional tasks that may damage the human-machine system, this damage may be associated to many criteria such as safety, quality, production, workload, etc. The human error concept is the antagonist of the reliability one. Therefore, it relates to the capacity of human operators to fail to realize correctly their allocated tasks in given conditions during a period of time or at a given time, or to carry on additional tasks that may affect the humanmachine system functioning in terms of safety, quality, production, workload, etc. Factors such as preferences, motivations, trust, experience, beliefs, or confidence may weigh human error impact in terms of occurrence frequency or error consequences. Several human error analysis methods focus on occurrence probability assessment, integrating some of these Performance Shaping Factors (PSFs). However, some studies have shown that these methods cannot guarantee homogeneous results [24], [25]. Several arguments can explain such inefficiency [26], [23], [27]. Factors or behaviors dependencies must be considered for efficient success rate assessment. For instance, achievement of an action plan depends on the efficiency of decision making and perception processes. However, mathematical modeling of the dependencies is not trivial: conditional probabilities are required but are difficult to obtain. Tests that are efficient to deal with technical failures do not apply in this case and any probability distribution laws associated to human behavior are hypothetical. Expert judgement based methods can solve such a problem, given that the correct answer is provided: Are we going to rely on opinions of system designers or system users? Furthermore, the concept of violations, i.e., intentional and spontaneous human misbehavior has no equivalence in the technical case. For example, human operators can justify such violations because they want to favor safety over production (or the opposite). They also sometimes have to deal with unexpected or unknown situations. Knowledge about this kind of situations is insufficient and the associated probabil-

7 ities are difficult to verify, while the operational situations for a technical component and the associated occurrence rates are theoretically known. To sum it up, human operators are required when automated technical solutions will underperform, for problems favouring resilience and qualitative thinking. It is natural that quantitative representation of the related knowledge is troublesome. A possible solution is on-line learning approaches used to fine-tune experience and capitalize on task achievement success or failure resulting from trial-and-error based behaviors [28], [29]. Probability assessment is handled as a dynamic procedure as it should be, improving static human reliability analysis methods. Other approaches aim at supporting the on-line human decision making process in order to reduce the risk of human errors and to select better alternatives [30], [31], [25], [32], [33], [34]. In these references, uncertainty is considered from a probabilistic perspective taking into account factors such as preference, acceptability, consequence, belief or utility. Other approaches use the redundancy concept to reduce the risks of human errors by involving several decision makers with similar abilities. There are, for instance, cooperative structures of human-machine system organizations to share tasks between human and automated tools regarding contextual factors such as human workload or performance [35], [22]. In addition to occurrence-rate, an error is characterized by its consequences. Some approaches to analyze human reliability focus indeed on human error consequences by implementing positive and negative parameters of a given human error [29] and by using uncertainty on these parameters in order to infer new knowledge [36]. Also, the analysis of cognitive and organizational dissonances is another challenge for human reliability analysis to study conflict between knowledge [37]. It appears that the notions of human error, misbehavior and reliability are quite complex and ambivalent and as such, different scientific communities are involved into the development of human reliability analysis methods. Future researches have to study these contributions in order to develop an unifying efficient approach capable to deal efficiently with the core problems of automated human reliability analysis methods. VI. CONCLUSION In this paper, we summarize the requirements for RAM parameters of ERTM) defined in the railway standards. Then we present major issues such as taking into account all types of uncertainty in failure data, human failures, and methods to obtain failure data from experts opinion. In the future, we will discuss about graphical models such as Bayesian networks or Valuation based systems which could be well adapted to evaluate RAM parameters of ERTMS form RAM parameters of its components. We will also studied the components failure dependencies which are a real problem encountered when studying such systems but unfortunately not discussed in the railway standards. REFERENCES [1] EN50126, Railway Applications - The Specification and Demonstration of Reliability, Availability, maintainability and Safety (RAMS), CENELEC, Tech. Rep., [2] ERTMS/ETCS, ERA, System Requirements Specification, UNISIG SUBSET - 026, Ref: Index004-SUBSET-026, Tech. Rep., [3], ERA, Functional Requirements Specification, Ref: ERA/ERTMS/003204, Tech. Rep., [4] ERTMS/ETCS, RAMS Requirements Specification, Reference EEIG : 96S126, [5] MIL-HDBK-217, Military Handbook: Reliability prediction of Electronic equipement, [6] Handbook Of 217Plus Reliability Prediction Models, Reliability Information Analysis Center (RIAC), [7] SR-332, Reliability Prediction Procedure for Electronic Equipment. TELCORDIA, [8] C. L. Smith and J. B. J. R. Womack, Assessment of prism as a field failure prediction tool, in Proc. Ann. Reliability & Maintainability Symp, Institute of Electrical & Electronics Engineers, [9] P. Hokstada, K. Øien, and R. Reinertsen, Recommendations on the use of expert judgment in safety and reliability engineering studies. two offshore case studies, Reliability Engineering & System Safety, vol. 61, no. 1, pp , [10] T. Bedford and R. Cooke, Probabilistic risk analysis: foundations and methods. Cambridge University Press, [11] M. E. Paté-Cornell, Uncertainties in risk analysis : Six levels of treatment, Reliability Engineering & System Safety, vol. 54, no. 2-3, pp , [12] D. Blockley, Analysing uncertainties: Towards comparing Bayesian and interval probabilities, Mechanical Systems and Signal Processing, pp. 1 13, Jun [13] C. Camerer and M. Weber, Recent developments in modeling preferences: Uncertainty and ambiguity, Journal of Risk and Uncertainty, vol. 5, no. 4, pp , Oct [14] D. Dubois, Representation, propagation, and decision issues in risk analysis under incomplete probabilistic information. Risk Analysis, vol. 30, pp , [15] E. Zio, Reliability engineering: Old problems and new challenges, Reliability Engineering & System Safety, vol. 94, no. 2, pp , Feb [16] T. Aven, Some reflections on uncertainty analysis and management, Reliability Engineering & System Safety, vol. 95, no. 3, pp , Mar [17] D. Dubois and H. Prade, Formal representations of uncertainty, in Decision-making Process: Concepts and Methods. London: ISTE & Wiley, 2010, ch. 3, pp [18] L. V. Utkin and I. Kozine, On new cautious structural reliability models in the framework of imprecise probabilities, Structural Safety, vol. 32, no. 6, pp , Nov [19] A. P. Dempster, Upper and lower probabilities induced by a multivalued mapping, Annals of Mathematical Statistics, vol. 38, pp , [20] M. Sallak, W. Schön, and F. Aguirre, Reliability assessment for multi-state systems under uncertainties based on the Dempster-Shafer theory, IIE Transactions, vol. 45, pp , [21] D. Dubois and H. Prade, Representation and combination of uncertainty with belief functions and possibility measures, Computational Intelligence, vol. 4, no. 3, pp , [22] F. Vanderhaegen, D. Jouglet, and S. Piechowiak, Human-reliability analysis of cooperative redundancy to support diagnosis, Reliability, IEEE Transactions on, vol. 53, pp , [23] F. Vanderhaegen, Human-error-based design of barriers and analysis of their uses, Cognition, Technology & Work, vol. 12, no. 2, pp , [24] B. Reer, Review of advances in human reliability analysis of errors of commission part 2: {EOC} quantification, Reliability Engineering & System Safety, vol. 93, no. 8, pp , [25] J. Hey, A. Morone, and U. Schmidt, Noise and bias in eliciting preferences, Journal of Risk and Uncertainty, vol. 39, no. 3, pp , [26] F. Vanderhaegen, A non-probabilistic prospective and retrospective human reliability analysis method application to railway system, Reliability Engineering & System Safety, vol. 71, no. 1, pp. 1 13, 2001.

8 [27], Cooperation and learning to increase the autonomy of adas, Cognition, Technology & Work, vol. 14, no. 1, pp , [28] K.-A. Ouedraogo, S. Enjalbert, and F. Vanderhaegen, How to learn from the resilience of human - machine systems? Engineering Applications of Artificial Intelligence, vol. 26, pp , [29] F. Vanderhaegen and C. P., A multi-viewpoint system to support abductive reasoning, Information Sciences, vol. 24, pp , [30] R. A. Ribeiro, Fuzzy multiple attribute decision making: a review and new preference elicitation techniques, Fuzzy sets and systems, vol. 72, pp , [31] P. R. Blavatsky, Preference reversals and probabilistic decisions, Journal of risk and uncertainy, vol. 39, pp , [32] K. Sedki, P. Polet, and F. Vanderhaegen, Using the bcd model for risk analysis: An influence diagram based approach, Engineering Applications of Artificial Intelligence, vol. 26, pp , [33] F. Aguirre, M. Sallak, F. Vanderhaegen, and D. Berdjag, An evidential network approach to support uncertain multiviewpoint abductive reasoning, Information Sciences, vol. 253, pp , [34] P. Polet, F. Vanderhaegen, and S. Zieba, Iterative learning control based tools to learn from human error, Eng. Appl. Artif. Intel., vol. 25, pp , [35] F. Vanderhegen, Cooperative system organisation and task allocation : illustration of task allocation in air traffic control, Le Travail Humain, vol. 62, pp , [36] F. Vanderhaegen, P. Polet, and S. Zieba, A reinforced iterative formalism to learn from human errors and uncertainty, Engineering Applications of Artificial Intelligence, vol. 22, pp , [37] F. Vanderhaegen, Dissonance engineering: a new challenge to analyse risky knowledge when using a system, International Journal on Computers, Communications and Control, vol. 9, pp , 2014.