fault-tolerant input/output (i/o) networks applied to ship...

Ship Designers have already done much to place moderninformation systems aboard ships. The U.S. Navy Smartship andother projects have shown that it is both possible and beneficialto interface with and merge data from many of the ship's sub-systems.[1] These high-level information networks make it possi-ble for a small crew located in a central control room to monitorand control subsystems throughout the ship. But this alone doesnot make it possible to operate the ship with a small crew. Today,subsystems throughout the ship are manned to allow thesecrews to assume manual control and make repairs should battledamage or failures occur. Before these subsystems can be oper-ated unmanned, their dependability and damage survivabilitymust be improved substantially.

The techniques for constructing highly dependable electroniccontrols have been established by applications such as fly-by-wire aircraft flight controls. These same techniques were appliedsuccessfully to the U.S. Navy Seawolf submarine ship control.[2]

The basic approach is to use physically redundant electronicsand a fault-tolerant digital controller with sophisticated softwareto detect faults and reconfigure to use the redundancy, allowingthe system to operate despite equipment failure or damage. Theproblem with widespread application of the approach used onSeawolf is cost and complexity. Modern ships already incorpo-rate a myriad of wiring, junction boxes, electronic racks, and com-puters that are difficult and costly to install and maintain.Duplicating, triplicating, or quadrupling this equipment to pro-vide redundancy for fault tolerance is not practical.

At least a partial solution to this problem can be found by theincreased use of data multiplexing and highly miniaturized elec-tronics placed within intelligent sensors and actuators. Since thesensors and actuators are now part of a network of input andoutput devices, we refer to this arrangement as network I/O. Thedifference between a traditional system and a system that usesnetwork I/O is illustrated in Figure 1.

Fault-Tolerant Input/Output (I/O) Networks Applied to Ship Control 25

Robert Hammett

Reprinted, with permission, from the Proceedings of the 12th Ship Control Systems Symposium held in the Hague, Netherlands, October 10-21, 1999

Fault-Tolerant Input/Output (I/O) NetworksApplied to Ship Control

Future ships will require sophisticated onboard control systems tocontrol machinery, automate tasks, optimize subsystem perfor-mance, and simplify maintenance. These controls will exploit theavailability of inexpensive computer processing, will use manysensors and actuation devices, and will provide for completelyintegrated and coordinated control of all subsystems. The crew'sincreased reliance on these automated functions makes it essen-tial that they provide dependable operation despite equipmentfailure or battle damage, e.g., they must be fault tolerant anddamage survivable. An example of such a system is the U.S.Navy Seawolf submarine ship control. But the redundant sensorsand actuation systems used on Seawolf, with their associated elec-tronics and wiring, must be made more compact and affordablefor the approach to find widespread use on future ships. Thispaper describes how the use of data buses, intelligent sensors,and fault-masking actuation electronics can be used to constructInput/Output (I/O) networks that provide flexibility and growth,and that are highly dependable, affordable, and easily installed.These I/O networks can make widespread use of fault- and dam-age-tolerant systems practical. The use of I/O networks comple-ments other efforts to make greater use of electrical actuationaboard ships. This paper explores the requirements for such sys-tems and examines some of the technology trade-offs that mustbe made, such as network media type (i.e., optical fiber, wired, orwireless), power distribution to network electronics, networktopology (ring or bus), network size vs speed, distributed vs cen-tralized I/O processing, and cross connections between I/O chan-nels. The paper concludes by describing a concept for afault-tolerant network I/O system and discusses the steps neededto develop such systems for future ships.

ntroduction

As illustrated in Figure 1, using the network I/O approach, theanalog sensors and actuators that interface with data acquisi-tion and actuator control electronic units by dedicated wiringare replaced by "intelligent" sensors and actuators that com-municate over a shared digital data bus. An obvious advan-tage of this approach is a reduction in the amount of wiringand connectors needed. For fault- and damage-tolerant sys-tems, the reductions are increased by the number of redun-dant I/O devices needed. Less obvious but of equal or greaterimportance is the ability to program these intelligent I/Odevices to perform I/O processing functions such as signalprocessing (linearization, calibration, filtering, etc.), fault de-tection and self tests, self identification, and actuator com-mand fault masking. The later of these, actuator commandfault masking, makes it possible to ensure that an actuatorsuch as a valve will operate correctly despite any single elec-tronics failure.

