CityMobile PRT Info

EUROPEAN COMMISSION

DG RESEARCH

SIXTH FRAMEWORK PROGRAMME

THEMATIC PRIORITY 1.6

SUSTAINABLE DEVELOPMENT, GLOBAL CHANGE & ECOSYSTEMS

INTEGRATED PROJECT – CONTRACT N. 031315

Towards advanced transport for the urban environment

Deliverable no. D. 2.5.1

Dissemination level Public

Work Package 2.5 Legal and administrative issues

Author(s) WP 2.5 partners: IKA, SINTEF, TNO

Co-author(s)

Status (F: final, D: draft) F

File Name D2.5.1-Public-Certification procedures ATS-CITYMOBIL-FINAL Draft v2.1-vDijke-23-1-2008

Project Start Date and Duration

01 May 2006 - 30 April 2011

D.2.5.1 Certification procedures for automated transport systems 2

TABLE OF CONTENTS 1 INTRODUCTION ................................................................................................................................................................ 7 2 SAFETY ............................................................................................................................................................................12

2.1 WORK DONE IN THE PAST............................................................................................................................................12 2.1.1 General ...............................................................................................................................................................12 2.1.2 Requirements .....................................................................................................................................................12 2.1.3 Considerations and choices ...............................................................................................................................13

2.1.3.1 Standards ............................................................................................................................................................13 2.1.3.2 References: "how safe is safe enough" ...................................................................................................................14

2.1.4 Limitations ..........................................................................................................................................................15 2.1.4.1 Human Factors .....................................................................................................................................................15 2.1.4.2 Software ..............................................................................................................................................................15 2.1.4.3 Present laws.........................................................................................................................................................16

2.1.5 The certification method .....................................................................................................................................16 2.1.5.1 General ................................................................................................................................................................16 2.1.5.2 Overview..............................................................................................................................................................16 2.1.5.3 Preparation ..........................................................................................................................................................17 2.1.5.4 System definition and function analysis...................................................................................................................20 2.1.5.5 Failure Modes, Effects and Criticality Analysis (FMECA) .........................................................................................22 2.1.5.6 Conclusions .........................................................................................................................................................27

2.2 RECENT DEVELOPMENTS IN EUROPE...........................................................................................................................28 2.3 THE NEW CERTIFICATION PROCEDURES.......................................................................................................................29

2.3.1 Goals ..................................................................................................................................................................29 2.3.2 Changes in the procedure ..................................................................................................................................35

3 SECURITY ........................................................................................................................................................................39 3.1 PERSONAL SECURITY.................................................................................................................................................39 3.2 PROTECTION AGAINST TERRORISM..............................................................................................................................41 3.3 PROTECTION AGAINST VANDALISM AND MISUSE...........................................................................................................42 3.4 FREIGHT SECURITY.....................................................................................................................................................43

4 PRIVACY ..........................................................................................................................................................................44 4.1 MONITORING..............................................................................................................................................................44 4.2 DATA HANDLING.........................................................................................................................................................45 4.3 TRACKING AND TRACING.............................................................................................................................................45 4.4 LEGISLATION..............................................................................................................................................................45

5 LEGISLATION ..................................................................................................................................................................46 5.1 VIENNA CONVENTION ON ROAD TRAFFIC.....................................................................................................................46 5.2 PRODUCT SAFETY AND LIABILITY LAW..........................................................................................................................46 5.3 CRIMINAL LAW............................................................................................................................................................47 5.4 ROAD TRAFFIC REGULATIONS......................................................................................................................................47

6 OTHER BARRIERS..........................................................................................................................................................48 6.1 POLITICAL BARRIERS..................................................................................................................................................48 6.2 ORGANISATIONAL BARRIERS.......................................................................................................................................49

6.2.1 Information and knowledge ................................................................................................................................49 6.2.2 Financial barriers................................................................................................................................................49

6.3 SOCIAL BARRIERS......................................................................................................................................................50 6.4 BARRIERS FROM ANOTHER PERSPECTIVE....................................................................................................................51

7 CONCLUSIONS ...............................................................................................................................................................53 7.1 CERTIFICATION PROCEDURES.....................................................................................................................................53 7.2 REQUIREMENTS FOR PERSONAL SAFETY, SECURITY AND PRIVACY................................................................................53 7.3 BARRIERS..................................................................................................................................................................53

REFERENCES ...........................................................................................................................................................................54


8 ANNEX................................................................................................................................................................................II Annex 1 : Flow diagram FMECA procedure..........................................................................................................................ii Annex 2: CityMobil: Informal report on task 2.5.1: Review phase...........................................................................................v

1 INTRODUCTION ...........................................................................................................................................................VIII 1.1 TASK 2.5.1 REVIEW PHASE...................................................................................................................................... VIII

2 LEGAL AND ADMINISTRATIVE BARRIERS .................................................................................................................IX 2.1 TECHNICAL BARRIERS.................................................................................................................................................XI

2.1.1 Systems safety and reliability .............................................................................................................................. xi 2.1.2 Harmonization and standardization ...................................................................................................................xii

2.2 USER RELATED BARRIERS........................................................................................................................................ XIII 2.2.1 Societal barriers ................................................................................................................................................xiii 2.2.2 Security and privacy.......................................................................................................................................... xiv

2.3 ORGANIZATIONAL BARRIERS.................................................................................................................................... XIV 2.3.1 Institutional ........................................................................................................................................................ xiv 2.3.2 Impacts on city image .........................................................................................................................................xv 2.3.3 Project organization and management ...............................................................................................................xv 2.3.4 Financial and commercial ................................................................................................................................. xvi

2.4 LEGAL REGULATIONS AND LIABILITY.......................................................................................................................... XVI 2.5 BARRIER EXAMPLES...............................................................................................................................................XVII

3 EXISTING STANDARDS, LEGISLATIONS AND GUIDELINES ............................................................................. XVIII 3.1 CURRENT PRACTISES FOR APPROVAL OF ADVANCED TRANSPORT SYSTEMS.............................................................XVIII 3.2 EXISTING SAFETY STANDARDS .................................................................................................................................. XX

3.2.1 Specific standards for automatic guided vehicles ...............................................................................................xx 3.2.2 Specific standards for surface vehicles on wheels .............................................................................................xx

Vehicles for use on public roads ........................................................................................................................................xx Vehicles for use on private grounds ..................................................................................................................................xxi Rail Vehicles for use on public roads ...............................................................................................................................xxii Rail Vehicles for use on private grounds ..........................................................................................................................xxii

3.2.3 Specific standards for electronic and computer controlled systems ...............................................................xxii 3.3 EXISTING LEGISLATION ..........................................................................................................................................XXIV

3.3.1 Vehicle and machinery......................................................................................................................................xxv 3.3.2 Road infrastructure .......................................................................................................................................... xxvi 3.3.3 Rail infrastructure ............................................................................................................................................ xxvi 3.3.4 Encompassing systems .................................................................................................................................xxvii

3.4 CERTIFICATION PROCEDURES.............................................................................................................................XXVIII 3.4.1 Certification of road vehicles .........................................................................................................................xxviii 3.4.2 Certification of vehicles not meant for public roads ........................................................................................ xxix

4 HOW TO WORK ON SAFE SITES AND SYSTEMS .................................................................................................XXIX 4.1 GENERAL............................................................................................................................................................. XXIX 4.2 RISK REDUCTION METHODOLOGY............................................................................................................................XXX 4.3 SYSTEM SAFETY ANALYSIS................................................................................................................................... XXXII

5 FURTHER WORK PLAN ....................................................................................................................................... XXXIV 5.1 TASK 2.5.2, DEFINITION PHASE...........................................................................................................................XXXIV 5.2 TASK 2.5.3, PRODUCTION PHASE ........................................................................................................................XXXIV

6 SOURCES .............................................................................................................................................................. XXXVI 6.1 REFERENCE LIST ...............................................................................................................................................XXXVI 6.2 WEB SITES.........................................................................................................................................................XXXVI

Annex 3 : CityMobil: Informal report on Task 2.5.2: Definition Phase ..............................................................................xxxvii 1 INTRODUCTION .................................................................................................................................................... XXXIX 2 CERTIFICATION PROCEDURES ......................................................................................................................... XXXIX

2.1 NON-AUTOMATED MODES...................................................................................................................................XXXIX


2.1.1 Platooning ..................................................................................................................................................... xxxix 2.2 ASSISTED MODES...............................................................................................................................................XXXIX

2.2.1 ADA systems................................................................................................................................................. xxxix 2.2.2 Advanced city cars .............................................................................................................................................. xl

2.3 AUTOMATED MODES..................................................................................................................................................XL 2.3.1 Driving versus riding ..........................................................................................................................................xlii

3 GENERAL GUIDELINES ............................................................................................................................................ XLII 3.1 SAFETY.................................................................................................................................................................. XLII 3.2 SECURITY.............................................................................................................................................................. XLII

3.2.1 Personal safety..................................................................................................................................................xlii 3.2.2 Protection against vandalism, misuse and terrorism ........................................................................................xlii

3.3 PRIVACY...............................................................................................................................................................XLIII 4 LEGAL BARRIERS ....................................................................................................................................................XLIII

4.1 EXISTING LEGISLATION ..........................................................................................................................................XLIII 5 OTHER BARRIERS....................................................................................................................................................XLIII

5.1 ORGANIZATIONAL BARRIERS..................................................................................................................................XLIII 5.2 SOCIETAL BARRIERS..............................................................................................................................................XLIV 5.3 OVERCOMING THE BARRIERS.................................................................................................................................XLIV

Annex 4: National provisions especially addressing CCTV1 ................................................................................................xlv Annex 5: Checklist for functions/requirements for automated transport systems ..................................................................xlvi

TABLES Table 1-1 : Procedures for automatic modes........................................................................................ 10

Table 1-2 : A shift from non-automated towards automated drive mode......................................................11

Table 2-1: Severity Categories.......................................................................................................... 25 Table 2-2: Likelihood categories........................................................................................................ 26

Table 2-3: Safety score table............................................................................................................ 27

Table 2-4: New severity categories.................................................................................................... 35

Table 2-5: Likelihood categories........................................................................................................ 36

Table 2-6: Safeguard categories....................................................................................................... 37

Table 2-7: Determine Lres from Likelihood and Safeguard categories....................................................... 37

Table 2-8: Determine safety score from severity and Lres ...................................................................... 38

Table 2-9: Relevant safety scores and combinations where the system is safe enough................................ 38 Table 1.1: Documents overview ..........................................................................................................ix

Table 2.1: Characteristics of different system’s use of vehicles and infrastructure...........................................x

Table 2.2: Barriers identified by Netmobil........................................................................................... xvii

Table 3.1: Existing vehicle and machinery legislation ........................................................................... xxv

Table 3.2: Existing rail infrastructure legislation .................................................................................. xxvi

Table 3.3: Existing encompassing systems legislation........................................................................ xxvii

Table 4: A shift from non automated transport towards automated drive mode ....................................... xxxix Table 5: Procedures for automatic modes.............................................................................................xl


FIGURES Figure 1-1: CityMobil mobility concepts ...............................................................................................11 Figure 2-1: Overview of the structure................................................................................................. 18

Figure 2-2: System boundaries......................................................................................................... 21

Figure 2-3: Example of a passport diagram ......................................................................................... 22

Figure 2-4: FMECA sheet................................................................................................................ 23

Figure 2-5: Adaptations to the procedure ............................................................................................ 29

Figure 2-6: Accident with high severity and high likelihood ..................................................................... 32

Figure 2-7: Necessary risk reduction.................................................................................................. 32 Figure 2-8: Necessary risk reduction expressed as ASIL level................................................................. 33

Figure 2-9: Necessary risk reduction in old TNO approach..................................................................... 33

Figure 2-10: Necessary risk reduction in new TNO approach.................................................................. 35

Figure 4-1: Project phases and focus on safety assessment.................................................................. xxx

Figure 4-2: Step by step risk reduction ............................................................................................ xxxii

Figure 4-3: Overview of the system safety analysis process ................................................................xxxiii

Figure 2-1: Procedures for automatic modes with backward loops............................................................ xli


Abstract CityMobil is an Integrated Project in the 6th Framework Programme of the European Union. The project aims at a more effective organization of urban transport, resulting in a more rational use of motorized traffic with less congestion and pollution, safer driving, a higher quality of living and an enhanced integration with spatial development. The project is divided in 6 sub-projects; Sub-project 2 deals with future scenarios. Work package 2.5 of sub-project 2 focuses on legal and administrative barriers. A considerable part of the work done in this work package is dealing with certification. The goal is to develop and evaluate a certification procedure for automated transport systems and to develop guidelines for safety, security and privacy. This deliverable is the result of work done in the first 18 months of work package 2.5. The work consisted of three phases: 1. A review phase, in which an overview was made of existing procedures and guidelines related to automated guided transport systems and barriers that are in the way of large scale implementation of these systems. 2. A definition phase in which actions were defined to develop or modify procedures and to remove or at least lower the severity of existing barriers. 3. A production phase in which these actions were carried out, resulting in certification procedures for automated systems and a first text on guidelines for safety, security and privacy. This deliverable concern the certification procedures for automated systems and specifies a number of requirements that guidelines for security and privacy should meet. The final guidelines for safety, security and privacy will be included in the final deliverable of work package 2.5. The deliverable describes the requirements of certification procedures, the past work that the procedures are based on and the relevant developments in recent years in the field of Advanced Driver Assistant Systems (ADAS). As a final result the deliverable presents the first version of the certification procedures and a flow diagram that will allow experts to carry out safety analyses in accordance with the procedures.


1 Introduction The CityMobil project “Towards advanced transport for the urban environment” aims at achieving a more effective organisation of urban transport, resulting in a more rational use of motorised traffic with less congestion and pollution, safer driving, a higher quality of living and an enhanced integration with spatial development. This will be achieved by promoting the introducing of advanced technologies into the transport environment. The concepts, methods and tools developed in CityMobil will be validated and demonstrated in a number of different European cities under different circumstances. The three main demonstrators will take place in Heathrow, Rome and Castellón. These will be real implementations of innovative new concepts, and represent the first stages of automated transport systems that are really integrated in an urban environment. A number of smaller events will take place in different locations all over Europe. CityMobil is divided in 6 sub-projects. Sub-project 2 “Future scenarios” investigates how automated road transport systems fit into the expected scenarios for advanced transport in the future. Work package 2.5 “Legal and administrative issues” within this sub-project aims at identifying legal and administrative barriers that are in the way of large scale introduction of advanced transport systems, to take them away where possible and to define strategies for the removal of the remaining barriers. WP 2.5 consists of two parts. In the first part from month 1 (the project started in May 2006) to month 18 (November 2008) certification procedures and guidelines for safety, security and privacy have been developed. For the purpose of a good understanding the following definitions are used:

• Safety: The level of protection in case of malfunctions of the system. • Security: The protection against unfriendly actions of other people • Privacy: The level of protection of personal information

In the second part of WP 2.5, running from month 19 to the end of the project the results of the first part will be evaluated in practice by carrying out safety analyses of the demonstrations and showcases from SP 1. The results of the work in the second part will be used to update the procedures and guidelines, developed in part 1. The present deliverable is the report on part 1 of the work: “Certification procedures for automated transport systems”. Three tasks have been carried out in the first part of the work package: Task 2.5.1: Review phase Task 2.5.2: Definition phase Task 2.5.3: Production phase Task 2.5.1: Review phase In the review phase a brief survey was carried out to identify the different barriers that are in the way of mass introduction of automated transport systems. Furthermore a survey was held to identify as many existing procedures, standards and guidelines on relevant issues as possible, in order to have an overview of what already exists and may be suitable for


automated transport systems. The review phase resulted in an informal report that is attached to this report as Annex 2. The review differentiated the barriers in a number of categories and sub-categories as follows: 1. Legal and administrative barriers System safety and reliability Harmonization and standardization 2. User related barriers Societal barriers Security and privacy 3. Organizational barriers Institutional barriers Impacts on city image Project organization and management Financial and commercial Although the review phase was not more than a review, a number of early conclusions could be drawn: The most concrete barrier that withholds automated transport systems from being introduced on a large scale is safety. The main issue related to safety is not that there is doubt about the safety of automated systems as such, but that there is no way of establishing whether or not a system is safe. For traditional means of transport that use rails or public roads a plethora of certification standards exists, but none of these standards is applicable to automated transport systems in a practical way. Another important barrier, also of a concrete nature is existing legislation. The present European legislation, having its basis in the treaty of Rome demands that the driver is at all times responsible for a vehicle that uses public roads. In case of automated vehicles there is no driver, which raises the question who is going to be held responsible in case of an incident. The uncertainty about this issue effectively bars automated systems from using public roads, banning them to private terrains. There are many other barriers, all more or less important, also depending on circumstances, infrastructure and land use and national laws and regulations. Annex 2 lists a number of them with references to documents, standards and guidelines where applicable. Task 2.5.2: Definition phase In task 2.5.2, the definition phase, the results of the review phase were the basis for a discussion on what can be done to remove the barriers that were identified in task 2.5.1. Where appropriate and feasible concrete steps were identified to remove barriers and in other cases strategies were developed with the aim to make the first steps towards removal of the barriers on the longer term or to define actions that can make the barriers less severe. The definition phase resulted in an informal report that is attached to this report as Annex 3. For the non-safety related barriers the discussions resulted in a list of issues that need attention when guidelines are being developed.


The main conclusions of this report, however, concentrate on the safety issue. A categorization was made of automated transport systems and which existing rules already apply to these systems. Where there are no rules as yet or where the situation is uncertain it was decided to develop a certification system based on work done in the CyberCars and CyberMove projects [1, 2, and 3]. A 4-step procedure was defined that could in future cover safety and certification of automated transport systems. 1. Preliminary risk reduction 2. Determine which safety regulations apply 3. Production and implementation of the system 4. Certification 1. Preliminary risk reduction In the first step the risk reduction method [3] is used to roughly analyse a number of issues that have influence on the safety of the transport system in its environment. The basis of the analysis is a series of checklists that take into account a number of actors present in the environment and estimate their influence on the safety of the system. The analysis has been carried out by the authorities, the operator and the evaluation organization. The result is a series of recommendations that can be applied in the first planning phase. By following the recommendations, fewer corrections will need to be made in the later stages. The Risk Reduction Method is a ‘quick and dirty’ method that is also suitable as an instrument to evaluate the safety of showcases and demonstrators, where a comprehensive safety analysis is impractical or too expensive. 2. Determine which safety regulations apply In the second step it is established which existing safety regulations the system should meet. In addition to the safety evaluation and certification procedure, most systems will have to meet particular requirements, related to the environment they are being used in. For instance, requirements concerning the applicability for disabled people or local fire regulations. The second step is carried out by the authorities and the evaluation organization. 3. Production and implementation of the system In the third step for which the manufacturer of the system in combination with the operator is responsible the system is produced and implemented on site. For the production phase it is highly advisable to follow the Code of Practice for the design and evaluation of ADA systems, as developed in the Response projects [4]. Although the recommendations in the Code of Practice are meant for standard cars with drivers, most of the recommendations are directly applicable to fully automated systems and can greatly improve the safety of a system if applied correctly. For the safety evaluations the analysis method described in step 4 should be used. 4. Certification In the final step the system is certified, using the Certification procedures described in Chapter 2 of this deliverable and Annex 1. An independent evaluator should carry out the procedure, until, after formal acceptance of the procedures by the European authorities a notified body will take over this task.


If these four steps have been followed with a positive result, the system is considered safe enough to be introduced.

Table 1-1: Procedures for automatic modes

Step Procedure Responsible

1 Risk reduction method Authorities, operator and evaluation organization

2 Safety regulations Authorities and evaluation organization

3 Code of practice Manufacturer

4 Certification methods Evaluation organization

Task 2.5.3: Production phase In the production phase, the findings of Task 2.5.1 and the results of the discussions in task 2.5.2 were the basis for developing 2 types of documents: certification procedures and guidelines for personal safety, security and privacy. Certification procedures concern mainly the system safety of automated transport systems in their environment. For many different technical systems procedures and standards exist, that deal with the analysis of the safety of such systems, but for automated transport systems such standards did not yet exist. In the CyberCars and CyberMove projects [1, 2, and 3] a set of recommendations for certification procedures were developed. In Task 2.5.3 these recommendations were transferred to real certification procedures. Chapter 2 contains a rough description of the procedures and Annex 1 contains a flow diagram that can serve as a manual for using the procedure. The second phase of the work package will be used to evaluate the procedure using the CityMobil demonstrations and showcases. For a number of issues for which it is not easy to define concrete and objective procedures a set of guidelines has been developed. Such issues are for instance security, personal safety and protection against vandalism, misuse, terrorism and privacy. Also guidelines on how to deal with a number of barriers that are in the way of the mass implementation of automated transport systems have been under consideration. The results of this work will be in the final deliverable of work package 2.5. The status of the work after the first part of the project is reported in chapters 3 and 4 of this deliverable.


Table 1.2 presents an overview of the different vehicles and transport concepts which are under consideration.

Table 1-2 : A shift from non-automated towards automated drive mode

Drive mode Non automated Assisted Automated Driving Car (individual use)

Car sharing Car pooling

Advanced city cars Cars with ADA systems Platooning (driver present)

Dual mode vehicles

Riding Taxi Collective taxi Public transport (bus, tram, metro, train)

Cybercars Personal Rapid Transit (PRT) High-tech buses Platooning

