Time Constraints And Fault Tolerance In Autonomous Driving Systems
Time Constraints and Fault Tolerance in AutonomousDriving SystemsYujia LuoElectrical Engineering and Computer SciencesUniversity of California at BerkeleyTechnical Report No. /TechRpts/2019/EECS-2019-39.htmlMay 14, 2019
Copyright 2019, by the author(s).All rights reserved.Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission.AcknowledgementI would like to thank Professor Joseph Gonzalez for advising me during mycandidacy. He provided support and advice above and beyond therequirements of an advisor. I would also like to thank the rest of the CarOSproject: Ionel Gog, Sukrit Kalra, Peter Schafhalter, Raluca Ada Popa and IonStoica.
Time Constraints and Fault Tolerance in Autonomous Driving SystemsYujia Luo ** Based on paper draft ”CarOS: A Data-flow Operating System for AutonomousVehicles” written with Ionel Gog, Sukrit Kalra,Peter Schafhalter, Raluca Ada Popa, Joseph E. Gonzalez, and Ion Stoica1
AbstractSafety is one of the biggest concerns for autonomous vehicles. Safety depends on accurate driving algorithms, reliable hardware, secure networks, and real-time software systems, the last of which is what wefocus on. It is critical for software systems on autonomous vehicles to respond in real time and be robust topotential system failures.After analyzing the distinct characteristics of autonomous vehicles and the related system solutions, webelieve that a specialized software platform for autonomous vehicles is in need. The goal of such a platformis to achieve strict latency and availability requirements of autonomous vehicles. We propose a more flexibletime constraint mechanism that covers a wide range of application needs, as well as a hybrid fault tolerancemechanism that fits into different availability needs of different driving applications. Lastly, we present theprototype of CarOS, an open source platform for developing time-aware and highly-available autonomousvehicles.2
Contents1Introduction42Problem Statement63Related Systems93.1 AI Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Real-time Embedded Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Data Streaming Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Time Constraints4.1 Timestamped Dataflow . . . . . . . . .4.2 Clock Synchronization . . . . . . . . .4.3 Progress Tracking . . . . . . . . . . . .4.4 Time Constraints . . . . . . . . . . . .4.4.1 Operator-level Time Constraints4.4.2 Graph-level Time Constraints .4.5 Time Constraints Violation . . . . . . .14141414151719195Fault Tolerance5.1 Amnesia . . . . . . . .5.2 Active Replication . .5.3 Rollback . . . . . . . .5.4 Fault Tolerance in ADS.21222223256Solution Prototype6.1 Design Goals . . . .6.2 Architecture . . . . .6.3 Programming Model6.4 System Mechanisms.27272727297Conclusion.313
1IntroductionAutonomous driving is one of the biggest unsolved problems in the domain of artificial intelligence. Bothacademia and industry have devoted considerable amount of efforts into the field for two major benefits:improving transportation efficiency and reducing traffic accidents. On average, a person wastes 960 and42 hours per year because of traffic jams [32]. An average urban commuter can spend up to 82 hours peryear on traffic delays [55]. Besides wasting resources, approximately 1.2 million lives are lost in trafficaccidents each year around the world, where 94% of the accidents are caused by human error [18; 23].These accidents are estimated to cost 836 billion annually [62]. By replacing human drivers, autonomousvehicles are expected to address both of the problems.However, with strict regulations, autonomous driving still remains an unsolved domain. In order for selfdriving cars to be as reliable as human-driven cars, they must be driven with no disengagement for (i) 291million miles without causing a fatality, and (ii) 5.4 million miles without being involved in an accident thatcauses personal injury [27]. The top self-driving car company Waymo, which has logged the most miles,has only driven 7 million miles [38; 66]. Most importantly, the disengagement rate is very high acrosscompanies. Table 1 shows the most recently reported disengagement frequency for known self-driving 1,9716,5725,007125,000352,545Miles 45,595.9Table 1: Average self-driven miles between disengagements [12].According to the company reports collected by California Department of Motor Vehicles [8], there aresix types of disengagement causes in general:1. Perception discrepancy2. Unwanted maneuver of the vehicle3. Incorrect behavior prediction of other traffic participants4. Reckless road user behavior5. Software discrepancy6. Hardware discrepancyCause 1-3 are all related to the reliability and accuracy of the driving algorithms, which is what most autonomous driving research focuses on but not our focus. Cause 4 concerns the unexpected incidents thathappen in the physical world; cause 5 indicates the delay of reaction in software systems; cause 6 describesthe uncontrolled failures that occur in hardware. Causes 4-6 are all related to key real-time systems problems – how can autonomous vehicles engage with the driving environment in a timely manner, even withpotential delays in software delay, failures in hardware, and unpredictability in the physical world?This thesis approaches these real-time problems from a software perspective, specifically, by studyingthe system platform that sits between the Real-time Operating System (RTOS) and the autonomous drivingapplications. We will address such a platform as Autonomous Driving System (ADS). We believe that4
designing a time-aware and fault tolerant ADS will fundamentally solve the real-time problems, advancingsystem research while also providing development supports for algorithm research.The unique characteristics of autonomous vehicles impose challenging requirements on ADS, whichmust support complex workloads requiring gigabyte-level throughput and millisecond-level latency. Moreover, ADS should be elastic in the face of high-variation and unpredictable environments. Meanwhile, theymust be available at all times. We claim that no existing systems can meet all of these requirements.In this thesis, we make the following contributions: Identify the challenges in supporting autonomous driving applications Propose a comprehensive time constraint mechanism for ADS to meet tight latency requirements Propose a hybrid fault tolerance mechanism for ADS to ensure reliability and availability Propose the prototype of CarOS, an open-source ADS that supports the development of real-timeautonomous vehiclesThe rest of the thesis is organized as follows: §2 defines the problem space. §3 discusses related systems,analyzing which aspects make them insufficient to be deployed in autonomous vehicles yet which aspectscan be leveraged. §4 focuses on designing time-related mechanisms for ADS based on existing concepts. §5analyzes the existing fault tolerance solutions and proposes a hybrid solution. §6 demonstrates the solutionprototype.5
2Problem StatementAutonomous vehicles have rigorous real-time requirements. On average, it takes a human 0.96 secondsto release the accelerator, 2.2 seconds to achieve maximum braking, and 1.64 seconds to begin steering[44]. Moreover, it takes a human 100-150 milliseconds to react to a new signal in the best scenario [49]; inautonomous driving, this is equivalent to the time from receiving a sensor input to making a control decisionbased on this input. In order to achieve human-level safety, autonomous vehicles should react in less than100 ms, which is perceived as an end-to-end processing latency constraint [39; 68]. Any delay in takingactions can have catastrophic consequences. For example, if the vehicle travels at 70 miles per hour onthe highway, an additional 100 ms latency can increase stopping distance by 3 meters. The concept of thetime constraint is never explicit in ADS. Instead, developers try to impose ”virtual time constraints” throughconducting extensive testing. Certification approaches used in the automotive industry consider all possiblesystem behaviors in the testing and certification stages, which is impossible to do for autonomous vehiclesthat learn and adapt online in an unpredictable physical world [40]. In addition to tight time constraints,system failures may lead to catastrophic consequences. System failures are not corner cases as the averageoccurrence of software and hardware faults ranges from 400 to 16,000 miles across leading companies [8].The distinct characteristics of autonomous vehicles make it challenging to achieve such tight real-timeconstraints. As an evolving field, autonomous vehicles feature increasingly complicated application pipelineand diverse sensor inputs. Figure 1 shows a simplified dataflow graph of the state-of-the-art autonomousdriving pipeline [1; 9; 10; 64]. We summarize the properties of an autonomous vehicle into four aspects:data forgetfulness, computation, runtime and hardware. In the following, we discuss the details of each andexplain how it influences meeting real-time requirements: Data is forgotten fast. An autonomous vehicle should only operate on fresh data. Historical data areirrelevant as they will not contribute to making correct control decisions at the present. Autonomousvehicles compute over much smaller time windows (milliseconds to seconds level) than other timecritical applications do (e.g. streaming applications’ time windows are usually minutes, hours or evendays in size). Therefore, any stateful operation in ADS only contains a small state, and we considersuch an operation as quasi-stateless. Containing only stateless or quasi-stateless operations, ADSneed to reconsider their fault tolerance strategy. Computation is high-load and diverse. In practice, an autonomous driving pipeline can containhundreds of processing modules [1; 65]. For example, NVIDIA’s DRIVE AV runs more than 10 deepneural network models simultaneously, together with a large number of computer vision and planningalgorithms, and requires approximately 250 trillion operations per second [56]. On another end, anautonomous vehicle is equipped with a large number of sensors (e.g., a dozen of cameras, severalLIDARs and radars), which help improve algorithmic accuracy and increase sensor availability incase of hardware failures. These sensors are required to publish data at a minimum frequency of 10frames per second to ensure human-level safety [39]. In practice, each sensor can generate 1-2 GB/sof data (see Table 2), which then get processed through multiple algorithms and neural networksin real-time, leading to computation requirements that are at least 100 higher than those of thevehicles in production today [1]. In such a complex dataflow graph, defining time constraints isalready a problem: what exactly should these constraints restrict? A time constraint should addressmultiple factors such as graph dependencies and individual module’s performance, which are hard fordevelopers to monitor. The frequency divergence and convergence of data paths in the graph can alsoadd ambiguity. For example, if a data path is influenced by another (e.g. due to synchronization), wemust address how its time constraint will be affected. In addition, the diversity of computation makesit hard to find a unified solution to keep every component available at all times.6
Figure 1: Simplified Autonomous Driving Dataflow Graph. There are four main parts of an autonomousdriving pipeline: (i) sensors, which receive environment states, (ii) perception, which uses sensor data todetect, recognizes and localizes objects around the vehicle, (iii) planning, which generates vehicle’s futuretrajectories based on perception results, and (iv) control, which physically operates the vehicle based on theplanning results [53]. Runtime has high-variation and is unpredictable. Complex computation logic and data content canlead to high variation in runtime, and such a variation can be unpredictable. There can be occasionalbursts of computation load: a more complicated data (e.g. an image with more pedestrians to track)can require much longer computation time, and it is impossible to learn the true ”worst case” duringprofiling. Figure 2 uses components in the Apollo pipeline [10] to demonstrate this runtime variation. In addition, the involvement of external systems can increase unpredictability. For example, thevehicle uses Tensorflow for modelling and communicates with external systems to retrieve mappingand traffic information. As a result, runtime profiling is no longer sufficient to ensure real-time in thephysical world. Hardware is constrained. Unlike big data systems that can leverage an entire cluster of machines,autonomous vehicles only have limited amount of hardware. Such a restriction makes it harder forADS to achieve resource elasticity by scaling up or achieve availability by running copies of all7
computation.HardwareBackfly CameraIMX390CQV CameraVLS-128 LIDARRadar#88521f (Hz)22601040BW etnamfaster-r-cnn-arizonafaster-r-cnn-vietnam35 45 55 65 75 85 95 105Inference runtime [ms](a) Object detector inference runtimevaries by: (i) up to 50% across framesfrom the same environment, (ii) upto 10% across environments for thesame model, and (iii) up to 100%when using different models.Prediction runtime [ms]1.0CDF of runtime [ms]CDF of inference runtime [ms]Table 2: A self-driving car has several types of sensors that generate around 1 GB/s [1; 6; 65].0.80.60.40.20.005101520Traffic light runtime [ms](b) CDF of runtime of the Apollotraffic light detector. The runtime isunpredictable, and thus Apollo eitherrun the component at a low frequency(e.g., every 25 milliseconds) or riskmissing deadlines.100755025001020 30 40Time [sec]50(c) Timeline of the Apollo predictioncomponent runtime. The componentcould cause deadline misses becausethe max runtime is an order of magnitude greater than the 90th percentileruntime.Figure 2: The runtime of different Apollo pipeline components varies greatly.Because of these characteristics, autonomous vehicles cannot avoid potential real-time constraint violations in the physical world. However, the current policies to deal with these violations are not sufficient.When the system disengages, an autonomous vehicle will execute one of the three actions: (i) signals humans to take over, (ii) stops itself and (iii) crashes. (i) is the most common, but in high (level 4) and full(level 5) automation, human intervention is not even an option [39]. Even in situations where human driversare presented, they might fail to react due to various reasons (e.g. lack of attention [50; 51]). In eventof system failures, some companies enable action (ii) by employing redundant hardware (e.g., deployingcritical components on independent power systems) and using backup computing to safely stop the vehicle[1; 2; 66]. Nevertheless, in a safe autonomous vehicle, we should not take any of these actions and makethe system robust to any potential delays or failures. We believe that no existing systems can sustain such aworkflow while meeting the real-time requirements, which will be explained in the next section.8
3Related SystemsThe most widely-used software platforms in developing robots and autonomous vehicles is the Robot Operating System (ROS) [9; 52; 64; 65]. However, ROS is far from satisfying our requirements for ADS,which not only have reliability, safety, and real-time requirements similar to Real-time Embedded Systems(RTES) but also have processing and throughput demands similar to Data Streaming Systems (DSS). In thefollowing, we analyze these related systems, exploring how they are insufficient or can be leveraged to serveautonomous vehicles. Table-3 shows an overview of the system comparison between ADS and the relatedsystems.SystemPurposeTimeawareROS [52]robots, autonomousdrivingRL modelsRay cDataflowResourceElasticityFault eeNoModularityand ointCheckpointNoYesML autonomousdrivingYesYesNoNoNoMostly tHybridYesYesYesYesTable 3: System Property Comparison3.1 AI SystemsROS is originally designed for large-scale integrative robotics research. It is a flexible platform that allowsdevelopers to build evolvable and modular applications. Applications implemented using ROS consist ofone or more ROS nodes (e.g, OS processes), which require users to manually deploy them on machines(e.g., fork a new process to start new ROS node). ROS nodes communicate using either an asynchronouspublishers/subscriber pattern or a synchronous RPC service with no message delivery guarantee. We claimthat such a design is sufficient for implementing research prototypes but not for real-time production applications. Fundamentally, ROS is just a message communication layer; it is not a real-time system thatprovides any form of time constraints or fault tolerance.More recently, the prototype of a new version of ROS, ROS2 [54], was released to address the limitationsin ROS but the actual system is still under heavy development. Based on its published prototype [43], ROS2changes the original communication middleware from ROSTCP to Data Distribution Service (DDS), whichprovides a similar publisher-subscriber communication mechanism as ROS. DDS provides a distributeddiscovery system so that a master node is no longer required. It also adds shared-memory transport (ROSonly uses TCP transport) and provides configurable QoS. Furthermore, Baidu’s Apollo [10] has an opensource autonomous driving platform that was previously built on ROS but switched to their new open-sourcemiddleware solution, CyberRT [7], which is similar to ROS but has its own task-graph-based scheduler.All of ROS, ROS2 and Apollo have the following limitations: No Real Time: because these systems do not provide their own time constraint mechanisms, theycannot monitor and regulate application runtime based on the constraints. ROS and ROS2 do not evenhave a resource manager. Each ROS node is fixed to be run in one OS process, so scheduling and9
resource allocation are completely handled by the RTOS. Without overseeing the overall workflow,the system cannot make global decisions such as load shedding and message prioritization in order toensure real-time, and message bursts cannot be mitigated with the help of back-pressure. No Reliability: these systems have no fault tolerance mechanisms. For example in ROS, the coremaster node which monitors publisher/subscriber topics is a single point of failure. Because they donot have state management, they can’t recover a failed state. No Adaptability: it is hard to implement reactive applications that adjust when workflow (e.g. inputrate) or computation duration changes in these systems. For example, ROS does not support backpressure, so messages will be dropped if a ROS subscriber node cannot keep up with the publishernode. Similarly, in Apollo, there are occasional message delay problems. Figure-3a evaluates thecomponents built with Apollo and demonstrates the irregularity in their data sending. No Message Delivery Guarantee: these systems all use the publisher-subscriber communicationmechanism, which has no order guarantees for message delivery. The publishers and subscribersmaintain pre-configured fixed-size queues that drop messages when they are full. Moreover, thereis no notion of progress in these systems, so that they cannot guarantee message delivery throughprogress checking.In addition to these execution platforms designed particularly for robots and autonomous vehicles, thereare many other frameworks used in implementing AI algorithms such as Tensorflow and Caffe [3; 34].However, these frameworks focus on providing fine-grain operators for machine learning model developers.They also focus on optimizing for batch processing since model training is their target application. Ray [47]is another dataflow graph execution system designed for reinforcement learning applications. In order totrain and deploy learning policies, Ray needs to focus on facilitating stateful computation (e.g. simulator,model), therefore using global state storage and actor model to make state editing and management moreefficiently, a functionality that is at odds with the needs of ADS. Moreover, Ray is not a real-time system soit is not time-aware and does not provide any time constraint mechanism, and its message delivery latencyis higher than that in ROS.3.2 Real-time Embedded SystemsReal-time Embedded Systems (RTES) are systems that are built on Real-time Operating Systems (RTOS)and execute multiple tasks in the real world with strict time requirements and limited hardware resources.Such systems are used in a wide range of devices that assist humans in interacting with the real world, suchas telephones, vehicle controls, military weapon devices and aircraft controls. Depending on the needs ofthe devices, RTES have different levels of strictness in terms of their time constraints: hard, soft and firm.Missing a hard time constraint is considered a system failure and will cause catastrophic consequences suchas loss of human lives. Systems like aircraft controls usually have hard time constraints. Systems with softtime constraints try to reach deadlines but do not fail if a deadline is missed; instead, they degrade theirperformance metrics to signal the system to improve responsiveness. Systems like cruise control and entertainment video delivery software fall into this category. Furthermore, systems with firm time constraintstreat information delivered or computations made after a deadline as invalid while degrading their performance metrics, which is closer to a soft real-time system. Systems like robots on the assembly lines couldbe considered to have firm time constraints. ADS are considered most similar to the hard RTES like aircraftcontrol systems because they share a similar level of safety concern.However, there are still multiple major aspects that hard RTES are at odds with ADS: Strictness of Time Constraints: although both systems can cause catastrophes when violating atime constraint, ADS should not consider it as a system failure; instead, they can initiate differentstrategies to deal with violations, such as stopping the vehicle or shedding loads to prevent future10
0.60.40.20.0baselinepatched0 200 400 600 800 1000 1200Traffic light inter-output time [ms](a) CDF of message inter-output timeof the Apollo traffic light detector.Apollo’s camera runs at 8 FPS (i.e.,inter-output time should be 125 milliseconds plus traffic light detectorruntime), but the traffic light detectorsometimes does not output messagesfor over 1 second.perception messages7505002500020 40 60 80 100 120Time [sec](b) Timeline of message inter-outputtime of the Apollo perception component. Despite frames arriving every125 milliseconds, the component often does not output any messages formore than 250 milliseconds, indicating that frames are dropped.Inter-output time [ms]10000.8Inter-output time [ms]CDF of inter-output time [ms]1.01500control messages10005000020 40 60 80 100 120Time [sec](c) Timeline of message inter-outputtime of the Apollo control component. The mean inter-output time ofcontrol messages is 10 milliseconds,but the controller sometimes does notoutput commands for over one second.Figure 3: Apollo’s components do not output data regularly. They unpredictably, fail to meet deadlines andto output data. violations, but these strategies are not options for an aircraft. Therefore, ADS should not enforce hardtime constraints.Predictability and Determinism: a key requirement for tasks running on hard RTES is predictability- the timing behavior of all tasks must always be within an acceptable range [58], but this is infeasible for autonomous vehicles to achieve (explained in §2). On another end, hard RTES usuallydeal with deterministic workflow. Therefore, most research efforts in real-time systems target RTOSand programming languages [46], aiming at avoiding non-deterministic operations in the executionpaths (e.g., page faults, dynamic memory allocation, synchronization primitives that block indefinitely). However, since ADS ensure real-time by having time constraints influenced by wall-clocktime and dynamic dataflow strategies to meet time constraints (see details in §4), they are dealingwith non-deterministic workflow in the application level. As a result, studying RTOS does not solveour problem.Isolation: the key design principle in hard RTES is isolation - different processes have different priorities, and high priority processes run on separate machines. For example, flight control is physicallyseparated from cabin environment control. However, ADS are not self-contained as they depend onexternal large codebases (e.g. Tensorflow) and communicate with external systems (see details in §2)Throughput: ADS deal with much higher throughput than most hard RTES do. For example, amodern luxury vehicle has 60 more code than an F-22 fighter jet [40] as the land has much moreinformation to be processed than the sky. Moreover, these aircraft usually have a straighter and clearerroute to follow while having less external objects to interact with.Testing: Given the multitude of situations they can encounter, autonomous vehicles are validatedon public infrastructure instead of in-house simulation. Testing on the road exposes the vehicles tosignificant risks.Modularity and Evolvability: autonomous vehicles are required to be updated much more frequently11
than hard RTES because autonomous driving is still an unsolved domain undergoing rapid innovation.RTES typically target problems whose solutions are well understood and stable. As a result, thedevelopers of RTES assume they rarely change and often design them as monolithic systems thattightly integrate hardware and software.All the above points besides the last one show how RTES and ADS are designed for very differentpurposes and that RTES is insufficient for building autonomous vehicles. The last point on modularity andevolvability reveals the key reason we should not use RTES as a backbone for ADS. However, the reliabilityrequirements of RTES is very similar to that of ADS. Hardware redundancy and software diversity are themost common fault tolerance mechanisms implemented in RTES, while some RTES also leverage a hybridsolution that incorporates a diverse set of mechanisms [4], which could potentially be leveraged by ADS.3.3 Data Streaming SystemsDistributed data processing system is a well-studied domain in system research. It is divided into two majorareas: batch processing and stream processing. ADS have fewer overlaps with batch processing systems[20; 31; 69], which target big data analytic applications and interact with finite data stored in the database.Their primary goal is to optimize throughput. They ignore the continuous and real-time nature of data. Onthe contrary, Data Streaming Systems (DSS) [5; 14; 48; 63] share some properties with ADS as they bothdeal with infinite and continuous streams of data (e.g. webpage monitoring logs, stock market trading data,bank transactions) and these streams are required to be processed immediately.Similar to ADS, DSS are time-aware, but they are still different from ADS in the following aspects: Control of Data Source: DSS may interact with external remote applications (e.g., webpage runningon a different machine, cloud databases) to get data source. Therefore, they do not have control overthe arrival time and order of the data because the data may be lost or delayed. In contrast, ADS relyon in-house sensors which communicate directly with the system on the same machine. Latency: DSS are still not fast enough given autonomous vehicles’ high processing load and millisecondlevel execution latency requirement. Time Constraints: DSS have no notion of deadlines. Their notion of latency requirement is moreof a Quality of Service (QoS) measurement component running on the side to monitor the overallperformance over a certain time span. ADS require time constraint specification and monitoring on aper-message-level granularity. Data Forgetfulness: sometimes DSS require large time windows (state) to compute over historicaldata. Quasi-stateless operations are much more common in autonomous vehicles than streamingapplications. Fault Tolerance: rollback is a common strategy to ensure reliability in streaming systems. However,because of the quasi-stateless property of autonomous vehicles, recovering historical data is not aconcern for ADS. Resource Elast
Safety is one of the biggest concerns for autonomous vehicles. Safety depends on accurate driving algo-rithms, reliable hardware, secure networks, and real-time software systems, the last of which is what we focus on. It is critical for software systems on autonomous vehicles to respond in real time and be robust to potential system failures.
Objective 5.2: Plan and implement VMware fault tolerance Identify VMware Fault Tolerance requirements Configure VMware Fault Tolerance networking Enable/Disable VMware Fault Tolerance on a virtual machine Test a Fault Tolerant configuration Determine use case for enabling VMware Fault Tolerance on a virtual machine
Configuring vSphere Availability Settings 34 Best Practices for VMware vSphere High Availability Clusters 44 3 Providing Fault Tolerance for Virtual Machines 48 How Fault Tolerance Works 48 Fault Tolerance Use Cases 49 Fault Tolerance Requirements, Limits, and Licensing 50
Literature on Tolerance Design The relationship between the functional requirements and entities of the mechanical part can be derived and expressed as F 1 ¼ fðE 1;E 2;.;E nÞ. Tolerance design consists of tolerance analysis and tolerance synthesis. In tolerance analysis, the goal is to ensure the tolerance of functional require-
Constraints (Cs) are bounds on acceptable solutions. There are two kinds of constraints: input constraints and system constraints. Input constraints are imposed as part of the design specifications. System constraints are constraints imposed by the system in which the des
CDS G3 Fault List (Numerical Order) Fault codes may be classified as sticky or not sticky: Type of fault Method to clear Not sticky Clears immediately after the fault is resolved Sticky Requires a key cycle (off and on) after the fault is resolved to clear. CDS G3 Fault Tables 90-8M0086113 SEPTEMBER 2013 Page 2G-3
In this paper, the calculation of double line to ground fault on 66/33 kV transmission line is emphasized. Figure 3. Double-Line-to-Ground Fault 2.4 Three-Phase Fault In this case, falling tower, failure of equipment or . ground fault, fault current on phase a is I a 0. Fault voltages at phase b and c are: V b .
Capacitors 5 – 6 Fault Finding & Testing Diodes,Varistors, EMC capacitors & Recifiers 7 – 10 Fault Finding & Testing Rotors 11 – 12 Fault Finding & Testing Stators 13 – 14 Fault Finding & Testing DC Welders 15 – 20 Fault Finding & Testing 3 Phase Alternators 21 – 26 Fault Finding & Testing
illustrated in Figure 3. This is a fault occurring with phase A to ground fault at 8 km measured from the sending bus as depicted in Figure 1. The fault signals generated using ATP/EMTP are interfaced to the MATLAB for the fault detection algorithm. (a) Sending end (b) Receiving end Figure 3. Example of ATP/EMTP simulated fault signals for AG fault
