robotic vehicle communications interoperability

N

No. 13387

ROBOTIC VEHICLE COMMUNICATIONS INTEROPERABILITY

AUGUST 1988

4

Daniele MarianiU.S. Army Tank-Automotive CommandATTN: AMSTA-RRT

By Warren, MI 48397-5000

APPROVED FOR PUBLIC RELEASE:DISTRIBUTION IS UNLIMITED

U.S. ARMY TANK-AUTOMOTIVE COMMANDRESEARCH, DEVELOPMENT & ENGINEERING CENTERWarren, Michigan 48397-5000

0), a ca330 F(

UnclassifiedSECURITY CLASSIFICATION OF THIS PAGE

REPORT DOCUMENTATION PAGE Form Approved

I - I0MS Nc. 07,14-0 188Ia. REPORT SECURITY CLASSiFiCATION Ib. RESTRICTIVE MARKINGS

Unclass-ifiedI

2a. SECURITY CLASSiFiCATION AUTHORITY 3. DISTRIBUTION /AVAILABILITY OF REPORT

Approved for Public Release:20. DECLASSiFICATIo/DowNGRADING SCHEDULE iDistribution is Unlimited

4. PERFORMING ORGANIZATION REPORT NUMBER(S) 5. MONITORING ORGA\;ZATION REPORT NUMBER(S)

6a. NAME OF PERFORMING ORGANIZATION 6b. OFFICE SYMBOL 7a. NAME OF MONITORING ORGANIZATIONU.S. Army Tank- (If applicable)

Automotive Command IAMSTA-RRT U.S. Army Tank-Automotive CommandSc. ADDESS (City, Stare, and ZIP Code) 7b. ADDRESS (City, State, and ZIP Code)

Warren, rI 483197-5000 Warren, MI 48397-5000

8a. NAME OF FUNDING/SPONSORING 8,. OFFICE SYMBOL 9. PROCUREMENT INSTRUMENT IDENTIFICATION NUMBERORGANIZATION (if applicable)

8c. ADDRESS (City, State, and ZIP Cooe) 10. SOURCE OF FUNDING NUMBERSPROGRAM PROJECT TASK WORK UNITELEMENT NO. NO. NO. ACCESSiON NO.

11. TITLE (Inciude Security Classification)

Robotic Vehicle Communications Interoperability (u)12. PERSONAL AUTHOR(S)

rMariani, D ani• e le13a. TYPE OF REPORT 13b. TIME COVER'ED 414. DATE OF REPORT (YearMonth,Day)I S1. PAGE COUNT

F inaI FR~OM- D ec _ý7 To Auq 84 August 1988 10816. SUPPLEMENTARY NOTATION

17. COSATI CODES 18. SUBJECT TERMS (Con-inue on reverse if necessary and idenufy by block numoer)FIELD GROUP SUB-GROUP Robotic communications Communication protocols

Communications interoperabilityI I19. ABSTRCT (Continue on reverse if necessary and identify by block number)

Communications interoperability (CT) amongst different roboticvehicle systems would provide many benefits to the roboticsdevelopment and user communities. This report takes a firststep towards CI by proposing protocols for a communicationsinterface standard for robotic vehicle communication systems.

20. DISTRIBUTION/AVAILABILITY OF ABSTRACT 21. ABSTRACT SECURITY CLASSIFICATION•UNC•.ASSIFIEDAJNLIMITED [ SAME AS RPT. E DTIC USERS Unclassi fied

22a. NAME OF RESPONSIBLE INDIVIDUAL 22b. TELEPHONE (include Area Code) 22c. OFFICE SYMBOLDaniele Mariani (313) 574-5798 AMSTA-RRT

DD Form 1473, JUN 8S Previous editions are obsolete. SECURITY CLASSIFICATION OF THIS PAGE

Unclassified

NOTICES

This report is not to be construed as an official Department of the Armyposition.

Mention of any trade names or manufacturers in this report shall not beconstrued as an official endorsement or approval of such products orcompanies by the U.S. Government.

Destroy this report when it is no longer needed. Do not return it tothe originator.

TABLE OF CONTENTS

Section Page

1.0. INTRODUCTION ................ ................. 9

2.0. OBJECTIVE ................. .................. 9

3.0. CONCLUSION . . ................... 9

4.0. RECOMMENDATIONS .................. 10

5.0. DISCUSSION. .............. . . . . .I..... i15.1. Interoperability . . . . . . ....... ii5.2. Robotic Vehicle System Functions . . . . . 335.3. Representation of the Compiled Information 395.4. Protocol Testing . . . .......... . 50

SELECTED BLIOGRAPHY . .. ........ ............. 51

APPENDIX A. CONTROL/STATUS OF MANNED MILITARYVEHICLES .......... ............... A-i

APPENDIX B. CONTROL/STATUS REQUIRED FOR ROBOTICVEHICLE SYSTEMS ....... ............ B-i

APPENDIX C. CONTROL COMMAND !ODING .... ......... C-IAPPENDIX D. STATUS INFORMATI.N CODING ... ....... D-I

DISTRIBUTION LIST .......................... Dist-I

ai

/3

LIST OF ILLUSTRATIONS

Figure Title Page

5-1. Environmental Obscurations .... ............ 16

5-2. The OSI Reference Model ........... . 20

5-3. Frame Formats . . . . ............. 26

5-4. Simplified SDLC ......... ............... 28

5-5. Candidate Message Formats . . ........ 41

5-8. Proposed Message Format . ........... 46

5-9. Complete Data Packet .............. 51

5

LIST OF TABLES

Table Title Page

5-1. Designation of Electromagnetic Waves . ... 15

5-2. Data Link Layer Protocols . . .......... 27

5-3. Data Unit Codes ............... 32

5-4. Robotic Vehicles Studied . ....... ... 36

5-5. Message Format Comparison ... ........ ... 44

7

1.0. INTRODUCTION

This technical report, prepared by the Robotics Division ofthe U.S. Army Tank-Automotive Command (TACOM), describescommunications interoperability (CI) between differentrobotic vehicle systems, and also different roboticmodules. It does this by proposing protocols for acommunications interface standard for robotic vehiclecommunication systems.

"Interopefability is critical to the Army's roboticsprogram." Achieving CI will provide three major benefits.The first is the more effective deployment of roboticsystems. The second is the significant enhancement oftesting and demonstrations. And the third is a reductionin the cost of developing and building these systems.

2.0. OBJECTIVE

The primary goal was to propose a communications interfacestandard, consisting of a set of protocols and a uniquemessage format, that will lead to CI.

3.0. CONCLUSIONS

This study offers the following conclusions:

"* The development and adoption of a communica-tion interface standard is a better approachto CI than the use of translators.

"* Now is a good time to develop and test proto-cols for robotic vehicle communicationsbecause many robotic systems are still in theýtestbed stage.

• The use of a robotic vehicle communicationsubsystem suggests that:

- The separation of the video imagery fromthe command and control data allows thecommand and control data to be transmittedon a separate, lower frequency carrier inthe VHF band. There are advantages totransmitting in this band.

1 Captain Rick Lynch, Program review at TACOM,

Warren, Michigan, 23 October 1987

9

- A digital comminication system issuperior to an analog one for the commandand control of rdbotic vehicles.

* A simplified v~rsioh of Synchronous Data LinkControl (SDLC) Is the mbst efficient datalink layer protocol.

• A protocol for the network layer is notcurrently needed, but may be added at a latertime.

* A transport layer protocol which adds a two-byte header to the message will provide theneeded transport ser-Oices.

* A block message fortiit, developed and com-piled in this report, is superior to a fixedor variable length !,essage format because:

- The use of high-leVel commands allowsfor the ability to add additional commandsand the capability to use the message forany application. It is extremely flexibleand will not become obsolete.

- It reduces the bandwidth requirements ofa communication subsystem on a complexrobotic vehicle.

- It allows for the use of commands whichcan be ordered by priority.

a Automating functions is a way of reducing thebandwidth requirements of the communicationsystem.

4. 0. RECOMMENDATIONS

Based on the results of this investigation, the followingrecommendations are submitted:

a A communication interface standard should beused in order to achieve CI.

* The protocols and message format proposed inthis report should bi evaluated and testedfor application to robdtic vehicle systems.Revisions should thqn e made to ensure, thatoptimum protocols at Available for systemsthat will be fielded.

i I I I

"* For a robotic vehicle communication sub-system:

- Video imagery and command and controldata should be separated, at least untilpractical image compression becomesavailable. The command and control datashould be transmitted in the VHF band.

- Digital communications should be used.

o A simplified version of SDLC should be usedas the data link layer protocol.

"* A block message format should be used todigitally represent the control commands andthe status information that passes between acontrol station and an RV.

"* As many functions on-board the roboticvehicle as possible should be automated.

5.0. DISCUSSION

5.1. Interoperability

5.1.1. Standard vs. Translator. Achievinginteroperability requires one of two approaches:

"* Have each entity talk in its own language, andhave a "translator" interpret the language itreceives.

"* Develop and adopt a communications interfacestandard.

Each of these two approaches has advantages. Using thetranslator is the best way to achieve CI for a roboticvehicle (RV) system that has already been built. It wouldbe costly to redesign an existing system so that it wouldmeet a standard's specifications.

Adopting a standard, however, is a better approach forsystems which have not yet been built because it is moreefficient, and it will result in cost savings.

Without a standard, most developers will design theirsystem with no concern for communications interoperability.Then at a later time they will need to implement atranslator. Designing to an existing standard will savetime and money down the road.

ii

A different translator would be needed for every systemthat is talked to. Also, itwould need to be modified withthe changes in functionality of every vehicle.

Using a standard cuts out one step in the communicationprocess. With the translator, there is a "middle man"between the two entities that are communicating. Using astandard allows the two to'#speak" directly to each other.

Building a communication system to standard specificationswill result in several types of cost savings. The first isin the design of communication/control subsystems. Sincethe communication interface to be used will be described inthe standard, it will not nee4 to be designed.

The second savings will be in hardware and software costs.All communication systems adhering to the standard willhave common hardware and software. Once the software iswritten and the hardware developed for one system, they canbe used at minimal cost for other common systems.

Also, the best way to keep costs down is throughcompetitive procurement. To, achieve the cost savings ofcompetitive procurement, and to get the highest performancepossible, a high degree of compatibility between.contractor's subsystems will be necessary. Adoption of acommunication standard will provide this compatibility.

5.1.2. Background. TACOM contacted two offices to deter-mine if a standard for robotic vehicle communications hadalready been developed: 1) The Interoperability NetworkDirectorate of the U.S. ArmuyCommunications-ElectronicsCommand (CECON) at Fort Monmouth, New Jersey, which has theresponsibility of making Army communication equipment com-patible. 2) The Joint Tactical C3 Agency (JTC3A) of theDefense Communications Agency (DCA) in Washington, D.C.,which has the responsibility of ensuring compatibility ofcommunication equipment in the joint community (all themilitary services). This investigation yielded no stan-dard.