Below a different way of presenting the CityMobil mobility concepts is presented.

Figure 1-1: CityMobil mobility concepts

For some of these categories actions to meet security and safety requirements and to overcome identified barriers are presented. Equipment and systems, which have to be considered at the introduction of a new automated transport system, are presented. The authorities and the responsible operator must decide which of these objects the new system must include to ensure the safety and security of people and goods, protect their customers’ privacy and demolish barriers against use of the system. The considerations must be based on the system design (e.g. vehicle speed), the surrounding areas (e.g. mixed traffic or not) and the general threat picture (e.g. metropolis or small town). Annex 5 summarizes the different functions/requirements taken into consideration. This list will be further developed in the final deliverable of work package 2.5 after the evaluation phase. The intention in the final version is to put a remark regarding the priority of each point, if it is regarded as a high, medium or low priority action or not necessary at all.


2 Safety

2.1 Work done in the past

2.1.1 General In the CyberCars and CyberMove projects [1, 2, 3], that were carried out between 2000 and 2004 the first version of what were called "Recommendations for certification procedures" for fully automated transport systems without mechanical guidance were developed and described. Since then a lot of experience has been gained with these procedures. Certification procedures need to meet a number of requirements in order to be called certification procedures. Furthermore there are considerations, limitations and choices to be made, depending on the particular circumstances of the system that needs to be certified. The paragraphs below describe those requirements, choices and limitations.

2.1.2 Requirements Certification standards for automated guided vehicles should meet a number of requirements. • They should be based on the system safety approach and the safety life cycle. Life cycle safety is one of the major topics in system safety analysis. The concept of life cycle safety is that safety is an issue during the whole design cycle of the product and that safety not only concerns the period the product is being used, but the complete period from the first concept until the end of the life of the system. The big advantage of the life cycle approach is that safety issues are raised and solved in an early stage of system development and in this way avoid more radical and expensive changes further down the development path. Another advantage is that decisions on the necessity of redundancy of systems can be taken on the basis of a well-structured and documented approach. By using the life cycle safety approach, developers can be more confident that the system will meet the requirements when the system is up for its final certification test. • They should contain performance criteria instead of design criteria. In order to guarantee that innovations offer the maximum benefits, limitations to design choices by means of design criteria should be avoided. Performance criteria guarantee that a system meets the required performance without preventing the designer from making the most economic choices. • They should include a rating system so that a quantitative assessment is possible. Almost all present standards and regulations include quantitative requirements that components or complete systems must meet in order to be approved. When, like in the case of automated transport systems, the system to be assessed is a complicated integrated system with large software content, simple component testing of for instance a steering or braking system is not sufficient anymore. Since the braking and steering systems are part of


a much larger integrated system everything influences everything and simple input-output testing does not give the required answers. Here system safety acceptance levels must be defined and an analysis method with which it is possible to establish whether or not a system meets the defined level must be used. In order to define system safety acceptance levels the question: "how safe is safe enough" should be answered. • They should define acceptance levels for different kinds of vehicles. The present motor vehicle regulations specify several categories of vehicles for which different requirements are defined. Parameters like mass and maximum speed of motor vehicles have a strong influence on safety. The safety requirements of, for instance CyberCars should reflect the fact that they, because of their limited weight and speed are relatively safe in comparison with cars. • They should use relevant existing standards and follow developments in standards for

road vehicles carefully. Some automated transport systems will use the same road infrastructure as traditional cars and it would be preferable when all systems that are being used on public roads meet the same requirements. Therefore it is not only important to refer to existing standards, but also to carefully follow developments in relevant standards. In addition, a number of practical requirements can be defined that ensure that the analysis method is fit for use. The method has to fulfil the needs of several parties who are involved in the decisions concerning the safety of automated transport systems. • User friendliness: The method must be easy to use, so that people from different

backgrounds can use it with a minimum of training. • Uniformity: The method must be suitable for analysis of almost every vehicle system,

vehicle or vehicle component without the need for special adaptations. • Reproducibility: The results should be the same, independent of the people that carry out

the analysis. • Acceptability: In order for a method to be acceptable, it should have a firm basis in

existing standards.

2.1.3 Considerations and choices

2.1.3.1 Standards Although there are no standards immediately available for the system analysis of an automatic guided vehicle system, nevertheless starting points can be found in existing standards. The most important one is IEC 61508: Functional Safety of electrical/electronic/ programmable electronic safety-related systems [5]. IEC 61508 is a generic standard in which amongst others Safety Integrity Levels are defined. A system meets the requirements of IEC 61508 if its Safety Integrity Level is in accordance with the level prescribed for that particular system. IEC 61508 is a very comprehensive set of documents. The Safety Integrity Levels are not specifically adapted for use with automated transport systems and the standard does not specify which analysis methods should be used. Therefore IEC 61508 does not meet the above requirements of user friendliness and reproducibility. The standard does, however, provide important guidance and it was used as a reference for further work.


As the basis for the analysis method the Failure Modes, Effects and Criticality Analysis (FMECA) was chosen. Literature describes many methods for system safety analysis. For instance the System Safety Analysis Handbook [6] describes over a hundred methods. The FMECA, however, has the advantage that it is extensively used in the vehicle industry and that most developers have either heard of it or have contributed to one. The FMECA is not the only analysis method that would be suitable. It was considered to add other methods to the method, for instance a fault tree analysis. That would increase the accuracy of the result but it would have an adverse effect on the user-friendliness of the method and especially on the time consumed with an analysis. An important consideration to limit the method to the FMECA was that all traditional certification tests are in fact compromises. A product has to meet certain requirements when it is tested under well-defined standard conditions. When the conditions are slightly different, like in a real situation the product will not perform the same way and might not meet the certification requirements. Since the method is a certification instrument and since the requirement of user friendliness is considered important it was decided not to include other methods. The FMECA is per definition a subjective analysis method. In a typical FMECA a group of 4 - 5 people use their knowledge and experience to systematically list all possible failure modes of the system to be analysed. Then the causes and effects of these failure modes are established and the severity and likelihood of the effects are rated. Whether or not the result is reproducible depends on the knowledge of the participants but also strongly on the strictness with which the procedure is being followed. In order to guarantee an acceptable reproducibility, so that different groups of analysts reach the same conclusions, the analysis process is described in detail and the process manager has to monitor the process strictly in order to guarantee that the procedure is being followed. Essential in this respect is the system definition that precedes the actual FMECA. A complex system like a Cybercar is divided in a number of systems that are analysed separately. It is essential that it is clear to all participants what the boundaries of a system are. When the systems to be analysed are clearly defined a function analysis should provide all possible functions that the system performs. These functions are the basis of the FMECA, where a failure is defined as a failure to perform a certain system function.

2.1.3.2 References: "how safe is safe enough" Whether or not a transport system or any other system is safe enough depends on the risk that is accepted in a given context based on the current social criteria. For traditional road vehicles "safe enough" is made concrete by establishing limits that vehicles should meet under well-described and realistic test conditions. For intelligent transport systems like CyberCars this is not possible, since the number of variables that influences the results of a test is so high that testing would cost too much time and money. This means that "safe enough" for automated transport systems should be defined differently. The choice made here is to base "safe enough" on the safety of comparable systems. For innovative systems, like automated transport systems it is for instance possible to state that they should be safer than comparable traditional vehicles in the same class. Safety or the


lack of safety can be expressed in various units. In statistics the number of casualties per traveller-kilometre is often used. Safety is thus expressed on the basis of the seriousness of an accident and the distance travelled. In this proposal we express safety as the number of casualties per travelled hour. Safety is expressed in terms of the seriousness of an accident and the time a person spends travelling. The risks connected with one hour walking or one hour flying an airplane is perceived as a more realistic means of comparison than the risks of travelling a certain distance. When, for instance, we know that in Europe there are 6 casualties per billion travelled kilometres (Eurostat 1997) and when we assume that the average speed driven by passenger cars is 60 km/hour we can calculate that there will be 36 x 10-8 casualties per hour travelled. Or expressed differently: the chance to die each hour as a result of an accident with a passenger car is 1 on 2.8 million. Another consideration is the contrast between "as safe as possible" and "as safe as necessary" The last expression encompasses an accepted level of risks. The idea of this approach is that it is not possible to ban all the risks from the lives of people but the harm that a system can cause should be limited to a level that is generally deemed acceptable. This approach is also used in IEC 61508.

2.1.4 Limitations

2.1.4.1 Human Factors The guidelines, as presented in this report are only meant for the analysis of technical systems. This means that human factors are not part of the equation. This is not so much a problem if we consider that automated transport systems are not controlled by human drivers, but that humans nevertheless play a role in controlling central systems, maintenance, repairs etc. There is limited knowledge about the behaviour of the human system controllers, so more research and the contribution of human factors experts is needed in order to establish the limits of use of the method.

2.1.4.2 Software Software is a difficult subject in any safety analysis. How can a judgement be made as to whether or not software is safe? Certainly in complicated control software like that in automated transport systems the number of possibilities for failure is very large. It is generally acknowledged that it is risky to make firm statements based on tests about the safety of complicated software. The more extensive and complex the software is the more tests are necessary to exclude all possible failure modes. A more realistic approach therefore is to follow generally accepted design rules during the design phase. By strictly following such design rules (for instance the IEEE Software Engineering Standards [7]) the risk of failure will be minimised. These standards give recipes for developing the software and also for documentation. When the design rules are followed and the software meets its functional specifications the chance of failure can be deemed to be small.


2.1.4.3 Present laws In order to be approved for use on public roads, present laws require the presence of a driver in a motor vehicle. Since automated transport systems do not have a human driver, they cannot be approved under the present laws. This can be interpreted in two ways: 1: automated transport systems are not allowed to use public roads and 2: automated transport systems are not motor vehicles as defined by the law and as such do not have to meet this law. The 2nd interpretation would offer a window for the introduction of automated transport systems on public roads, but at present only the first interpretation is accepted.

2.1.5 The certification method

2.1.5.1 General A complete certification program for an automated transport system will consist of a combination of functional tests and evaluations and a series of FMECA analyses. The functional tests should prove that the system does what it is supposed to do according to its specifications. The FMECA analyses should prove that the risks involved in system failures are within the range of acceptance. Such a certification process can be carried out when the development phase is concluded and the system is ready for introduction or it can start when the first concept is available and end with the final functional tests and analyses. The advantage of the last option is that it is very unlikely that in the last tests and analyses serious failures will be discovered. Such serious failures would have been detected in earlier phases and the design would have been adapted accordingly. If, however, a certification process starts when the design phase has been completed and the system is ready for introduction possible faults that are discovered could lead to expensive redesign and loss of time. It is therefore highly recommended to observe the safety life cycle and start the safety analysis process in the earliest design phases. The certification process should result in a certificate that shows that the system meets the requirements. Since automated transport systems can differ from each other strongly and since a system may or may not include infrastructure and communication devices there is no standard set of requirements and thus there cannot be a standard certificate. The proposal therefore is to include a table stating what the requirements are, what the results of the tests and analyses are and a conclusion as to whether or not the system did meet the stated requirements.

2.1.5.2 Overview On the basis of the considerations, choices and limitations laid down in Paragraphs 2.2, 2.3 and 2.4, a basic structure for the certification process was designed. The structure consists of a number of process steps, each in its turn divided in sub-steps. Figure 2.1 shows a graphic overview of the structure. For reasons of reproducibility, it is essential to carry out all of the above steps in the order given. 1. Preparation of the safety evaluation • Collect information about the system


• Form a group of experts • Agree on goals, safety criteria, planning and process • Set up a program for functional tests 2. System definition and function analysis • Define system boundaries • Divide into subsystems • Make Passport diagrams • Define all functions 3. FMECA • Establish failure modes • Establish causes • Establish effects • Identify possible safeguards • Establish severity and likelihood • Add recommendations • Add comments 4. Conclusions and reporting • Draw conclusions • Lay results down in a report

2.1.5.3 Preparation The preparation phase is mainly meant to collect all information that is needed to carry out the analysis and to prepare all necessary requirements, so that the following steps in the process can be carried out without delays.

2.5.3.1.1 Collect information about the system The purpose of collecting and documenting all information about the system is twofold. Firstly, it is important to establish the status of the system at the moment of the analysis. If the system to be analysed is a system in development and the status is not clear, design changes that are implemented during the analysis can cause confusion. Secondly, the collected and documented information is a reference for later, in case questions arise about the results of the analysis. All documentation is listed and provided with a unique number. As a minimum, the following information is needed: • The information about the use of the system and the circumstances in which the systems

operate like climate, other users of the environment, etc. This information is in most cases already available in a system specification.

• Information about the system itself and the components of the system. • Functional specification • Specification of standards with which components possibly must comply. • Test results


• Certificates of manufactures of sub-components • Track record of components with information about failures • Construction plans • Process descriptions

Preparation of thesafety evaluation

Functional tests

System definition andfunction analysis

FMECA Conclusions and report

Collect info aboutthe system

Form a group ofexperts

Establish safetycriteria

Define functionaltests

Define the systemboundaries

Make PASSPORTdiagrams

Define allfunctions

Divide intosubsystems

Draw conclusions

Make a report

Define the failuremodes

Define the causes

Define the effects

Define thesafeguards

Establish severityand likelihood

Add commentsand recommend.

Figure 2-1: Overview of the structure

2.5.3.1.2 Form a group of experts The next steps in the process, the system definition, the function analysis and the FMECA are carried out by a group of experts. In an FMECA the group is typically 4 - 5 people. The


composition of this group is important and depends strongly on the system to be analysed. The composition of a group that analyses an automated transport system should be such that expertise from the design side (mechanically; electronically and software), from the operator side and, if safety-critical sub-systems supplied by external suppliers are involved, from this supplier should be represented. An open communication on the safety issues is important, so in case external parties are present it is essential to agree on confidentiality and intellectual property issues. Not all detail knowledge has to be represented in the group. The members can consult other experts if detail knowledge is needed, but the group members should have a thorough overall knowledge of the system. It is important to work with the same group of people during the whole analysis. Changes in the group can disturb the process and the quality of the results. One of the group members performs the moderator function. His or her job is mainly to control the process and see to that all the process steps are properly taken.

2.5.3.1.3 Agreements on goals, safety criteria, planning and process 2.5.3.1.3.1 Goals Before the actual analysis process starts a number of issues must be discussed, so that all parties involved agree on the basics of the analysis. Most important is the goal of the analysis. Is it a concept or design analysis, meant to identify safety issues that have to be taken into account in following development phases, or is the goal certification, to establish that a system meets the given requirements? The system boundaries should be agreed upon so that it is clear which systems are parts of the system to be analysed. In a Cybercar system not only the vehicles, but also the central control system, the road infrastructure, the stops, possible energy supplies and garages could or could not be part of the analysis. 2.5.3.1.3.2 Safety criteria In paragraph 2.4 a proposal is made for a manner in which a decision can be made as to what "safe enough" means. This proposal can give guidance and the resulting safety level can be chosen as the safety criterion for the automated transport system. However, until a generally agreed safety level for automated transport systems exists, it is important to decide on the safety criteria that are going to be used before the analysis starts. 2.5.3.1.3.3 Planning The time needed for the safety evaluation depends of a number of aspects like the complexity of the system, how familiar the experts are with the system, experience with similar safety evaluation processes and the availability of results of former safety evaluations already done on the (sub) system. It is also important in what phase of the design process an analysis is carried out. A concept analysis, done in a phase when there is little or no detail information available will take considerably less time than a full analysis on a complete design. It is therefore difficult to give reliable general estimates about the length of the analysis process and the time involved. Experience with FMECA sessions learns that individual sessions should be limited to 4 hours and that sessions should not be to close together. 2 - 3


sessions per week is a reasonable average. A really reliable estimate on the number of necessary sessions can only be given after the completion of the preparation phase. 2.5.3.1.3.4 Process It is important that the people who are going to be involved in the analysis are fully aware of the tasks that they are going to perform, of the type of questions that are going to be asked and of the process steps that are going to be taken. They also should be aware of what is going to be done with the results. This is generally guaranteed if the same people that are going to be involved in the preparation phase also will be involved in de following phases. Where this is not the case a clear explanation of goals, planning and process has to precede their involvement.

2.5.3.1.4 Functional tests Automated transport systems are not standard devices like automobiles. It is therefore not possible to make a standard list of functional tests that should be carried out in each automated transport system certification. For each system to be certified a dedicated list has to be made, based on the specifications of that particular system. To illustrate this let us compare 2 systems that have been analysed and are reported in [1] The Floriade Cybercab is a system that runs with a low speed (max. 12 km/h) on a dedicated infrastructure. The chances that a collision between a CyberCab, even if it drives at full speed, and a pedestrian would be fatal for the pedestrian, is very small. Therefore there is only a limited obstacle detection system present in the shape of a bumper with emergency switches and a short distance ultrasonic device. The Rivium People Mover, on the other hand, is a much heavier vehicle driving with a higher speed (max. 40 km/h). A collision between this Cybercar driving at full speed and a pedestrian could very well be fatal for the pedestrian. Therefore the Rivium People Mover has an extensive array of obstacle detection systems on board, for which a specific test cycle has been defined. The way in which the Floriade CyberCab is tested is completely different from the way the Rivium People Mover is tested. The functional tests that are to be carried out strongly depend on the specification of the system. The main guideline in making the list of functional test therefore depends strongly on these specifications. Nevertheless, since the heart of the system always are a series of vehicles braking tests, tests of the steering system and acceleration and speed tests will almost always be included.

2.1.5.4 System definition and function analysis

2.1.5.4.1 General The functions of the system to be analysed are the basis of the FMECA analysis. If not all functions have been identified certain failure modes can be overlooked. In order to be certain that all functions are being identified a strict procedure, as described below must be followed.


2.1.5.4.2 System definition In order to avoid confusion about what is and what is not part of the system to be analysed a clear system definition is necessary. A simple method to help with this task is to define which (sub) systems are outside the system. Only those systems are listed that have interactions with the system. In principle it is possible to perform an FMECA on the system thus defined. For analyses of very small systems this may be an option, but a complete automated transport system is much too complex for such an approach. Therefore the system is divided into subsystems that are analysed separately. The division in subsystem is done in a pragmatic way, so that systems to be analysed as much as possible coincide with actual subsystems in the vehicle. Experience with the procedure will be an advantage in choosing the optimum division. Figure 2.2 shows a sheet that can be helpful in defining the various subsystems. For each separate subsystem that must be analysed a sheet should be made. System Boundary SYSTEM: CyberCar system

: example Systems outside the boundary interacting with the system

1 Passengers 2 Operators 3 Infrastructure 4 crossings 5 Energy deliverance 6 Other traffic 7 Obstacles 8 Garage 9 Weather 10 Security camera's

CyberCars system

Communication System Operator

room

Vehicle

Platform vehicle stops Charge station

Control system

steering

Obstacle detection Propulsion

Braking Safety system

Carosserie Chassis

System boundary

Figure 2-2: System boundaries

2.1.5.4.3. Function analysis For each of the subsystems to be analysed the interactions between the subsystem and the subsystems outside the system boundary are listed. Interaction means that there is an exchange between the systems. These exchanges are always in the form of either


information or matter or electric current. Although people strictly spoken are "matter" and radiation is "electric current", for practical reasons the division below is being used. 1. information 2. matter 3. people 4. electric current 5. radiation All exchanges can be defined as either types of inputs or types of outputs of the system to be analysed and functions are defined as relationships between outputs and inputs. So if all the functions of a system have to be established it is sufficient to establish all relationships between outputs and inputs. In order to establish all functions the PASSPORT method is used. The PASSPORT method is a result of the DRIVE-II project [8]. The goal of the project was to develop a systematic methodology for a hazard analysis of an advanced road transport telematic system. A PASSPORT diagram (see figure 2.3) is a graphical representation of the system.

System

Input 1 Exchange

Input 2 Exchange

Input 3 Exchange

Input 4 Exchange

Input 5 Exchange

Output 1Exchange

Output 2Exchange

Output 3Exchange

Output 4Exchange

Output 5Exchange

Output 6Exchange

Figure 2-3: Example of a passport diagram

The functions of a system are defined by the relationships between system outputs and system inputs. Therefore, in order to find all functions of the system for every output the inputs must be identified that have an influence on that output. The functions thus identified are the input for the FMECA analysis.

2.1.5.5 Failure Modes, Effects and Criticality Analysis (FMECA)


2.1.5.5.1 The FMECA process The FMEA (Failure Modes and Effects Analysis) is an instrument that is used extensively in many industries to identify safety and reliability flaws in a design. In case it is not only important to identify flaws, but to also give them a certain value an FMEA becomes an FMECA (Failure Modes, Effects and Criticality Analysis). The basic principle is the same everywhere, but many variations in the execution of FMECA's are possible. For our purpose, where the FMECA must not only give a quantifiable result but also a reproducible one, it is important to follow a strict procedure. FMECA sessions are carried out in a number of sessions by a group of 4 - 5 experts. The sessions are therefore very labour-intensive and a careful preparation as described in the paragraphs before is important. The steps in the analysis process are depicted in figure 2.4 by the green line.

Figure 2-4: FMECA sheet

ID

FUNCTION

FAILURE MODES

CAUSES

EFFECTS

SAFEGUARDS

S L R RECOMMEN-DATIONS

COMMENTS

1

2

3

4

5

6