DEPENDABILITY REQUIRED OF THE I/O NETWORK

A fundamental question when designing a system to be faultand damage tolerant is "what degree of dependability isneeded?" Designing a system to recover from a few obviousfailure conditions is a far easier problem than providing thelevel of dependability needed for life-critical applications,such as a fly-by-wire aircraft. Often, the way in which a systemis allowed to fail is of as great a concern as if it can fail. Forexample, failure of a weapon system to operate is of less con-cern than premature detonation of that weapon aboard theship. So in this case, we would say that we require a very lowprobability of premature operation, but can tolerate a higherprobability that the system will fail to operate. Similarly, anunexpected shutdown of a turbine engine is less of a problemthan an explosive overspeed condition of the engine. In thiscase, we can tolerate the loss of function, but must design thesystem to avoid the overspeed malfunction. Yet other func-tions can have catastrophic consequences only if they fail tooperate at the proper time, such as in response to an emer-gency condition like a fire or flooding casualty. Another mea-sure of system dependability is found in the rate at which false

alarm conditions are reported. Examples of false alarmsinclude a false indication to an operator that equipment isfaulty or an automatic reconfiguration to discontinue usingequipment that is not faulty. To summarize, some of the fail-ure modes that must be considered when designing a fault-and damage-tolerant system include:

• Loss of function while operating.

• Malfunction while operating.

• Premature operation.

• Failure to operate at the proper time.

• Failure to cease operating at the proper time.

• False alarms.

• Degraded operation.

A useful concept is that of categories of function criticality.Borrowing from the aircraft industry, three levels of criticalitycan be established: Critical, Essential, and Nonessential. A non-rigorous definition of each is as follows:

• Critical: malfunction or loss of function endangersthe crew or the ship.

• Essential: malfunction or loss of function requiresimmediate and effective action by the crewto prevent endangerment of the crew orship.

• Nonessential: malfunction or loss of function will have nodirect effect on the safety of the crew or ship.

It has been established by general practice that the only typeof system suitable for critical functions are those that useTriple Modular Redundancy (TMR). A TMR system (Figure 2)makes use of three redundant channels of control and relieson a mechanism to "vote" the output of these strings and tooperate the system based on a two-out-of-three consensus ofthe channels. Dual-redundant systems can be constructedthat provide protection against malfunction or prematureoperation, but are limited in their ability to protect against aloss of function while operating.

Fault-Tolerant Input/Output (I/O) Networks Applied to Ship Control26

Actuators

DedicatedWiring

ControlComputer

ControlComputer

Data Acquisition andActuator ControlElectronics

IntelligentActuatorsIntelligent SensorsSensors

MiniaturizedActuatorControlElectronics

MiniaturizedDataAcquisitionElectronics

SharedBusWiring

Typical Data Acquisitionand Actuator Control Electronics

Network I/O Data Acquisitionand Actuator Control Electronics

Figure 1. Network I/O approach reduces wiring and connections.

SUBSYSTEM CONTROL REQUIREMENTS

Before investigating how I/O networks can be applied to pro-duce affordable fault- and damage-tolerant subsystem con-trols for ships, it is important to define the types of systemsthat are to be controlled and to establish some basic I/Orequirements for these systems. Table 1 summarizes systemsthat are candidates for control or monitoring using I/O net-works and lists a few of the basic control system functionsrequired. Tables 2 and 3 list sensors and actuators needed tosupport these functions. Typically, for control applications, thesensors and actuators are sampled/updated at rates of 1 to 10times per second.


If A = B = C, Then X = A or B or CIf A = B ≠ C, Then X = A or B,If A ≠ B = C, Then X = B or C,A = C ≠ B, X = A or C,

no failureC is failedA is failedB is failed

Table 1. Subsystem control functions supported by network I/O.

Propulsion • Machinery speed control• Pressure and temperature limiting• Torque sensing/limiting• Startup/shutdown sequencing• Performance monitoring (vibration, temperature, oil quality, etc.)

Electrical Power Generation, Distribution, and Control • Voltage and frequency regulation• Load management/load shedding• Short circuit detection and recovery• Damage detection/reconfiguration• Performance monitoring (normal current loading, temperatures, vibration, etc.)

