2000 - Draper Laboratory

Using many small I/O networks will directly reduce therequired data rate of each network. And there are many otherreasons 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/sSince 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 network.I/O PROCESSING – CENTRALIZED OR DISTRIBUTED?Since the I/O network introduces individual sensors and actuatorswith a network terminal containing at least rudimentaryprocessing capability, the question becomes how might thisprocessing be used to best advantage? Potentially, the processingcan be used to offload or even eliminate the need forcentralized I/O processing. In the extreme, distributed processingcould 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/isolatefaults, correct sensor outputs.+ Avoids interaction of complex software in multiple processors.+ 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 softwaredata changes.- Sending raw data rather than processed information consumesnetwork 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 application-specificlogic.The only conclusion to be drawn from this limited investigationis that there are many advantages to distributing I/O processing,but also limitations and concerns. For simplefunctions, such as linearization and filtering, these can be distributedeasily 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-test32Fault-Tolerant Input/Output (I/O) Networks Applied to Ship Control