Function In the column "Function" all functions are listed that have been identified in the function analysis. Failure Modes The column "Failure Modes" contains all modes in which the system can fail to perform each of the functions. As an aid in identifying failure modes checklists are available, but each system has its own characteristics and checklists will never be complete. Causes The column "Causes" lists all possible reasons for each failure mode. Often there is more than one cause for a failure mode. All of these possible causes are listed, even the most improbable. Effects In the column "Effects" the effects of each failure are listed per cause. In identifying effects it is important to have a thorough knowledge of the world outside the system boundary. When the system to be analysed is a Cybercar, the effects can be totally different in a situation where the vehicles drive on a separate infrastructure where no other road users are present or when they make use of the public roads. In principle only those effects that threaten the safety of man, animals and material are listed. If the analysis not only concerns safety but for instance also reliability other effects, not directly related to safety can be considered.


SafeguardsThe column "Safeguards" contains possibly built-in measures that can soften the effect of the failure. Safeguards are often included in users’ instructions, prohibiting the use of the system under certain risky conditions. Severity In the column "Severity" the seriousness of the effect is rated on a 5-point scale. The categories used are direct results of DRIVE II [8]. See paragraph 2.1.5.5.2 Likelihood In the column "likelihood" the probability that an effect will occur is rated on a 5-point scale. See paragraph 2.1.5.5.2. Safety Score The safety score is a combination of the severity and likelihood score. It is a figure between 1 and 10 that gives an immediate rating for the risk that is related to the failure mode. Recommendations if the Safety Score is too low (below or near the safety criterion established in par. 2.5.3.1.3.2); can be included for actions that would raise the safety score to an acceptable level. Experience learns that during an FMECA the attendants often come up with ideas to improve the design. These improvements can also be included in the "Recommendations" column. Comments In the "Comments" column relevant remarks, like references to standards or reasons for a certain rating can be recorded, but also differences of opinion that emerged during the analysis or facts and events that came to light during the analysis.


2.1.5.5.2 Severity and likelihood tables The table below shows the severity categories that were developed in the DRIVE II project [8].

Table 2-1: Severity Categories

Category Description

5 Uncontrollable Failures whose effects are not controllable by the vehicle occupants, and which are most likely to lead to extremely severe outcomes. The outcome cannot be influenced by a human response.

4 Difficult to control Failures whose effects are not normally controllable by the vehicle occupants but could, under favourable circumstances be influenced by a mature human response. They are likely to lead to very severe outcomes.

3 Debilitating Failures whose effects are usually controllable by a sensible human response.

2 Distracting Failures which produce operational limitations, but a normal human response will limit the outcome to no worse than minor.

1 Nuisance only Failures where safety is not normally considered to be affected

In practice these categories appear to be easier to handle when they are interpreted in terms of harm to occupants and other road users: The severity categories are easy to work with, but the likelihood ratings appear to be the most difficult and most critical part of the analysis. In practice it is difficult, even for experienced engineers to establish whether a component will fail once in every 10 years, or once in every 100 year or even once in every 1000 years. Here more background information is needed, for instance in the form of tables with failure data for various components and other reference data-based on practical experiences. The documentation collected at the beginning of the process should include all manufacturer information about failure data of critical components. For the likelihood of software failure the principles set out in paragraph 2.5.3.1.3.2 can be used.


Table 2-2: Likelihood categories

Likelihood

5 Once in 10 years

4 Once in 100 years

3 Once in 1000 years

2 Once in 10.000 years


2.1.5.5.3 Safety score The combination of the severity and likelihood scores leads to a safety score for the failure mode and its cause. Table 2.3 shows the combinations as they were used in the analysis performed until now. In this table the highest safety score is 10 and the lowest safety score is 1. The figures in the table are not based on a formula but are arbitrary figures that only have a practical basis. More discussion and more experiences with the method are necessary to establish a final table.


Table 2-3: Safety score table

Safety score Likelihood

1 2 3 4 5

Severity 1/100.000 years

1/10.000 years

1/1000 years

1/100 years

1/10 years

1 Nuisance only 10 10 9 7 5

2 Distracting 10 9 8 6 5

3 Debilitating 7 6 5 5 4

4 Difficult to control 6 5 4 3 2

5 Uncontrollable 5 4 3 2 1

2.1.5.6 Conclusions The result of the FMECA analysis is a table with a large number of safety scores and a number of recommendations. The safety level for the system or subsystem is equal to the lowest safety score in the table. That means that if one single failure mode results in a safety score that is lower than the safety requirement, then the complete system does not meet that requirement. The complete system is considered to be as safe as its weakest link. The results are laid down in a report that contains as a minimum the following: 1. Agreements on goals, safety criteria, planning and process 2. System definition 3. Function analysis 4. FMECA sheets 5. Result of the functional tests 6. Conclusions 7. Certificate


2.2 Recent developments in Europe Over the last years the number of electronic and computer controlled systems that has been introduced in road vehicles has risen dramatically. The latest developments include Advanced Driver Assistance Systems (ADAS) like for instance Adaptive Cruise Control and Lane Departure Warning systems. This has caused concern about the safety of these systems. For almost all subsystems in vehicles standards and regulations exist, but this is not yet the case for ADA systems and other advanced computer controlled systems. Solutions were and are being sought following two routes: A. Adapting existing standards to include safety regulations for ADA systems The first steps to adapt existing regulations were taken concerning steering and braking systems. Until recently all the transfer of information from the driver to the braking or the steering system was done through firm mechanical or hydraulically systems with a proven reliability record. More and more the need arises to replace this information transfer by electronic systems. For example: A sensor assesses the force and movement of a foot on a braking pedal and the signal is transferred to the braking actuator electronically. In order to be able to approve these so called steer-by-wire or brake-by-wire systems an extra annex was added to the relevant European regulations. The annexes contain requirements to analyse the safety and reliability of such systems by means of a simple system safety analysis. The annexes require the manufacturer to provide a documentation package on how a safe system is guaranteed and an analysis of how the system will behave on the occurrence of a number of specified faults. However, no quantitative criteria were established on the basis of which a system can be approved or rejected. B. Developing new guidelines exclusively for these systems The European automobile manufacturers, led by the German automobile industry decided that it was necessary to develop a Code of Practice for the development of advanced driver assistance systems. This was done within the framework of the Response, Response II and Response III projects. The result was presented in 2006. This Code of Practice [4] is a recommendation to manufacturers on which rules and practices to apply when developing ADA systems but it is not a certification procedure. An ISO Working Group took up the task to develop such a certification procedure. At present the work is under way and a draft ISO 26262 standard is expected to be available in 2008. No formal document is available yet, although some of the characteristics of the ISO standard were already included in the Code of Practice. The ISO standard will be based on IEC 61508 [5], as are the Recommendations for certification procedures described in Chapter 2. Although there is no formal documentation on the ISO standard yet, it was decided to make a few adaptations to the certification guidelines in order to be as much as possible in accordance with this newly to be developed standard. The reason for this action is mainly that the general principle is not to develop new procedures but to adapt existing ones where necessary. The chance that a new procedure will be acceptable to all involved parties is higher when the procedure is based on standards that are widely accepted. Since the automobile industry probably will let itself be guided by ISO 26262 as soon as it is a formal document it was decided that the ISO standard also should give direction to the procedure development for fully automated systems.


2.3 The new certification procedures

2.3.1 Goals The goal is to modify the certification procedures as described in Chapter 2 to incorporate as many items of the draft ISO 26262 as is practical and feasible. An analysis of the process diagram in 2.1 and the descriptions of the ISO 26262 characteristics results in the conclusion that only a few changes need to be made. The preparation phase, the system definition and function analysis and the conclusions and reporting phases stay the same. Only the FMECA and in particular the step where likelihood and severity are rated needs adapting.

Figure 2-5: Adaptations to the procedure

In order to establish which changes need to be made a comparison between the ISO 26262 approach and the approach as described in chapter 2, (from now on called the "TNO approach") in carrying out an FMECA analysis was made. The main differences are: ISO-26262 - Aims at ADAS vehicles + driver - Focuses on accident situations - Driver responses to events are main parameters

Define systemboundaries

Divide in subsystems

Add comments

Addrecommendations


Definesafeguards

Define effects

Make report

Drawconclusions

Define causes

Define allsystem functions

Make Passportdiagrams

Define failure modes

System def &function analysis FMECA Conclusions

& reportingPreparation

Collect info

Form a group of experts

Establish safety criteria

Step to be redefined


TNO - Aims at autonomous vehicles - Also suitable for individual systems and ADAS vehicles - Focuses on failure modes - No driver, so no driver response to events The fact that ISO focuses on systems that are always controlled by a driver and that the TNO method focuses on driverless vehicles is the main difference. In the ISO method the response of the driver to an event (defined as controllability) is a major factor. For instance, if a vehicle system senses an event, the driver is informed and controllability is defined as the possibilities the driver has at that moment to prevent an unwanted event. Since there is no driver present, this factor does not exist in the TNO method, but a factor that plays a comparable role is the presence of safeguards; sub-systems with the explicit goal to avoid or mitigate the effect of an unwanted event. There is a minor difference in the way the severity of an event is rated. In both systems the rating is based on IEC 61508. TNO uses a 5 point scale, where ISO uses 4 points. Establishing the severity ISO: Uses AIS scale (Abbreviated Injury Scale): AIS 0 no injuries AIS 1 light and moderate injuries AIS 3 serious injuries / survival probable AIS 5 perilous injuries / fatalities TNO: Uses IEC 61508 definitions: 1 nuisance only 2 distracting 3 debilitating 4 difficult to control 5 uncontrollable There is a more significant difference in the way the likelihood of an event is rated. This has to do with the controllability issue as described above. ISO: Uses exposure * controllability - Exposure is fraction of traffic situations concerned - Controllability is a measure for the possibility the driver has to Influence the outcome - Mitigates risk by the possibility of drivers to influence an event TNO: - Uses the likelihood that a failure mode with the cause and effect as analyzed occurs - Mitigates risk by built-in safeguards that limit the risk in case


an event occurs The methods use different values to express the results of the analysis. ISO uses ASIL levels (Automotive Safety Integrity Levels), in conformity with the generic SIL (Safety Integrity Levels) from IEC 61508. The ASIL levels (A, B, C and D) express the necessary risk reduction to achieve a safe state TNO has defined a safety score on a 10-points scale. The lower the safety score the higher the risk. In order for a system to be safe the safety score has to be higher than a pre-established reference level. ISO: - ASIL level, representing the necessary risk reduction measures needed - ASIL levels A, B, C and D TNO: - Safety score per failure mode/cause/effect combination - Safety scores from 1 - 10; all scores above a certain value mean no further actions necessary; the system is "safe enough" The figures below show how the ASIL levels link with the TNO safety scores. Figures 2.6 – 2.8 show the ISO approach. A high likelihood in combination with a high severity means an unacceptable risk. Figure 2.6 shows such an accident situation with a high severity level and a high likelihood. In figure 2.7 the risk reduction necessary to create a safe situation is shown. This risk reduction is expressed in an ASIL level, (A, B, C or D). If the ASIL level is A, the necessary measures to achieve a safe situation are considerable. If the ASIL level is D less severe measures are needed to achieve a safe situation (figure 2.8)


Figure 2-6: Accident with high severity and high likelihood

ISO 26262 Basis is accident situation

often possible accident

risknotacceptable

Likelyhood =exposure * riskcontrollability acceptable

rarelylow hazardous

Severity

Figure 2-7: Necessary risk reduction



Necessary risk reductionexpressed as ASIL level(Automotive Safety Integritylevel; A, B, C, D)

riskLikelyhood = notexposure * risk acceptablecontrollability acceptable

rarelylow hazardous

Severity


Figure 2-8: Necessary risk reduction expressed as ASIL level



Necessary risk reductionexpressed as ASIL level(Automotive Safety Integritylevel; A, B, C, D)

riskLikelyhood = notexposure * risk acceptablecontrollability acceptable

rarelylow hazardous

Severity

CB

D

A

-

Figure 2-9: Necessary risk reduction in old TNO approach

TNO old Basis is failure mode/cause/effect situation

often safety score

Necessary risk reductionby improving safety scoreto acceptable level (>5)

risknot

Likelyhood acceptableriskacceptable

rarelylow hazardous

Severity

9

7

5

6

4

2

3


Figure 2.9 shows the TNO approach. Events are rated on a 1-10 scale. If an event has a safety score of 2, severe measures are needed to increase the safety score to 5 or higher, where a safe situation is achieved. If the safety score is 4, less severe measures suffice. The result: The goal was to adapt the TNO method to incorporate elements of the ISO method as much as possible. This was achieved by: - Severity rating: The severity score of the ISO method was adopted. - Likelihood rating: In the ISO method the likelihood is defined as exposure * controllability. Since there is no figure for the controllability in the TNO method (there is no driver) an alternative needed to be found. This alternative, the Resultant Likelihood (Lres) is the combination of the old TNO likelihood definition with a score based on the benefit rating of safeguards. The result is expressed in a new safety score on a 1-5 scale that matches the ASIL levels as follows: ISO 26262 New ASIL Safety score --------------------------------- A 1 B 2 C 3 D 4 - >5 As in the ISO method there is no difference in rating above the level where the system is declared safe. A score of 5 always means that the system is safe. During the course of the CityMobil project this new approach will be tested in a number of cases, in order to prove that it is a viable method that enables manufacturers, operators and authorities to establish whether or not a system is safe enough.


Figure 2-10: Necessary risk reduction in new TNO approach

TNO + Basis is failure mode/cause/effect situation

often safety score

Necessary risk reductionby improving safety scoreto acceptable level (>4)

risknot

Likelyhood (res) = acceptablecombination riskof likelyhood acceptableand safeguards

rarelylow hazardous

Severityadjusted to ISO levels

5

5

4

5

3

1

2

2.3.2 Changes in the procedure In paragraph 2.1.5.5.2 the 'old' tables for establishing the severity likelihood and the safety score is shown. The new tables, adapted as described above follow below:

Table 2-4: New severity categories

Category Description

S3 Fatal Perilous injuries and fatalities

S2 Serious Serious injuries, survival probable

S1 Moderate Light and moderate injuries

S0 No injuries No injuries, only operational losses


Table 2-5: Likelihood categories

Likelihood

5 Once in 10 years

4 Once in 100 years

3 Once in 1000 years



In the TNO method the following safeguard categories were defined. The effects of the different safeguards must be considered as 'rules of thumb'. The values are not based on calculation or analysis, but are assumptions. Representative values will only be available after a long period of use of the method in practical situations. C1 Hardware Safeguards A hardware safeguard is an independent system with its own likelihood of failure. If a

hardware safeguard is built in to protect against a software failure, the likelihood of failure of the hardware safeguard is usually much lower than that of the software.

Effect: The total likelihood is the likelihood system * likelihood safeguard. C2 Software safeguard; part of the same system The same software, with the same likelihood of failure, placed in the same housing and

thus vulnerable to the same influences that caused the failure of the basic software. Basically we have two software modules in the same system that check each other. The value of the safeguard is limited.

Effect: Decreases the total likelihood with one step (factor 10) C3 Software safeguard; part of the same software in a mechanically separated system Still the same software, vulnerable to the same influences, but placed in a different

mechanical environment. Effect: Decreases the total likelihood with three steps (factor 1000) C2 Software safeguard; different software in a mechanically separated system The chances that different software, placed in a different housing fails at the same time

as the basic software is very small. Effect: Decreases the total likelihood with 4 steps (factor 10000) .


Table 2-6: Safeguard categories

Category Effect

C1 Hardware safeguard Lfailure * Lsafeguard

C2 Software safeguard; part of the same software system

Lfailure /10

C3 Software safeguard; part of same software in a separated system

Lfailure /1000

C4 Software safeguard; different software in a separated system

Lfailure /10000

Table 2-7: Determine Lres from Likelihood and Safeguard categories

Lres

Likelihood 1 / 100.000

years1 / 10.000

years1 / 1.000

years1 / 100 years

1 / 10 years

Controllability L1 L2 L3 L4 L5

C1 Lres = L * Lsafeguard L * Ls L * Ls L * Ls L * Ls L * Ls

C2-C4: Lres = C * L

C2 1 / 10 1 / 100.000 1 / 100.000 1 / 10.000 1 / 1000 1 / 100

C3 1 / 1.000 1 / 100.000 1 / 100.000 1 / 100.000 1 / 100.000 1 / 10.000

C4 1 / 10.000 1 / 100.000 1 / 100.000 1 / 100.000 1 / 100.000 1 / 100.000

The minimum likelihood category used is 1 (once in 100.000 years). If the calculated value of C*L is below this value, the minimum value is used.


Table 2-8: Determine safety score from severity and Lres

Safety score R

Lres1 / 100.000

years1 / 10.000

years1 / 1000 years

1 / 100 years

1 / 10 years

Severity Lres1 Lres2 Lres3 Lres4 Lres5

S0 No injuries 5 5 5 5 5

S1 Moderate 5 5 5 4 3

S2 Serious 5 5 4 3 2

S3 Fatal 5 4 3 2 1

Table 2-9: Relevant safety scores and combinations where the system is safe enough

Safety score R

Lres1 / 100.000

years1 / 10.000

years1 / 1000 years

1 / 100 years

1 / 10 years

Severity Lres1 Lres2 Lres3 Lres4 Lres5

S0 No injuries 5 5 5 5 5

S1 Moderate 5 5 5 4 3

S2 Serious 5 5 4 3 2

S3 Fatal 5 4 3 2 1

Table 2.9 shows the final result. The combination of severity (S0-S3) and Lres gives the final safety score for each failure mode/effect combination. In this table safety scores above 4 mean that the system is safe enough and that no further risk mitigation actions are needed. However, until there is an established formal regulation what is safe enough, needs to be established for each system before each analysis see paragraph 2.3.2.


3 Security

3.1 Personal security The personal security for passengers is important for automated public transport systems. The following proposals can improve personal security. The implementation of the requirements can help to increase the security feeling of the passengers. The minimum requirements are: Access control For CyberCars the number of users has to be limited to vehicle capacity. This can be achieved by two different strategies. The first option is that the Cybercar can only be entered by the passenger at designated stops. Here the passenger can queue as already known from bus stops and pass a turning hub or some other form of counting/billing machine. The second option is for the passenger to stop the vehicle at any place in case the passenger possesses a valid ticket and the cabin still provides enough space. Depending on the vehicle type the possibility to have exclusive access to a cabin is given. PRT systems and high-tech busses can only be entered at designated stations. Here the conventional access control mechanisms are sufficient. For advanced city cars the access is limited to persons, who ordered the vehicle. There is no access from outside without authorisation possible. Identification of the paying (responsible) passengers Cybercars and PRT-systems require identification at the entrance by using a valid ticket or transportation pass. Although this is in conflict with personal privacy, identification will improve the personal security of the passengers. For High-tech busses the identification of passengers is not needed. Advanced city car passenger need to register at the vehicle pick-up and are therefore automatically identified by the operator. Monitoring the inside and outside areas with cameras and television systems In order to provide personal security all cabins of shared automated transport systems are to be monitored by camera systems. This is in conflict with privacy. The legal regulation of so-called CCTV (Closed Circuit Television) varies greatly across Europe. Its employment is regulated by federal and state data protection acts, by police laws and codes of criminal procedure, by specific laws on video surveillance and furthermore special regulations for locations such as banks or sport stadiums. Also copyrights provisions touch the usage of CCTV. In some countries strict regulation exists in regard to private CCTV systems. In other countries mainly public systems are legally regulated. As a general rule, different acts govern the employment of CCTV for purposes of public security and the prevention of disorder or crime. The employment is regulated by specific laws as police acts. Some countries such as Spain have explicit laws for CCTV surveillance by the police in the public realm. In Denmark the 'Law on the ban against TV-surveillance', which came into force on July 1st 1982 forbids the private use of CCTV in public areas. In other countries such as Germany explicit sections on CCTV by no police actors can be found in the data protection acts. From case to case this variety causes major differences, for example, in regard to the demand of transparency as required by data protection regulations. In Great Britain there is no explicit CCTV law and there is also no explicit regulation of video


surveillance in the British Data Protection Act. But meanwhile there is a "Code of Practice" issued by the British Information Commissioner that sets a framework on how the Data Protection Act of 1998 should be put into practice in regard to CCTV. As this code does not have any independent legal character it is unknown how effective it is. Nevertheless, besides this formal diversity of legal regulations there are different regulatory tools such as the registration of systems as it is known from France, Norway and Sweden or the notification in order to guarantee transparency. [13] Communication system connecting the passengers with the security company In CyberCars and PRT-systems a two-way communication without delays increases the personal security of passengers in case of emergencies. The operator at the control station needs to make quick decisions and take necessary measures. The communication protocol is not stored for long, only to analyse the emergency process. The communication language is of importance and the operator should be able to speak at least two different languages (native language and a wide-spread language). Universal access could be problematic for non-native speakers and disabled persons. In high-tech busses and advanced city cars a two-way communication with the operator service is necessary in case of technical failure or breakdowns. This type of communication is not safety relevant and thus does not have high requirements compared to the emergency communication. Emergency procedures (emergency buttons and alarm systems for instance) For CyberCars an emergency button to stop the vehicle (and open the doors, if necessary) is required. Information on how to behave in case of emergencies is to be provided in visible and comprehendible form. A communication to operator is established in case of an emergency. Furthermore the passenger should be able to leave the vehicle at any time by means of an emergency device e.g. in case of a breakdown and fire. The operator is immediately informed, in case the emergency button is pushed. PRT-systems also need to have an emergency button to stop the vehicle and a mechanism for opening the doors (similar to trains). In case the PRT-system is not on ground level a warning for not stepping out in case of bridges etc. is given. Additionally, information on how to behave in case of emergency and a two-way communication to the operator is established. An emergency device to exit the cabin is provided. The operator is immediately informed, in case the emergency button is pushed. The doors should be only opened automatically at velocities lower then 5 km/h. A fire extinguisher could be used with direct link to the communication device to prevent misuse. High-tech busses should also provide an emergency button to stop the vehicle (and open the doors, if necessary). Information on how to behave in case of an emergency and a two-way communication to the operator is established. An emergency device to exit the bus is provided as it is known from conventional buses. In case the vehicle is operated in a vehicle platoon, an emergency button for dissolving the platoon is installed into each vehicle. Lighting Vehicle lighting is to be divided into inside and outside lighting. Cybercars, high-tech busses and advanced city vehicles require standard vehicle lighting from the outside, as they might share the roads with conventional traffic or other traffic participants such as pedestrians and cyclists. PRT-systems require outside lighting only at PRT-stops as they drive on dedicated tracks.