Fire Detection and Suppression • Smoke, heat, flame detection• Suppression agent activation• Readiness testing

Flooding Detection and Control • Seawater intrusion detection• Pump activation and flow routing• Readiness testing

Weapons Handling Machinery Control • Conveyor and lift control• Sequencing• Stores inventory measurement

Miscellaneous Winches, Lifts, Elevators, Cranes • Electric motor control• Sequencing• Performance monitoring (vibration, oil quality, actuation speeds, etc.)

Mechanical Fluid Systems• Hydraulic power• HVAC• Liquid cooling (chilled water, sea water)• High- and low-pressure compressed air• Steam

• Electrical motor control• Pressure control and monitoring• Temperature control and monitoring• Flow control/diversion• Performance monitoring (temperatures, vibration, oil quality, flow rates, etc.)

A

C

B X

Redu

ndan

t Sen

sors

Figure 2. TMR systems provide highly dependable operation.

NETWORK I/O DESIGN TRADE-OFFS

The design of an effective network I/O system requires theinvestigation and evaluation of a number of alternatives. Afew of these selected for discussion in this paper are:

• Network media selection.

• Powering the I/O network electronics.

• Network topology.

• Network data rate requirements.

• Centralized or distributed I/O processing.

• I/O channel cross-strapping.

NETWORK MEDIA SELECTIONThree good choices are available for the network media: opti-cal fiber, copper wire, and wireless (RF or Infrared (IR)). Eachoffers advantages, and all have drawbacks. It is likely thatfuture ships will make use of all three, matching the strengthsof a particular media to a specific problem. The following arethe trade-offs between these media, with advantages preced-ed by a plus (+) sign and disadvantages preceded by a minus(-) sign.

Optical Fiber

+ Supports very high data rates.

+ Insensitive to Electromagnetic Interference (EMI).

+ Does not propagate electrical faults (electrically isolated).

- Optical signal is attenuated by connectors and splitters.

- Attenuation makes fiber poorly suited to bus topologies(see I/O Network Topology).

- Requires complex terminals.

- Installation is complicated if wires are needed to power theterminal.

Wire

+ Small, low-cost terminals are available.

+ Wiring can deliver power in addition to data.

+ Electrical connections are easy to make.

- Limited speed compared to optical fiber.

- Requires shielding from EMI.

Wireless (RF and IR)

+ Very low cost to install (no wiring or fiber).

+ Small, low-cost RF electronics are available.

- To remain wireless, requires a battery (needs replacement)or power scavenging.

- Vulnerable to EMI (RF).

- Vulnerable to optical path obstruction by smoke, dust,equipment, or personnel (IR).

- Limited bandwidth compared with wire or fiber.


Table 2. Potential sensors requiring network I/O interfaces.

Table 3. Potential actuators requiring network I/O interfaces.

• Pressure• Temperature• Shaft speeds• Linear and rotary positions• Limit switches• Flows• Liquid levels• Voltages• Currents• Switch positions• Lever positions

Valve Control (modulated and two position)• Hydraulically actuated• Pneumatically actuated• Electromechanically actuated (EMA)

Linear Actuator Control (modulated and two position)• Hydraulically actuated• Pneumatically actuated• EMA

Electrical Switching and Contactors• Solid-state• Electromechanical

Electric Motors• ac and dc• Fixed and variable speed, indicators, lamps, displays

• Vibration• Acoustic• Strain• Oil quality (conductivity, other)• Smoke• Heat• Flame (IR)• Seawater intrusion (conductivity)• Joysticks• Keypads• Barcodes, other ID devices

POWERING THE I/O NETWORK ELECTRONICSThe sensors and actuation control devices that make up thenetwork require electrical power to operate. For sensors, pow-er is used to power the sensor and the terminal used to trans-mit its data. In the case of actuators, two types of power areneeded: power to operate low-power actuator control elec-tronics and the network data terminal, and power to operatethe actuator. Several options for delivering power to networkI/O terminals are:

• Tap into the nearest source of ship’s power.

• Distribute power as part of the data network.

• Power the devices with batteries or other wireless sources.

The strengths and weaknesses of each option are compared.As before, advantages are preceded by a plus (+) sign and dis-advantages are preceded by a minus (-) sign.