There are three other Army programs which address inter-vehicle communications.

• Inter Vehicle Intercommunication System(IVIS) deals with digitally transferringinformation that is.now transferred by voice.It is an Armor SchoOl concept for communica-ting at the battaliqn level and below. It isbeing proposed for MIAI Block II.

e Combat Vehicle Comm&nd and Control (CVC2) isthe next generation IVIS. It provides for

12

the networking of vehicles at the individualvehicle, platoon, company and battalion com-mander echelons. CVC2 applies to MIAI, Brad-ley, and future combat vehicles.

e Battlefield Management System (BMS) is thenetworking of all assets at battalion leveland below.

These three programs are in the very early stages. At thispoint it is difficult to speculate how robotic vehiclecommunication systems will be affected by these programs,which are targeted for manned vehicles.

Most likely there will be commonality between the roboticvehicle communication standard and these other battlefieldcommunication techniques. But robotic vehicle communica-tion needs are unique in some ways and thus should beaddressed.

5.1.3. Communications Interface Standard. The standardmust completely describe:

* The information - its structure, format, andmeaning.

* The communication system - the hardware,protocols, and signals used to transfer theinformation.

This report will describe and use the Open Systems Interco-nnection Reference Model (OSI-RM) as a means of discussingthe issues involved in the development of a standard inter-face document. Before further discussing the OSI-RM, how-ever, it is important to clarify what needs to be communi-cated by these subsystems, what portion of those communica-tions will be addressed in this report, and what format(digital or analog) the communication system should use.

5.1.4. Communication Needs. A robotic vehicle systemcommunication subsystem provides for continuous, bidirec-tional communications between a control station and one ormore RVs. From a control station to an RV, the subsystemprovides for the transmission of signals generated at thecontrol station which control the functions of the RV(movement, weaponry, etc.).

From an RV to a control station, the subsystem provides for thetransmission of signals which allow the remote operatorlocated in the control station to effectively operate theRV. These signals depict the status of the RV and itssubsystems. Also, video and other sensory informationcaptured by cameras and other sensors aboard the RV are

13

needed.

5.1.5. Communication Portion Addressed. Robotic vehiclesystems need to maintain continuous communications to avoida control station losing conttol of its RVs. The abilityto do so is hindered dA to spectrum jamming, naturalelectromagnetic interference (EMI), signal attenuation, andfoliage and terrain blocking the line of sight (LOS) pathbetween the two communicating vehicles.

The communicating medium can be either hardwired (fiberoptic cable, coaxial cable) or softwired (radio communica-tions). For radio communications, there are specificadvantages to transmitting at lower frequencies (VHF orUHF) as opposed to higher fr'iiencies. See Table 5-1 for adesignation of the frequencies.

These advantages include:

"* The ability to penetrate foliage and otherobstructions increases as frequencydecreases. (See Figure 5-1)

"* As frequency decreases, signal attenuationdecreases.

"* Simple antennas can be used instead of com-plex arrays.

An obstacle to using the lower frequency bands is the lackof available frequency bandwidth. Using current tech-nology, about 6 MHz of bandwidth are required for a singleFM-modulated video channel. For an RV with four videochannels, bandwidth needed would be a minimum of 36 MHz.

Currently, there are no VHF or UHF bands allocated for anapplication requiring so much bandwidth. The existingbands are extremely congested with both military and com-mercial users, and it is unlikely that any bands willbecome available. Therefore the video imagery will need tobe transmitted in the higher frequency ranges, at leastuntil practical image compression techniques become avail-able. Once practical compression techniques become avail-able, it will be possible to transmit video in a VHF or UHFband.

The command and control information requires far lessbandwidth than uncompressed video. The exact bandwidthrequired is yet to be deteri~ind, but it is in the range of5-100 kHz. This is narrow enough to be placed in a VHF orUHF band. Therefore, it is advantageous to separate thevideo information from the command and control information,transmitting the video channels in the microwave band or

14

Table 5-1. Designation of Electromagnetic Waves

Frequency Band Designation

3 - 30 kHz Very low frequency (VLF)

30 - 300 kHz Low frequency (LF)

300 - 3000 kHz Medium frequency (MF)

3 - 30 MHz High frequency (HF)

30 - 300 MHz Very high frequency (VHF)

300 - 3000 MHz Ultrahigh frequency (UHF)

3 - 30 GHz Superhigh frequency (SHF)

30 - 300 GHz Extremely high frequency (EHF)

NOTE: 500 MHz - 40 GHz is also designated as the

microwave band.

15

ijLisIA

Figure 5-1. Environmental obscurations

16

S¶

higher, and the comnmand and control channels in the VHF orUHF band. Command of the RV can be maintained even as thevideo picture fades out.

The rest of this report will deal only with compatibilityfor the transmission of command and control information.It will not deal with compatibility for the transmission ofvideo and other sensory imagery.

5.1.6. Digital Versus Analog. Command and control signalscan have one of two representations, either digital oranalog. Both systems have advantages.

5.1.6.1. Digital advantages.

"* Good performance is possible with a signal-to-noise ratio of only 20 to 30 decibels(dB). A frequency-modulated analog systemwould require 30-40 dB for similar quality,and an amplitude-modulated analog signal aneven higher signal-to-noise ratio.

"* Works well with systems requiring the data tobe relayed over multiple hops, because thedigital information is regenerated at eachrelay. This is in contrast to an analog sys-tem, where the noise and distortions are notsimply those of the weakest link, but thoseof the accumulation of all the relays.

• Error control techniques can be used todetect and/or correct most bit errors.

"* Most encryption techniques are discrete innature, allowing for data security.

"* Transparent to the type of data. The signalcould be voice, video, or computer data andany user with a compatible digital interfacecould receive the information. For analogsystems, channels must be modeled accordingto the nature of the signal.

"• A higher capacity per carrier frequency canbe accommodated, using a time divisionmultiple access (TDMA) technique. TDMA is amore efficient multiplexing technique thanfrequency division multiplexing (FDM), whichis used withP analog systems.

5.1.6.2. Analog advantage. Most sensors have an analogoutput. To use a digital Fysten, an analog-to-digital(A/D) conversion must take place. This process increases

17

system complexity and cost. It also can introduce aquantization error.

5.1.6.3. Preferred Signal Representation. A digitalsystem is superior to an analog system for the roboticvehicle communications application because of:

"* Superior performance with the same signal-to-noise ratio

"* Superior performance over multiple hops

o Available error control techniques

o Compatibility with eii6iytion techniques

o Transparency to the type of data

o Higher capacity per carrier

The rest of this chapter will deal only with digital datacommunications.

5.1.7. The OSI Reference Model.

!.1.7.l. Introduction. The International Organization forStandardization (ISO) is a voluntary organization formed tomake standards. TC97, one of ISO's technical committees,is concerned with information systems. TC97 developed, andin 1978 ISO introduced, the Open Systems InterconnectionReference Model (OSI-RM).

The OSI-RM is a model of a computer communicationsarchitecture. It was developed to promote compatible com-munications among a wide variety of digital systems. It isa framework for developing itandards, and it provides theterms of reference for discussing communication systemdesign. It has succeeded inwinning general acceptance inthe telecommunication industry, and therefore will beapplied to the problem of robotic vehicle system's communi-cation compatibility.

S.1.7.2. Description. The oSI-RM is not a protocolstandard. Instead, it specifies seven distinct layers thatdefine the functions involved in communicating. Toimplement the OSI-RM, protocols have been and are beingdeveloped and standardized at each layer.

One advantage of the OSI-RM is that all the layers aremodular. This allows differenq groups to develop protocolsat different layers with some assurance that the variouslayers can work together in a system. Modularity alsopermits the existence of sublayers, meaning multiple proto-

18

cols at each layer.

Each layer must communicate with the layer above and belowit. They must follow rules for these interlayerinterfaces.

For communicating between entities, it is imperative thatall the entities have identical layers and use the sameprotocols.

The OSI-RM is shown in Figure 5-2. It ranges from themedium, to the Physical (lowest) Layer, and up through theApplication (highest) Layer.

The bottom three layers are communication layers, concernedwith the transmission of bits and bytes. These layers arehardware dominated. The top three layers are the informa-tion processing layers, adding intelligence to the bitsand bytes which will be or have been transmitted. Theselayers are software dominated. The fourth, or middlelayer, bridges the gap between these two sets of layers.

The following sections describe the medium and each layerin some detail.

* The Medium. The medium refers to the type ofchannel over which the signal is transmitted.Some possibilities include:

- Air

- Twisted pair wire

- Coaxial cable

- Fiber optic cable

- Water

- Laser

e The Physical Layer. The physical layer isthe bottom, and first, layer of the OSI-RM.

Its responsibility is to send and receivebits over the medium. It covers the physicalinterface between devices and the rules bywhich bits are sent and received. This layeris concerned with the following functions:

- Matching the physical medium.

- Channel encoding the data.

19

7. APPLIC)IMON

6. PRESENTATION

5. SESSION

4. TRANSPORT

3. NETWORK

2. DATA LINK

1. PHYSICAL

S''I,, MEDIA ,

Figure 5-2. The Open Systems Interconnection Reference Model

20

- Sequencing of events for transmitting data.

- Physically connecting the devices.

- Modulating and demodulating the signals.

• The Data Link Layer. The data link layer isthe second layer of the OSI-RM. It attemptsto make the physical layer reliable. Itperforms the following functions:

- Link management - activation, mainte-nance, and deactivation of the link.

- Error control - bit error detectionand/or correction.

- Flow control - does not allow a fastsender to clobber a slow receiver.

- Synchronization - synchronizes the sen-der and the receiver that are exchangingdata.

- Addressing - identifies the senderand/or receiver of the data.

To perform these functions, the bits arearranged into frames. The frames add over-head bits, which are used to perform thefunctions of this layer. These frames arepassed down to the physical layer for trans-mission. The layer above the data link layercan assume error free data because the trans-mission errors have been corrected by thislayer.

o The Network Layer. The third layer is thenetwork layer. The network layer routes datathrough a network of computers/terminals. Itrelieves the upper layers of the need to knowanything about the methodology used to estab-lish the connection between the end entities.It also allows the lower two layers to dealonly with point to point communications.

It does this by organizing the data intopackets. Packets are the frames from thedata link layer with additional overheadadded.

o The Transport Layer. The tralsport 1ayer is21

the fourth, and middle, layer. It is thebridge between the three lower communicationslayers and the three higher information pro-cessing layers. The transport layer is re-sponsible for Ond-to-end (originating source,to ultimate destination) services. Theseservices include flow control, error control,sequencing, survival of the connection, andexpedited delivery.

The transport layer does for an end-to-endlink (including relays and repeaters) whatthe data link layer does for point-to-pointlinks. It performs t4se functions by assem-bling the data into Ekinsport protocol dataunits (TPDU). The TPDUs add overhead bits,which are used to perform the functions ofthis layer.