The necessity for inside lighting depends on the type of vehicle. In case the cabin is for a shared party of passengers (public transport) lights inside the cabin should be turned on manually on demand and should automatically be turned on at stations. In case of PRT-systems the lights can be turned on continuously as no other traffic participants can be distracted by the lighting. Information system The information system (operating procedures, maps and driving route, status, position, clear emergency procedures and instructions, messages for system behaviour, etc.) should be installed into every automated transport system. The HMI should be easy to understand, even for non-skilled users and foreigners. In case of emergencies a warning message is to be played. In a PRT-system the next driving stop is clearly to be announced before the arrival optically as well as acoustically. A warning tone should be played before the door begins to close automatically. Information about passenger privacy In case a monitoring system is installed to the vehicle, which could help prevent possible crimes and misuse, the passengers should be informed. This can be done by signs.

3.2 Protection against terrorism After September 11 in 2001 EU decided new legislation to protect people from terrorism in Civil Aviation (EU R2320/2002). The regulation includes security checks of airport areas, screening of airport and aircraft staff, passengers, luggage, mail and freight/goods entering airport areas. The terrorist attacks in September 2001 and later events like the Madrid and London attacks have shown that transport systems are terrorist targets and might represent an unwanted vulnerability for the passengers. This represents a barrier against use of the systems. Also efforts to secure passengers and equipment can become barriers against use, because it increases the travel time and the cost of using the system. Therefore it is important to consider the terrorist threat and arrange the sufficient protective actions. It is not possible to protect transport systems entirely from the risk of terrorism. Most transport systems are meant to be open to any potential user, and it is hard to know who has sinister purposes and who has not. Conventional transport systems offer a manual and visual check of the passengers, freight and activities on board, and thus represent better protection against terrorism compared to driverless transport systems. Since platooning is based on the surrender of control to a lead driver operated vehicle, this transport system can be regarded as a driverless system in this aspect. We have emphasized the driverless systems as they have an altered risk situation. There are some means to be taken to diminish the possibility to use automatic vehicles to carry bombs, either with a courier or without, towards terrorist targets. Actions to protect the driverless units against terrorist attacks are:

• Installing a central control desk • Monitoring the inside and outside areas with cameras and television systems


• Identifying the paying (responsible) passengers • Ensuring that the vehicle does not move if it is unoccupied or has been called in an

unauthorized way • Safe communication with control desk and remote control

A control desk would be able to register what happens inside the vehicle and follow up other signals from the system which indicates that the system is not working correctly. It would also represent a possibility for the passengers to get help, either in order to operate the system correctly, or in case of emergency events. Driverless vehicles could potentially carry a terrorist, but to separate ordinary passengers from people with vicious intentions is hard. Monitoring the inside of the coupe would give some kind of precaution against such misuse. To avoid the possibility of sabotage to the vehicle or dedicated infrastructure, such as attaching explosives on the outside of the vehicle or placing explosives on the tracks, there should be some kind of monitoring of the outside areas or/and sensors on the vehicles. Identification of the paying (responsible) passengers is regarded as a rather ineffective remedy for protection against terrorism. This could only be protective if the system recognizes users that are suspended from the system because of former actions. Some of the systems are meant to carry goods, and for those it is necessary to be able to send units on their own. This could be utilized by terrorists to send explosives towards their target. A way to minimize such a threat is to limit the access to send goods. There should be a system to ensure that the vehicle does not move if it is unoccupied or has not been called in an authorized way. Also it should not be allowed to open or access the vehicle except for accepted users. Some of the driverless vehicles (Cybercar) have predefined routes or will operate in a bounded or restricted area. The control central should be able to direct these vehicles (remote control) and/or they should be automatically stopped if they move away from the predefined area. Remote control by other (unauthorized) users must be hindered by safe communication channels.

3.3 Protection against vandalism and misuse All the actions recommended for protection against terrorism, will also represent important contribution to protect against vandalism and misuse. It should not be possible to intentionally trigger off any false alarm. Therefore it might be necessary to install systems for misuse of for instance obstacle detection. This could be arranged with monitors, giving the control central the opportunity to double check if there are for instance obstacles lying in the track. The consequence of obstacle detection misuse could be that an alarm goes off unnecessarily, and perhaps stops the vehicle. This is regarded as a minor consequence, but could give the mob a chance to damage equipment. Some damage of the equipment can be avoided due to design. Unfastened object can become too tempting and weak materials could be too easy to destroy by the rowdies. Also it is recommended to use materials with surfaces, which are easily washed or cleaned from tagging. In order to avoid damage to the equipment because passengers are unaware of how


the system works, it is important to keep all instruments and information as simple and self-explanatory as possible. A driverless vehicle could be a tempting shelter for homeless people or playing children. To avoid this kind of misuse some kind of access control is recommended. If passengers have to pay for each trip, and the trips are limited by time and distance, this would reduce the opportunity for people to use the vehicles as a shelter or playground.

3.4 Freight security On the one hand freight can be used as an instrument of misuse, e.g. by shipping bombs or drugs and on the other it can be stolen and has to be protected itself. Therefore safety measures are recommended, which take both possibilities into account. Access control The access control to the transport vehicle is restricted to registered persons only. The registration is carried out before the system is used for the first time. Therefore the name and the identity of each person, who wants to ship freight is known to the operator. The procedure is similar to modern mailing systems. Each user will receive an identification card, which he can use for freight shipping. An operator of the control desk should monitors the exit control sensors of all vehicles and is warned by the system in case of unauthorised vehicle stopping or door opening or freight removing. This should be implemented independently of the system. Additional access control for the freight itself is necessary. Dangerous goods as well as goods of high value such as money should not be allowed for automated transport in order to decrease the danger of terrorism and theft and on the other hand increase the safety of the transport system. Therefore the transport of freight should be limited to the multilateral agreement of the United Nations (e.g. see ADR 2007 (Accord européen sur le transport des marchandises dangéreuses par route), part 3). Restriction and qualification system for access to the system In order to prevent the unauthorised transport of dangerous goods, bombs, etc. the PRT transport system should be protected from access of non-employees. Cybercars drive on public roads. For this type of vehicles the access control has to be very sophisticated to give access only to authorised persons e.g. the receiver of the delivery. Valuable goods should not be transported by such a system. Freight monitoring In case the access control systems of the vehicles operate satisfying, the vehicles do not have to be monitored during the transport process. Also the freight in the vehicles does not have to be monitored. To prevent theft and misuse the pick-up station for freight should only be monitored by means of camera systems.


4 Privacy There might be a contradiction that you cannot have a fully safe and secure system while maintaining full privacy. While full privacy would imply that the passengers are not seen on or being registered in any way, safety and security issues might require some monitoring and registration. It is important however to limit the monitoring and registration of people and activities to what is necessary in order to respect peoples need for privacy.

4.1 Monitoring Cybercars Monitoring of outer areas is not in conflict with passenger security. In this case it is not only the passengers entering or leaving the automatic transit unit that are monitored, but also the city or the surroundings in general. As long as the cameras are there primarily to ensure the security of passengers in CyberCars and accompanying infrastructure, it could be restricted in accordance to where (and perhaps when) CyberCars are in action. Otherwise the cameras could be used for surveillance purposes. Whether monitoring of outer areas is regarded as a major barrier is dependent on the general monitoring level of the society. Monitoring inside the Cybercar is of little importance if it is used as a private car. Then the reason must be protection against vandalism. If the Cybercar is shared, the monitoring of the coupé is there to protect the equipment but also to secure the people inside. A way to maintain the personal security and at the same time increase the privacy of passengers is to lower the dissolution or transference frequency, for instance, in operating mode. Personal Rapid transit This is not shared with unfamiliar people and thus it is not required to identify or monitor passengers of the vehicle due to safety or security reasons. It might be relevant to do so for protection against vandalism or crime. High-tech busses In high-tech buses there are drivers present all the time and this limits the need to use cameras to maintain passenger safety and security. Monitoring should still be installed in order to protect the buses from vandalism. Lack of monitors is not regarded as a major barrier against large scale introduction of high-tech buses and is therefore given low priority. At the European level CCTV is mainly regulated in the context of privacy and data protection: in particular by Article 8 of the European Human Rights Convention, the European Convention on the Automated Processing of Personal Data of the Council of Europe and the data protection directive 95/46/EC of the European Union. Passed in 1995 the directive came into force in October 1998 with the aim to harmonise European data protection legislation. [13] An overview of national provisions especially addressing CCTV can be found in the annex (see chapter 8).


The employment is regulated by specific laws such as the codes of criminal procedure. The latter use is mostly regulated within the framework of the data protection legislation As an example, in Germany data may be collected by video surveillance and then matched to a particular individual. According to the law (Section 6b of the Federal Data Protection Act, Sections 26 and 27 of the Data Protection Acts of the Federal Border Police Act.) the individual in question shall be notified of the processing or use in law concerning Data Protection. The data shall be erased immediately after it is no longer necessary for the attainment of the purpose or in case further retention would be contrary to data subjects' legitimate interests. In case it is not possible to make the individual persons anonymous the data is to be deleted at the latest two month after the recording. If data are collected without the data subject's knowledge, he shall be notified of the fact of the recording, the identity of the data controller and the purpose of the collection, processing or use.

4.2 Data handling Data handling is not regarded as a major barrier against the dispersion of automated modes of transit. Safety and security reasons state the need for payment and monitoring when passengers share a coupe and there is no driver present. This could potentially be a source to knowledge about the identity of the passengers. To know who the Cybercab passengers are, however, is regarded as not necessary due to safety reasons. Identification of passengers could however be used as a protection of the equipment. Relevant data, to be collected and stored, are how many passengers used the service and when, perhaps a customer register, to some degree who used the service (or paid to use it), and pictures from the cameras. Data must be stored in places with limited access. Routines to save and follow up information from transactions and cameras must ensure passenger privacy. The information should not be stored longer than required. Data should not be used in other purposes than it was intended to.

4.3 Tracking and tracing Passengers must get information about how data is collected, saved and used. Identification of the passengers is regarded as not necessary in any if the suggested systems due to safety and security issues, and is given low priority as a means to protect the equipment. As a consequence this information should not be stored longer than necessary. This limits the possibility to identify, track and trace data about passengers.

4.4 Legislation This point addresses the question of legislation about data collection, data storing and use of data or statistics. Legislation regarded use of automated vehicles are covered under chapter 5.2. Some countries have strict legislation about data storing and handling. These must be followed.


5 Legislation

In the following the existing legislation in the EU-member states is addressed. Criminal law and road traffic regulations are regulated by each country of the EU independently. The presented laws have to be considered for the introduction of automated transport systems.

5.1 Vienna Convention on Road Traffic The Vienna Convention on Road Traffic is the most recent multilateral international treaty on road traffic. This treaty is the result of the United Nations World Conference in Vienna, which ended on 8th Nov. 1968. The goal had been to substitute various earlier international treaties in this field. The Vienna Convention on Road Traffic has been put down in Chinese, English, French, Russian and Spanish – and it has been decided that every one of these languages shall be likewise binding. From the wording alone, it may be concluded that the driver must always be able to control a vehicle according to his own intentions. This would mean that autonomous systems that actively intervene into the major aspects of driving (longitudinal and lateral control such as acceleration, braking, steering) cannot be considered to be concurrent with the Vienna Convention on Road Traffic as long as they can not be overridden by the driver. The wording of the treaty gives reason to assume that the contracting parties’ representatives wanted to see a human being in control and fully responsible for any consequences of a car’s movement. This becomes clear from the understanding of the term “driver” that can commonly only be understood as a human being and most certainly not including from the contracting parties’ representatives point of view, any electronic systems. It can, furthermore, be assumed that this restriction has been made in order to warrant traffic safety. In case it should prove necessary to diverge from this understanding of the Vienna Convention in order to allow for non-overridable, actively intervening electronic system, an amendment of the Vienna Convention would be the only legal possibility to achieve this goal (which Art. 49 Vienna Convention on Road Traffic provides). At least in Germany, an amendment of the Vienna Convention would lead at the same time to an unprecedented change in terms of road traffic law, which, at present is based on the responsibility of a human driver. This should equally apply to other European countries as the Vienna Convention is a common basis for legislation on road traffic. [9] As a conclusion a change of European as well as national law is necessary in order to allow automated transport systems to operate in mixed traffic.

5.2 Product safety and liability law Product safety law has firstly been regulated in the EU-directive 92/59/EEC from the 29th of June 1992 on general product safety. The directive has been replaced by the directive 2001/95/EEC, which had to be implemented by the member states until 15 January 2004. [10]


For the assessment of safety it is assumed that a product is safe, if it conforms (1) with specific safety requirements that are set out by community legislation for specific products (European legislation) or, if such specific provisions do not exist, (2) with national laws. It is further assumed that in the absence of such laws, a product is safe if it conforms to (3) national standards incorporating European standards. The directive further states that if such standards do not exist, safety will be assessed considering especially one or more of the following elements [10]

• National Standards • Recommendations of the Commission setting guidelines on product safety

assessment • Product safety codes of good practice in force in the sector • The state of the art and technology • Reasonable consumer expectations concerning safety.

Product liability law has been regulated in the EU-directive 85/374/EEC of the 25th of July 1985 on the approximation of the laws, regulations and administrative provisions of the Member States concerning liability for defective products. It is also implemented into law of the member states within the following years, e.g. into German law on the 15th of December 1989 (in the so-called "Product Liability Law" - "Produkthaftungsgesetz"). [10] According to the legal definition given in this EU-directive, a product is defective, if it does not warrant the safety that can be reasonably expected taking into consideration all circumstances, especially (1) the presentation of the product, (2) the use of the product that can be expected in faith and (3) the point in time when the product was marketed. [10]

5.3 Criminal law Today the criminal law is regulated by each government of European-states independently. As an example the criminal law is in conflict with automated systems for § 315 c Abs. 1 Nr. 2 d) Strafgesetzbuch (StGB) in Germany, as the driver ignores warning signals (due to the automation of the driving task) on purpose. [12] The criminal law has to be adapted to automated transport systems for each country by its government.

5.4 Road traffic regulations Road traffic regulations are regulated by each country of the EU independently. In Germany the driver violates the road traffic regulations in case he does not monitor the vehicle functions continuously, is distracted by another task and the automated controller takes over the driving task. § 3 Abs. 1 S. 1 StVO states that the driver has to control the vehicle at any time. [12] Therefore an adaptation of the national road traffic regulations by each country’s government is necessary.


6 Other barriers Other (potential) barriers are separated into two groups, one that exists within organisations, and one that exists in peoples mind. To overcome organisational barriers one would have to change decisions made by politicians or company managers. To overcome social barriers one would have to change how people think about implementing a new transport system.

6.1 Political barriers Political barriers include:

• Resistance against funding • Politically sensitive to change laws to allow driverless vehicles • Unclear or distorted motive to introduce automatic transit systems • Election periods could intrude with the planning or implementation of new systems • Combination of policy instruments

Automatic transport systems have potentially many benefits. It is environmentally friendly, it is safe, it can provide an adjusted transport system to disabled people, the lacking driver could make the system cheaper than conventional systems, implying at least lower operating costs and so forth. With a wide variety of benefits following a new system, it could be appealing to several political wings, even to people who are against public funding in principle. When a scheme with automatic transport system is put forward, it should be clarified completely which problem it is meant to solve. (The problems could both be local or a wider area.) If the system is introduced merely because of the potential publicity it might get disliked, or because professionals are worked up over new exiting transport system, the system might be implemented in settings where it does not solve any transport problems or disburden the environment. This could lead to too few passengers and economic deficiency, mistrust in the automatic transport systems and lack of public funding and support in future projects. Any demonstration carried out should be precise about what the motive of implementing a new system is. It is also important to measure and report how well the new systems were in practice. Successfully implemented projects would give the systems good reputation. Information campaigns and other forms of publication of results could become a powerful tool in order to make decision-makers aware of gains to be expected by automatic transport systems. Implementation of automatic transport systems also must demonstrate that the safety is increased by the new system. Some of the demonstration implementations are given exceptions from legal obstacles regarding driverless vehicles. If the safety level of the automatic transport systems is questioned, it might be difficult to change the legal framework to allow driverless vehicles in the future. Some situations require a combination of means to make the automatic transport system work in association with the rest of the transport system. This might require politically unpopular actions, like extra parking fees, limited access to certain areas for some transport groups and so forth. In these cases information about how the transport system is meant to work as a united system and how the different instruments are fitting in the greater system is important. Also some patience might be needed until the system operates as intended, and


until the potential passengers have altered their habits, or overcome personal objections, and started using the system.

6.2 Organisational barriers

6.2.1 Information and knowledge Publication of results from earlier work should answer two questions:

1. Why past implementations perhaps were not or were a success either financially or technically?

2. What were the experiences in the different demonstrations that have been carried out?

This would eventually lead to knowledge about what the success criteria are? Information about the benefits of the new automatic transport systems should reach the planners, the decision-makers and the society. Automatic transport systems can solve many of the challenges urban developers are facing now. It is important though that it is implemented in places where it actually improves the situation. Otherwise there could be situations where negative information is spread and hinders what could become new successful implementations. The introduction of new transport systems presupposes an appropriate process and good dialogue between politicians, planners and transport providers to identify objectives and strategies. Lack of an agreed plan can become a crucial barrier to implementation. It is also important to put the new transport system into the correct context; the new system will in most cases be supplementary and will not replace conventional solutions.

People must be convinced that the safety of automatic transport systems without a driver present can conquer more familiar systems where there is a driver present. Until it is the general opinion that an automatic system can be just as safe, or even safer, than traditional systems, it might be necessary to keep a driver and face extra cost due to lack of public acceptance. Information about existing systems would eventually convince people.

6.2.2 Financial barriers Financial risks relate to robustness of cost/revenue forecasts and the likelihood of future financial viability and of obtaining funding for implementation. There may also be difficulties in constructing robust forecasts for innovative systems. Additionally there may be problems of “believability” even if it can be demonstrated that forecasts are robust. This may belong partly in the political category. Potential solutions to the financial barrier, as identified in TRANSPLUS (2003) might include Public-Private Partnerships (PPP) and financial restructuring. A PPP is essentially a relationship between actors, which may be used in situations where the respective authorities lack the resources (e.g. financial, organisational, knowledge, skills) to overcome delaying and or hindering implementation. Cities in member states such as the UK where there is now a strong emphasis on PPPs may be more comfortable with such an approach than cities with a tradition of public sector ownership (Netmobil 2004).


Financial Restructuring refers to the adaptation of existing financial structures or creation of new structures. It applies where the financial structure is hindering the processes of design/planning and implementation. This seems to be the case in situations where municipalities are competing with each other for financial resources. The financial situation is one of the main obstacles towards implementing automatic transport systems, especially in the initial phase (as the uncertainty is greatest in that phase). There is a greater financial risk to be one of the first to implement new systems. Later implementations have the advantage to avoid pitfalls and learn through earlier experiences. Also there have been some implementations earlier that for different reasons have not been dispersed further but have stopped. In such situations you miss the advantage of large-scale production effects. A contribution to overcome such problems, are to support demonstrations, to report experiences from the demonstrations and also focus on the financial side. Furthermore mechanisms influencing on the competition between different transport systems and transport providers like pricing strategies and subsidies should be used actively to promote new transport solutions.

6.3 Social barriers A new system could affect the society through the use of public funding, staff or space to run an automatic transport system instead of using it for other purposes. If the new systems replace or compete with existing transport systems, there is a risk that some of the staff might become redundant. It is therefore important to introduce the system along with a plan that covers such issues. One of the benefits of driverless systems is that it doesn’t need a driver, and that saves costs. Redundant Staff should therefore, if possible, be offered other positions, maybe as parking inspectors. In Trondheim, when the tram service was stopped in 1987, the former tram drivers were offered positions as parking inspectors. The impact of innovative transport systems on local businesses would largely depend on the success of the system. If they deliver all that is promised, it could have a huge positive impact for city and town centres and the businesses located there. It could also bring potential benefits in encouraging redevelopment and new buildings in focal centres that would be positive for existing business. However, on the other side, the failure of a scheme would cast an extremely negative view on a town or city (Netmobil 2004). Both the authorities and public have barriers against different advanced and innovative transport systems for various reasons. This manifests itself through investments resistance and lack of general user acceptance in the systems. The barriers can be summarized in the following categories: Authorities

• Operational level scepticism