Connect Network to Nearest Ship's Power

+ Established practice.

+ Unlimited power available.

+ Power already needed by network I/O actuators.

- Ship’s power can become a network I/O single point of fail-ure.

- If network I/O controls the power (a desired capability), fail-ures can cascade.

- Wiring to ship’s power is expensive to install.

- Ship’s power can transmit EMI or transient dropouts into thedata system.

Dedicated Wiring as Part of I/O Network

+ Combine installation of data and power wiring.

+ Provides sensors with dedicated, uninterruptible power.

+ Can power up sensors and actuation control for checkoutprior to applying main power.

+ Allows actuator node to detect/report problems with actu-ation power.

- Adds wires or increases wire gauge, may constrain maxi-mum size of an I/O network.

Battery

+ Network devices are very easy to install.

- Requires periodic battery replacement.

- Limited power available.

- Batteries may be large and temperature sensitive.

- Many battery chemistries are explosive, corrosive, andexpensive.

A preliminary conclusion, at least for sensors, is that includingpower distribution along with the data network offers thebest combination of ease of installation, network dependabil-ity, and system maintainability. This option becomes particu-larly attractive if the same electrical conductors can be usedfor both the power and the data.

I/O NETWORK TOPOLOGYSelecting an appropriate topology for the I/O network is animportant design consideration. Two viable topologies arethe ring and the bus. These two options are illustrated inFigure 3. Examined closely, the ring topology consists of aseries of dedicated, one-way data links from each terminal tothe next. Ultimately, the last terminal is linked to the first toform a ring. Data are sent from terminal to terminal by havingeach terminal rebroadcast any message that is not directed toit to the next terminal until the final destination is reached.The terminal that receives the message "absorbs" it; that is, itdoes not rebroadcast it. As an example, for terminal A to senda message to terminal B, it sends the message to terminal C onthe link from A to C, then terminal C rebroadcasts the messageto terminal B. A primary motivation for using a ring topologyis that each time the message is rebroadcast, its signalstrength is restored. This is ideal for fiber-optic media, whereeach physical terminal connection could otherwise attenuatethe signal until it became too weak to be received.

In contrast, the bus architecture uses a common physical link,the "bus," to connect all terminals to each other. Terminalsmust take turns using the bus to transmit messages directly toanother terminal(s). A subtle advantage of the bus over thering is that the bus can convey power as well as data to eachterminal on the bus. Table 4 makes a few comparisonsbetween the single-channel nonredundant ring and single-channel bus topologies shown in Figure 3.

Table 4 highlights that a number of single failures can disablethe entire network. For critical functions, this is unacceptable.To overcome vulnerability to single failures, redundancy isintroduced. For the ring topology, a proven approach is theuse of a redundant, counter-rotating ring and the addition ofa special switch that will bypass the terminal should the ter-minal fail or have its power interrupted (Figure 4). If a link isbroken, a terminal must detect this and reroute data through


Ring Topology

BusTopology

Figure 3. Ring and bus topologies.

the other ring to reach the destination terminal. The dual ringtherefore uses "active" reconfiguration to achieve fault-toler-ance. If a single computer is controlling the terminal, the oper-ation of the network is dependent on that computer, both tocorrectly reconfigure the network and to not malfunctionitself. As an example of a computer malfunction, the dual net-work would be disabled if the terminal were to transmit at thewrong time ("babble") on both rings.

Similarly for the single-channel bus topology, allowing failureof the bus data path to interrupt all communications is unac-ceptable. Adding a second redundant bus can correct theproblem, but also requires "active" reconfiguration to deter-mine when the backup bus should be used. So as for the dualring, if a single computer controls both terminals, both redun-dant buses may be corrupted by a faulty computer, disablingthe entire network.

As previously introduced, applications that require absolutedependability make use of TMR. Such systems have been con-structed using triple data buses for many years, e.g., the U.S.Space Shuttle and all fly-by-wire aircraft flight controls. Theuse of TMR with buses is illustrated in Figure 5.

Note in Figure 5 that each bus terminal contains its own com-puter and that the system has been carefully segmented intoindependent channels. On the actuator side of the network, amajority voting device has been used to allow the actuator torespond to only a two-out-of-three consensus of bus com-mand messages. Although implementation of the votingdevice will not be discussed, it can be constructed as a "pas-sive" device that simply responds to the majority and does nothave single points of failure.