e The Session Layer. *The fifth layer is thesession layer. The session layer providesthe mechanism for controlling the dialoguebetween applications. It can do the follow-ing:

- Establish and terminate connections.

- Provide one of three types of dialogue:full-duplex, half-duplex, or simplex.

- Allow either abrupt or graceful discon-nections, meaning a message can or cannot be disrupted in the midst of atransmission, and also what to do if themessage is interrupted.

"* The Presentation Layer. The presentationlayer is the sixth layer. The presentationlayer ensures that information is deliveredin a form that the rdceiving system can un-derstand. Its purpose is to resolve differ-ences in format and data representation bydefining the syntax used.

Security through encryption, message compres-sion, and syntax conversion can also be doneat this layer.

"* The Application Layer. The application layeris the seventh, and t0, layer. It serves asa window between the application process andthe OSI communications environment. Thislayer manipulates information and manages

22

resources to support distributed applica-tions. To the user, this layer appears to bedoing the real work.

5.1.7.3. Application of the OSI-RM.

The Physical Layer. There are a variety ofstandard protocols for the physical layerwhich define all the functions for thislayer. The most popular are:

- RS-232-C

- RS-449/422-A/423-A

- CCITT X.21

All three provide the necessary mechanical,electrical, functional, and procedural speci-fications.

RS-232-C is the oldest and most widely usedof the interface standards.

The RS-449/422-A/423-A set of protocols wasdesigned specifically to replace the RS-232-C. It provides performance advantages overthe RS-232-C in the areas of achievabletransmission distances, speed characteris-tics, and modem control. While the RS-232-Cremains the most popular interface protocol,the RS-449/422-A/423-A set is experiencingincreasing growth in usage.

X.21 is the newest and thus far the leastused of the three protocols. It providesfewer circuits (pin connections) than theother two protocols, but adds more logic.With the falling cost of logic circuitry,this can be an advantageous approach.

X.21 provides the same speed characteristicsand transmission distances as the RS-449/422-A/423-A set of protocols. It is also moreflexible and potentially less costly.

Choosing the optimum physical layer protocolwill involve weighing the following advan-tages against each other:

The extremely wide-spread use of the RS-232-C.

23

- The improved performance and growing useof the RS-449/422-A/423-A.

- The strong performance, flexibility, andpotential cost savings of the X.21.

The analysis of these thrge protocols and thechoice of an optimum one for robotic vehiclesystems is outside the scope of this report.

e The Data Link Layer. To perform the func-tions of the data link layer, overhead bitsare added to the data bits and arranged intoframes. An optimum frame format is one whichcan effectively perfbil the needed functions,and do so with the minimum number of overheadbits. A minimum number of overhead bits isdesired because as the overhead goes up, theamount of data that can be transmitted drops,assuming constant bandwidth.

The functions needed at the data link layer

for robotic vehicle systems are:

- Synchronization

- Vehicle addressing

- Error control

Synchronization refers to the ability of thereceiving entity to determine when a signalbeing transmitted to it starts and ends.This is usually done using some type of flag.

Vehicle addressing refers to the ability of acontrol station to transmit information tothe RV it intends toi When there is a one-to-one control-station-to-RV ratio, as withcurrent robotic vehicle systems, this is notnecessary. Also, if each vehicle is con-trolled over a different channel, as withnear term systems, it is unnecessary. Butfor far term systems, when one control sta-tion will be supervising multiple RVs, anaddressing scheme will be necessary.

Error control is the ability of the receivingentity to detect and either correct or disre-gard data frames thdt have been damaged (con-tain erroneous bits) dkring transmission.

There are a variety of standard protocols24

which perform these necessary functions.

Some of the more widely used ones are:

- High-level data link control (HDLC)

- Synchronous data link control (SDLC)

- Digital data control message protocol(DD CMP)

- IEEE 802.3

HDLC and SDLC are virtually identical, andthus will be treated as one protocol.

In addition, there are many nonstandard datalink layer protocols used by communicationsystems.

Using a standard protocol offers the advan-tage of using already developed and availablecommunications controller hardware. There-fore the protocol proposed will be an exist-ing standard.

Choosing the standard will be done by deter-mining which protocol performs the neededfunctions in a satisfactory manner with theminimum overhead. This can be done by exam-ining the frame format of each protocol men-tioned above. The different frame formatsare shown in Figure 5-3. Table 5-2 shows acomparison of the different protocols.

As shown, HDLC/SDLC has the least overheadbits per frame and also allows for a largenumber of data bytes to be transmitted ineach frame. Therefore, it is the most effi-cient.

For robotic vehicle systems, a simplifiedversion of the SDLC protocol is proposed.(See Figure 5-4.) This protocol provides allthe needed functions.

e Network Layer. The network layer routes datathrough a network of communicating entities.For current robotic vehicle system applica-tions, all communications are simple point topoint (control station directly to RV).Therefore, no protocol is needed for thislayer.

25

NO

L .

cm,, a 8

SC

.0 L .. 0Af

La.0 .w

CSS

- S .o

0.6 o

FiuU -, FrmeFrmt

26U

Table 5-2. Data Link Layer Protocols

Protocol Synchron- Vehicle Error Overhead Data Bytes/lzation Address Control Bits/frame Frame

HDLC/ Any number

SDLC Yes Yes Yes 48 of bytes

DD CMP Yes Yes Yes 98 1-16,383

IEEE 802.3 Yes Yes Yes 208 64-1518

27

Address

Flag Data CRC Flag

RCC RV

- -

01111110 3 bits 5 bits a bits 16 bits 01111110

I- -

Figure 5-4. Simplified SDLC Frame Format28

As robotic vehicle systems become more intel-ligent, however, they will need to cooperateand thus should be networked together. Also,using an RV that is in the line-of-sight ofthe control station as a signal repeater isone way to maintain a data link with otherRVs that are not in the line-of-sight of thecontrol station.

Due to the modular nature of standardsdeveloped using the OSI-RM, a network layerprotocol may be added at a later time withoutaffecting the protocols at the other layers.

* Transport Layer. The transport layer makesend-to-end transmissions reliable. It doesfor a multihop network what the data linklayer does for point-to-point communications.

Since currently we are only dealing with adirect data link between the control stationand the RV, some of the transport layer ser-vices are not needed. The following servicesare needed:

- Sequencing

- Expedited delivery

- Survival of the connection

Transport Protocol Data Units. These ser-vices are provided by assembling the datainto TPDUs. For robotic vehicle systems, aTPDU consisting of a two-byte header added tothe message received from the upper layers isproposed.

The first header byte is the data unit code.The second header byte is the sequencenumber.

TPDU Types. There are three types of TPDUs:

- Information packet

- Acknowledgement packet

- Blank packet

Information Packets. An information packetcarries the message from the higher layer.There are six different types of information

29

packets:

- Normal data ,(ND). Has the lowest pri-ority. Will be sent last when expeditedor exprw-;type packets are waiting tobe sent.

-'Expedited data .(ED). Has middle priori-ty. Will be sent before normal butafter express data.

- Express data (XD). Has the highestpriority. Will be sent before any otherpacket type.

- Normal data with acknowledgement (NA).Lowest priority but requires an acknowl-edgement.

- Expedited data with acknowledgement(EA). Middle Priority with acknowledge-ment required.

- Express data with acknowledgement (XA).Highest priority with acknowledgementrequired.

Acknowledgements Packets. An acknowledgementpacket is used when .the receipt of an infor-mation packet requires an acknowledgement.Only positive acknoVledgements are provided.If a positive acknowledgement is not receivedbefore the transport timer expires, the soft-ware treats it as tie negative acknowledge-ment Of an information packet. A 125-mstimer is proposed.

There are three types of acknowledgements:

- Positive acknowledgement for normaldata (ACK) '

- Positive acknowledgement for expe-dited data (ECK)

- Positive acknowledgement for expressdata (XCK)

Blank Packets. Blank packets are used to letthe other side know tbat the communicationlink is still up even though there is noinformation to be sent. A blank packet issent when the transport has nothing to send

30

for 200 ms. When nothing has been receivedfor three cycles (600 ms), an alarm messageis sent to the appropriate application soft-ware saying that there is something wrongwith the communication link.

Data Unit Codes. Table 5-3 has a list of thedata unit codes.

Sequence Number. Each packet is numberedsequentially. Since it is a one byte number,256 (28) TPDUs can be numbered before start-ing over.

TPDU Lengths. Each information packet hasthe two byte header followed by a data fieldof unlimited length. An acknowledgementpacket has a total length of three bytes, thetwo byte header and the sequence number ofthe received information packet to be acknow-ledged. A blank packet consists of only thetwo byte header.

e Session Layer. The session layer can berather lean due to the simple point to pointcommunications. One issue that can be set-tled at this layer is the dialogue type.

There are three dialogue types:

- Simplex: can transmit only in one direction.

- Half-duplex: can transmit in both directions,but only one at a time.

- Full-duplex: can transmit in both directionssimultaneously.

For maintaining effective, real-time controlof an RV, many of the control signals fromthe control station and status signals fromthe RV must be relayed as soon as they areavailable for transmission. This requirementwarrants the use of full-duplex communica-tions.

Another issue that should be discussed atthis layer is the type of disconnection,either graceful or abrupt, that should beemployed. With a graceful disconnection, amessage that is cut off before it is com-pletely transferred will be retransmitted assoon as the resources to do so are available.

31

Table 5-3. Data Unit Codes

TYPE DATA UNIT CODE

InformationaeND 0000 0000SPacket

"ED 0000 0001

XD 0000 0010

NA 00000100

EA 0000 0101

XA 00000110

Acknowledg- ACK 0000 1000ment packet

ECK 0000 1)01

XCK 0000 1 )10

Blank Packet BLNK 0001 0 00

32

With an abrupt disconnection, the messagethat is not completely transferred is ig-nored.

The need for graceful disconnections arisesfrom systems exchanging large amounts ofdata, such as file transfers, with no timerestriction. In contrast, controlling arobotic vehicle requires many short commandand status messages. Because of this,retransmission of cut off messages is notrequired. Therefore abrupt disconnectionsare proposed.

e The Presentation Layer. For robotic vehiclecommunication system applications, the pre-sentation layer must provide for security andmust describe the bit and byte representa-tions of the control commands and the statusinformation. Current and very near termrobotic vehicle systems are primarily tech-nology demonstrators, and thus do not requiredata security. Future fielded systems, aswell as mid and far term demonstrators, willrequire security, and this can be provided byan encryption sub-layer of the presentationlayer. Addition at a later date of this sub-layer is possible due to the modular natureof the OSI-RM.

Description of the bit and byte representa-tions of the control commands and the statusinformation can be achieved by the develop-ment and implementation of a robotic vehiclemessage format. The development of a messageformat for this purpose is detailed in sec-tions 5.2 and 5.3.