− Is there someone who can operate and administrate, perhaps also finance, the system in a viable way?


− Can the system coexist with other local transport systems and other traffic? − Is the system vulnerable for specific weather conditions?

• Strategic level scepticism

− Will the system solve all or some of the problems they were intended to, for instance congestion problems, safety levels, pollution?

• Technological level scepticism

− Will it work technically? − What are the consequences if the technology fails?

General Public

• Personal level scepticism

− Would drivers and passengers feel uncomfortable using a system, which replaces their full control of the vehicle?

− Will all user groups, regardless of their cultural background, driving experience, etc., manage to use the systems as intended?

• Society level scepticism

− Would the investment in new systems have a positive or negative impact on the growth of Gross Domestic Product (GDP) (also discussed in Sessa et al. 2007)?

− Would the automatic system replace some of the existing workforce, leading to unemployment?

The system could potentially become aesthetically intrusive in a city environment. This must be considered as the system is designed. Installation of a new and advanced transport system might have negative impacts on the visual appearance of the city. This could be due to the system’s degree of “futuristic appearance”, space consume, mismatch with architectonical style of historical city centre, noise, etc. City image can be related to an existing transport system, e.g. the cable pulled tram in San Francisco. Introducing a new system can thus interrupt a city image in a negative way, even though the system itself is regarded as not being visual intrusive. The design of vehicle and infrastructure would have to be complementary to the aesthetics of historic buildings, and help maintain the city’s identity. A pilot system should prove effectively and not being visually intrusive. However, if a pilot proves wrong, this could represent a significant barrier for ability to a full scale introduction in other cities. The impact of innovative transport systems on local businesses would largely depend on the success of the system. If they deliver all that is promised, it could have a huge positive impact for city and town centres and the businesses located there. It could also bring potential benefits in encouraging redevelopment and new buildings in focal centres that would be positive for existing business. However, on the other side, the failure of a scheme would cast an extremely negative view on a town or city (Netmobil 2004).

6.4 Barriers from another perspective The European Conference of Ministers of Transport (ECMT) is an inter-governmental organisation established in 1953 to provide a forum in which Ministers responsible for


transport, and more specifically the inland transport sector, can cooperate on policy. Four different ECMT reports presented at a ministerial meeting in Dublin in May 2006 address different policy objectives and policy instruments, they all highlight key barriers to the effective implementation of policies to promote sustainable transport [14].

The work done within the ECMT initiative addresses most of the barriers described in former chapters but from another standpoint i.e. from a superior transport political view. In CityMobil the basis is to look into solutions on local level for single towns. The final deliverable of work package 2.5 will include solutions on a superior level based on experiences gained during the demonstration activities supported by the work done by ECMT.


7 Conclusions This report describes the work carried out in the first phase of Work Package 2.5 as a part of Sub Project 2 of the CityMobil project. The report describes certification procedures for automated systems, defines the requirements of guidelines for safety, security and privacy and lists a number of barriers that are in the way of mass-introduction of automated transport systems.

7.1 Certification procedures The certification procedures are meant for 2 major purposes: 1. As a final certification instrument to establish whether or not an automated transport system meets the requirements that were established with respect to safety. 2. As a method to analyse the safety of a system during the development phases of an automated transport system, in order to be able to make modifications and take issues into account in an early stage of the development process. The method is based on well-established analysis methods (FMECA), which were adapted to suit the purpose of this procedure. The procedure itself is based on recommendations that were formulated in other projects [1, 2, and 3] and which were updated in accordance with the latest developments in Europe [4, 5]. During the remaining parts of the CityMobil project the procedure will be evaluated in practice and improvements will be made when necessary. The result, ready for use certification procedures for automated transport systems will be presented as part of the final deliverable of CityMobil sub-project 2.

7.2 Requirements for personal safety, security and privacy The final deliverable of WP 2.5 will include a list of guidelines for personal security and privacy. This report lists a number of requirements that such guidelines should meet. Personal security deals with the risks and hazards people are subjected to due to actions, deliberate or not, of other people. The report explains which factors can contribute to a more secure feeling of passengers, in the absence of a driver. Finally some attention is paid to the security aspects when transporting freight. By nature privacy aspects are contradictory with security and safety, so there has to be a compromise between these aspects when implementing automated transport systems.

7.3 Barriers When implementing automated transport systems there are a lot of barriers to overcome, such as legal barriers political barriers, social barriers. A number of these barriers are listed in this report. In the remaining part of the project strategies will be developed to remove these barriers or decrease the influence they have.


References

[1] CyberCars project: Deliverable D.6.1: Safety standards for Cybercars Part 1: Existing standards and guidelines. J.J. Uwland and J.P. van Dijke. September 2002

[2] CyberCars project: Deliverable D.6.2: Safety standards for Cybercars Part 2: Recommendations for certification procedures. J.P. van Dijke and J.J. Uwland. June 2004

[3] CyberMove project: Deliverable 3.2: Safe sites and systems: J.P. van Dijke and M.M. Janse. October 2004.

[4] Code of Practice for the design and evaluation of ADA systems. RESPONSE III project. October 2006

[5] IEC 61508: Functional Safety of electrical/electronic/programmable electronic safety-related systems; IEC 1998

[6] System Safety Analysis Handbook; System Safety Society.

[7] EEE Software Engineering Standards; IEEE 1999

[8] Passport II, Promotion and Assessment of Procurement of Operable and Reliable Road Transport Telematics-II, DRIVE II project V2508, 1995

[9] T. M. Gasser, A German view on the international legal barriers for the implementation of ADAS, BASt

[10] EU-project: Response 2, deliverable : D4

[11] EU-project: Promote Chauffeur, deliverable D24

[12] W. FRENZ, Haftungsfragen bei Fahrerassistenzsystemen, 2003

[13] EU-project: Urbaneye, Final Report: CCTV in Europe

[14] A.D. May, M. Crass, Sustainability in Transport: Implication for policy makers, July 2006

D.2.5.1 Certification procedures for automated transport systems ii

8 Annex

Annex 1: Flow diagram FMECA procedure - Steps 1, 2 and 3 to be discussed in a preparatory conversation with the principal - Step 4 to be carried out in close cooperation with the principal. A. General preparation

Discuss with the principal and register: 1. Name of the project 2. Description (maximum 10 lines) 3. Principal 4. Date of the analysis 5. Name of the project leader 6. Name of the project leader/contact principle

Discuss and register the action plan with the principal: 1. Overall system borders Which systems are considered (what is inside and what

is outside the system boundaries) 2. System definition and function analysis Describe the method in 10 lines 3. Description FMECA analysis

Type of FMECA (is it a concept, design or certification analysis)

Estimate the number of subsystems; Estimate the number of sessions; timing; names of the

participants 4. Documentation

Which documents are going to be used How to register documents

5. Provisional planning 6. Accepted safety level Discuss and agree on which accepted safety level will be used 7. Agree on and sign off on the plan of action 1. List of available documentation and drawings;

Give each document a unique number Register doc. number, date of receipt and source The list is a controlled document. Organize version control 2. Only registered documents are used in the analysis 3. All new information is numbered and registered also

sketches and notes 4. Verbal information from the principal is put on

paper, authorized, numbered and added to the list 5. In case of software: register which design

rules/principles have been applied 6. Assess whether or not there is sufficient informatio n to carry out an analysis. If not the principal is asked to

provide additional documentation

1. project description

2. Plan of action

3. Documentation

D.2.5.1 Certification procedures for automated transport systems iii

B. Execution: Go through the steps below for every separate sub-system that is analysed

1. Name the system to be analysed and establish the system boundaries. Do this by establishing which components/subsystems are inside the system boundaries and which are outside but do have interactions with the system inside the system boundaries

2. Subdivide the systems within the system boundaries further on the basis of pragmatic choices and repeat step 1 for each of these sub-systems. Choose the subsystems in such a way that they will probably coincide with the subsystems on which an FMECA will be carried out

3. Indicate which interactions exist between the (sub)system to be analysed and the outside world (everything outside the system boundary)

4. Establish on practical grounds on which (sub)systems analyses will be performed and which systems need to be subdivided further

5. Establish the inputs and outputs entering and exiting each (sub)system. Distinguish between the following categories: information; matter; people; electric currents; radiation

6. Establish the terminator (input/output point) through which the media named under 5 enter or exit the (sub)system

7. Draw up a passport diagram based on the information above

8. Carry out a function analysis Functions are defined as every relation between an

output and an input and in some cases between output and internal sources

9. Each system has one or more functions. The failure modes on which the FMECA is based are defined as deviations from those functions

1. All Information that becomes available during the

analysis is registered and added to the list of documents 2. In preparation of the FMECA sessions the list with

functions as established above is included in an Excel file

3. To be carried out for each (sub)system: 1. Establish the failure modes for each function 2. Determine all causes of each failure mode 3. Establish the most serious effect for each failure mode/cause combination 4. Indicates for each failure mode/cause combination which safeguards exist.

4. System definition & function analysis

5. FMECA sessions

D.2.5.1 Certification procedures for automated transport systems iv

5. Establish the severity [S] for each combination 6. Establish the likelihood [L] for each combination without taking the safeguards into account 7. Establish the controls/safeguard value [C] 8. Establish from the table the resulting Likelihood (Lres = L * C) 9. Derive the security score [R] from the table 10 Define and add recommendations 11. Add relevant comments.

The report includes: 1. A summary 2. Contents 3. Introduction 4. The project description 5. An action plan 6. The system definition 7. The relevant results (safe scores below the accepted safety level) 8. Conclusions 9. Recommendations Appendices: a. List of documents b. The complete FMECA sheets

6. Reporting

D.2.5.1 Certification procedures for automated transport systems v

Annex 2: CityMobil: Informal report on task 2.5.1: Review phase

EUROPEAN COMMISSION

DG RESEARCH





Legal and administrative issues Task 2.5.1: Review Phase

Deliverable no. T 2.5.1 Dissemination level Public Work Package 2.5 Legal and administrative issues Author(s) Ragnhild Wahl, Trude Tørset and Torgeir Vaa Co-author(s) Jan van Dijke and Adrian Zlocki Status (F: final, D: draft) F_31.01.07 File Name Task 2.5.1 Final deliverable 31 jan2007.doc Project Start Date and Duration

01 May 2006 - 30 April 2011

D.2.5.1 Certification procedures for automated transport systems vi

TABLE OF CONTENTS 1 INTRODUCTION VIII

1.1TASK 2.5.1 REVIEW PHASE VIII 2 LEGAL AND ADMINISTRATIVE BARRIERS IX

2.1TECHNICAL BARRIERS XI 2.1.1 Systems safety and reliability xi 2.1.2 Harmonization and standardization xii

2.2USER RELATED BARRIERS XIII 2.2.1 Societal barriers xiii 2.2.2 Security and privacy xiv

2.3ORGANIZATIONAL BARRIERS XIV 2.3.1 Institutional xiv 2.3.2 Impacts on city image xv 2.3.3 Project organization and management xv 2.3.4 Financial and commercial xvi

2.4LEGAL REGULATIONS AND LIABILITYXVI 2.5BARRIER EXAMPLES XVII

3 EXISTING STANDARDS, LEGISLATIONS AND GUIDELINES XVIII 3.1CURRENT PRACTISES FOR APPROVAL OF ADVANCED TRANSPORT SYSTEMS XVIII 3.2EXISTING SAFETY STANDARDS XX

3.2.1 Specific standards for automatic guided vehicles xx 3.2.2 Specific standards for surface vehicles on wheels xx 3.2.3 Specific standards for electronic and computer controlled systems xxii

3.3EXISTING LEGISLATION XXIV 3.3.1 Vehicle and machinery xxv 3.3.2 Road infrastructure xxvi 3.3.3 Rail infrastructure xxvi 3.3.4 Encompassing systems xxvii

3.4CERTIFICATION PROCEDURES XXVIII 3.4.1 Certification of road vehicles xxviii 3.4.2 Certification of vehicles not meant for public roads xxix

4 HOW TO WORK ON SAFE SITES AND SYSTEMS XXIX 4.1GENERAL XXIX 4.2RISK REDUCTION METHODOLOGY XXX 4.3SYSTEM SAFETY ANALYSIS XXXII

5 FURTHER WORK PLAN XXXIV 5.1TASK 2.5.2, DEFINITION PHASE XXXIV 5.2TASK 2.5.3, PRODUCTION PHASE XXXIV

6 SOURCES XXXVI 6.1REFERENCE LIST XXXVI 6.2WEB SITES XXXVI

D.2.5.1 Certification procedures for automated transport systems vii

TABLES Table 1.1: Documents overview ..........................................................................................................ix Table 2.1: Characteristics of different system’s use of vehicles and infrastructure...........................................x

Table 2.2: Barriers identified by Netmobil........................................................................................... xvii

Table 3.1: Existing vehicle and machinery legislation ........................................................................... xxv

Table 3.2: Existing rail infrastructure legislation .................................................................................. xxvi

Table 3.3: Existing encompassing systems legislation........................................................................ xxvii

FIGURES Figure 1: Project phases and focus on safety assessment .................................................................... xxx

Figure 2: Step by step risk reduction............................................................................................... xxxii

Figure 3: Overview of the system safety analysis process...................................................................xxxiii

D.2.5.1 Certification procedures for automated transport systems viii

Review phase

1 Introduction The CityMobil project “Towards advanced transport for the urban environment” aims at achieving a more effective organisation of urban transport, resulting in a more rational use of motorised traffic with less congestion and pollution, safer driving, a higher quality of living and an enhanced integration with spatial development. This should be achieved by promoting the introducing of advanced technologies into the transport environment. The concepts, methods and tools developed in CityMobil will be validated and demonstrated in a number of different European cities under different circumstances. The three main demonstrators will take place in Heathrow, Rome and Castellón. These will be real implementations of innovative new concepts, and represent the first stages of automated transport systems that are really integrated in an urban environment. Sub project 2 “Future scenarios” will investigate how automated road transport systems fit into the expected scenarios for advanced transport in the future. Work package 2.5 “Legal and administrative issues” within this sub project aims at identifying legal and administrative barriers that are in the way of large scale introduction of advanced transport systems, to take them away where possible and to define strategies for the removal of the remaining barriers. Three tasks are planned within WP2.5;

• Task 2.5.1: Review phase

• Task 2.5.2: Modification and actions to be taken

• Task 2.5.3: Production phase, with development and adaptations of procedures, proposals and guidelines

1.1 Task 2.5.1 Review phase The present report documents task 2.5.1 the “review phase”. A brief survey of existing legislation, legal traditions and cultural differences in Europe is carried out. A request was sent to all CityMobil partners asking for information about relevant procedures and regulations regarding advanced transport systems. Topics listed in the request were:

• Safety

• Security

• Privacy

• Responsibility

• Certification procedures

Table 1.1 gives an overview of references received from the partners.

D.2.5.1 Certification procedures for automated transport systems ix

Table 1.1: Documents overview

Title Supplementary information References Related project

Safety standards for cybercars, D6.1 Existing standards and guidelines www.cybercars.org CyberCars Safety standards for cybercars, D6.2 Recommendations for certification procedures www.cybercars.org CyberCars

D3.2 Safe Sites and Systems www.cybermove.org CyberMove

ECE Regulation no. 79, Revision 2, 21 April 2005 “ Uniform Provisions concerning the approval of vehicles with regard to steering equipment”

Annex 6 Special requirements to be applied to the safety aspects of complex electronic vehicle control systems.

ECE Regulation no 13, Revision 5, 8 October 2004 Uniform Provisions concerning the approval of vehicles of categories M, N and O with regard to braking”

Annex 18 Special requirements to be applied to the safety aspects of complex electronic vehicle control systems.

http://www.unece.org/trans/main/wp29/wp29regs.html

Wet Personenvervoer 2000

Description: Dutch Law with regard to requirements and rules to acquire and conduct of public transport in the Netherlands

Deliverable 2. ANNEXES, Research Synergies, Needs and Opportunities

Annex B: Legal and institutional issues, Annex C: Risks and barriers www.netmobil.org NetMobil

Proceedings of NETMOBIL Conference and Final Dissemination Workshop "New transit in town" Milestone M5 www.netmobil.org NetMobil CEN documents concerning train systems CEN www.cenorm.be

Verordnung über den Bau und Betrieb der Strassenbahnen

German law for construction and operation of tramways

Vorläufige Richtlinien für den Fahrbetrieb ohne Fahrzeugführer nach der Verordnung über den Bau und Betrieb der Strassenbahnen

Regulation for autonomous trains systems

EFAS - Einsatzszenarien für Fahrerassistenzsysteme im Güterverkehr und deren Bewertung Fortschritt-Bericht VDI www.fahrerassistenzsysteme.de

EFAS / MFG / KONVOI

Automatisches fahren im spurgeführten verkehr nach EBO Basispapier

RESPONSE 3 A PREVENT Sub-project

http://www.prevent-ip.org/en/prevent_subprojects/horizontal_activities/response_3/response_3_02.htm PREVENT

The present report is based on review of this literature. However, these documents do not cover the required range of aspects. Therefore it is necessary to carry out an additional customised survey to fill out the picture. This will be further commented in section 5.

2 Legal and administrative barriers A number of research questions are based on general open issues or barriers that are known to stand in the way of large scale implementation of advanced transport in cities. Most of these issues were identified in earlier (European) research projects (notably LUTR and NETMOBIL clusters). These barriers can be of a technological nature, like obstacle detection and avoidance, but there are also issues of traffic management and a number of very important legal and institutional issues to be addressed. Furthermore there are issues that

D.2.5.1 Certification procedures for automated transport systems x

have not been addressed in these earlier projects and that are mostly related to the seamless integration of new innovative systems in existing environments. In the future new vehicles and transport systems will be introduced in urban environments. Future scenarios include the following concepts (Carlier et al 2006):

• ADAS – Advanced Driver Assistance Systems – for cars

• PRT – Personal Rapid Transit

• Advanced bus systems

• CTS – Cybernetic Transport Systems, divided in two sub-categories: “road-based people movers” and “advanced car sharing”

It is highlighted that CityMobil will focus on the three classes of innovation, which have a direct and potentially sensible impact on “urban transport” – i.e. PRT, Advanced Bus Systems and CTS - while ADAS for cars, whose application is not specific to the urban context, are considered as a complementary technology to the other new urban transport concepts. The vision of CityMobil includes both systems supporting a driver and systems without a driver taking part of the control system of the vehicle. Some of these systems require adapted and customized vehicles among the following categories:

• Cybercars: Small autonomous vehicles for individual or collective transportation of people and goods, for specific areas such as city centres with little or no interaction with other (manual) vehicles

• High-tech buses: Buses on rubber wheels, operating like a tram on lanes with a light infrastructure using electronic guidance either for automation or for driver assistance

• Personal Rapid Transit vehicles (PRT) : Small fully automatic vehicles operating on guide ways to segregate them from pedestrians and other traffic

• Advanced city cars: New city vehicles integrating zero or ultra-low pollution mode and driver assistance such as ISA (Intelligent Speed Adaption), parking assistance, collision avoidance, stop&go, etc.

• Dual-mode vehicles: Developed from traditional cars but able to support both fully automatic and manual driving. Dual-mode vehicles represent the migration path from traditional vehicles to automatic driving

The different vehicles can be introduced and combined in innovative transport systems, which have been the issues in several EU projects, such as STARDUST, EDICT, CyberCars and CyberMove. This is shown in Table 2.1.

Table 2.1: Characteristics of different system’s use of vehicles and infrastructure

Driving mode\ Infrastructure:

Public Roads Segregated roadways

Driver operated vehicles Advanced city cars High-tech buses Dual-mode vehicles

D.2.5.1 Certification procedures for automated transport systems xi

Automatic vehicles Cybercars PRT Cybercars

The systems differ in focus group and degree of public management. Advanced city cars are seen as an extension of private transport, while PRT systems are a development of public transport. Systems based on cybercars falls somewhere in between these two. All three principals will be shown within the three main demonstrations:

• The Heathrow demonstration consists of a PRT system named ULTra, which is a system of small vehicles running on tracks without conflict with other traffic between the passenger car park and terminal areas.

• The Rome demonstration consists of cybercars running between a new exhibition building and the nearest train station and a parking lot. The cybercars will run in a closed system without conflicts with external traffic, but will consist of several vehicles. This requires good vehicle-to-vehicle communication.

• The Castellón demonstration is based on guided buses/tramways. The bus will be on rubber wheels, electricity driven, and have a reserved platform for most of its path, but will go together with other traffic on some sections of the path. The bus/tramway will have priority over all the private traffic at intersections. The system implies automatic steering of the vehicle for part of the route to minimize lateral movement, saving road space.

Legal and administrative issues will be exemplified by how the different demonstrations have addressed these questions. In addition the cities in the Reference Group will be asked to fill out a questionnaire, see section 5 for more details. Introducing innovative transport systems in an urban environment is a challenging task. A number of barriers are hindering full scale introduction, and in the following these barriers are discussed in a more general way.

2.1 Technical barriers

2.1.1 Systems safety and reliability There are a number of technical barriers relating to advanced urban transport systems. The importance of the functioning of the system as a whole, and of individual components within it, should be strongly emphasized. Technical barriers relate to the actual functioning of any proposed system;

• System robustness

• System reliability

• System capacity

• General fitness for purpose

Technical barriers appear in two different categories; safe design and safe interaction.

D.2.5.1 Certification procedures for automated transport systems xii

Safe design: includes that the passenger or others should not be harmed by the design of the system or its components.