Table 5 makes a summarized comparison of the single, dual,and TMR options. Single failures that lead to network failurehave been highlighted. Only TMR resists all single failures.


Table 4. Comparison of single-channel bus and ring topologies.

Consequence of failure of a terminal to transmit Network disabled Loss of use of one terminal(or loss of power to the terminal)

Uncontrolled broadcasts by a terminal (babbling) Network disabled Network disabled

Failure of data path between terminals (opened or shorted) Network disabled All or part of the network disabled

Worst-case number of transmissions to pass one message All terminals on the ring must transmit One terminal transmits(requires power)

Number of optical or wire connections to each terminal Two optical fibers or wire pairs One wire pair connected to each terminal

Bypass

Bypass

Bypass

Bypass

Normal

Bypass

Bypass

Bypass

Ring #1

Ring #2

Deta

ils o

f Byp

ass S

witch

Ope

ratio

n

Figure 4. Dual counter-rotating ring network topology.

NETWORK DATA RATE REQUIREMENTSThe speed required of the network depends on the number ofI/O devices on the network, the amount of data to or fromeach device, and the repetition rate at which it must be sent.Although modern data network electronics are capable ofhigh data rates at reasonable cost, it is still not practical todedicate a data transmitter and supporting electronics capa-ble of gigabit-per-second rates to a single sensor. And as thedata rate increases, the length of data bus wiring must be lim-ited, and more expensive and less durable cabling is needed.Fiber optics overcomes some of these disadvantages, butintroduces other difficulties as previously discussed.

A key consideration is the total number of I/O devices on agiven network. A large ship might require thousands of I/Odevices, but this does not mean that each I/O network mustsupport very high data rates. Consider Figure 6, which illus-trates the use of a few large I/O networks compared with alarger number of smaller I/O networks.


Table 5. Comparison of simplex, dual, and TMR using rings and buses.

Redu

ndan

t Sen

sors

Actuator

Internal Details of Bus Terminal (BT)

Terminal Fails to Transmit Network Disabled Network Disabled Normal Operation After Normal Operation After Normal Operation WithActive Reconfiguration Active Reconfiguration Passive Reconfiguration

Uncontrolled Terminal Network Disabled Network Disabled Normal Operation After Normal Operation After Normal Operation WithTransmit Active Reconfiguration Active Reconfiguration Passive Reconfiguration

Media Failure Network Disabled All or Part of Normal Operation After Normal Operation After Normal Operation WithNetwork Disabled Active Reconfiguration Active Reconfiguration Passive Reconfiguration

Wrong Command Actuator Responds to Actuator Responds to Actuator Responds to Actuator Responds to Normal Operation-is Transmitted Incorrect Command Incorrect Command Incorrect Command Incorrect Command Fault is Masked

Number of Physical 2 1 4 2 3Connections Required

Ship’s Wide Area Network

Intelligent Sensors and Actuators

A Few Large I/O Networks

Many Small I/O Networks

I/O Networks

Figure 6. Alternative sizes of I/O network’s impact network speed required.

Figure 5. TMR system using bus topology.

Using many small I/O networks will directly reduce therequired data rate of each network. And there are many oth-er reasons to limit the size of the networks. One is to limit theextent of the effect of failure or battle damage to one smallnetwork. Another is that many types of network terminalsimpose limits on the number of devices that can be on onenetwork due to addressing limitations or electrical fan out.Also, if it is desired to provide power to the network terminalsover the same wiring as the data, the number of terminalspowered by the network wiring must be limited. By assumingan I/O network size of one hundred terminals per network,that each device transmits or receives 12 8-bit bytes of data,and that the average frequency of transmission is 10 times persecond, it follows that:

Data rate = 100 devices x 12 bytes x 8 bits/byte x 10updates/s x 1.5 efficiency

= 144,000 bits/s

Since very low-cost terminals are available that can supportdata rates up to 1 Mb/s, smaller I/O networks can be built withreadily available and low-cost components. The conclusion isthat there is little motivation to use a very high data rate net-work.

I/O PROCESSING – CENTRALIZED OR DISTRIBUTED?