Application Layer. The application layertakes care of functions such as file trans-fers, graphics, data base management, etc.Proposing protocols for this layer is out ofthe scope of this report.

5.2. Robotic Vehicle System Functions

5.2.1. Introduction. A message format describes the bitand byte representations of the control commands and statusinformation used by a robotic vehicle system. A messageformat is part of the Presentation Layer of the OSI-RM, asdescribed in the previous section.

The development of a message format can be broken down into

33

two main tasks:

Compilation of the control functions and statusinformation required to; remotely operate a

,vehicle.

A method of representing the compiled information.

This section will address th'e first task, that of compilingthe information needed to remotely control a vehicle. Theobjective is to make the compilation as comprehensive aspossible so that the messagj format can be used by any andall military robotic vehicle systems, both now and in thefuture, performing a wide va4ieity of missions.

5.2.2. Manned Military Vehicles. Operating a vehicleremotely requires performing, at a remote location, theoperations normally performed by a crew within the vehicle.To begin compiling a list of all the control commands andstatus information necessary to remotely control a vehicle,the operation of current manned vehicles can be studied.

5.2.2.1. Vehicles studied. For this study, four vehicleswere chosen:

MIA1 Abrams Main Battle Tank

M2/M3 Bradley Fighting Vehicle

High Mobility Multipurpose Wheeled Vehicle (HMMWV)

ACEC Cobra

These four particular vehicles were chosen for two reasons:

e All are state-of-the(-art vehicles, recognizedas performance leaders in their individualfields.,

* They represent a good cross section ofmilitary vehicles.

- They represent the three general weightclasses of vehicles:

Heavy - -MlAl

Medium - .M2/N43, Cobra

Light - WV,

Three are tracked, one is wheeled (theHMMwV) .

34

- Three are diesel powered, one is turbinepowered (the MIAl).

- Three have mechanical transmissions, onehas electric drive (the Cobra).

By studying four vehicles which are significantly differentin design, a more complete list of control commands andstatus information which will be required on future roboticvehicle systems performing a wide variety of missions canbe obtained. Appendix A gives the results of the survey ofthe four vehicles.

5.2.3. Unmanned Vehicle Systems. Compiling a list offunctions and status information needed for robotic vehiclesystems can be aided by studying current robotic vehiclesystems and learning from what has already been done. Thiswas done with systems developed or under development by thesix organizations listed in Table 5-4.

These systems were studied, but the documents describingthe systems will not be included in this report because ofthe competitive situation these companies are in.

5.2.4. Additional Functions. Surveying current manned andunmanned military vehicles was very helpful in compiling acontrol/status listing. But future vehicles will continueto change and progress, and will have additionalrequirements for command and control.

To predict requirements of future systems, a series ofmeetings was held with personnel from TACOM's RoboticsDivision. At these meetings, additional controls andstatus were discussed and compiled.

5.2.5. Higher Level Control Commands. Surveying the fourmanned vehicles has led to an accumulation of low-levelcommands required to control a vehicle. Likewise, theGrumman, Kaman, and Sandia systems were completelyteleoperated, thus accumulating more low-level vehiclecontrol commands.

5.2.5.1- RV intelligence. The commands required tocontrol an RV vary greatly with the intelligence of thevehicle. Robotic vehicle system developers are working tocontinually increase the intelligence of their RVs.

When RVs lack intelligence, they require many explicit lowlevel directions on what to do and on how to do it. As RVsgain intelligence, a smaller quantity of high level

35

Table 5-4. Robotic Vehicles Studied

* FMC Corporation

0. General Dynamics Land Systems

* General Motors Delco

* Grumman Corporation

* Kaman Sciences Corporation

* Sandia National Laboratories

36

commands can be substituted for the many low levelcommands.

5.2.5.2. Autonomy. An increase in onboard RV intelligencemeans the vehicle has become more autonomous. An RV withincreased autonomy is desired for two reasons:

1. The RV to control stations data link has adecreased bandwidth requirement.

2. Workload of RV operator is decreased.

"* Decreased Bandwidth Requirement. Inter-vehicle communications on the battlefield arehindered by enemy electromagnetic warfare, aswell as by natural obstacles (hills, trees,foliage) and natural electromagnetic inter-ference. The greater the amount of informa-tion needed to be transmitted, the greaterthe bandwidth requirement of the communica-tion system, and the more difficult it is tosuccessfully transfer the data.

Conversely, the less information that must betransmitted, the smaller the bandwidth re-quirement of the communication system, andthe capability to successfully transfer thedata is improved. Decreasing the number ofcommands needed by an RV lessens the amountof information that must be transmitted.

"* Decreased Operator Workload. As an RV'sautonomy increases, the number of moment-to-moment commands generated by the operator tocommand the vehicle is decreased, thus de-creasing the operator workload. If the work-load is sufficiently decreased, the operatorcan perform other duties while at the sametime maintaining control of the RV. Otherduties may include controlling additionalRVs. This increases the productivity of theoperator, and thus increases force effective-ness.

5.2.5.3. Examples. To further describe high-levelcommands, two examples, using vehicle speed and weaponusage, will be given.

* Vehicle Speed. At the lowest level, thespeed of a vehicle is controlled by adjustingthe engine throttle. This requires the oper-ator to constantly change the throttle de-pending upon the vehicle, road and weather

37

conditions.

A higher level commahd would set the vehiclespeed. It would thdn be the job of the RV,independent of the human operator, to gener-ate the a0ment-to-moment throttle commandsneeded to maintain the desired speed. Acruise control device, common on commercialautomobiles, could be mounted on an RV andcould carry out this higher level command.

Another high-level c6mmand might be to tellthe RV to go from point A to point B in theshortest time possible. Now the RV wouldattempt to maintain t highest speed pos-sible while taking into account the terrainand weather conditions and the engine andvehicle limitations.

o Weapon Usage. At the lowest level, the oper-ator would detect a target. He would thensend commands to position the weapon and tofire it.

At a higher level, the operator might stillneed to detect the target. He could then senda command,, "Lock on target." When the weaponhad autonomously locked on the target, theoperator could send a command to fire.

At the highest level, the operator could givethe single command, *Engage enemy." The RVwould then autonomously detect a target, posi-tion the weapon, and fire at the target.

5.2.5.4. Need for high-level commands. The principalargument used against the adoption of standards is thatthey tend to freeze technology, and become obsolete. It isimperative that the developer of a standard take intoaccount future requirements io that the standard would notbecome obsolete.

With RVs, the trend is for increased onboard intelligence.Therefore, the standard message format developed in thisocument must include high-le'4el control commands, as well

as have the flexibility to add additional high-levelcommands as they are needed.-

5.2.6. Automated Functions. Ihcreasing the autonomy ofRVs (using high-level commandq is one method by which toreduce the bandwidth requir6mibts of robotic vehiclecommunication systems. Another method is to automate asmany functions as possible.

38

An automated function is one which normally must beperformed by a human operator but can be done autonomously.It differs from a high-level command in that it needs nooperator supervision at all.

There are many functions that have the potential to beautomated. An example of one is the operation of avehicle's bilge pumps.

Bilge pumps are turned on by a vehicle's crewmember whenwater has entered the hull. The function of turning on thebilge pump could be automated by putting water sensors inappropriate locations. Upon sensing a predetermined amountof water, the bilge pumps would automatically turn on.Also, the pumps would automatically turn off when the waterhas been flushed out. Automating the operation of thebilge pumps would give the RV operator one fewer functionto control and would delete the need to send a controlcommand.

Some of the other functions that are candidates for

automation include:

Interior temperature

Suspension height

Fuel tank selector

Fire extinguishing system

Camera lens focus

5.2.7. Complete Control/Status Listing. Appendix Bcontains the results of this section.

5.3. Representation of the Compiled InformationThe control commands and the status information compiled inthe previous section can be digitally represented by amessage format. Three different types of message formatsare considered:

Fixed-length message format

Variable-length message format

Block message format

5.3.1. Description of the message formats. The threetypes of message formats are described below.

5.3.1.1. Fixed-length message format. A fixed-length

39

message fornat is a stream of parameters in a predeterminedsequence. (See Figure 5-5.(a)) The location of theparameters within the stream dictates the function beingcontrolled and the status information being transferred.

The'RV knows what to dc with each parameter because of itslocation in the sequence. No function identification isnecessary in this type of message format.

5.3.1.2. Variable-length message format. A variable-length message format, like a fixed-length message format,is also a stream of parameters in a predetermined sequence.With a variable-length format, however, a parameter is onlysent when it is needed.

Whether or not a parameter is needed is depicted by a"parameter needed (PN)" bit. (See Figure 5-5(b)) When thePN bit is set (has a value of one), a parameter is neededand will immediately follow. When the PN bit is not set(has a value of zero), a parameter is not needed and thuswill not follow. The following bit will instead be another]?N bit.

5.3.1.3. Block message format. With a block messageformat, each parameter is individually identified. (SeeFigure 5-5(c)) Parameters are not part of a datapacket with a predeterminedparameter sequence, as with thefixed-and-variable length message formats.

Not being part of a sequence, different parameters can besent at different frequencies. For example, an RV beingremotely driven out to a sentry post may require hundredsof steering commands, but no weapon control commands.

Because the parameters are not transmitted in a prede-termined sequence, they must each be identified. This isdone with a series of'labels.

The message length is variable. When little or no activityis required, the message length will approach zero bytes.An RV performing a variety cf functions in a complexenvironment will have a long message length.

The parameter labels also vary in length. Some messagesrequire more bits than others to be accurately identified.

5.3.2. Analysis of the message formats.

5.3.2.1. Fixed-length message #-ormat. The fixed-lengthmessage format offers two advantages. The first is that nobits are needed to identify. to. what application thetransmitted parameters apply. All the bits of data areparameters. This makes for an efficient use of the data

40

Steer Brake Throttle Camera Gear

(a) Fixed Length Format

PN Steer PN Brake PN Throttle PN Gear

(b) Variable Length Format

FunctionControl ParameterIdentifier

(c) Block Format

Figure 5-5. Candidate Message Formats41

link.

The second advantage is the simplicity with which an RV anda control station can handle the received message. Routingtheparameters to the 'roper location is easily done sincethe parameter applications are predetermined.

There are three disadvantages to using a fixed-lengthmessage format. The first is that the frequency with whicha parameter is sent cannot be varied. A parameter is sentonce in every message. Even though a parameter may not beneeded, it is still transmitted. This leads to thetransmission of unneeded parameters.

The second disadvantage is that there is no way to orderthe parameters by priority . Since the parameters must besent in their predetermined sequence, there is no means tosend a more important parameter before a less importantone.

The third disadvantage is the lack of flexibility that thistype of message format offers. Different types of roboticvehicles require different control commands and statusinformation depending upon their configuration and themission they are performing.- A message format must be ableto accommodate different requirements if it is to become astandard. The fixed-length message format does not offerthis flexibility since it would need to be altered for eachdifferent application.

5.3.2.2. Variable-length message format. The advantagesand disadvantages of the fixed-length message format alsoapply to the variable-length message format, with twodifferences. The first is that the variable-length messageformat is more data rate efficient than the fixed-lengthformat. This is because parameters are not transmitted ifthey are not needed.

The second difference is that there is an increase in theprocessing required of the receiving entity when using thevariable-length format. The receiving entity mustdetermine if it should or should not route the parametersto certain applications, depending on the value of the"parameter needed" bit.

5.3.3.3. Block message format. There are three advantagesto using a block format. The first advantage is theflexibility of this format. Functions can be identifiedfor each vehicle and mission module, but only thoseapplicable to a particular qyspem need to be used.As requirements for robotic vehicle systems develop andevolve, new messages can be added and obsolete ones

42

deleted. This will keep the message format from becomingobsolete.

The second advantage is that the parameters can be orderedby priority. This is possible since they are not arrangedin a predetermined sequence.

The third advantage is that messages are only sent whenneeded, decreasing data rate requirements.

There are two disadvantages to using a block messageformat. The first is that each parameter needs to beidentified. This can be done with a label two bytes inlength.

The second disadvantage is the burden put on the receivingentity. Upon the receipt of data, it must be processed todetermine what application the parameter is for.

5.3.4. Comparison. Table 5-5 summarizes the advantagesand disadvantages of the three message formats presented inthis chapter.

As shown, the bandwidth required for each message formatvaries with the complexity of the message. For a roboticvehicle system requiring few commands, the variable-andfixed-length message formats can operate over linksusing slower data rates. The block format requires fasterrates.

For a more complex robotic vehicle system requiring manydifferent commands, the block format can use the link withthe slowest data rate because it only sends messages whenthey are needed.

The block format is flexible and allows commands to beordered by priority. Flexibility is extremely importantfor a message format that is to be part of an interfacestandard. Without flexibility, the standard will notlikely be adopted.

Neither the fixed-nor-variable length message formats offerflexibility or the ability to order commands by priority.

A communication system using a functional block formatrequires the most processing by the receiving entity. Thefixed-length message format requires the least processing,and the variable-length format requires an intermediateamount.

The increased amount of processing time and resourcesrequired when using a functional block format is a penaltyto adopting this format. But this penalty is negligible

43

Table 5-S. Message Format Comparison

Message Flexible Bandwidth Processing PrioritizedFomat reqnlr_ _ required commands

Varies withFixed No message Least NoLength complexity

Varies withVariable No message NoLength complexity

Varies withFunctional Yes message YesBlock complexity

44

because of the increasing speed and decreasing cost ofcomputer equipment.

These facts, plus the flexibility and the ability to orderthe messages by priority, make the block format the bestmessage format for a robotic vehicle communicationsinterface standard.

5.3.5. Proposed Message Format. There are many differentpossible structures that a block message format can take.The format proposed for robotic vehicles is shown in Figure5-6. Appendices C and D define the digital coding for themessages.

5.3.5.1. Field descriptions. The message length field isone byte in length and describes the length (number ofbytes) of the message, including the length byte itself.The source address field is also one byte in length and ittells where the message originated.

The message field can be broken down into multiplecommands. Each command consists of:

- A length field one byte in length which describes thelength (number of bytes) of the command, including thelength byte itself.

- A block field one byte in length. This field is thefirst part of the command/status identifier Its one bytelength makes it possible to identify 256 (2•) differentblocks. The blocks are the result of the control commandsand the status information being classified according totheir function.

- One or more function fields. Each function fieldconsists of a one byte function identifier, which is thesecond part of the command/status identifier. The one bytelength makes it possible to identify 256 functions perblock. Where necessary, a parameter one or more bytes inlength follows. A parameter is the actual control or statusvalue.

5.3.5.2. Parameter types. There are three types ofparameters which can be used:

Numeric (N)

Select (S)

Proportional intensity (PI)

The type of parameter associated with each block is shownin Appendices D and E.

45

Message length MesagaddressMesg

BlockLength Fil Function 1 Functdon 2 Function x.

[Function Pgrameter 1 P~rameter 2 Parameter y

Figure. 5-6. Coinmamd/Status Message For~mat

46

5.3.5.3. Parameter representations. Numeric parametersare represented with binary encoding. For example, decimal71 is represented by 0100 0111. This is hexadecimal 47.

Select parameters are used when we need to choose one ormore options from a group of choices.

Proportional intensity parameters are used to representthree types of commands/status:

Off, incrementally increasing to full on.

Down, incrementally rising to full up.

Straight ahead, incrementally changing tofull left or full right.

"* Of f to on is represented by a one-byte param-eter. Hexadecimal 00 (binary 0000 0000)represents off. Hexadecimal FF (binary 11111111) represents full on. All values inbe-tween represent proportional positions.

"* Down to up is represented by a one-byteparameter. Hexadecimal 00 represents fulldown. Hexadecimal FF represents full up.All values inbetween represent proportionalpositions.

* Left to right is represented by a one-bytesigned parameter. Hexadecimal 7F is fullleft. Hexadecimal 00 is straight ahead.Hexadecimal FF is full right. All valuesinbetween represent proportional positions.

5.3.5.4. Message generation. Messages are generated usingthe following steps:

Determine the block field codes from AppendicesD and E.

Get the function field code from Appendices D

and E.

Append the required parameters.

Determine the message length and the commandlengths.

Enter numeric values into the message format.

5.3.5.5. Examples. Three examples are given which

47

illustrate using Appendices D and E and the message formatto generate coded messages which represent control commandsand status information.

Example 1. An oper&ti ihitiate. t1% following coininijds:

- Turn vehicle full right

- Engine at half throttle

- Turn on headlights

- Turn on the power to the FLIR

The following chart is used t 81put the commands into therequired message format:

Command Block FunctionNumber Message Field Field Parameter Length

1 Vehicle full right 03 01 FF 042 Engine half throttle 01 03 40 043 Turn on headlights OE 01 034 Power to the FLIR 18 01 03

The resulting message, in hexadecimal values, is:

10 03 04 03 01 FF 04 01 03 40 03 OE 01 03 18 01

NOTE: Source address has arbitrarily been chosen to be 03.Also, the above codes would be put in the SDLC format fortransmission over the data link.

Example 2. An operator initiates the following commands:

- Engine at zero throttle

- Turn heater on

- Turn air conditioner off

- Turn on bilge pump

- Stop transmitting video from the left and rightperipheral cameras

- Begin transmitting images from the reconnaissancecamera and the FLIR

The following chart is used'to 'put the commands into therequired message format:

48


1 Zero throttle 01 03 00 042 Heater on OD 03 S-

AC off 06Bilge pump on 09

3 Stop transmission ofright peripheralcamera imagery 10 08

Stop transmission ofleft peripheralcamera imagery 06

Transmit FLIR images OFTransmit reconnais--

sance images OB

The resulting message, in hexadecimal values, is:

11 03 04 01 03 00 05 OD 03 06 09 06 10 08 06 OF OB

Example 3. An RV's central control unit initiates the

following status messages:

- Engine hot

- Fuel low

- Interior temperature 720

The following chart is used to put the commands into therequired message format:


1 Engine hot 81 06 032 Fuel low 8B 02 033 Interior temperature 8D 01 48 04

Message: OC 03 03 81 06 03 8B 02 04 8D 01 48

5.3.5.6. Request for status. A request for status is madeby sending the appropriate status identifier from a commandcenter to an RV. For example, a request command for theRV's heading would have the block field BO and the functionidentifier 01.

5.3.5.7. Room for growth. The proposed message formatwill only be effective if it does not hinder the

49

development of new systems pnd subsystems. Therefore itmust be flexible and have rdoa to grow. By using one byteto identify the message block, there are 256 possibleblocks. The current compilation of messages resulting fromthe investigation deuaibed earlier produced 62 blocks,lediing ample room for expansion. Also, by using one byteto identify the functions inleach block, there are 256possible functions. So far, the most identified for anyone block is 27.

5.3.6. Complete Message. The message format described inthe previous sections will become part of the whole datapacket that is transferred between entities. The wholepacket also includes the traniort layer protocol overheadas well as the data link layer protocol overhead.

Figure 5-7. illustrates the-entire data packet includingdata link, transport, and presentation layer protocolsoverhead.

5.4. Protocol Testing

The proposed protocols and message format will be imple-mented in TACOM's Robotic Combat Vehicle program in fiscalyears 1989 and 1990. This will allow the protocols to betested.

Also, TACOM will make the documentation available to otherrobotic systems being developed so that they may evaluatethe proposed protocols as well. This will lead toidentification of any revisions or improvements required tomake the protocols fully functional.

By evaluating and testing communication protocols now,while robotic vehicle systems are still in the testbedstage, an optimum set of protocols can be available whenrobotic vehicles are ready for full-scale development.

50

Flag Address Data CRC Flag

Sequence' Data Unit DataNumber Type

Message length SoreMessageaddress

Command 1 1Command 2 Command n

BlockLength Field Function 1 Function 2 Function x

Function P~arameter 1 Parameter 2 Parameter y

Figure 5-7. Complete Data Packet

51

SELECTED BIBLIOGRAPHY

Caskey, B.C., and Hoover, E.R. "Robotic Combat VehicleSystem Study." Sandia National Laboratories, (July1987)

Chandra, Sarat. FMC Corporation. Presentation, (24 November1987)

Collin, Robert E. "Antennas and Radiowave Propogation", NewYork: McGraw-Hill Book Company, (1985)

Comdel Incorpbrated, "Radio Communication Systems forRobotic Vehicles," (April 1987)

Fitzgerald, M.L., and Barbera, A.J. "A Low-Level ControlInterface for Robot Manipulators," National Bureau ofStandards, (1985)

Garg, Ewa. "RCC-RV Data Link Protocol Proposal," FMCCorporation. (26 April 1988)

Klarer, Paul R. "Communication Systems for Robotics atSandia," Sandia National Laboratories, Letter,(18 November 1987)

Osterhoff, Michael D. "Wireless Communication Link forPassenger Compartment Electronics," Fisher BodyCentral Engineering, (15 April 1984)

Schehr, Steve. "RCC/ROBAT Interface Specification Require-ments." U.S. Army Tank-Automotive Command,(20 July 1987)

Stallings, William. "Data and Computer Communications", NewYork: Macmillan Publishing Company, (1985)

Voelcker, John. "Helping Computers Communicate," IEEESpectrum, (March 1986)

52

APPENDIX A

CONTROL/STATUS OF MANNED MILITARY VEHICLES

A-1

MANNED VEHICLE CONTROLS

M1 M2/M3

Description Abrams Bradley HMMWV Cobra

of function (heavy) (med) (light) (elec)

Accelerator x x

Bilge pumps on/off X X X

Brake X X X X

Defroster control X

Driver's night vision viewer X

Driver's periscope wiper X

Engine accesory X

Engine shutoff X X

Engine starter X X X

Engine starter (cold start) X X

Fire suppression X

Fording control X

Fuel control X

Fuel tank selector X

Garage toggle X

Gear selector X X X X

Hazard warning light X X

High/low ratio selector x

Horn X X

Infrared lenses X

A-3

MANNEDP VEHICLE qPNTROLS

MI M2/M3Description Abrams Bradley HMMWV Cobraof function (heavy) (med) (light) (elec)

Intercom X X

Light selector X x x

Master power x X

NBC system on/off X X

Panel lights control X X X X

Parking brake release x X

Parking brake set X X X

Periscope adjustment x

Periscope washer pump x

Pivot X X X

Road/water toggle X

Service brake X X

Smoke screen generator x x

Splash guard up/down X

Steering X X X X

Steering wheel lock cable X

Tactical idle X

Throttle control X X X

Transfer case X

Transmission on/off X

A-4

MANNED VEHICLE CONTROLS

M1 M2/M3



Turn indicator X x X

Water barrier release X

Windshield washer/wiper x

A-5

MANNED VEHICLE qTATUS


Air cleaner clogged warning X x

Alternator temperature high X

Back door open X

Battery charge low x

Bilge pump (fwd,rear) X X x

Brake master cyl fluid level low X

Brake worn X

Cable disconnected X

Circuit breaker open x

Cold start indicator X

Coolant high temp warning X X

Coolant low level warning X X

Engine started X

Engine abort X

Engine accessory indicator x

Engine coolant temp gauge X X X

Engine hour meter x X

Engine oil filtler clogged X

Engine oil low x

Engine oil pressure gauge x X X

A-6

MANNED VEHICLE STATUS

M1 M2/M3



Engine oil pressure warning X X X X

Engine oil temperature high X X

Exhaust temperature X

Fire detector sensor X

Fire ext bottle pres gauge X

Fire supp discharge indicator X X

Fire supp manual indicator X

Fuel (Fl/2,1/4,E) X

Fuel control faulty X

Fuel filter clogged warning X X

Fuel gauge X X X

Fuel level low X

Full pivot X

Gas over temperature X

Headlights high beam X X X X

Headlights low beam X X

Heater control X

Heater fan X

Hydraulic system malfunction X

Master caution X

A-7

MANNO VEHICLE ITATUS


Master power indicator x X

Master warning

NBC filter clogged X

NBC on x

NBC overheated X

NBC overpressure X

NBC system indicator X X

Night periscope X

Odometer x X X X

Parking brake sys hyd pres gauge X X

Parking'lights on X

Parking/service brake on X

Ramp unlock indicator X

Rear left fuel pump bad X

Rear right fuel pump bad X

Road mode X

STE/ICE diagnostic connector X

Slope indicator X

Smoke screen generator on X X

Speedometer X X X

A-8

MANNED VEHICLE STATUS

M1 M2/M3Description Abrams Bradley HMMWV Cobraof function (heavy) (med) (light) (elec)

Tachometer X X

Transmission damage-inspect X

Transmission Sear selected X X X X

Transmission off X

Transmission oil filter clogged X

Transmission oil low X

Transmission oil pressure warning X X

Transmission oil temp warning X X

Trip odometer X

Turn indicator lights X X X X

Turret power indicator X

Turret seal pressure gauge X

Voltage gauge X X X

Water mode X

A-9

APPENDIX B

CONTROL/STATUS REQUIRED FOR ROBOTIC VEHICLE SYSTEMS

B-1

Controls Required for

Robotic Vehicle Systems

1. Power plant 9. Turret

2. Brakes 10. Interior

3. Steering 11. Lights

4. Transmission 12. Electro-optic Sensors

5. Suspension 13. Condition Sensors

6. Fording 14. Communications

7. Mobility 15. Inertial Navigation System

8. Fuel 16. Mission module

B-3

REQUIRED CONTROLS

1. Power plant

Start

Cold start

Kill

Throttle

Idle set

Tactical idle

Fuel delivery

Cruise control (CC)

CC SetCC ResumeCC AccelerateCC DecelerateCC Coast

Electric current *

2. Brakes

Brake

Parking brake set/unset

Service brake set/unset.

3. Steering

Steer

Radius of turn

Heading

Directional movement

• For battery power plant

B-4

REQUIRED CONTROLS

4. Transmission

Automatic gear select

ParkReverseNeutralDriveDrive, LPivotTow

Manual Gear select

Transfer case

HighLowNeutral

Wheel drive

5. Suspension

Air shock height

Hydroneumatic suspension level control

6. Fording

Road/water propulsion

Splash guard up/down

Water barrier release level

Exhaust pipe rise

7. Mobility

Emergency stop

Velocity

Move to grid coordinates

Pivot

CARD mode

Autonomous road following mode

REQUIRED CONTROLS

8. Fuel

Fuel tank selector

Fuel filler lock/unlock

Fuel filler open/close

9. Turret

Power

Enable (turret travel lock)

Slew

Elevation

10. Interior

Defroster

Heater

Air Conditioner

Temperature setting

NBC system On/Off

Bilge pumps, front

Bilge pumps, rear

Fire supression

Horn

Vent open/close

Vent fan

Wipers

Heated glass

Doors lock/unlock

Windows up/down

B-6

REQUIRED CONTROLS

11. Lights

Head lights

High beamLow Beam

Parking lights

Turn indicator

LeftRight

Hazard lights

Blackout lights

Interior lights

Exterior flood lights

Exterior spot light

Fog lights

Back-up lights

12. Electro-optic Sensors

Sensor switch

VideoRadarIR Thermal imaging systemImage intensifierLaser ranger

Video camera selector

ForwardStereoRear

Sensor control

AzimuthElevationTiltScan rateSector size

B-7

REQUIRED CONTROLS

12. Electro-Poptic Sensors (cont)

Sensor control.

B & W/ColorContrastIris F/B switchShutter speedZoomFocusHomeWipersDe-icerConvergenceHot/whiteLogic selectField of view

13. Condition sensors

Radar detector

Magnetic field detector

Motion detector

Frequency detector

Light detector

Sonic detector

NBC detector

Noise detector

Rain detector

Snow detector

14. Communications

System choice

RFFiber opticMicrowave

Laser

B-8

REQUIRED CONTROLS

14. Communications (cont)

Radio options

Frequency selectAJ techniquesTransmitting power

Fiber optic options

Antenna control

ElevationAzimuthPolarizationAuto-track

15. Inertial navigation system

Initialize

Reset

16. Mission module

Reconnaissance module

Mine field breacher

Weapons package

CARD module

Jamming device

Smoke generator

Others to be determined

B-9

Status Required for

Robotic Vehicle Systems

1. Power plant 10. Interior

2. Brakes 11. Lights

3. Steering 12. Electro-optic Sensors

4. Transmission 13. Condition Sensors

5. Suspension 14. Communications

6. Fording 15. Inertial Navigation Data

7. Mobility 16. Mission modules

8. Fuel 17. Circuit breaker faults

9. Turret- 18. Exterior

B-10

REQ)JTRID A s'A'rtJs;

i.. Power plant

Running/started

Tachometer

Coolant

Temperature gaugeLow levelHigh temperature

Oil

Pressure gaugePressure lowLevel lowTemperature high

Alternator

Temperature highNot functioning

Cold start indicator

Exhaust temp high

Battery charge low

Voltage gauge

Air cleaner clogged

Oil filter clogged

Fuel filter clogged

Fuel pump bad

Fuel control faulty

Hour meter

Throttle feedback

Microphone in engine compartment On/Off

B-li

REQUIRED STATUS

*2. Brakes

Brake feedback

Brakes worn

Master cylinder fluid level low

Brake line pressure gauge

Low brake air

Brakes nonfunctional

Parking brake

On/OffHydraulic pressure gauge

3. Steering

Steering feedback

4. Transmission

Automatic transmission gear selected

ParkReverseNeutralDriveDrive, LDrive, HPivotTow

Manual transmission gear selected

Transfer caseHighLowNeutral

Wheel drive

Transmission fluid

Filter clogged

Pressure warning

B-12

REQUIRED STATUS

4. Transmission (cont)

Temperature warning

Level low

Damaged

Shift gear indicator

5. Suspension

Air shock height

Hydroneumatic suspension level

6. Fording

River depth

River current speed

Road/water propulsion

7. Mobility

8. Fuel

Fuel gauge

Fuel low

Fuel temperature high

Fuel filler cover on/off, lock/unlock

Fuel leak alarm

Instantaneous MPG

Battery powerpack charge level

9. Turret

Power

Seal pressure gaugeB-13

REQUIRED STATUS

10. Interior

Vehicle iknter-ior temperature

NBC system

On/OffFilter cloggedSystem overheatedSystem overpressure

Bilge pump, front

Bilge pump, rear

Fire supression

DetectorDischarge indicatorExtinguisher bottle pressure gauge

Wipers on/off

Door lock/unlock

Windows up/down

Vent open/close

Vent fan on/off

Cabin pressure

Moisture detector alarm/level meter

Door/hatch ajar

Heater on/off

Air conditioner on/off

Absorbed power

11. Lights

Head lights

High beamLow beam

Parking lights

B-14

REQUIRED STATUS

11. Lights (cont)

Turn indicators

Hazard lights

Blackout lights

Interior lights

Exterior flood lights

Exterior spot lights

Fog lights

Back-up lights

Engine compartment lights

Bulb burned out

12. Electro-optic sensors

Sensor switch

VideoRadarIR Thermal imaging systemImage intensifierLaser ranger

Video camera selector

ForwardStereoRear

Sensor control

Scan rateSector size

B & W/ColorIris F/B switchShutter speedwipers

ConvergenceHot/whiteLogic selectField of view

B-15

REQUIRED STATUS

13. Condition sa.nsors

Radar detected

Magnetic field detected

Motion detected

Frequency detected

Light detected

Sound detected

NBC detected

Noise detected

Rain detected

Snow detected

14. Communciations

System choice

RFFiber opticsMicrowave

Radio options

Frequency selectedAJ techniqueTransmitting power

F.O. status

Cable usedCable leftCable cut

Antenna

PolarizationAuto-track on

B-16

REQUIRED STi '(. S

15. Inertial navigation system data

Heading

Altitude

Roll

Pitch

Yaw

Roll limit warning

Pitch limit warning

Slope indicator

Speedometer

Odometer

Trip odometer

Doppler speed

Wheel count speed

UTM coordinates

Latitude

Longitude

16. Mission modules

Reconnaissance module

Mine field breacher

Weapons package

CARD module

Jamming device

Smoke generator

Others to be determined

B-17

REQUIRED STATUS

17. Circuit Breaker Faults

Master

Light

Ignition

Brake boost

18. Exterior

Vehicle hit

Track off

Exterior temperature

Audio sensors (microphone):

Tire flat

Intrusion detection system

B-18

APPENDIX C

CONTROL COMMAND CODING

c-1

RCC TO RV CONTROL COMMAND CODING

Function/status Block Function Palramet%:.,ýDescription Field Field Field

Power plant 01Start 01Ki 1.102"nhrottle 03Cold start 04 PIT7:&tical idle on 05Iactical idle off 06Idle set 07 PIFuel turn on 09Fuel shut off OACruise control set OBCruise control resume 0CCrui,-0. control accelerate ODCruise control decelerate OECruise control coast OF"'Oectric current flow 10 PI

za .es 02ra ke 01 Pl

?a.kinq brake set 02iParking brake unset 03

v .:v(ce brake set 04Service brake unset 05

Steering 03Steer 01 PIRadius of turn 02 NHeading 03 N

Directional movement 04 N

Automatic transmission 04 SPark 01Reverse 02Neutral 03Drive 04

Drive, L 05Drive, H 06Pivot 07Tow 08

Manual transmission 05 SReverse 00

First 01

Second 02

Third 03

C-3


Function/status Block Function ParameterDescription Field,, Field', Field

Fourth 04Fifth 05

Transfer case 06, S

Wheel drive 07 S

Suspension 08Air shock height 01 PISuspension height- 02 PI

Fording 09Road propulsion 01Water propulsion 02Splash guard up 03Splash guard down 04water barrier set 05Water barrier release 06Exhaust pipe rise 07Exhaust pipe lower 08

Mobility OAEmergency stop 01Velocity 02 NGrid coordinates 03 NPivot left 04 PIPivot right 05 PICARD model enter 11CARD mode, exit 12CARD command identifier 13Autonomous road following, on 15Autonomous road following, off 16

Fuel OBFuel tank A 01Fuel tank B 02Fuel filler lock 03Fuel filler unlock 04Fuel filler open 05Fuel filler close 06

TurretPower on 01Power off 02Enable 03

Disable 04slýw 05 PI

c-4


Function/status Block Function ParameterDescription Field Field Field

Elevation 06 PI

Interior ODDefroster on 01Defroster off 02Heater on 03Heater off 04Air conditioner on 05Air conditioner off 06NBC system on 07NBC system off 08Bilge pumps, front, on 09Bilge pumps, front, off OA

Bilge pumps, rear, on 0BBilge pumps, rear, off 0CFire suppression on 0DFire suppression off OEVent open 11Vent close 12Vent fan on 13Vent fan off 14Wipers on 15Wipers off 16Heated glass on 17Heated glass off 18Doors lock 19Doors unlock 1A

Temperature setting 20 NHorn 21Windows up/down 22 PI

Lights OEHead lights on 01Head lights off 02High beam on 03High beam off 04Parking lights on 05Parking lights off 06

Right turn indicator 07Left turn indicator 08Hazard lights on 09Hazard lights off OABlackout lights on OBBlackout lights off OCInterior lights ODFog lights on OEFog lights off OF

C-5


Function/status ýBlock Function ParameterDescription Field Field Field

Back-up lights on ---Back-up lights off 11Exterior flood lights 12Spot light on 13Spot light off 14Spot light elevation 15 PISpot light azimuth 16 PISpot light tilt 17 PI

Electro-optic SensorImage Transmit Select 10 S

Video, forward, transmit 01Video, forward, do not transmit 02Video, Stereo, transmit 03Video,' Stereo, do not transmit 04Video, left peripheral, transmit 05Video, left peripheral, do nottransmit 06Video, right peripheral, transmit, 07Video, right peripheral, do not transmit 08Video, rear, transmit 09Video, rear, do not transmit.. GAVideo, reconnaissance, transmit 0BVideo, reconnaissance, do not transmit OcDriver's thermal viewer (DTV), transmit GDDriver's thermal viewer (DTV), do not transmit OEForward looking infrared (FLIR), transmit OFForward looking infrared (FLIR), do not transmit 10Radar, transmit 11Radar, do not transmit 12Laser, transmit 13Laser, do not transmit 14

Video, forward ....... 11Power on '01Power off 02Slew 03 PIElevation 04 PITilt 05 PIScan rate 06 NSector size 07 NDe-icer on 0-08De-icer off 09Wipers on OAWipers off OBContrast OC PIIris adjust ... D PIShutter speed O - GE N

-C-6


Function/status Block Function Parameter

Description Field Field Field

Zoom OF PIFocus 10 PI

Home 11

Convergence 12 PI

video, Stereo 12

Power on 01.Power off 02

Slew 03 PI

Elevation 04 PI

Tilt .05 PIScan rate 06 NSector size 07 NDe-icer on 08De-icer off 09Wipers on OAWipers off 0B

Contrast 0C PI

Iris adjust OD PI

Shutter speed OE N

Zoom OF PIFocus 10 PIHome 11

Convergence 12 PI

Video, left peripheral 13Power on 01

Power off 02

Slew 03 PI

Elevation 04 PI

Tilt 05 PI

Scan rate 06 N

Sector size 07 N

De-icer on 08

De-icer off 09

Wipers on OA

Wipers off OB

Contrast OC PI

Iris adjust GD PI

Shutter speed OE N

Zoom OF PI

Focus 10 PI

Home 11

Convergence 12 PI

Video, right peripheral 14Power on 01

c-7

"CONTROL COMMAND CODING

Function/status Block 'Function ParameterDescription Field Field Field

Power off 02Slew 03 PIElevation 04 PITilt 05 PIScan rate 06 NSector size 07 NDe-icer on 08De-icer off 09Wipers on GAWipers off GBContrast GC PIIris adjust OD PIShutter speed OE NZoom OF PIFocus 10 PIHome 11Convergence 12 PI

Video, rear 15Power on 01Power off 02Slew - 03 PIElevation 04 PITilt 05 PIScan rate 06 NSector size 07. NDe-icer-.on 08De-icer off 09Wipers on 0AWipers off OBContrast OCC PIIris adjust GD PIShutter speed NZoom OF PIFocus 10 PIHome 1 ...Convergence 12 PI

Video, reconnaissance. 16Power on 01Power off 02Slew 03 PIElevation 04 FITilt 05 PIScan rate 06 NSector size 07De-icer on

C-8



De-icer off 09Wipers on OAWipers off 0BContrast OC PIIris adjust OD PIShutter speed 0E NZoom 0F PIFocus 10 PIHome 11Convergence 12 PI

Driver's thermal viewer (DTV) 17Power on 01Power off 02Slew 03 PIElevation 04 PITilt 05 PIScan rate 06 NSector size 07 NDe-icer on 08De-icer off 09Wipers on 0AWipers off OBContrast 0C PIIris adjust 0D PIShutter speed OE NZoom OF PIFocus 10 PIHome 11Convergence 12 PIStand by 13Thermal hot 14Thermal cold 15

Forward looking infrared (FLIR) 18Power on 01Power off 02Slew 03 PIElevation 04 PITilt 05 PIScan rate 06 NSector size 07 NDe-icer on 08De-icer off 09Contrast OC PIZoom OF PIFocus 10 PI

C-9

CONTROL COMMAND CODING'


Home 11Flir thermal level 13 PIFlir thermal gain 14 PIFlir focus 15 PIFlir contrast 16 PI

Conditions Sensors 20Radar detector on 01Radar detector off .02Magnetic field detector on 03Magnetic field detector off 04Motion detector on 05Motion detector- off 06Frequency detector on 07Frequency detector off 08Light detector on 09.Light detector off OASonic detector on GBSonic detector off OCNBC detector on ODNBC detector off 0ENoise'detector on OFNoise detector off 10Rain detector on 11Rain detector off 12Snow detector on 13Snow detector off 14

VHF radio 21Power on 01Power off 02Frequency select 03 NRadio transmitting power. 0.4 PIAntenna azimuth 05 PIAntenna elevation 06 PIAntenna polarization' 07 S

,Antenna auto-track on 08Antenna auto-track off"', 09

Microwave radio 22Power on ..Power off 02,Frequency select. 03 NRadio transmitting power 04 PIAntenna azimuth PAntenna elevation 1. 0Antenna polarization. '•Q', S,07..S

.. c,-.. b . .

CONTRO[, COMMAND CODING

Function/status Block Function r i e telOescription Field Field Field

Antenna auto-track on 08•rntenna auto-track off 09

Fiber optic link 23

S-.se: link 24

tal navigation system 30v •i lize 01 TBD

et 02

mrission module platform 40

C-ll

APPENDIX D

STATUS INFORMATION CODING

D-1

RV TO RCC STATUS INFORMATION CODING


Power plant 81Engine running 01Engine not running 02Tachometer 03 NCoolant temperature gauge 04 NCoolant level low 05Coolant temperature high 06Oil pressure gauge 07 NOil pressure low 08Oil level low 09Oil temperature high 0AOil filter clogged 0BAlternator temperature high 0CAlternator not functioning 0DCold start indicator 0EExhaust temperature high OFBattery charge low 10Voltage gauge 11 NAir cleaner clogged 12Fuel filter clogged 13Fuel pump bad 14Hour meter 15 NThrottle feedback 16 PIEngine microphone on 17Engine microphone off 18

Brakes 82Brake 01 PIBrakes worn 02Master cylinder fluid

level low 03Brake line pressure gauge 04 NLow brake air 05Brakes nonfunctional 06Parking brake set 07Parking brake hydraulic

pressure gauge 08 N

Steering 83Steering feedback 01 PI

Automatic transmission gear 84 SPark 01Reverse 02Neutral 03

D-3


Function/status Blockk Function ParameterDescription Field Field Field

Drive, L 05Drive, H 06Pivot 07Tow 08Fluid filter clogged 10Fluid pressure low 11Fluid temperature high.- 12Fluid level low 13Transmission damaged 14

Manual transmission gear 85, SReverse 00First 01Second 02Third 03Fourth 04Fifth 05Fluid filter clogged 10Fluid pressure low 1iFluid temperature high 12Fluid level low 13Transmission damaged 14Shift gear indicator 1A

Transfer case 86 S

Wheel drive 87 S

Suspension 88Air shock height 01 NHydronuematic suspension

leval 02 N

FordingRiver depth N01 NRiver current speed 02, NRoad propulsion 03Water propulsion 04

Mobility 8AIn CARD mode iiIn autonomous mode .15

Fuel

Fuel gauge "1-NFuel low



Fuel temperature high 03Fuel filler cover off 04Fuel filler cover unlocked 05Fuel leak 06Instantaneous MPG 07 NBattery power pack charge

level 08 N

Turret 8CPower 01Seal pressure gauge 02 N

Interior 8DTemperature 01 NNBC system on 02NBC filter clogged 03NBC system overheated 04NBC system over pressure 05Front bilge pump on 06Rear bilge pump on 07Fire detected 08Fire supression discharged 09Fire extinguisher bottle

pressure gauge OA NWipers on OBDoors unlocked OCWindows down ODVent open OEVent fan on OFCabin pressure 10 NMoisture level high 11Door/hatch ajar 12Heater on 13Air conditioner on 14Absorbed power 15 N

Lights 8EHead lights low beam 01Head lights high beam 02Parking lights 03Left turn indicator 04Right turn indicator 05Hazard lights 06Blackout lights 07Interior light, front 08Interior light, middle 09Interior light, back OA

D-5


Function/status Block Function Par-ameterDescription Field Field Fiela

Exterior flood light OBExterior spot light SCFog lights ODBack-up lights OEEngine compartment light OFBulb(s) burned out 10 S

Electro-optic SensorImage Transmit Select 90 S

Video, forward, transmitting 01Video, forward, not transmitting 02Video, Stereo, transmitting 03Video, Stereo, not transmitting 04Video, left peripheral, transmitting 05Video, left peripheral, not transmitting 06Video, right peripheral, transmitting 07Video, right peripheral, not transmitting 08Video, rear, transmitting 09Video, rear, not transmitting OAVideo, reconnaissance, transmitting SBVideo, reconnaissance, not transmitting SCDriver's thermal viewer (DTV), transmitting ODDriver's thermal viewer (DTV), not transmitting SEForward looking infrared (FLIR), transmitting OFForward looking infrared (FLIR), not transmitting 10Radar, transmitting 11Radar, not transmitting 12Laser, transmitting 13Laser, not transmitting 14

Video, forward 91Power ,on 01Power off 02Scan rate 06 NSector size 07 NShutter speed OE N

Video, Stereo 92Power on 01Power off 02Scan rate 06 NSector size 07 NShutter speed OE N

Video, left peripheral -3Power on 01Power off 02

D-6


Function/status Block Function Parameter

Description Field Field Field

Scan rate 06 NSector size 07 NShutter speed OE N

Video, right peripheral 94Power on 01Power off 02Scan rate 06 NSector size 07 NShutter speed OE N

Video, rear 95Power on 01Power off 02Scan rate 06 NSector size 07 NShutter speed OE N

Video, reconnaissance 96Power on 01Power off 02Scan rate 06 N.Sector size 07 NShutter speed OE N

Driver's thermal viewer (DTV) 97Power on 01Power off 02Scan rate 06 NSector size 07 NStand by 10Thermal hot 14Thermal cold 15

Forward looking infrared (FLIR) 98

Power on 01Power off 02Scan rate 06 NSector size 07 N

FLIR thermal level 13 PIFLIR thermal gain 14 PIFLIR focus 15 PIFLIR contrast 16 PI

Condition sensors AO

Radar detected 01

D-7



Magnetic field detected 02Motion detected 03Frequency detected 04Light detected 05Sound detected 06NBC detected 07Rain detected 08Snow detected 09

VHF radio AlPower on 01Power off 02Frequency select 03 NRadio transmitting power 04 PIAntenna azimuth 05 PIAntenna elevation 06 PIAntenna polarization 07 SAntenna auto-track on 08Antenna auto-track off 09

Microwave radio A2Power on 01Power off 02Frequency select 03 NRadio transmitting power 04 PIAntenna azimuth 05 PIAntenna elevation 06 PIAntenna polarization 07 SAntenna auto-track on 08Antenna auto-track eff 09

Fiber optic link A3Fiber optic cable cut 02Fiber optic cable left on spool 03 NFiber optic cable dispensed 04 N

Laser link A4

Navigation BOHeading 01 NAltitude 02 NRoll 03 NPitch 04 NYaw 05 NRoll limit warning 06Pitch limit warning 07Slope indicator 08 N

D-8



Speedometer 09 NOdometer 0A NTrip odometer 0B NDoppler speed OC NWheel count speed OD NUTM coordinates OE NLatitude OF NLongitude 10 N

Mission Modules platform CO

Circuit Breaker Faults DO

Master 01Light 02Ignition 03Brake boost 04

Exterior E0Vehicle hit 01Track off 02Exterior temperature 03 NTire flat 04Intrusion detection 05

D-9

DISTRIBUTION LIST

Copies

Commander 12Defense Technical Information CenterATTN: DDACBldg. 5, Cameron StationAlexandria, VA 22304-9990

Manager 2

Defense Logistics Studies Information ExchangeATTN: AMXMC-DFort Lee, VA 23801-6044

Commander 2U.S. Army Tank-Autcmotive CcarmandATTN: AMSTA-DDL (Technical Library)Warren, MI 48397-5000

CommanderU.S. Army Tank-Automotive CommandATTN: AMSTA-CF (Mr. G. Orlicki)Warren, MI 48397-5000

CcmmanderU.S. Army Tank-Automotive CommandATTN: AMSTA-RVE (Adams)Warren, MI 48397-5000

Royal Armament R&D Establishment VT4ATTN: Alan BarradaleChobham Lane, ChertseySurrey, KT16 OEEUnited Kingdom

Jet Propulsion LaboratoryATTN: Mr. Roger Bedard4800 Oak Grove DrivePasadena, California 91103

U.S. Marine CorpsATTN: GATORS V0310 (Colonel Ray Bowles)Quantico, VA 22134

AFV Task ForceATTN: DAMO-AFV-C (Major Robert Buckstad)Fort Eustis, VA 23604-5597

Dist-1

DISTRIBUTION LIST (Continued)Copies

Naval Explosives Ordnance Disposal 1ATTN: Mr. Frank ClarkCode 501Indian Iead, MD 20640.50S 0

Microwave Radio Corporation 1ATTN: Mr. Edward Dahn847 Rogers StreetLowell, MA 01852

Michigan Automated Vehicle Research Consortium 1ATTN: Mr. Herbert Dobbs2727 Second StreetDetroit, Michigan 48201

Harry Diamond Labs 1ATTN: SLCHD-RT-IRD (Emmerman)2800 Powder Mill RoadAdelphi, MtD 20783

FmC CorporationCentral Engineering LabsATTN: Ewa Garg1205 Coleman Avenue Box 580Santa Clara, California 95052

John Deere Dubuque WorksATTN: Mr. Dan GriswoldP.O. Box 538Dubuque, Iowa 5204-0538

Commander 1U.S. Army Human Engineering LabATTN: Mr. Gary HaazAberdeen Proving Grounds, MD 21005-5001

Kraft TeleRobotics 1ATTN: Mr. Steve Harbur11667 West 90th StreetOverland Park, KS 66214

Naval Ocean Systems Center 2ATTN: Mr. Tom HughesCode 531Kailua, HA 96734-0997

Commandant 1U.S. Army Infantry SchoolATTN: ATSH-CD-MLS-E (Johnson)Fort Benning, GA 31905-5400

Dist-2

DISTRIBUTION LIST (Continued)

Copies

Sandia National Laboratories52-67ATTN: Mr. James KelseyAlbuquerque, NM 87185

Grumman Electronics SystemsGuided Weapons Systems ProductsATTN: Mr. Jerry KirschMail Stop B01-45Bethpage, New York 11714-3585

Sandia National Laboratories 1Advanced Technology Division 5267ATTN: Mr. Paul KlarerAlbuquerque, NM 87185

Oak Ridge National LaboratoryATTN: Mr. Bill KneeBuilding 6025, Mail Stop 360P.O. Box XOak Ridge, TN 37391-6360

Commander 2U.S. Army Communications-Electronics CommandATTN: AMSEL-RD-ASCO-SC (Kobylarz)Fort Monmouth, NJ 07703

HoneywellATTN: Mr. Bill KraetzMail Station MN 50-43005901 S. County Road 18Edina, MN 55436

Oakland UniversitySchool of Engineering & Computer SciencesATTN: Dr. Nan K. LohRochester, Michigan 48063

Oak Ridge National LaboratoryInstrumentation & Controls DivisionATTN: Mr. Wayne MangesP.O. Box XOak Ridge, TN 37831

General Dynamics Land Systems DivisionATTN: Mr. Phil McCownP.O. Box 2074MZ 436-32-23Warren, Michigan 48090

Dist-3


CopiesOdetics, Inc.ATTN: Mr. Bob Merket557 Arundel DriveSeverna Park, HD 21146

Delco Systems OperationsATTN: Chris MichaelsMail Code E6036767 Hollister AvehueGoleta, California 93117

U.S. Army Transportation SchoolATTN: ATSP-CDC (Captain Milling)Fort Eustis, VA 23604-5393

Honeywell Defense Systems GroupAdvanced Systems CenterATTN: Pat Narendra5901 South County Road 18Edine, MN 55436

CcmmanderU.S. Army Tank-Automnotive CcmuandATTN: AMSTA-R (Major Leonard Ogborn)Warren, MI 48397-5000

Delco Electronics CorporationDelco Systems OperationsATTN: Ferenc Pavlics6767 Hollister AvenueGoleta, California 93117

Commander 2U.S. Army Missile CammandATTN: AMSMI-RD-ST-GD (Dr. John Prater)Redstone Arsenal, AL 35898

Ommander 1U.S. Amy Ccmmunications-Electronics CcmuandATTN: AMSEL-RD-C3-IS (Saganowich)Fort Monmouth, MJ 07703

CaomanderU.S. Army Tank-Automlotive CommandATTN: AMSTA-TD, (Schmitz)Warren, MI 48397-5000

Advanced Decision SystemsATTN: Marcel Schoppers1500 Plymouth StreetMountain View, California 94943

Dist-4


Copies

National Bureau of Standards 1ATTN: Mr. Harry ScottBuilding 220, Room B124270 Quince Orchard RoadGaithersburg, MD 20899

CormmanderU.S. Army Humian Engineering LabsATTN: SLCHE-CS (Chuck Shoemaker)Aberdeen Proving Grounds, MD 21005-5001

U.S. Army TCE & FLW 1ATTN: ATZT-CD (Dr. Bob Sickler)Fort Leonardwood, MO 65473-5000

Kaman SciencesATTN: Mr. Kieth StokesP.O. Box 7463Colorado Springs, Colorado 80933-7463

U.S. Army Armor CenterATTN: ATSB-CD-SD (Captain Dennis Szydlowski)Fort Knox, KY 40121

Royal Armament R&D Establishment (Vehicle Dept)ATTN: John TindleChobham Lane, ChertseySurrey, KT16 QEEEngland

Vectran CorporationATTN: Mr. Tom Wilson261 Kappa DrivePittsburgh, Pennsylvania 15238

FMC CorporationCentral Engineering LabsATTN: Yue Min Wong1205 Coleman Avenue Box 580Santa Clara, California 95052

International Microwave Systems CorporationATTN: Mr. Mike Young2416 Our Country RoadEscondio, California 92025

Headquarters, Department of the.ArmyATTN: SARD-TR (Bruce Zimmerman)Washington, D.C. 20310

Dist-5


Copies

Director 1AMSAAATTN: ANXSY-NP (Mr. Cohen)Aberdeen Proving Ground, ND 21005-5071

Dist-6

robotic vehicle communications interoperability

Documents