• Sensors; do the sensors detect obstacles of different kinds at a satisfactorily level? For fully autonomous vehicles this is a crucial factor, which has strong implications on safety.

• Vehicles; are the vehicles functioning as expected and has it adequate safety equipments?

Safe interaction: means that the passenger should be safe using the vehicle in ordinary transport. The importance of this part increases with interaction with other traffic; from no interaction with other traffic (separated traffic) to full interaction (mixed traffic).

• Actions; are actions like for instance navigation and collision avoidance performed adequately and as expected?

• Communication; is the communication between involved parties functioning? This includes users, vehicles, sensors, infrastructure, control central, etc.

It is important that all these elements meet the requirements, and that the system is able to meet the various regulations and standards under which the system would have to operate (for instance weather conditions, mixed traffic, different user groups, etc.) The extent of interaction with other traffic increases the need to place the responsibility for the system. With ordinary vehicles the driver has most of the responsibility. As the driver gives up his or her control over the vehicle to a system, it would be natural to hand over the responsibility to the system as well. In certain concepts there are no drivers, and then the system should take over the responsibility. No matter how compelling demonstrations at the testing and prototype stage may be, it is only when a complete system is working as intended in normal public use that one can be sure of its quality and reliability of operation, and what its outturn construction and operating costs are.

2.1.2 Harmonization and standardization Lack of harmonization between countries and standardization can be an important barrier against large-scale introduction of advanced transport systems. This goes for both system design, involved vehicles and components, and legal framework. Introducing advanced and innovative systems might involve high costs, which represents an investment barrier in addition to other barriers. However, a high degree of standardization and harmonization could imply lower costs and therefore contribute to increased acceptance to such implementations. Adaptations and development could be both time consuming and costly. If existing transport systems are based on local and specialized technology, the need for adaptation will be significant and costly. Thus, lack of standardized and harmonized systems and legal framework can represent barriers, which complicates and hinder the introduction in new cities and countries.

D.2.5.1 Certification procedures for automated transport systems xiii

2.2 User related barriers In many aspects the user related barriers are linked to the technical barriers presented in section 2.1.1. Thus, the present section will overlap thematically to a certain degree.

2.2.1 Societal barriers Both the authorities and public have barriers against different advanced and innovative transport systems for various reasons. This manifests itself through investments resistance and lack of general user acceptance in the systems. The barriers can be summarized in the following categories: Authorities

• Operational level scepticism

− Is there someone who can operate and administrate, perhaps also finance, the system in a viable way?

− Can the system coexist with other local transport systems and other traffic? − Is the system vulnerable for specific weather conditions?

• Strategic level scepticism

− Will the system solve all or some of the problems they were intended to, for instance congestion problems, safety levels, pollution?

• Technological level scepticism

− Will it work technically? − What are the consequences if the technology fails?

General Public

• Personal level scepticism

− Would drivers and passengers feel uncomfortable using a system, which replaces their full control of the vehicle?

− Will all user groups, regardless of their cultural background, driving experience, etc., manage to use the systems as intended?

• Society level scepticism

− Would the investment in new systems have a positive or negative impact on the growth of Gross Domestic Product (GDP) (also discussed in Sessa et al. 2007)?

− Would the automatic system replace some of the existing workforce, leading to unemployment?

Findings from the Cybermove project support this (Stardust 2003). In the study findings suggest that public acceptability of automated motorway systems in the future will improve if:

• the system is proved 100% fail-safe

• it is easy to get on and off the motorway safely

• the system operated as a toll – drivers who want to use it have to pay for it

• the infrastructure is made available at no cost to the motorist

• the system was demonstrated and tested on a section of the motorway

D.2.5.1 Certification procedures for automated transport systems xiv

There is a need to determine the implications of the these systems in mixed traffic with a mixed population of drivers - some of whom are going to be well informed, some of whom already have surrendered a part of their control and others who are not. Therefore, this leads to a problem of unpredictable driver behaviour, which could ultimately lead to a reduction in safety. It is of crucial importance to reduce the public acceptance barriers in order to obtain the fully potential of the new systems. This requires an extensive use of the new systems, and thus a substantial reduction of private car use.

2.2.2 Security and privacy One of the issues that are often connected to unmanned transport systems is that of security. In times like the present where vandalism and terrorism are issues that cannot be left without consideration, the security issue should be addressed. Security and safety issues involve both personal safety of persons being transported by an unmanned system, and issues like the possibility that a terrorist uses the system to transport bombs to a busy urban centre. With the risk that the systems could be exposed for terrorist attacks, a surveillance system would be anticipated. The acceptance level for surveillance systems among the general public is probably higher as people get used to is (and after some international disreputable terrorist attacks), but it raises questions of privacy for the passengers. This could represent an important barrier due to existing legal framework, which might hinder the approval of identifying individuals. It could also represent a barrier from a user perspective, due to their resistance against being kept under surveillance. Provided a system of surveillance and collection is introduced, implying registration of personal data, it is necessary to treat the data with concern and respect for the users’ privacy. Individuals’ trust in the system and their confidence on how the data is treated is of great importance.

2.3 Organizational barriers

2.3.1 Institutional A transport system involves numerous institutions, both public and private, each with their own set of interests. Thus, conflicts of interests might be at hand. This is the situation for conventional transport systems, and would indeed be a challenge with advanced innovative transport systems. Many transport innovations fail because the interests of different institutions cannot be reconciled, leading to inability to implement. Both public and private parties can initiate concept studies and implementation of new system, and both parties can operate the system. Some systems are based on parallel operations of public and private parties, while other systems are based on a level-based distributed responsibility. Thus, the roles and responsibilities of the public and the private sector might be undefined regarding advanced transport systems. This could be a barrier to large scale implementation. Private actors benefit from economies of scale. Thus, when entering a new market of advanced transport systems, these parties require activities at a viable extent. This can represent a conflict with other transport systems, due to the competition, typically between the conventional and the new systems. If new systems are not adequately integrated with

D.2.5.1 Certification procedures for automated transport systems xv

other existing modes of public transport, there is a risk of commercial competition between operators with winners and losers. The various presidential, national, federal and local electoral cycles mean that there may not be a neutral period in which schemes can be developed and implemented away from the political spotlight. There is therefore a requirement for innovative transport schemes to be promoted by a single layer of government, on the basis of an electoral mandate, which offers a realistic time period for scheme development (Netmobil 2004). Local engagement of the stakeholders will improve ability to implement new transport systems. This engagement will probably increase in line with the degree of customization and adaptation of the planned system. This could represent a barrier to large-scale implementation, due to the request for standardized and harmonized solutions (cf. section 2.1.2). These barriers increase with the risk of negative media coverage, both for local private actors and politicians.

2.3.2 Impacts on city image Installation of a new and advanced transport system might have negative impacts on the visual appearance of the city. This could be due to the system’s degree of “futuristic appearance”, space consume, mismatch with architectonical style of historical city centre, noise, etc. City image can be related to an existing transport system, e.g. the cable pulled tram in San Francisco. Introducing a new system can thus interrupt a city image in a negative way, even though the system itself is regarded as not being visual intrusive. The design of vehicle and infrastructure would have to be complementary to the aesthetics of historic buildings, and help maintain the city’s identity. A pilot system should prove effectively and not being visually intrusive. However, if a pilot proves wrong, this could represent a significant barrier for ability to a full-scale introduction in other cities. The impact of innovative transport systems on local businesses would largely depend on the success of the system. If they deliver all that is promised, it could have a huge positive impact for city and town centres and the businesses located there. It could also bring potential benefits in encouraging redevelopment and new buildings in focal centres that would be positive for existing business. However, on the other side, the failure of a scheme would cast an extremely negative view on a town or city (Netmobil 2004).

2.3.3 Project organization and management Clearly, successful implementation of any new transport system will largely depend upon how well the project is organised and managed. It is important here that the project has clearly defined objectives and expected outcomes, with which all members of the project team have the same understanding. Here it is essential to involve specialist project managers with a track record of innovation, who may have useful expertise to import from elsewhere. Experience in innovative technologies is important. This is however not always present in municipal authorities, and represents a barrier against successful implementation of the

D.2.5.1 Certification procedures for automated transport systems xvi

system. Such negative experiences would have effect for following cities and is therefore a barrier against full-scale introduction.

2.3.4 Financial and commercial Financial risks relate to robustness of cost/revenue forecasts and the likelihood of future financial viability and of obtaining funding for implementation. There may also be difficulties in constructing robust forecasts for innovative systems. Additionally there may be problems of “believability” even if it can be demonstrated that forecasts are robust. This may belong partly in the political category. Potential solutions to the financial barrier, as identified in TRANSPLUS (2003) might include Public-Private Partnerships (PPP) and financial restructuring. A PPP is essentially a relationship between actors, which may be used in situations where the respective authorities lack the resources (e.g. financial, organisational, knowledge, skills) to overcome delaying and or hindering implementation. Cities in member states such as the UK where there is now a strong emphasis on PPPs may be more comfortable with such an approach than cities with a tradition of public sector ownership (Netmobil 2004). Financial Restructuring refers to the adaptation of existing financial structures or creation of new structures. It applies where the financial structure is hindering the processes of design/planning and implementation. This seems to be the case in situations where municipalities are competing with each other for financial resources.

2.4 Legal regulations and liability Legal and liability barriers can relate to compliance with existing regulations. In the STARDUST project Stolker en Van Wees (STARDUST 2003) identify three topics for which special legal attention must be paid: appeal to circumstances beyond the drivers’ control in ADAS-related accidents, the position of the governments as road authorities, and the position of the government as lawmaker. The “government” in the first case refers to the national, regional and local governments of Europe, in contrast to the lawmaking apparatus, which is being harmonised at the European level. The liability of the driver is an important aspect in Stolker and Van Wees (op.cit). Situations can be imagined in which for example the ADAS system is dependent on communication with other vehicles or the infrastructure. If the driver claims that an aspect of the ADAS communication failed in some way, legal cases could be quite difficult. Proof or reasonable proof of failure (or non-failure) must be established. The liability of road authorities is not mentioned in the STARDUST project. However, there are some crucial issues, for example the liability for roads that do not meet the requirements that reasonably can be expected for such roads. This liability does not limit itself to the asphalt itself. Road equipment also falls under liability. Any ADAS that in some way falls under road equipment, regardless of who put it there, is the liability of the road authority. ADAS that make use of satellites create another scenario. Signal reception can be influenced by the road itself or structures along the roadside. Norms for the performance of these systems for roads are being developed. Roads, which do not meet these norms, face a substandard classification, requiring warnings to drivers of the substandard situation (Netmobil 2004). These examples illustrate that legal regulations and liability might represent a barrier against full-scale introduction of advanced systems, especially driver-less systems. Thus, the legal

D.2.5.1 Certification procedures for automated transport systems xvii

regulations must be adjusted and supplemented to fulfil the needs related to operate an advanced transport system. An overview of existing standards, legislations and guidelines is offered in section 3, followed by a plan for making such adjustments and supplementations.

2.5 Barrier examples In the Netmobil project, a number of barriers were identified (Gallais and Wagner 2004). Some of these are already mentioned in the text above. The barriers with examples are listed in Table 2.2.

Table 2.2: Barriers identified by Netmobil

Barrier Significance for NETMOBIL Example

Engineering difficulties High for PRT, low for CyberCars

Specific technological problems

Varying PRT vehicle range limited by battery technology

Political process High for schemes needing capital investment

AHS systems may be considered to be politically sensitive since drivers relinquish control of private vehicle

Opposition from traders High where land-take reduces parking

Opposition from residents High where infrastructure results in environmental impact

Industrial Action Significant concern where drivers are to be eliminated, but should not be insurmountable

Driverless public transport has been accepted in UK (DLR) where service staff is employed. PRT may raise concerns with Unions

Lack of User Acceptance Likely to be high where there is a perception of dependence on IT solutions for safety

Some trains on London Underground are suitable for driverless operation but drivers are retained, partly to reassure passengers

Legal obstacles At domestic level systems may need to comply with Health and Safety regulations which may be inappropriately specified

In UK, PRT is classified as a railway and subject to HM Railways Inspectorate approval.

New modes may require definition of new safety devices, signs etc

Lack of funds Start-up costs will be high for new mode, but unit costs will drop as market grows

AHS solutions will require driver investment but may reduce the need for construction

Schemes such as the Parry People Mover have been widely studied in the UK but have failed to develop a market to enable cost-effective production

Operational problems Innovative mode may not function in full-scale implementation

MAGLEV people-mover at Birmingham Airport proved unreliable and was abandoned

Complexity of interaction Innovative modes may not fit easily within

D.2.5.1 Certification procedures for automated transport systems xviii

between institutions defined institutional structure

3 Existing standards, legislations and guidelines The majority of the text in this section is based on Uwland and van Dijke (2002). In principle everybody is free to follow the requirements set out in standards and guidelines and in principle there is no obligation to meet these requirements. Standards and guidelines only become obligatory when laws refer to those standards and guidelines. Basically standards and guidelines are documents in which requirements for products and processes are given, for instance with maintaining a certain quality or safety level as the objective. Standards are being published by organisations that have a certain interest in maintaining quality of safety standards. These organisations can be authorities, societies of producers or groups of experts in the same discipline. Laws are usually made on a national level. This means that in different countries different requirements for the same product can be valid. In recent years a lot of effort has been invested in harmonising standards throughout Europe and even on a world-wide scale. Taking away trade barriers is an important driving factor for harmonisation of standards and guidelines. Harmonised standards ease the comparison of products and enable a fair comparison of products with regard to quality and safety. In the European Union harmonisation is making rapid progress in some fields, while it is still in its infant stage on other fields. For instance, in the whole of the Union the requirements for road vehicles are the same, and a road vehicle that is approved for use on the public roads in one of the countries of the Union, is automatically approved for use in all of the countries. The requirements for road vehicles are laid down in European Directives. On the basis of European treaties these Directives are part of the national laws of all of the countries of the union. In rail traffic matters have not progressed that far. At present there is only one Directive, with requirements for high-speed trains (that are often border crossing). With the exception of this directive, there are no international agreements about harmonised requirements for rail vehicles. This means that each country in the Union can and does make its own laws and standards. However, there are certain standards that are being observed on a voluntary basis by a growing number of countries.

3.1 Current practises for approval of advanced transport systems The chance of success of an implementation project could be enhanced if national governments play a facilitating role. There is a need for vision and policy for system innovations and a more clear-cut strategy for the selection of innovations. The national government should not only facilitate the compilation of development plans but also their implementation. There are considerable synergies to be exploited between the public and private sectors including car manufacturers, infrastructure providers, public authorities and the end users. For example, where the road infrastructure is substandard and not managed by the highway authorities, there are a lot of safety problems, which could be solved by the types of systems

D.2.5.1 Certification procedures for automated transport systems xix

which have been deployed in Japan (Smartcruise 21). This raises issues concerning equipping the infrastructure (e.g. communication sensors, maps etc) so that these synergies can be exploited. Questions asked to the partners in the CyberCar project as to the current practises for approval of cybercars gave varying results. The only constant was that it is unclear what exactly the legal requirements for cybercar systems are. Authorities are wrestling with the matter as well as the manufacturers and other parties involved. This shows again that there is a real need for formal certification procedures and guidelines that can provide a reference for all parties involved with cybercar systems. A number of examples are presented in the following:

• Rivium People Mover; The Netherlands. The certification of the first generation of people movers did not raise a special issue. The new track built for the project was declared 'private road', which meant that the vehicles did not have to meet the rules for vehicles on public roads. The company that operates the people mover applied for and received a special waiver under the Public Transport Law to have the system function as a public transport system. Since the law was declared applicable to the system liability was arranged in line with a 'normal' bus system

• Serpentine; Lausanne, Switzerland. The Serpentine system should have been in operation in 2001. Already in 1990 a request for a licence to operate the system was made, at which time the system was classified as a 'railway' system. At the time the authorisation for the first experiments was applied for, the system was classified as a 'trolley bus'. The infrastructure (the patented magnetoglisseur system) is subject to the railway regulations and the vehicles are subject to road traffic regulations. This last requirement makes the system subject to the European Agreements (signed by Switzerland) that require a driver to be present in a vehicle.

• Various Cycab systems; France. Drive-by-wire systems like cybercars are not (yet) allowed on public roads in France (and elsewhere in the European Union). On private roads cybercars are considered machines. Some cybercar systems produced and supplied by Robosoft have been audited by an independent organisation (APAVE) to show compliance with the Machinery Directive (98/37/EEC) and the European EMC and low voltage requirements.

• RUF system; Denmark. The developments are not yet such that formal approval has to be applied for. However, there are plans to contact the railway authorities in Denmark to discus the concept.

• ULTra United Kingdom. Two major demonstrations have been made at the Cardiff trials site of key capabilities of the ULTra system. These tests are maintenance of headway and station operations, and follow on a previous demonstration of the Automatic Vehicle Protection system. Thus, all of the key aspects of the technology of the ULTra system have now been demonstrated. Approval to operate a public transport system such as the ULTra system in the UK is granted by Her Majesty's Rail Inspectorate (HMRI). Because of the novel nature of the ULTra system, a set of specific approval procedures has been developed with HMRI. The approval procedures include four different approaches, a preliminary hazard analysis and risk assessment, an assessment against the Railway Safety Principles, an assessment using Goal Structuring Notation (GSN) techniques and preliminary failure modes and effects analysis. These safety assessments indicated that there are no features inherent in the current design definition and operating procedures that would indicate that the ULTra System, once applied, would be unsafe.

D.2.5.1 Certification procedures for automated transport systems xx

3.2 Existing safety standards The standards and guidelines that have been studied mainly focus on safety requirements. Requirements for the use and maintainability of systems have not been made part of the work.

3.2.1 Specific standards for automatic guided vehicles There are only a few existing dedicated standards for fully automatic guided vehicles. When no dedicated standards are available vehicles are subject to the requirements of more general standards, like the Machinery Directive or the Directives for road vehicles. In Europe CEN EN 1525 is used. This standard contains safety guidelines for industrial driverless trucks and their systems. In the US the Automated People Mover (APM) Standards (ASCE 21-96; ASCE 21-98 and ASCE 21-00) exist. These standards establish the minimum set of requirements necessary to achieve an acceptable level of safety and performance for an Automated People Mover (APM) system. The standards consist of three parts:

• Part 1: Operating Environment; Safety; System dependability; ATC; Audio and Video

• Part 2: Vehicles; propulsion and braking

• Part 3: Electrical; stations; guideways

The APM standards are based on the contents of MIL-STD-882C In Germany the BOStrab standard with specific guidelines for streetcars is used. There is a separate annex that describes guidelines for operation without drivers. Although this standard is only available in the German Language is widely used outside Germany.

3.2.2 Specific standards for surface vehicles on wheels If we look at surface vehicles on wheels there are several sets of laws that can be relevant, depending on the application of the vehicle. An important distinction is whether the vehicle makes use of the public road, or whether it is driving on private property. It is also important to know whether the vehicle is mechanically guided. For the purpose of this investigation, surface vehicles on wheels can be divided in the following 4 categories:

• Vehicles for use on the public road

• Vehicles for use on private grounds

• Rail vehicles (mechanically guided surface vehicles) for use on public roads

• Rail vehicles for use on private grounds

Vehicles for use on public roads Examples: cars, motor cycles; trucks busses, trolley buses, etcetera In Europe vehicles for the public road have to comply with the requirements of directives 70/156/EEC and 92/61/EEC. These directives contain requirements for the approval of motor vehicles. The directives each contain references to many detailed directives, that are all part of the approval system. There are different requirements for different categories of vehicles.

D.2.5.1 Certification procedures for automated transport systems xxi

The Economic Commission for Europe (ECE), a body of the United Nations, issues ECE-standards. Many European countries that are not part of the European Union have included ECE-standards in their law systems. The ECE-regulations exist parallel to and sometimes additional to the EEC Directives. Contrary to the EEC Directives where all countries of the European Union are obliged by law to accept the requirements, ECE regulations can be accepted by all European countries on a voluntary basis. Cybercars that are going to be used on private roads will eventually have to meet the requirements that all present road vehicles have to fulfil. The present requirements have to change, however, to allow CyberCars on public roads, for one of the implicit requirements of the present regulations is that a driver always has to be in control of the vehicle. This is not only important for safety reasons, but also from a liability point of view. In Europe, if a car is involved in an accident and the accident is not caused by gross negligence of the manufacturer, the driver is liable and the manufacturer is not held responsible. In case of CyberCars, where there is no driver, it is unclear where the liability lies. Fingers will point to the manufacturer or the operator when an accident occurs. This is a problem that could hamper the development of CyberCars, but also the development of ADA-systems (Advanced Driver Assistance) that take part of the control over the vehicle away from the driver. Since ADA systems from a technical point of view are very close to market introduction, this problem is addressed by the European automobile industry. In another European project: RESPONSE II, a code of practice for the development and manufacturing of ADA systems is being developed to enable ADA systems to be introduced.

Vehicles for use on private grounds Examples: PRT, cars, industrial vehicles The ULTra test track in Cardiff, Wales has provided the basis for evaluating many of the PRT schemes in the EDICT project (one of the NETMOBIL cluster projects) (NETMOBIL, Deliverable 1). Research into all of the legal aspects of system development will take place in Cardiff(UK), Ciampino (Italy), Almelo (Netherlands) and Huddinge (Sweden) under the variety of local legal framework. In this category we also see a variety of vehicles that are used for transport of people and goods in factories; on industrial premises and in attraction parks. There are no specific guidelines for this category of vehicles. Some of them are subject to the Machinery Directive (Directive 98/37/EEC), that contains fundamental requirements on the field of safety and health, and a list of more specific requirements for specific types of machines. The Machinery Directive, however, has a lot of exclusions:

• Means of transport, i.e. vehicles and their trailers intended solely for transporting passengers by air or on road, rail or water networks, means of transport designed for transporting goods by air, on public road or rail networks or on water. Vehicles used in the mineral extraction industry shall not be excluded.

• Special equipment for use in fairgrounds and/or amusement parks.

Means of transport for people and goods on non-public roads are subject to the requirements of the Machinery Directive. This is also true for CyberCars running on private roads. Special (transport) equipment for use in fairgrounds is excluded, however. This is why the Floriade

D.2.5.1 Certification procedures for automated transport systems xxii

people mover was certified on the basis of a Dutch national Directive regarding the safety of attractions in an amusement park and not on the basis of the Machinery Directive. For most machinery the Directive allows a system of self-certification. The manufacturer declares that his machine complies with the requirements of the Machinery Directive and affixes the obligatory CE-sign to the equipment. For certain machines a government approved homologation service has to test and homologate the system. The Directive includes a list of such machinery. Means of transport, however, are not on the list. The Machinery Directive refers to a number of harmonised standards.

Rail Vehicles for use on public roads Examples: streetcars Streetcars or trams are widely used in the larger inner cities in Europe. They often make use of the same infrastructure as other road traffic does and they do have to meet the traffic laws that govern the use of the public road. There are no harmonised standards for streetcars and metro's. Since these systems are also excluded from the Machinery Directive, they are only subject to local requirements of local authorities. This certainly is a great contrast with the very detailed regulations that exist for cars, which in some cases use the same infrastructure as streetcars do. Only in Germany there is a specific regulation, BOStrab, which is mentioned in this report, because it is also used outside Germany.

Rail Vehicles for use on private grounds Examples: trains, metro's It is remarkable that in contradiction with other modes of transport standards for rail traffic are hardly harmonised on a European level. The only European Directive is Directive 96/84/EEC, concerning high-speed trains. For other rail traffic standards only exist on a national level. In spite of attempts to harmonise rail traffic there is still a large variety of voltages; track widths and safety systems. Most of the presently known Automatic Guided Vehicle systems fall into this category. In most cases they are automatic metro systems like they are operational in Paris, but also in Chicago and on several airports around the world. The Detroit People Mover also falls into this category. Strictly spoken, also cable cars and elevators fall into this category. The limitations that mechanical guidance offer, make these systems explicitly suited for automatic guidance. The mechanical guidance decides on the route so that navigation is easy or superfluous and safety risks can be controlled easily.

3.2.3 Specific standards for electronic and computer controlled systems One of the most important differences between CyberCars and traditional vehicles is the major role that electronics and software play in CyberCars. In and outside the world of transport the role of autonomous and non-autonomous electronic control systems is growing. This growth of importance leads to an increased impact on the safety of systems. In fully

D.2.5.1 Certification procedures for automated transport systems xxiii

automatic guided vehicles the electronic control system and the software are important safety critical components. Because the electronic control system influences and is influenced by almost all subsystems (propulsion, braking, steering) it is increasingly difficult to see these subsystems as separate units. The subsystems are increasingly part of a complete system and must in safety assessments be seen as parts of complete systems. This means that in future, the focus will shift more and more from component safety to system safety. Until now the transport world has not paid much attention to system safety and the safety of automated control systems. In the aircraft industry and the process industry system analysis is standard procedure. There are a number of standards in the field of system safety. These standards are not often referred to in binding laws, but they are gaining in importance. These standards are often based on the system life-cycle and classify systems in safety classes or safety integrity levels. The most relevant examples are:

• IEC 61508: Functional safety of electrical/electronic/programmable electronic safety related systems. IEC 61508 is a generic standard, aiming at the whole width of application areas. Specific sector-oriented standards can be derived form this standard. The standard particularly addresses systems of which failures can have consequences for persons or the environment; it is less suited for establishing economic damage. IEC 61508 is a European standard and it is mainly used in Europe.

• MIL-STD-882C Safety Systems Program Requirements. Originally an American military standard that also found wide acceptance in the civil world. Comparable to IEC 61508. Often both standards are referenced in the literature.

• EN 50126 Railway Applications: The specification and demonstration of Reliability, Availability, Maintainability and Safety (RAMS). A European standard, especially developed for the rail world. Defines safety integrity levels just like IEC 61508 and MIL-STD-882C

• Software Standards Electronic control systems are almost always dependent on software. In future CyberCars software will be an important, if not the most important safety-critical component.

• The integrity of the software used shall be decisive for the safety of the complete system. Therefore software should be subject to high reliability and safety demands. A problem that immediately presents itself is that even software for simple control systems is already very complex, which makes the evaluation of software difficult. Evaluation of software safety can be carried out through tests only up to a certain limit. In a complex system it is often impossible to check all possible failure modes through testing. In the existing standards for software focus is therefore on the quality of software engineering, rather than on testing. This is based on the premises that the reliability of software will be higher, when this software is developed according to strict guidelines. Certification of software and software controlled systems will therefore probably more and more be carried out on a proven reliable and robust design and less on the basis of tests. The existing standards and guidelines are based on that principle and on the software lifecycle. This connects them with the system safety standards mentioned above.

• IEEE standards IEEE Software Engineering Standards. Consist of 4 volumes with about 50 different standards on the following fields:

− Customer and terminology standards − Process standards

D.2.5.1 Certification procedures for automated transport systems xxiv

− Product Standards − Resource and technique standards

• MISRA Guidelines Development guidelines for vehicle based software. The MISRA Guidelines are sector-specific guidelines for software development, in which reference is made to IEC 61508. They are not software engineering standards, like the IEEE standards, to which also reference is made.

• DO 178-B Software considerations in airborne systems and equipment certification. Is used by the FAA (Federal Aviation Authority) to certify software. The standard provides guidelines for the evaluation of the safety of software for aircraft and related equipment

For CyberCars especially the MISRA Guidelines and the IEEE standards seem important. The MISRA guidelines while they concern (road)vehicles and the IEEE standards because they are widely used generic guidelines.

3.3 Existing legislation Deliverable 6.1 of CyberCars project (Uwland and van Dijke 2002) provides an overview of existing standards and of topics which are missing in these standards and which are relevant for cybercars. In this paragraph the findings are summarised.

• The overview in deliverable 6.1 shows that there is a consistent and extensive set of standards for vehicles that make use of public roads. There is also an extensive number of standards for rail vehicles, although these standards are mainly nationally orientated, instead of being accepted on a European scale. For non-rail systems and systems that do not use public roads there is the Machinery Directive. This Directive, however, is not designed for means of transport and explicitly excludes some means of transport. The draft new Machinery Directive indeed excludes all means of transport

• The inventory shows that the existing standards and laws do not form a uniform and all encompassing system, not even for traditional vehicles. For instance, in The Netherlands there are no safety requirements for streetcars that operate within city limits, although these streetcars are vehicles that make use of public roads and share that road with other road users. For other rail vehicles the formal rules have a limited reach.

• The existing cybercars and those that are being developed, depending on the environment they are used in, are subject to the same laws and standards as traditional vehicles. In addition to the limitations mentioned in par. 1.4 these existing laws and standards have another limitation. The present laws imply the presence of a driver in the vehicle. The absence of a driver causes legal problems: who is accountable in case of an accident.

• The three main functions that drivers carry out are observing; analysing/deciding and transferring the decision to the vehicle systems. In a cybercar the sensors, the obstacle detection system, the vehicle controller and the different actuators take over these functions. For traditional vehicles standards on component level exist. For these 'new' components such standards do not exist.

• A cybercar system often includes a command post, from which several functions are centrally controlled. Also for such command posts no specific standards exist.

• Control software can be seen as part of these systems. The specific character of software makes it necessary to establish specific requirements. Although there are

D.2.5.1 Certification procedures for automated transport systems xxv

many standards in the field of software engineering and software development, these are at present not part of the current legislation.

• The existing standards not only list the requirements a product must meet, but they also supply binding guidelines for the construction of a product. They do not only contain performance criteria, bust also design criteria. For instance, the Directive for seatbelts has requirements that must be met by the seatbelt retractor, thus implicitly requiring a seatbelt retractor to be part of the seatbelt. Better solutions can perhaps be thought of, but the Regulation does not allow them.

The standards listed here are subject to periodic adaptations and modifications. The characteristics represent the situation as it was at the time the report was written.

3.3.1 Vehicle and machinery

Table 3.1: Existing vehicle and machinery legislation

Title Description Concern

Directive 70/156/EEC Approval of motor vehicles

On the approximation of the laws of the Member States relating to the type-approval of motor vehicles and their trailers

Motor vehicles intended for use on the road, with or without bodywork, having at least four wheels and a maximum design speed exceeding 25 km/h and its trailers

Directive 92/61/EEC Approval of 2- or 3-wheeled motor vehicles

Relating to the type-approval of two or three-wheel motor vehicles

This Directive applies to all two or three-wheel motor vehicles, twin-wheeled or otherwise, intended to travel on the road, and to the components or separate technical units of such vehicles

Directive 98/37/EEC Machinery

Health and safety requirements for machinery

An assembly of linked parts or components, at least one of which moves

EN 1050

Principles for risk analysis

General principles for the procedure known as risk assessment, to assess the risk during all the phases of the life of the machinery

Detailed instructions on how to comply with one of the requirements from the Machinery Directive

EN 1525 Safety of industrial trucks; Driverless trucks and their systems

Technical requirements to minimize the dangers related to automated functions of machinery

Self propelled trucks up to and including 10.000 kg capacity and tractors with a drawbar pull up and including 20.000 N

Response 3 European code of practice for ADAS

The IP PReVENT subproject, RESPONSE 3, is elaborating a European Code of Practice for an accelerated market introduction of Advanced Driver Assistance Systems (ADAS). The Code of Practice will help manufacturers to “safely” introduce new safety applications through an integrated perspective on

A comprehensive insight into the legal barriers still surrounding ADAS. Proposition of the next steps towards evaluation and adoption of the Code of Practice at European level.

D.2.5.1 Certification procedures for automated transport systems xxvi

human, system and legal aspects.

EFAS German StVo §1, §7 and § 20 Platooning of commercial vehicles

Operating license of advanced driver assistance systems in commercial freight transportation. Liability of owner and manufacturer of the vehicles.

System of trucks with advanced driver assistance systems allowing trucks to follow each other in short distances electronically. The assistant consists of lateral guidance and velocity- and distance control.

3.3.2 Road infrastructure No relevant road infrastructure legislations have been identified in this review.

3.3.3 Rail infrastructure

Table 3.2: Existing rail infrastructure legislation


EN 50126 Railway applications

The specification and demonstration of Reliability; Availability, Maintainability and Safety (RAMS)

All railway applications and all levels of such an application

At all relevant phases of the lifecycle of an application

For use by railway authorities and the railway support industry

BOStrab Strassenbahn Bau- und Betriebsordnung (Germany: Streetcar building and operating procedures)

Instructions for the construction and operation of streetcars systems according to par 4. of the German law for transport of people (PBeFG)

Strassenbahnen (streetcar systems; not being railroads)

BOStrab Vorläufige Richtlinien für den Fahrbetrieb ohne Fahrzeugfahrer (Germany: Preliminary guidelines for operation without driver)

Specific Instructions for the operation of streetcars without driver

Operations when no driver is present

On independent tracks (par. 1.2.2 BOStrab):

• no crossings • safety space according

to BOStrab par. 19 next to each platform

• getting in and out of the vehicle on a level plane

D.2.5.1 Certification procedures for automated transport systems xxvii

3.3.4 Encompassing systems

Table 3.3: Existing encompassing systems legislation


ASCE 21-96 and 21-98

Automated People Mover Standards

Minimum set of requirements necessary to achieve an acceptable level of safety and performance. Includes minimum requirements for the design, construction, operation and maintenance of APM systems.

Three parts: Operating Environment, Vehicles and Electrical

APM's; a guided transit mode with fully automated operation, featuring vehicles that operate on guideways with exclusive right of way

IEC 61508 Functional safety of Electrical/Electronic/Program-mable Electronic safety-related systems

Part 1: General requirements

Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems

Part 3: Software requirements

Part 4: Definitions and abbreviations

Part 5: Examples of methods for the determination of safety integrity levels

Part 6: Guidelines on the application of parts 2 and 3

Part 7: Overview of techniques and measures

Parts 1, 3, 4 en 5 already exist; the others still have to follow

MISRA; Development guidelines for vehicle based software

8 extensive reports and a set of guidelines. Sector-specific guidelines for software development. As such more specific interpretation of IEC 61508-3. The MISRA guidelines, however, are not guidelines for software engineering

DO 178-B Software considerations in airborne systems and equipment certification

Provides guidance for determining, in a consistent manner and with an acceptable level of confidence that the software aspects of airborne systems and equipment comply with airworthiness requirements.

Is used by FAA to certify

Airborne systems

D.2.5.1 Certification procedures for automated transport systems xxviii

computer software


IEEE Software Engineering Standards

Software engineering

IEE Guidelines for the documentation of computer software

EFAS German StVo §1, §7 and § 20 Platooning of commercial vehicles

Operating license for driver assistance system. Liability of the manufacturer of the system.

System of trucks with advanced driver assistance systems allowing trucks to follow each other in short distances electronically. The assistant consists of lateral guidance and velocity- and distance control.

3.4 Certification procedures A report from Workpackage 6 of CyberCars: “Report on existing guidelines” describes the results of a survey of existing standards and guidelines that could be relevant for the future certification of CyberCars. The report focuses on the certification requirements for the vehicles as such. Requirements for the environment in which the vehicles will have to operate are subject of an alternative project CyberMove (van Dijke and Janse 2004), which will be presented in the following.

3.4.1 Certification of road vehicles Traditional vehicles that use public roads have to meet a large number of requirements laid down in standards and regulations. Most of these standards and regulations are related to safety but there are also standards on pollution, recycling of material and many other subjects. The sheer number of standards limits the car developers in their innovations. But the standards also give the developers guidance on how to create safe and reliable vehicles. When they develop new vehicles the manufacturers know the limits within which they have to stay in order to have their vehicle certified for use on public roads. Traditional road vehicles are meant for use on public roads. These public roads represent a system to which a very strict set of rules, that we call traffic regulations applies. Vehicle manufacturers develop their vehicles not only to meet the certification standards mentioned above, but also to fit into that system of traffic regulations. The system is so much a part of our daily lives that we do not even realize how rigid it is and which limitations it presents. One of the reasons for this lack of criticism is that the system fits its purpose. Everything is well arranged; all road users more or less adhere to the rules; everybody heading in the same direction drives on the same side of the road, we give way to vehicles that have preference over our own, we stop for red lights and in general we reach our destinations safely and within a reasonable amount of time. So when a car is certified the environment in which it is to operate is not explicitly considered. That is not necessarily because it is an implicit part of the vehicle design that the vehicle will operate in the very rigid environment of our public road system. This however is different for Cybernetic Transport Systems.

D.2.5.1 Certification procedures for automated transport systems xxix

3.4.2 Certification of vehicles not meant for public roads In contrast to the extensive set of certification standards for traditional vehicles, there are hardly any rules for vehicles that use private grounds or for vehicles that do not fit into the categories of the European Directive 70/156/EEC. This means on one hand that manufacturers have a large amount of freedom in designing their systems, which creates room for innovative solutions. On the other hand, however, manufacturers and operators run great liability risks in case something goes wrong with their systems. Operators and authorities will be reluctant to introduce innovative systems if there is no objective judgment possible on the safety of such systems. An objective judgment is only possible if it can be proven that a system meets generally accepted standards.

Thus, the absence of generally accepted standards puts up barriers for the introduction of innovative transport concepts like Cybernetic Transport Systems. So, on the one hand there is a need for standards and regulations that offer guidance to manufacturers for the design of their systems and give authorities and operators certainty about safety of the system. On the other hand rules and directives should leave room for innovative concepts and limit the manufacturers as little as possible in making design decisions. Deliverable

In the CyberCars project, van Dijke and Uwland (2004) describe the requirements for certification procedures for Cybercars and proposes a method to establish acceptable safety levels and to analyze a Cybernetic Transport System in order to find out whether or not it meets the requirements.

4 How to work on safe sites and systems This chapter provides the theory of both the Risk Reduction Methodology and the System Safety Analysis (van Dijke and Janse 2004). In combination these methods form a framework for comprehensive safety assessment.

4.1 General If city authorities want to make a decision as to whether or not a Cybernetic Transport System is a viable option to fulfil their specific transport needs, they need to be assured that this innovative transport concept in an existing urban setting is safe. The report presents a two step approach to obtain such an assurance: a Risk Reduction Methodology combined with a System Safety Analysis. It is not sufficient to certify the vehicle and vehicle-related systems, because of the interaction of the vehicles-without-driver with the environment. This is not the same as for standard cars. The complete environment of the Cybernetic Transport System has to be taken into account. In the first step the Risk Reduction Methodology has to be applied to make a risk analysis of the environment and the proposed Cybernetic Transport System in the pre-design and design phase, suggesting appropriate measures to prevent accidents and/or mitigate the effects of accidents. In the second step a System Safety Analysis has to be applied to assess the results of the design phase and evaluate the safety of the site and system at the start of the development & construction phase.

D.2.5.1 Certification procedures for automated transport systems xxx

Figure 4-1: Project phases and focus on safety assessment

A future final step would be a certification. But since the procedure described in the report is not yet a formally accepted procedure and since there are no other formally accepted procedures available, formal certification is not yet possible. However, until formal certification is possible, the procedure can be used for self-certification of the Cybernetic Transport System, thus providing the best possible guarantee that safety has been a major concern during the design and development of the system and that all reasonable measures have been taken to assure that the system is safe.

4.2 Risk reduction methodology The Risk reduction methodology starts long before a decision to implement a Cybernetic Transport System is taken. In order to decide whether a Cybernetic Transport System is a viable option from a safety point of view, an analysis of the risks of having a Cybernetic Transport System at this specific site must be carried out. This analysis gives an impression of the risks that the transport system imposes on users and non-users, and on the operator of the system itself. It must be clear that there is a big difference in estimating the risks of new transport systems and of existing ones. With existing transport systems there is a lot of experience related to (un)safety and more than enough statistical evidence to ground this. But with innovative transport concepts like Cybernetic Transport Systems, this is not the fact. Above this, to be accepted by the public no unsafety at all will be tolerated. The results of a risk analysis can be used to work on the safety of the site and the transport system, adding measures to reduce these risks and/or mitigate the effects of any incident. Examples of safety measures are:

• fences, to protect bystanders from being hit by vehicles; and/or

D.2.5.1 Certification procedures for automated transport systems xxxi

• driving at a lower speed to lower the risk of encounters and mitigate the effects of accidents.

If we elaborate on these two examples a little further, some predicaments are easy to see: fences around the track may block people on their shortest way to a destination, forcing them to make detours; and enhanced safety because of lower speeds makes the transport system less attractive for users with high values of time. Therefore the choice of risk reduction measures always seems to be subject to some kind of cost-benefit analysis, looking at safety aspects at the one hand and all other interests at the other. Applying the Risk reduction methodology is a relatively small effort, so it should be recommended to use this method for each pilot site with a Cybernetic Transport System, whether permanent or on a temporary basis for the purpose of demonstrations. Whenever a Cybernetic Transport System is going to be implemented at a site without day-to-day human supervision, it is necessary to carry out the next steps as well and go for the System Safety Analysis. The Risk reduction methodology was introduced in the CyberMove deliverable 3.1 and has –more or less explicitly - been used in pre-design and design phases of the feasibility studies and field trials of the CyberMove demonstration sites. From this work, a threefold conclusion is derived:

• A quantitative add-on is necessary at the beginning of the development & construction phase;

• There is a complementarity of in-vehicle and infrastructure safety aspects to be balanced any place on the track, anywhere on the trip;

• Both preventing an incident and mitigating the effects of an accident seem to be useful perspectives in the choice of safety measures.

To reduce the risks of delays, breakdowns and accidents a risk analysis and reduction method has to be applied. A risk analysis method is defined as the systematic way of recognizing and evaluating the risks of a technological activity, which implies a systematic enumeration of the likelihood of unwanted incidents, connected to the nature and the severity of the damage which is the result of the incident. The risk depends on two factors:

• the likelihood of an unwanted situation, and

• the severity of the unwanted situation.

Note that this implies that risk reduction can be achieved either way by reducing the likelihood of incidents and by reducing the severity of accidents. To analyze the risks and to come up with appropriate measures, we have to analyze the situation in which the Cybernetic Transport System is applied. We follow the next steps:

• Create a risk profile both of the site and the Cybernetic Transport System; and

• Indicate the types of risks and present precautionary and/or mitigating measures

The Risk Reduction Methodology always focuses on the interaction between the site and the system. In the risk profile we describe the site and the system, including possible initial safety

D.2.5.1 Certification procedures for automated transport systems xxxii

measures. Together, these elements form one simple equation: if a Cybernetic Transport System causes safety risks, measures should be taken to mitigate these risks. Risk reduction can be achieved both by reducing the likelihood of incidents and by reducing the severity of accidents. Risks can be reduced by going step by step through the process of preventing an incident and/or mitigate the effects of an accident. Accordingly, step by step risk reduction measures can be split in 5 categories presented in Figure 4-2.