Since the I/O network introduces individual sensors and actu-ators with a network terminal containing at least rudimentaryprocessing capability, the question becomes how might thisprocessing be used to best advantage? Potentially, the pro-cessing can be used to offload or even eliminate the need forcentralized I/O processing. In the extreme, distributed pro-cessing could completely replace the need for any type ofcentralized processing by allowing "intelligent" sensors tocommunicate directly with intelligent actuators to control thesystem, but this discussion is limited to what I/O processingfunctions might be distributed. Table 6 lists traditional I/Oprocessing functions that might be distributed.

As before, the trade-offs between distributed and centralizedI/O processing are listed:

Centralized

+ Established approach.

+ Provides access to system-wide information to detect/iso-late faults, correct sensor outputs.

+ Avoids interaction of complex software in multiple proces-sors.

+ I/O devices are kept simple, small, and lowest cost.

- I/O design changes require central computer softwarechanges.

- I/O repairs (replacement) can require central computer soft-ware data changes.

- Sending raw data rather than processed information con-sumes network bandwidth.

- Centralized closed-loop control can be problematic.

Distributed

+ High-level interface between sensor/actuator and centralprocessor (information, not data).

+ Promotes the use and reuse of standard I/Ocomponents/processing functions (plug and play).

+ Allows interchange of sensor/actuator units from differentvendors without software changes.

+ I/O-specific processing and data contained within I/O unit(simplifies replacement).

+ Sensor can preprocess raw data into compact or low-rateform for transmission.

- Not practical to provide access to system-wide informationfor complete self-test.

- Can introduce complex interaction between central anddistributed processors.

- Can require reprogramming of each I/O device with appli-cation-specific logic.

The only conclusion to be drawn from this limited investiga-tion is that there are many advantages to distributing I/O pro-cessing, but also limitations and concerns. For simplefunctions, such as linearization and filtering, these can be dis-tributed easily and offer many benefits. Distributing complexlogic, such as self-test and closed-loop control, requiresgreater caution during system design.

I/O NETWORKS – CROSS CONNECTING DATA BETWEEN CHANNELSPreviously, it was shown how a well-designed TMR system ispartitioned into channels to prevent fault propagation. Thereare, however, reasons to consider providing data pathsbetween individual intelligent sensor and actuator terminals(see Figure 7).


Table 6. List of I/O processing functions.

• Sensor linearization

• Sensor temperature and excitation level correction

• Filtering and averaging (simple and Digital Signal Processor (DSP))

• Individual sensor self-tests (range, rate, etc.)

• Redundant sensor comparisons (self-test and sensor selection)

• Calibration verification/correction

• System-level fault isolation/reporting

• Local actuator closed-loop control• Local actuator control sequencing• Network data error detection/recovery• Network data time-out detection• Local power monitoring• Equipment heath monitoring• Terminal self-identification• Terminal self-test

The trade-offs are:

System Without Cross Connections

+ No potential for faults to propagate between channels(electrical or data).

- Many two-fault conditions can lead to system failure.

- Distributed I/O processing is limited to what can be per-formed with only one channel of data.

System with Cross Connections

+ System can be made tolerant of most two-failure condi-tions.

+ Adjacent channel data provides many options for distrib-uted I/O processing.

+ Adjacent channels can monitor each other's health, localizenetwork failures.

- Adds hardware (size, weight, cost, power) to network I/Osystem.

- Requires isolation to avoid fault propagation betweenchannels.

It is believed that with careful design, both the added hard-ware and the potential for fault propagation can be mini-mized. The benefits of having the cross connections outweighthese costs.

CONCEPT FOR A FAULT-TOLERANT NETWORK I/O SYSTEM

In the previous discussions, it has been shown that many alter-native design solutions exist for creating I/O networks. No sin-gle solution will be optimal for all applications. Yet there arecompelling reasons for pursuing a system design based on asingle approach, using interchangeable components with astandard interface. With the understanding that no singleapproach will be optimal and that technological advancescould render some of these conclusions obsolete, this sectiondescribes a concept for a fault-tolerant network I/O system.The following are the design requirements:

• The network I/O system must be designed to support func-tions that are critical; that is, malfunction or loss of the func-tion endangers the crew or the ship. Providing this level ofdependability requires a TMR network I/O architecture.

