|
Research Challenges in High Confidence Systems
HCS Problem Exploration - Panelist Viewpoints |
 
|
|
|
|
|||
 |
|
|---|---|
|
|
|
|
|
Overview
|
This workshop started from a problem perspective, rather than starting with proposed solutions. The viewpoints expressed primarily by the workshop problem holders are presented in this section. The huge range of concerns expressed reflects the magnitude of the problem from both personal and organizational perspectives. |
|
|
|
|
HCS Problems
|
Demonstrating High Confidence The task before our agencies is establishing research that will provide the means that lead to high confidence in systems. We need technologies and methods that allow us to achieve high confidence in systems, to know when high confidence has been achieved, to convince someone else that high confidence has been achieved, and to integrate assurance methods that lead to high confidence into standard system development, evolution, and operations. All of this must be done in a cost-effective manner. How to measure how much confidence can be achieved through application of specific assurance techniques remains an open issue. Safe system design approaches are needed, as are means of recognizing when the use of high confidence technology has worked. As things now stand, when accidents have been prevented, no one knows it or -- worse -- no one believes it. Complex System Integration Why is it important to address high confidence now? Participants felt that it is the increased integration of systems that makes addressing high confidence systems a compelling and urgent matter. A high confidence system has to be one in which the consequences of its behavior are well understood and predictable. The trend is towards increased complexity: achieving high confidence is becoming more difficult as systems become more complex. Highly complex systems may have unknown, unpredictable, or emergent behaviors that may exhibit themselves at undesirable moments. Complex integrated and continuously evolving systems mean the simpler forms of analysis previously used to achieve high confidence may be reaching their limits. New analysis techniques are urgently needed. New analysis techniques must take a system-level view of the problem to include not only the digital components but also the electro-mechanical and human components. Also, new technology changes the operator's behavior, consequently inducing new kinds of errors. It is important to identify -- early in the design cycle -- features of the software black-box behavior that will induce user errors and then remove and/or modify those features. Technology should accommodate the user rather than try to change the user. Barriers to Transition of Methods and Tools Because of time pressures, industry does not use the methods and tools available today for achieving higher confidence. One panelist mentioned that typically four months are spent on quality assurance; systems must be safety critical to spend six months or more on assurance. The time budget for assurance is an attractive target for cutting as a development schedule slips. It takes too much investment to learn new tools and methods. Solutions are not perceived to provide enough benefit to compensate for this cost. Any new tool must give a system designer/builder a cost-effective capability to achieve something that cannot be done now, must require little training and not a tremendous amount of effort to use, and must be what is needed to do the job. For some industries, adopting new tools may be accomplished much more readily. For example, the computer chip industry needs new tools to address critical issues (e.g., feature size reduction) that cannot otherwise be addressed. New tools are much easier to adopt when the problem they are addressing is clear and the demand is urgent. In other industries, new software tools are adopted less readily because the quantifiable benefit, in terms of cost for the increased reliability achieved through their use, cannot be identified. However, one participant noted that industry should really consider the cost-per-product-item sold; for example, it may actually cost relatively little per copy of popular consumer software to apply an assurance technique, whereas to do so for a one-time system development could be perceived as more costly. Yet because of the regulatory environment, assurance techniques are used primarily in systems (generally safety-critical systems such as aviation or space vehicles) for which very few copies are built. Another economic factor in the use of assurance tools and techniques: supplying high-quality software components to the safety-critical industries is not a big business -- the volumes are low. Not all parts of a system can be evaluated formally, and so a variety of flexible analysis tools are needed for large complex systems. Problem holders need comprehensive and usable methods that combine both informal and formal techniques. Different individuals use different problem-solving strategies and may switch strategies midway through the problem, but today's tools typically support only one strategy. A characteristic of complex systems is that they are difficult to understand. Visualization methods could help to present complex information in multiple ways, depending on the question being asked. Analysis processes may need special tools tailored for different domains, as opposed to more general tools. Domain-specific languages, supported by common reasoning engines, may provide some efficiencies in tool development. Working on the Right Problems Researchers must engage with industry to make sure they work on the right problems. For example, there are too many research papers that improve on each others' recovery block algorithms: These algorithms are rarely, if ever, used in practice. Researchers must be directed toward real-world problems. Scaling Up Validating approaches on real systems is critical. Research approaches may not scale easily to real-world problems. A researcher cannot know the scalability of a proposed solution until it is tried on something real. Unfortunately, small research problems are different from large real-world problems. It is not simply a matter of scaling up the techniques that were developed and tested on small examples -- these often were not solving the right problems anyway. HCS research must consider problems of realistic scale from the beginning. Otherwise, we may find that we are working on wrong parts of the problem. Data Gathering Research must focus on areas for which it is possible to obtain the data needed for the analysis. For example, analysis tools for system models do not help if the domain information to build adequate models cannot be gathered efficiently. Designing in Safety Reduction in accident rates results from past accident analysis and making things "fail-safe" against what has happened previously. Ten percent of past errors are technology related; however, new technology introduces new ways that things can go wrong, making it difficult to predict future accident rates. Panelists pondered whether a system can be made safe once it has been built without safety in mind in the original design. This has been tried before, for example, putting a protection system around a legacy system. But participants felt that such an approach may be too costly to get ultra-high reliability and is not as effective as an inherently safe design. This is still a controversial topic in security, where research is currently being pursued on how to "add on" security in massively deployed critical infrastructure systems, such as telecommunications and power generation and distribution, where it is too late to "do it right" in the first place. Panelists agreed that one can't "test in" or "validate in" a quality. One cannot decide after the fact whether a system is safe. High confidence must be designed into a system and examined through a variety of confidence-generating means. In addition, some critical properties may conflict with each other, and attention must be paid to this from the beginning. Sometimes automating the design analysis process loses the opportunity for the designers to reason about that process and understand it. We need ways to help humans to reason about a process so they can bring all their expertise into understanding that process. Fault tree analysis2 serves as an example. We need to discover common-sense engineering principles for establishing properties such as safety and security in systems. Learning from the causes of past accidents, builders need to impose a discipline on their designs to minimize the introduction of additional complexity. |
|
|
|
|
Panelist Viewpoints
|
|
|
|
|
|
NASA
|
National Aeronautics and Space Administration NASA's system development programs have long time horizons. These systems belong to the category of critical systems requiring high confidence because of the harsh remote environment of space in which autonomous (e.g., deep space robots) and semi-autonomous systems must function and because of man-rating requirements of the manned space program. Satisfying these requirements means that the system meets specified criteria for human safety. Tolerance for loss of life in civilian aviation or in the manned space program is very low. Tolerance for mission failure in high cost space programs is also very low. These low tolerances and increasingly complex mission requirements present difficult challenges to system builders. Extraordinary -- though cost-constrained -- efforts must be taken to ensure that failure, malfunction, or loss incidents are maintained well below such tolerance levels. Manned missions to Mars are impractical today due to extremely high costs of developing and integrating technologies that would provide high confidence that such missions could succeed. NASA defines high confidence as knowing to some degree of predictability about a system's behavior in a given environment under specified usage conditions. Such understanding can be achieved through design analysis, demonstrated behavioral performance (simulation and testing), and detailed rigorous analytical review (verification and validation (V&V)). The confidence one has is the result of:
What is new in NASA systems is the increased scale of integration -- highly complex systems with many undiscoverable potential behaviors. Space programs are enabled through automated systems, and efficiencies of such systems are achieved through increased integration. In civilian aviation, flight safety concerns are increasing as air traffic control, navigation, and aircraft avionics become more highly integrated. Novel software architectures using artificial intelligence and neural networks are stretching the behavior understanding that can be achieved through state-of-the-art software V&V techniques. Current software engineering practices are human-centered activities. They are informal and often create "communication air gaps" that foster misunderstandings between requirements setters and designers that may lead to errors. Such practices do not adequately address very large or complex systems. New system engineering productivity improvements are also needed. An incredible amount of tedium in the software engineering process must be addressed by more automation. The software engineering environment has a very low level of automated tool support compared to other engineering disciplines. For example, high-level languages and their associated tools (compilers/debuggers) have provided the biggest productivity improvement in forty years. There is a continuing need for productivity-enhancing engineering design and development tools, such as compilers that are flight qualified. These could include tools that provide higher levels of abstraction and tools to automate software synthesis. V&V technology, with the exception of extensive work in system testing, has largely been ignored by industry. There is still a relatively high tolerance of software bugs that would not be tolerated in hardware, and at the same time a hesitation to trust software in critical applications. NASA designs for testability and then tests. It would like to extend V&V to be a more integral part of the early design process, and NASA wants tools supporting automated V&V throughout the system life cycle. Currently, NASA is working to shift from informal communications and models to formal syntactic processes capable of manipulation by machines to produce traceable, reusable, computer-based artifacts. |
|
|
|
|
FAA
|
Federal Aviation Administration The FAA currently uses a set of heuristic dependability standards oriented around sixty-six objectives. More than 250 industry representatives voted on these standards. These standards address different levels of confidence in dependability, but are not explicitly safety standards. Some of the future drivers for FAA high confidence systems will be:
The air travel system is currently near capacity. Current accident rates per flight hour, after having fallen due to corrections to planes made as the result of failure analysis following accidents, have been stable over the past ten years. Over the same time, air travel (number of flights) has increased faster than linearly. Even if the rate of accidents per flight hour stays stable along the current trend, we can expect to see one aircraft accident per week as the number of flights increase over the next twenty years. The public is unlikely to tolerate such a high frequency of aircraft accidents. Increased integration of disparate systems will increase the complexity of such systems. In the future, avionics, air traffic control, and navigation will be tightly coupled. To gain increased air traffic throughput, current safety margins (e.g., the "cocoon" in airspace around an aircraft) will be reduced. The current trend in aviation is to design human sensors out of the system. Such design approaches (e.g., fly-by-wire) increase the potential for human-generated error when the "human machine" is not appropriately considered as part of the system. For example, the European consortium Airbus designed a system that was non-intuitive to the experienced pilot in that it had non-moving throttles in the aircraft. The design introduced the potential for human error because human pilots have learned to subconsciously see the moving throttles out of the corners of their eyes. "Free flight," in which the aircraft automatically negotiate their desired airspace with each other as well as occasional ground controllers, is viewed as a replacement to conventional air traffic control, and is already being demonstrated in experimental programs. Such aircraft have increased dependence on various inter-communicating automated systems for flight from takeoff to landing. This increasing dependency on communications with free flight leads to concerns about the opportunity for terrorists to interfere with flight safety. At the same time, it also raises questions about the safety and predictability of interacting autonomous systems. Systems safety is different from component safety. Air safety cannot simply be satisfied by certifying the aircraft. For example, navigation depends upon the Global Positioning System (GPS), and flight safety depends on air traffic control. The HCS challenges faced by the FAA include achieving a higher degree of air traffic system dependability (i.e., the system correctly does what is expected) that subsumes safety. The ground component must have increased reliability. The airborne component must focus on safety (from the regulator's view) and on dependability (from the aircraft producer's view). The FAA is studying how system confidence should be gained and safety measured, considering the dependence on ground systems that have several million lines of code. Safety for the composite system may be different from what is determined for its constituent components. Complexity resulting from increased functionality and integration will lead to increased costs unless a means to reduce these cost pressures is developed. Industry thinks certification costs too much now. The FAA thinks that an order of magnitude improvement occurred in the Boeing 777 aircraft flight certification through the integrated product team (IPT) approach and the automated design and development support. This is significant since the 777 is a more complex system than earlier aircraft designs. Cost-effective approaches that support a priori behavioral provability -- not after-the-fact provability -- are desired. We need a means to assure behavioral properties at design time so as to incur less risk in building the system (e.g., so we will not have to return to an earlier phase of the development process and make significant changes). |
|
|
|
|
FDA
|
Food and Drug Administration The FDA faces the problems of determining:
The FDA is composed of five centers: (1) Drugs, (2) Biologic Products, (3) Food, (4) Animal Feed/Medications, and (5) Medical Devices. Drugs deals with statistical analyses of clinical results and qualification of software tools used in manufacturing of drugs. Biologic Products deals with software that runs blood banks. Food deals with all aspects of food processing. Animal Feed/Medications deals with medications that go into animals and how to prevent undesirable side-effects in the human food supply. Medical Devices deals with qualifying CAT scanners, laser surgery devices, MRI devices, pacemakers, and other medical devices. In all of these areas, software devices may be submitted for approval. The FDA is faced with consequence-management questions such as: Is society better off to have people die from heart failure in the absence of pacemakers than to have a one percent failure of pacemakers? Is such a failure rate good or bad? The FDA also has no regulatory authority over hospital informatics.3 These systems are being interconnected to medical devices. Such integration can make a low-confidence technology, such as a digital thermometer, into a critical system component requiring high confidence qualification when it is plugged into a hospital information system to control the administration of a drug. This sort of integration will be an increasingly significant issue for health care safety. Confidence in medical devices has depended critically on the expertise of the user. Manufacturers may claim that a device does not have to be high confidence because any doctor using it will catch errors. However, the next generation of nurses and doctors will not have this expertise because they have been trained using this device and rely upon it completely. Devices in the past that weren't high confidence systems (e.g., digital thermometers) are now becoming part of a system requiring high confidence; devices are being approved for one purpose and then being marketed or used for another. U.S. medical technology is a significant component of the U.S. share of the global economy. Our country has 62 percent of the global medical technology market. Regulations that affect the costs of production of such technology or its time of entry into the marketplace are of significant concern to technology producers. There are economic pressures to get safety evaluations out of the way. Such regulation is problematic when there is an inadequate understanding of what contributes to device safety. A set of expected "best practices" and complete hazard analyses of information-based safety-critical systems are needed. The FDA would like to get out of the certification business and instead require the use of established, open, standards and protocols with third-party certifiers that would be regulated by FDA. This third-party evaluation and qualification process should also reduce the time to get products approved. The international IC-1508 (draft) standard, Functional Safety: Safety Related Systems, is moving in that direction and will lead the way. Individual sectors will be required to extend IC-1508 (i.e., through the use of sub-standards). The IC-1508 standard requires documentation and responsible engineering (e.g., engineering accountability). A supplier has to make a safety case and bring it to a third-party reviewer. Europeans are leading this standard development. The IC-1508 standard is contained in seven volumes -- so absorbing, understanding, and applying the requirements of this standard is quite a hurdle. The standard is not open: the FDA had to fight for eighteen months to get an FDA person on the committee producing the standard. Hundreds of products have been through the IC Standard's certification process. In contrast, the FDA, with its 510(k) standard4, asks a company to write a plan for how it will demonstrate safety as opposed to mandating a particular process. There are few checks on what goes into such plans. Some who are experienced in safety issues think this is a better approach than a fixed certification process. The FDA also feels strongly that the certification and professional licensing of system engineers, software engineers, and safety engineers is important. The two major areas in which the FDA would like to see increased confidence are the Internet and Microsoft's Windows. The hazards that can result from operating system or Internet failures must be addressed: Today's practitioners within the health care industries assume that they can use these technologies safely in applications such as remote surgery, transferring X-rays and CAT-scans to remote doctors, and operating medical devices (e.g., one for turning surgical laser on and off). Addressing these concerns would help protect the U.S. market share in the world-wide drug and device market. Currently, U.S. producers have the market advantage, and addressing the issues of high confidence in medical devices would help preserve U.S. competitiveness and increase overall U.S. export market share of such devices. |
|
|
|
|
NIH
|
National Institutes of Health "First, do no harm!" This credo of medical practice is becoming more difficult to honor in today's technology-based medical practice.5 The medical community has no formal safety mechanisms to ensure that technology does not induce harm in their patients. This is becoming increasingly critical as medical devices move from stand-alone analog devices to more highly integrated digital systems. This problem is exacerbated when medical practitioners use commercial operating systems, such as Windows, that were never intended for use in safety-critical systems. The medical industry accounts for one-seventh of the nation's Gross National Product. Managed care is pushing the risk onto the individual patient who has the least knowledge and least leverage in the system.6 One study showed that 28 percent of patients are affected by "medical errors."7 These errors surfaced in medical rounds, the meetings in which nurses and doctors discuss things that went wrong. The rate of negligent errors may be higher today than before ...opportunities have been increased by the complexity of modern technology...8 The near future could bring large malpractice suits aimed at managed health care companies. The American Medical Association (AMA) now admits to the existence of medical error and is establishing a foundation to fund studies on medical error and research to systematically reduce it.9 The foundation will be funded through voluntary contributions from individuals. The Consortium of Hospital Informatics Manufacturers (CHIM) is an organization of vendors of medical information systems manufacturers. The vendors have developed a policy for medical information system regulation.10 American Medical Informatics Association (AMIA), an organization of hospital informatics managers, also developed a policy for medical information system regulation, including criteria and a methodology for evaluation.11 However, these policies do not deal with engineering or technical data and have no bearing on high confidence in systems. |
|
|
|
|
NRC
|
National Regulatory Commission The mission of the Nuclear Regulatory Commission (NRC) is to protect the health and safety of the public and the environment from hazardous consequences resulting from the use of nuclear materials in the U.S., and to provide for the national security of nuclear materials. The Commission addresses system assurance through system safety reviews of applicant submissions and license modifications. Nuclear Regulation 0800, Section 7, Standard Review Plan, Instrumentation and Controls, provides a standard review plan. NRC's Office of Research develops tools and the basis for technical assessment to support the reviews. The Safety Evaluation Report documents the results of these reviews assessing a licensee's conformance to standards. The report is peer reviewed by NRC management and the Reactor Committee for Safeguards before a license or a modification to a license is granted. There are 109 nuclear power plants in the U.S. These plants produce about 20 percent of the Nation's electricity. The NRC is concerned with two particular types of systems in these power plants. The first is the Operational Process Control System that controls the operation of the plant (e.g., feedwater control). The second is a separate and independent safety system that takes over in case of an operational failure and provides safe shutdown (e.g., shuts down fission process and initiates cooling if there is a threat to the safe operation of the plant). Security is associated with these systems. They use one-way, out-only communications, usually under administrative control. Such systems may also have access control imposed. Nuclear power plants have metrics of safety; for example, how often a safety trip ("scram") happens. Safety is defined only in terms of the safety trip (scram) system, not the control system. One out of every three trips is initiated by plant operators. Curiously, automatic trips are considered bad whereas operator trips are considered good. A high confidence goal could be to safely reduce the number of scrams. This could also provide economic benefits through increased safety plus lower cost of operation. The operational control and safety systems have been largely analog hard-wired systems. These systems were extremely sensitive to operate and generally took the best operator in the plant to start them. Digital control systems have been introduced to replace the older analog systems. Digital systems have increased the functionality of such control systems and have resulted in improved system operations. However, digital systems introduce new issues in the review process. For instance, safety standards were designed for the analog technology and current safety standards do not easily extend to digital control systems. What should the review plan look like for such systems? Lawrence Livermore National Laboratory (LLNL) recently completed a standard review plan to conduct reviews of digital systems. Until now, most of the standard review plans had conformance linked to analog hard-wired standards. To address these new issues in nuclear power digital control systems, the National Research Council was asked to review the safety and reliability issues associated with nuclear power plants. This study was initiated in October 1994 and a final report has been recently issued. It identified inadequate systems engineering as the source of most problems. The study proceeded in two phases: first to define issues (six technical and two strategic issues were identified); and second, to identify criteria for review and acceptance of digital instrumentation and control (I&C) technology. The six technical issues were:
|
|
|
|
|
Railroad
|
Federal Railroad Administration and State Public Utility (Railroad) Commissions13 The Federal Railroad Administration (FRA), an operating unit within the U.S. Department of Transportation, is the safety regulatory authority for the nation's freight, intercity passenger, and commuter railroads. Its regulations cover railroad operating practices, equipment, track, and train control. The freight railroads are, with the exception of a few short lines, privately owned. Amtrak, the intercity passenger operator and a contract operator of some commuter lines, is by statute a for-profit corporation, although heavily subsidized by the Federal government. It owns about 500 route miles of track in the Northeast Corridor and about 100 route miles in Michigan, and elsewhere operates on tracks owned by freight railroads or by states. Commuter railroads are generally owned by state agencies. Some of their trackage is owned outright, and some of their operations take place on track owned by freight railroads or Amtrak. The freight railroad industry was deregulated in 1980 by the Staggers Act and, as a result, has had the incentive to make substantial capital investments to improve the quality of its rolling stock and physical plant over the past 18 years. Nevertheless, train collisions and overspeed accidents continue to occur, and the National Transportation Safety Board (NTSB) has, for over a decade, been recommending that railroads install new communications-based positive train control (PTC) systems, and has been recommending that FRA issue regulations requiring that PTC be installed on the nation's railroads. The NTSB has placed PTC on its "most wanted" list of transportation safety improvements. Starting in the 1880s, U.S. railroads used track circuits to detect the presence of trains in a physical block of track, and gravity relays to pass information between blocks to preclude the presence of more than one train in a particular block. The track circuits also provide a mechanism to determine track integrity. This technology and philosophy, called "automatic block signaling" (ABS) remains in use on about 15 percent of the track in the U.S. In the 1920s railroads started to adopt "centralized traffic control" (CTC) on more heavily trafficked lines. CTC is overlaid on automatic block signals and involves the remote control of switches and signals by dispatchers at control centers. CTC is in place on about 35 percent of the track in the U.S. today. Starting in the 1930s, some railroad lines were equipped with cab signaling, in which the wayside signal indication is also displayed in the cab, and/or "Automatic Train Control" (ATC), in which there is on-board enforcement of the signal indication. Coded messages are transmitted through the rails and picked up inductively by coils mounted on the locomotive to permit the signal information to be displayed and acted on in the locomotive cab. A very small portion (less than 5 percent of total national mileage) of the ABS and CTC territory is currently equipped with such systems. In the 1970s, railroads began to use microprocessors to emulate the relays in their signal systems. Communications between relays historically took place over open wire pole lines, but more recently has used coded track circuits. About 50 percent of the railroad track in the U.S., generally with lighter traffic density, still has no signaling system in place at all and is controlled by voice radio instructions. It is referred to as "dark territory" or "Track Warrant Control" (TWC) territory. The NTSB has noted that, even though ABS and CTC signal systems are very reliable, it is still possible for individuals to make mistakes that cause collisions or overspeed accidents. In TWC and ABS territory the mistake can be made be either an engineer or dispatcher, while in CTC territory, the system prevents dispatcher-caused accidents, but a mistake by an engineer can still cause an accident. Since the early 1980s, the railroad and railroad supply industries have been conducting research and testing of PTC systems. PTC systems are made up of digital data links connecting locomotives, maintenance-of-way equipment, wayside base radios, and control centers; onboard computers, positioning systems, data radios, and display screens on locomotives and maintenance-of way equipment; and control center computers. Positioning systems on the vehicles inform the control centers of their location via the data link. The dispatcher and the control center computer issue movement authorities to the vehicles via the data link. On-board computers compare actual location with the movement authority, and if there could be a violation of the authority, the on-board computer stops the train. With traditional signal systems, the logic and "vitality" of the system reside with the relays and microprocessors along the track. With PTC, the intelligence of the system is moved to the control centers and the vehicles. Detailed track map data bases are carried in both the vehicle on-board computers and control center computers to permit comparison of real-time location with movement authorities. PTC can allow locomotive engineers to request that a switch be thrown in front of the train. The control center, before issuing the instruction to the switch, must be certain that this action will not cause derailment. Track circuits would probably be retained with PTC to provide broken rail protection. Wayside interface units provide radio communications to and from switches, and from wayside detectors and the track circuits. The PTC digital radio data links between locomotives, maintenance-of-way equipment, and wayside base radios use either VHF or UHF radio frequencies assigned to the railroad industry by the Federal Communications Commission. Messages move from the base radios along the wayside to control centers along backbone networks consisting, generally, of microwave radios, copper cable, and/or fiber optic cable that are owned by railroads or by commercial telecommunications companies. PTC systems that have been developed and tested have used a variety of positioning systems: dead reckoning using an odometer, transponders between the rails, inertial platforms, Global Positioning System (GPS), and differential GPS (DGPS). Current interest is focusing on DGPS augmentation of dead reckoning for cost and efficiency reasons. DGPS provides sufficient precision (2 meters) to differentiate between trains on parallel tracks that are typically four meters apart. FRA is cooperating with the U.S. Coast Guard and the Federal Highway Administration to expand the Coast Guard's current Maritime Differential GPS network into a Nationwide DGPS system using soon-to-decommissioned U.S. Air Force Ground Wave Emergency Network (GWEN) towers. FRA and the Coast Guard have converted a GWEN site at Appleton, WA to provide DGPS correction signals for a PTC demonstration project in the Pacific northwest. The braking system used on freight trains today uses compressed air both to provide the braking force and to provide the medium for transmitting brake application and release commands along the length of the train. In 1993, the first practical electronically-controlled pneumatic freight train braking systems were developed to provide faster, more reliable train braking and shorter braking distances. Two different approaches are currently being tested; one uses an electrical cable with connectors between each car to transmit the application and release commands, and the other uses a spread-spectrum radio on each car to transmit the commands. In both cases air hoses remain to supply air for recharging the braking system. Also, in both cases, the communications medium provides a way to transmit information about the "health" of the braking system, the car, and its contents to the locomotive where it can be sent to other locations on the railroad over the PTC digital data link. The railroad industry, using the freedoms and incentives provided by the Staggers Act, also downsized their physical plant and workforce over the past 18 years. However, the booming U.S. economy of the past several years has changed the situation on many railroad lines from one of over-capacity to one of significant capacity constraints. PTC offers the possibility of increasing the capacity on existing railroad lines by shifting from a fixed-block to a moving-block operating strategy. Studies done for the railroad industry and FRA indicate that PTC can also improve transit time, transit time reliability, and asset utilization. Major impediments to the implementation of PTC on the Nation's railroads appear to be the amount of capital required for PTC ($3 to 4 billion for the U.S. railroad industry) especially in view of other capital requirements, lack of confidence by senior executives about the reliability of the new (to railroads) PTC technology that will change the paradigm under which railroads are operated, and concern about liability if it is acknowledged that PTC systems are safer. FRA is funding PTC demonstrations on high-speed passenger corridors in Michigan and Illinois jointly with the respective state department of transportation, the development of interoperable PTC locomotive hardware by three major eastern railroads, and the first phase of a PTC implementation project on the Alaska Railroad. FRA has also initiated a rulemaking on PTC under the auspices of the Railroad Safety Advisory Committee, a collaborative rulemaking body consisting of railroads, railroad unions, railroad suppliers, and other interested parties. In conjunction with that activity, FRA is also carrying out corridor risk and business benefit analyses of PTC. |
|
|
|
|
Public Transit
|
Federal Transit Administration and State Public Utility (Public Transit) Commissions The Federal Transit Administration (FTA) is a funding agency, not a regulatory agency. Its primary role is to choose which public transit projects to fund and has a small research budget. FTA works with state and local authorities as well as contractors during project formulations to ensure the project requirements meet Federal funding standards. FTA also monitors the project implementation to ensure it stays within cost and schedule constraints. An example of such a project is the Los Angeles Green Line, which is the light rail line that runs east-west through Los Angeles County and is administered by the Los Angeles County Metropolitan Transportation Authority. The California State Public Utility requirements documented for the Los Angeles Green Line Project include the following quantitative requirements, which are characteristic of future automated train control systems:
In pursuing one train control project, researchers developed a model of hardware that the software was going to execute on, then they executed the actual software on that model to identify problems. They simulated unknown errors using fault injection techniques to exercise the exception handling and diagnostics in the software. However, still lacking is a means to obtain quantifiable safety for the complete hardware/software system. |
|
|
|
|
Highway
|
Federal Highway Administration and State Public Utility (Highway) Commissions14 The Federal High Administration (FHA) and the State Public Highway Commissions regulate transportation on the Nation's highways. Their regulatory issues are evolving toward computer-based control technology as a means to increase throughput over these highways while reducing accidents attributable to human error. Estimates of human error as a contributing factor in the Nation's 10.7 million automobile accidents each year are as high as 90 percent. Human error is attributed to more than 30 percent of the 40,000 annual fatalities that result from those automobile accidents. The U.S. Congress, through The Intermodal Surface Transportation Efficiency Act (ISTEA) of 1991, created the National Automated Highway System Consortium as a public-private effort with $200 million in funding to coordinate research in the field of automated highways. Several of its experimental projects were first demonstrated on August 6, 1997, over a seven-plus mile stretch of San Diego highway in the controlled-access car pool lanes. One experiment used inexpensive video cameras to control the hands-off driving of a bus at 45 mph, including speed changes and obstacle avoidance. Another experiment, with the goal of doubling or tripling lane capacity at high speeds, used radios and ceramic-magnets embedded in the roadway to control the distance between vehicles to create high-speed convoys with vehicle separation of as little as twelve feet. |
|
|
|
|
Endnotes |
|
|
|
|
|
|
|