Figure 4-2: Step by step risk reduction

4.3 System safety analysis The Risk Reduction Methodology supplies qualitative information about safety. The risk reduction measures that are suggested will make the system safer, but it is not possible to decide whether or not the system is "safe enough". In order to establish this, a safety indicator must be established and an analysis must show whether or not the system meets that indicator. Thus a System Safety Analysis is a quantitative method that results in an objective judgment about the safety of the system. This situation mirrors that of traditional vehicles on public roads that have to meet safety criteria to be allowed to use public roads. Such an objective judgment is important to convince stakeholders like city authorities and operators that the system's safety is state-of-the-art and meets all current criteria. Depending on the type and size of the system one ore more analyses can take place during the development & construction phase. The final stage in the process is an analysis that can be the basis for formal certification. At present there are no formal standards on the basis of which formal certification can take place, but such standards are under development.

D.2.5.1 Certification procedures for automated transport systems xxxiii

Compliance with these "standards under development" at least prove that safety has been a continuous issue during the development process and that the result meets the most current views on what is needed to make a system safe. As the basis for the analysis method the Failure Modes, Effects and Criticality Analysis (FMECA) was chosen. The FMECA has the advantage that it is extensively used in the vehicle industry and that most developers have either heard of it or have contributed to one. The FMECA is not the only analysis tool that would be suitable. It was considered to add other techniques to the method. That would increase the accuracy of the result but it would have an adverse effect on the user-friendliness of the method and especially on the time consumed with an analysis. In a typical FMECA a group of 4 - 5 people use their knowledge and experience to systematically list all possible failure modes of the system to be analyzed. Then the causes and effects of these failure modes are established and the severity and likelihood of the effects are rated. Whether or not the result is reproducible depends on the knowledge of the participants but also strongly on the strictness with which the procedure is being followed. Essential in this respect is the system definition that precedes the actual FMECA. A complex system like a Cybernetic Transport System is divided in a number of subsystems that are analyzed separately. It is essential that it is clear to all participants what the boundaries of a system are. When the systems to be analyzed are clearly defined a function analysis should provide all possible functions that the system performs. These functions are the basis of the FMECA, where a failure is defined as a failure to perform a certain system function.

Figure 4-3: Overview of the system safety analysis process

Preparation

Collect info

Form a group of experts

Define systemboundaries

Divide in subsystems

Add comments

Addrecommendations


Definesafeguards

Define effects

Make report

Drawconclusions

Define causes

Establish safety criteria

Define allsystem functions

Make Passportdiagrams

Define failure modes

System def &function analysis FMECA

Conclusions& reporting

SystemSafetyAnalysisprocess

D.2.5.1 Certification procedures for automated transport systems xxxiv

5 Further work plan The result of the review phase is an overview of existing regulations and procedures and barriers that stand in the way of the large-scale introduction of automated transport systems.

The document review has identified some black holes, which we should fill in order to answer the overall question in work package 2.5. Thus, it is necessary to do some more research regarding existing legacies. This will be done by carrying out a survey among the demonstration host cities and the Reference Group cities. The survey will carried out as a part of task 2.5.2 and will be based on a postal questionnaire.

In the following phases of the project, the results of the review phase will be used to define, which actions need to be taken to fill in the gaps in the existing framework of rules and regulations and what actions should be taken to minimize the impact of the barriers that were identified. The focus will be on certification procedures, legal barriers and guidelines for safety, security and privacy, since these appear to be issues that are relevant to all cities and sites. It is more difficult to address specific issues that are only applicable to one or a few cities or issues that have a relation to national requirements

In Task 2.5.2; definition phase, an overview will be made of the actions that need to be taken with regard to these issues and in Task 2.5.3; production phase, the actions defined in task 2.5.2 will be executed where possible and regulations and guidelines will be drafted or adapted where necessary.

5.1 Task 2.5.2, definition phase In Task 2.5.2 the following activities will be carried out: Additional survey addressed to demonstration host cities and the CityMobil Reference Group cities. Discussion and decision on: • The required certification procedures in order to guarantee that automated systems will

be safe for use • How to address the legal barriers that prevent the large scale implementation of

automated transport systems • Which general guidelines for safety, security and privacy are necessary to protect the

public in case automated systems are implemented on a large scale

5.2 Task 2.5.3, production phase In Task 2.5.3 the actions that were defined in Task 2.5.2 will be carried out. Existing certification procedures will be adapted to meet the requirements set out in Task 2.5.2. If needed new certification procedures will be drafted. If needed new guidelines for safety, security and privacy will be drafted and discussed. The main objective is to have a set of procedures and guidelines available at the end of phase 1 of the project, which can be applied to the demonstrations and reference group cities in the later phases.

D.2.5.1 Certification procedures for automated transport systems xxxv

It is not likely that the legal barriers that exist will easily be removed. It is more likely that this will be a process that will take years. The goal is to develop strategies that will result in a firm step towards final removal of these barriers. The activities will generally be on a European scale and should include actions to increase the awareness of the European lawmakers and regulating bodies of the existence of a new mode of transport and to motivate them to take first steps towards formal acceptance.

D.2.5.1 Certification procedures for automated transport systems xxxvi

6 Sources

6.1 Reference List Van Dijke, J. and Janse, M., 2004. Safe sites and systems. Deliverable 3.2 from the Cybermove project. Van Dijke, J. and Uwland, J.J., 2004. Safety standards for cybercars. Part 2: Recommendations for certification procedures. Deliverable 6.2 from the CyberCars project. Carlier, K., Ruberti, G., Schrijver, J., Janse, M. And Sessa, C., 2006. Common methodology, Deliverable 2.2.1 from the CityMobil project. Gallais, G. and Wagner, C., 2004. State of the art: related projects. Deliverable 1 from the NETMOBIL project. Netmobil, 2004. Research synergies, needs and opportunities. Deliverable 2 from the NETMOBIL project. Netmobil, 2005. Proceedings of NETMOBIL Conference and Final Dissemination Workshop New transit in town on “The potential of automatic vehicles for sustainable urban transportation, Capelle aan den IJssel and the Erasmus University, Rotterdam. Milestone 5 from the Netmobil project. Sessa, C., Gaggi, S., Vendetti, A. and Fioretto, M., 2007. Scenarios for Automated Road Transport. Deliverable 2.2.2 – Visioning of the future – from the CityMobil project. STARDUST Consortium, 2003. Assessment of behavioural acceptance of intelligent infrastructure and ADAS / AVG systems, Deliverable 4 of the STARDUST project. TRANSPLUS Consortium, 2003. Barriers, Solutions and Transferability, Deliverable 4.1. Uwland, J. and van Dijke, J., 2002. Safety standards for cybercars. Existing standards and guidelines. Deliverable 6.1 from the CyberCars project.

6.2 Web sites www.cenorm.be www.cybercars.org www.cybermove.org www.fahrerassistenzsysteme.de www.netmobil.org www.prevent-ip.org/en/prevent_subprojects/horizontal_activities/response_3/response_3_02.htm www.unece.org/trans/main/wp29/wp29regs.html

D.2.5.1 Certification procedures for automated transport systems xxxvii

Annex 3 : CityMobil: Informal report on Task 2.5.2: Definition Phase

EUROPEAN COMMISSION DG RESEARCH





CityMobil Towards advanced transport for the urban environment

Deliverable no. T 2.5.2 Dissemination level Internal Work Package 2.5 Legal and administrative issues Author(s) Ragnhild Wahl, Trude Tørset, Torgeir Vaa, Jan van Dijke,

Ahmed Benmimoum and Adrian Zlocki Co-author(s) Status (F: final, D: draft) F_11.02.07 File Name Task 2.5.2 final deliverable 110207.doc Project Start Date and Duration

01 May 2006 - 30 April 2011

D.2.5.1 Certification procedures for automated transport systems xxxviii

TABLE OF CONTENTS 1 INTRODUCTION XXXIX 2 CERTIFICATION PROCEDURES XXXIX

2.1NON-AUTOMATED MODES XXXIX 2.1.1 Platooning xxxix

2.2ASSISTED MODES XXXIX 2.2.1 ADA systems xxxix 2.2.2 Advanced city cars xl

2.3AUTOMATED MODES XL 2.3.1 Driving versus riding xlii

3 GENERAL GUIDELINES XLII 3.1SAFETY XLII 3.2SECURITY XLII

3.2.1 Personal safety xlii 3.2.2 Protection against vandalism, misuse and terrorism xlii

3.3PRIVACY XLIII 4 LEGAL BARRIERSXLIII

4.1EXISTING LEGISLATION XLIII 5 OTHER BARRIERS XLIII

5.1ORGANIZATIONAL BARRIERS XLIII 5.2SOCIETAL BARRIERS XLIV 5.3OVERCOMING THE BARRIERS XLIV

TABLES Table 1: A shift from non automated transport towards automated drive mode ....................................... xxxix

Table 2: Procedures for automatic modes.............................................................................................xl

FIGURES Figure 1: Procedures for automatic modes with backward loops............................................................... xli

D.2.5.1 Certification procedures for automated transport systems xxxix

1 Introduction Task 2.5.2 is a definition phase. The outcome of task 2.5.2 is a clarification of which modifications of existing documents should be done, and which actions has to be taken to eliminate or limit the consequences of existing barriers. The work in task 2.5.2 is based on

• Deliverable task 2.5.1

• Presentation of the Reference Group-survey

2 Certification procedures Table 4 presents an overview of the different vehicles and transport concepts, which are under consideration.

Table 4: A shift from non automated transport towards automated drive mode

Drive mode Non automated Assisted Automated

Driving Car (individual use) Car sharing Car pooling

Advanced city cars Cars with ADA systems Platooning (driver present)

Dual mode vehicles

Riding Taxi Collective taxi Public transport (bus, tram, metro, train)

Cybercars Personal Rapid Transit (PRT) High-tech buses Platooning

2.1 Non-automated modes Conventional systems are fully covered in existing legislation and legal framework. We will only look into special applications, like platooning.

2.1.1 Platooning If platoons are considered to be a fleet of vehicles following a driver operated vehicle, then they should be treated as either non-automated systems or ADA-systems, depending on the technology used. If there is no driver present, then the platoon is a fully automated system and should be subjected to the requirements for fully automated systems.

2.2 Assisted modes Assisted mode includes both Advanced city cars and cars with ADA systems (ADAS).

2.2.1 ADA systems Work has been done in several following EU projects (Response I, II and III, among others) to develop a code of practice for the development of ADA systems1.

1 The Response projects’ websites:

http://docs.adase2.net/response/ http://response.adase2.net/

D.2.5.1 Certification procedures for automated transport systems xl

An ISO Working group is developing a certification procedure for ADA systems, based on IEC 61508. This is a formal activity and it is expected that the result will be adopted by the EU, car manufacturers etc. in due time. This involves introduction of system safety analysis with specific procedures. The draft version is restricted at the time being, and thus cannot be referred in this report. This work is carried out by other parties at the moment. Therefore there is no need for CityMobil to develop activities, other than to carefully follow the developments and use the results where applicable.

2.2.2 Advanced city cars Rules and legislation regarding ADAS will also apply for advanced city cars. The driver is responsible in all cases, except for system failures caused by the manufacturer. When ACC systems were introduced, they were promoted as comfort systems only. This has changed during the last years, and today it is acceptable to present them as systems providing both comfort and safety. This will probably be the situation for new systems and assistance solutions as well. It is important to demonstrate the safety contribution and to test difficult cases in the national court of justice in order to establish an adapted code of practice.

2.3 Automated modes There are a number of procedures to be followed:

1. Risk reduction method to evaluate the system in the environment it is supposed to operate

2. Establishment of which existing safety regulations the system should meet depending on the environment in which it is used

3. Code of practice 4. Certification methods, based on ISO standards

The first step is the risk reduction method, which is carried out by the authorities, the operator and the evaluation organization. Based on this the other procedures should follow. The second procedure should be taken care of by the authorities and the evaluation organization, manufacturers are responsible for the third, and evaluation organization is responsible for the fourth. If these procedures have been followed with a positive result, we consider the system safe enough to be introduced. This will also be valid for PRT systems. We should consider whether existing rail standards could be used. The procedures are presented in Table 5.

Table 5: Procedures for automatic modes

Step Procedure Responsible

1 Risk reduction method Authorities, operator and evaluation organization

2 Safety regulations Authorities and evaluation organization

3 Code of practice Manufacturer

http://www.prevent-ip.org/en/prevent_subprojects/horizontal_activities/response_3/

D.2.5.1 Certification procedures for automated transport systems xli

4 Certification methods Evaluation organization

If a procedure does not give the required positive result, a backward loop to previous steps is necessary, as illustrated in Figure 2-1.

Certified vehicle and infrastructure in thesurrounding environment

Risk reductionmethod

Safetyregulations

Code of practice

Certificationmethods

Automatic mode + infrastructure + environment:

Responsible:

Authorities, operator and evaluation organization

Authorities and evaluationorganization

Manufacturer

Evaluation organization

Certified vehicle and infrastructure in thesurrounding environment

Risk reductionmethod

Safetyregulations

Code of practice

Certificationmethods

Automatic mode + infrastructure + environment:

Responsible:

Authorities, operator and evaluation organization

Authorities and evaluationorganization

Manufacturer

Evaluation organization

Figure 2-1: Procedures for automatic modes with backward loops

Software is a specific problem regarding automated systems. It should be developed according to accepted software developing guidelines. Vehicles on the road must meet numerous requirements. Automated vehicles can be of a totally different kind, and will not have to meet all these standards and requirements. This depends on which type of system environment these vehicles are used in. When vehicles are operated on dedicated infrastructure, a lot of these standards and requirements will be irrelevant. However, if the vehicles are operated in mixed traffic at the same speed as conventional vehicles, all the requirements should be met.

D.2.5.1 Certification procedures for automated transport systems xlii

2.3.1 Driving versus riding As far as certification procedures are concerned, there are no differences between driving and riding automated vehicles.

3 General guidelines

3.1 Safety The safety issues for both passengers and everybody outside the vehicles (pedestrians, etc.) are covered in certification procedures.

3.2 Security The difference between automated systems and traditional systems is that there are no drivers or other personnel present that can assist in case of an unsecured situation. We focus on personal safety and protection against vandalism, misuse and terrorism.

3.2.1 Personal safety Personal safety covers safety against actions performed by a third party. This involves safety of passengers using the vehicles or the access to these. What can be done to improve personal safety:

• Access control with identification of the passengers

• Monitoring the inside and outside areas with cameras and television systems

• Communication system connecting the passengers with the security company

• The possibility to have exclusive access to a cabin

• Emergency procedures (emergency buttons and alarm systems for instance)

• Lighting

• Information system (operating procedures, maps, status, position, clear emergency procedures and instructions, messages for system behaviour, etc.). The HMI should be easy to understand, even for non-skilled users.

• Information about installed monitoring systems could help prevent possible crimes and misuse

3.2.2 Protection against vandalism, misuse and terrorism Vandalism is for instance outside attacks on the vehicles, the guidance system or the electronic system by means of viruses. Misuse could be the use of vehicles for purposes they are not meant for, like use as a shelter (by playing children or homeless people), misuse of the obstacle detection by playing children, transporting freight, etc. When considering the threat of use of the system by terrorists, one could think of a bomb being sent into the urban centre in an unmanned vehicle by a terrorist. What can be done in general to protect against vandalism, misuse and terrorism:

• Control desk should be present

• Monitoring the inside and outside areas with cameras and television systems

• Recognize occupancy (both people and objects)

• Safe and secure communication with control desk

• Detection of unexpected events

D.2.5.1 Certification procedures for automated transport systems xliii

• System to ensure that the vehicle does not move if it is unoccupied or has not been called in an authorized way

• Minimize vandalism possibilities by use of materials, HMI design etc.

• Actions to detect obstacle detection misuse

• Price mechanism and means for payment for identification and minimize “kindergarden” and shelter kind of misuse

What can be done in the specific case of freight use:

• Control desk which monitor the vehicles

• Restriction and qualification system for access to the system (for preventing use for dangerous goods, bombs etc.)

• Exit control and camera system for preventing theft

3.3 Privacy Privacy issues are of relevance for both safety and security issues. Information about privacy sensitive systems should be provided to the public. Is there a contradiction that you cannot have a fully safe and secure system, while maintaining full privacy? Problematic issues:

• Cameras inside and outside

• Storing data (access control, misuse)

• All kinds of identification, tracking and tracing

• Different laws among the countries

4 Legal barriers

4.1 Existing legislation A number of shortcomings of the existing legislation have been identified:

• Public road legislation is based on the present of a driver responsible for the vehicle

• The fact that there is not a present legislation for driverless system represents a barrier - people does not know which laws will apply

• There is a lack of standardisation and harmonization of existing legislation

• Time frame, efforts and challenge for changing or adding legislation could be significant, and therefore represents a barrier

There are a number of elements missing. We need legislation for these.

5 Other barriers

5.1 Organizational barriers Important organizational barriers include:

• Political issues

D.2.5.1 Certification procedures for automated transport systems xliv

• Lack of information and knowledge (dissemination work)

• Funding issues (support demonstrations)

• Acceptance issues (dissemination work)

• Business issues (2.2 and 2.4)

• Operator issues Some of these can be addressed, and will be addressed within the CityMobil project.

5.2 Societal barriers Scepticism at an operational, strategic, technological, personal, and society level are present. Some of these aspects can be addressed. For instance, reduced number of jobs related to vehicle operation will be compensated by increased number of jobs within other areas of driverless systems. Other compensatory actions can be taken in a period of transition.

5.3 Overcoming the barriers In task 2.5.3, the production phase, we will address how to overcome the acceptability barriers. The list of relevant barriers will most likely be revised during this work. Thus, the present document should be regarded as an initial internal working plan, which represents the starting point for task 2.5.3.

D.2.5.1 Certification procedures for automated transport systems xlv

Annex 4: National provisions especially addressing CCTV1

Country National provisions

Denmark Consolidation Act No. 76 of 1 February 2000 on the ban of video surveillance. This act generally prohibits private entities from monitoring public streets, roads, squares or any similar area used for common travel. There are however, certain exceptions to this prohibition. DPA´s decision of 3 June 2002 concerning video surveillance by a large supermarket chain and live transmission from a pub on the Internet. DPA´s decision of 1 July 2003 stating that video surveillance conducted in privately run public transportation must be proportionate and in adherence with the rules of the Danish Data Protection Act. DPA´s decision of 13 November imposing certain limitations on video surveillance conducted by public authorities.

Germany Section 6b of the Federal Data Protection Act that governs the deployment of CCTV by private entities and federal authorities other than the police and secret services. Further regulations on video surveillance by state authorities other than the police and secret services in the Data Protection Acts of the 16 German states. Sections 26 and 27 of the Federal Border Police Act. Further regulation on video surveillance by the state police forces in the Police Acts of the 16 states.

Hungary DPA´s recommendation of 20 December 2000 on how to implement the Data Protection Act.

Norway Chapter VII in the Personal Data Act No. 31 of 14 April 2000.

Spain Ley organica No. 4/1997 on video surveillance by security agencies in public areas. Real Decreto No. 596/1999 implementing Act No. 4/1997.

United Kingdom

Section 163 of the Criminal Justice and Public Order Act 1994 that regulates local authority powers to provide CCTV. CCTV Code of Practice 2000 of the Information Commissioner which clarifies the more general provisions of the Data Protection Act 1998 (currently under revision).

1) This is not a comprehensive list of national provision that apply to CCTV: Other provisions applying to CCTV are found in codes of criminal procedures, assembly acts, sports acts, certain police acts, human rights acts, copyright provisions or case studies.

D.2.5.1 Certification procedures for automated transport systems xlvi

Annex 5: Checklist for functions/requirements for automated transport systems

Function/requirement Relevant according to:

Access control Personal security, terrorism, vandalism and misuse, freight, social barriers

Identification of passengers Personal security, terrorism, privacy, vandalism and misuse

Monitoring the inside and outside

Personal security, terrorism, vandalism and misuse, freight, privacy, social and political barriers

Vocal or visual communication system

Personal security, terrorism, vandalism and misuse, privacy, social barriers

Security company/operator Personal security, terrorism, vandalism and misuse

Exclusive access to a cabin Personal security, social barriers

Emergency buttons + Alarm systems

Personal security

Lighting outside stations Personal security

Lighting in vehicles Personal security

Lighting of tracks Personal security

Information system Personal security, social barriers

Information posters:

• Regular operation Personal security, social barriers

• Code of Conduct Social barriers

• Surveillance Terrorism, vandalism and misuse, social barriers

• Map + route(s) + destination(s)

social barriers

• Statistics Social and political barriers

• Emergency procedures

Personal security, social barriers

Recognize occupancy Terrorism, vandalism and misuse

Protected and secure communication

Terrorism, vandalism and misuse, social barriers

Detection of unexpected events

Terrorism, vandalism and misuse

Approval system to move the vehicle

Terrorism, vandalism and misuse

D.2.5.1 Certification procedures for automated transport systems xlvii

Ticket to ride Vandalism and misuse, social and political barriers

Choice of materials in the design

Vandalism and misuse, social and political barrier

Qualification system for access

Freight, social and political barrier

Exit control and camera system to prevent theft

Freight

Data collection and storing, incl. laws about surveillance

Vandalism and misuse, privacy, social and political barrier

Laws about driverless vehicles Social and legal barriers