• The primary network media will be copper wire. Fiber-opticand wireless media will be used to a lesser extent to sup-port special installation requirements.

• The network topology will be buses rather than rings. Aring topology complicates the installation of wiring andpower distribution, places too much dependence on thesurvival of individual network terminals, and makes eachterminal larger, more costly, and more power consuming.

• The network will supply dedicated power to the I/O net-work terminals over the same copper wire network used totransmit data.

• The ship will use many small I/O networks. The size of thesenetworks will be limited to the maximum of several hun-dred terminals and a data rate of below 1 Mb/s.

• The capability to cross-strap individual sensors and actua-tion terminals is provided.

Figure 8 illustrates an overall system concept that meets theserequirements.

CONCLUSIONS

The use of fault-tolerant I/O networks shows great promise forproviding highly automated and completely dependable con-trol systems for ships. There appear to be few major techno-logical barriers to the development and introduction of thesenetworks. Many of the components needed are emergingfrom the development of industrial and automotive data mul-tiplexing, data acquisition, and control systems. But theseapplications do not have the requirement for fault and dam-age tolerance, nor are the environmental requirements asdemanding. There is a need for a substantial engineeringdevelopment effort. Realizing the full benefits of theapproach will require highly integrated, miniaturized, and


Redu

ndan

t Sen

sors

Actuator

Figure 7. Adding cross connections between network terminals.

harsh environment electronics, produced at moderate cost,that are not currently available "off the shelf." Commercial-off-the-shelf products will only appear after visionary developershave proved the concept with a successful "first-of-its-kind"system. This paper is intended to stimulate interest in such adevelopment.

REFERENCES

[1] Moschopoulos, J., "Advanced Integrated Control andInformation Systems in the U.S. Navy," Eleventh ShipControl Systems Symposium, Southampton, UK, 1997.

[2] Hammett, R., "Seawolf Ship Control PerformanceMonitoring Provides Fault Tolerance and Simplified Main-tenance," Intelligent Ships Symposium II, Philadelphia,1996.


NetworkTerminalPowerSupplies

Separate Source ofActuation Electrical Power

Bus “Spurs” into Harsh or Vulnerable Areas

Triple Twisted Copper Wire Bus NetworkSupplying Data and Terminal Power(Routed and Shielded for Survivability)

Simplex Sensor or ActuationNode (Nonessential Function)

Dual Redundant Sensor or Actuation Node (Essential Function)

Network Control Computers

Triple Redundant Sensor or Actuator Node (Critical Function)

Figure 8. Concept for a complete network I/O system.

Fault-Tolerant Input/Output (I/O) Networks Applied to Ship Control: Biography 35

Robert C. Hammett is a Principal Member of the Technical Staff at DraperLaboratory. He has degrees in both Mechanical and Electrical Engineering. Mr.Hammett has 22 years experience in the design, development, test, and manu-facture of electronic control systems for aircraft, ships, and space applications. Hehelped pioneer the development of the first Full-Authority Electronic Engine

Controls (FADEC) for jet engines. These FADECs were first-of-a-kind systems that represented asignificant step forward in the use of digital electronic controls for life-critical applications. Hewas responsible for defining the fault detection, isolation, and recovery (FDIR) software thatmakes these FADECs fault tolerant and provides built-in-test features that enhance maintain-ability.These designs are in use today on aircraft such as the Boeing 757, 767, and 777. At Draper,he has developed fault-tolerant controls for several unmanned underwater vehicles, the Seawolfsubmarine, and the Kistler space launch vehicle. For the Seawolf, he was responsible for thedevelopment, test, and deployment of the performance-monitoring functions that detect faults,manage redundancy, and provide maintenance advisory information. The Seawolf was also aunique first-of-a-kind system, using a fault-tolerant computer and redundant I/O electronics toprovide a "swim-by-wire" system. Recently, Mr. Hammett has been the principal architect of theVehicle Health Management (VHM) software for the Kistler launch vehicle and a health man-agement system for a fault-tolerant unmanned underwater vehicle. He is currently the techni-cal lead of a NASA program to develop I/O networks similar to those discussed in this paper forfuture space vehicles.

obert C. Hammettbi

ogra

phy

fault-tolerant input/output (i/o) networks applied to ship...

Documents