wireless open-source/open-architecture command and control...

38
Wireless Open-Source/Open-Architecture Command and Control System Prepared by the Students of the Masters of Science, Product Development Harris RF Communications Class 1 November 12, 2008

Upload: vohanh

Post on 20-Mar-2018

218 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

Wireless Open-Source/Open-Architecture

Command and Control System

Prepared by the Students of the Masters of Science, Product DevelopmentHarris RF Communications Class 1

November 12, 2008

Page 2: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

2

Page 3: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

Executive Summary

The Wireless Open-Source/Open-Architecture Command and Control System (WOCCS) is a

module that provides communications between swarms of land, air and amphibious vehicles to the

command and control base station. The WOCCS modules will be developed by seniors in the

Rochester Institute of Technology Kate Gleason College of Engineering. The WOCCS teams will be

multidisciplinary and follow a roadmap developed by engineers at Harris Corporation participating

in the Master of Product Development (MPD) program at RIT.

The WOCCS program is expected to provide a rich pool of talent from which Harris

Corporation can recruit as well as providing students an opportunity to learn about the latest

technologies with regards to radio development. A technology roadmap created by the MPD

students (Figure 1) will provide the guidance for the WOCCS development and create at least one

major technological advancement per year in each of the six major components (Mechanical, RF,

User Interface, Command and Control Data Interface, Digital Baseband and Power Supply).

Set based concurrent engineering is expected to be utilized in order to promote individual

component development to occur at the fastest possible rate and in parallel with one another. This

will require teams to define a common interface that will support each phase of the development

of the individual components. The components for the development were chosen to align with the

architecture employed by Harris in the development of its line of Software Defined Radios. No

Harris proprietary information will be shared and students will have an opportunity to gain

experience in the various areas of radio development by learning fundamental radio design

techniques and exploring new technologies.

i

Page 4: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

TABLE OF CONTENTS

Executive Summary..................................................................................................................................i.................................................................................................................................................................3HMI Introduction.....................................................................................................................................3HMI Phase Development........................................................................................................................4HMI – Phase I...........................................................................................................................................4HMI – Phase II..........................................................................................................................................4HMI – Phase III.........................................................................................................................................5.................................................................................................................................................................7CCDI Introduction....................................................................................................................................7CCDI Module Functions, Phase I .............................................................................................................8CCDI Module Functions, Phase II............................................................................................................9CCDI Module Functions, Phase III.........................................................................................................10CCDI Design Interfaces..........................................................................................................................11

CCDI / Mechanical............................................................................................................................11CCDI / Power Supply Module............................................................................................................11CCDI / Digital Baseband Module.......................................................................................................11CCDI / RF Module..............................................................................................................................12CCDI / HMI Module...........................................................................................................................12

CCDI Module Deliverables Summary....................................................................................................12Documentation and Design Deliverables..........................................................................................12

Digital Baseband Introduction...............................................................................................................13Digital Baseband Module Functions, Phase I, COTS Hardware............................................................ 14Digital Baseband Module Functions, Phase II, Simple Power Management........................................14Digital Baseband Module Functions, Phase III, Advanced Power Management..................................15Digital Baseband Design Interfaces.......................................................................................................15

Digital Baseband / Mechanical..........................................................................................................15Digital Baseband / Power Supply......................................................................................................16Digital Baseband / RF........................................................................................................................16Digital Baseband / Data and Control Interface.................................................................................16Documentation and Design Deliverables..........................................................................................17

RF Module Introduction........................................................................................................................18RF Module Functions, Phase I, Basic Telemetry and Control...............................................................18RF Module Functions, Phase II, Telemetry, Control, and Low Speed Data..........................................19RF Module Functions, Phase III, Telemetry, Control, and High Speed Data.........................................20RF Module Design Interfaces................................................................................................................21

RF / Mechanical.................................................................................................................................21RF / Power Supply Module................................................................................................................21RF / Digital Baseband Module...........................................................................................................22RF / Command and Control Data Interface......................................................................................22

RF Module Deliverables Summary........................................................................................................23Hardware Deliverables......................................................................................................................23Documentation and Design Deliverables..........................................................................................23

Power Supply Introduction...................................................................................................................26Power Module Phase I: COTS Power....................................................................................................26Power Module Phase II: Energy Harvesting..........................................................................................27

ii

Page 5: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

Power Module Phase III: Rapidly Replenishable Power Source...........................................................27Power Supply Design Interfaces............................................................................................................27

Power / Mechanical..........................................................................................................................27Power / RF.........................................................................................................................................28Power / Digital Baseband..................................................................................................................28Power / Command and Control Data Interface................................................................................28

Power Supply Deliverables Summary...................................................................................................29Phase I: COTS Power.........................................................................................................................29Phase II: Energy Harvesting...............................................................................................................29Phase III: Rapidly Replenishable Power Source................................................................................29

Mechanical Module Functions, Introduction........................................................................................30Mechanical Module Functions, Phase I, Basic Mechanical Package.................................................... 30Mechanical Module Functions, Phase II, CNC Mechanical Housing.....................................................31Mechanical Module Functions, Phase III, Injection Molding Housing..................................................31Mechanical Module Functions, Summary.............................................................................................32Mechanical Module Deliverables Summary.........................................................................................32

Documentation and Design Deliverables..........................................................................................32 ..........................................................................................................................................................32

iii

Page 6: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

TABLE OF FIGURES

Figure 1, WOCCS Roadmap.....................................................................................................................1Figure 2, WOCCS Interaction Diagram....................................................................................................2Figure 3, US Amateur Radio Spectrum Allocation Plan........................................................................25

iv

Page 7: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

RF Subsystem

1 way communicationAnalog300mExample - RC Controller

2009 2012

2010 2011

Basic Telemetry and Control Telemetry, Control andLow Speed Data

Telemetry, Control andHigh Speed Data

Mechanical

Bud BoxReadily Available (COTS)Simplify IntegrationThermally ConductiveEMI/RFI Shielded

Power Subsystem

COTS Battery and external chargerCOTS DC/DC Supply for power railsVisual indication of battery capacity remainingExample – Li-Ion Battery

Command and Control Data Interface

Separate Control & Sensor BusStatic addressing for sensorsAnalog Control / Digital Sensor FeedbackWired busHigher bandwidth / Streaming VideoReliable Digital Control & DataSeparate BusesWireless Sensors

HMI

Simple Analog Vehicle & Payload Command (ie. joystick with buttons )LED | LCD for feedbackLittle to no Application supportText based GPS / BFTGeneric Text application for Receive Output of information / tracking

RF Subsystem

2 w ay communicationAnalogLow Speed Digital300mExample – digital or analog control + FSK data

Mechanical

CNC Machined HousingFull Customization CapabilityLighter Weight/Reduced SizeThermally ConductiveEMI/RFI Shielded

Power Subsystem

Energy Harvesting Technology InvestigationCreate a recharge mechanism to use reclaimed energyExample – Seebeck effect using RF Power Amplifier and chassis

HMI

More advanced Command TX / RXSimple Application supportSimple GPS / BFT (ie. linked to Google Maps)OTA RF parameters programmingDigital controlNon-specific APIsActive BIT / Post for error checking correctionSimple Transec

Command and Control Data Interface

Higher bandwidth / Streaming VideoReliable Digital Control & DataSeparate BusesWireless Sensors

RF Subsystem

2 w ay communicationHIgh Speed Digital1 kmExample – digital or analog control + networked high speed data

Power Subsystem

Rapidly Replenishable Power SourcesExample – Fuel Cells

HMI

Most advanced control application,Little to no analog controlCustom GPS / BFT app with Map nav, waypoint navSupport Cloning / Swarm technologyVoice command ideal, Voice response / warningGeneric APIs for ease of programmingRemote diagnostic supportMore advanced Transec

Command and Control Data Interface

Single wireless digital bus for control and sensorsDedicated control bandwidthLow Latency on ControlEncryptedDynamic addressing of sensors

Digital Baseband

Off the Shelf boards1 Hr battery lifeExample – Microcontroller or MicroITX

Digital Baseband

Custom BoardsSmaller Size, form factorPower management – 3 hour battery lifeSoftware Upgradeable - USBExample – Embedded DSP/GPP

Digital Baseband

High bandwidth dataPower Management – 8 hour battery lifeComponent power down – sleep/sniffExample – FPGA Softcore

Mechanical

Injection Molded HousingHigh VolumeSmaller /LighterEMI/RFI CoatingThermally Conductive Carbon Core Metal BondingIntegrated Circuitry

Figure 1, WOCCS Roadmap

1

Page 8: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

WOCCS

CPU, Memory

CPU, Memory

Steering Control

Position Sensor

UserControl Center

Land Vehicle

CPU, Memory

Flaps Control

Still Camera

Air Vehicle

CPU, Memory

Ballast Control

Depth Sensor

Underwater Vehicle

RF Module

RF Module

RF Module

Packaging

Packaging

Packaging

Packaging

User Interface

Command and Control Data

InterfaceRF Interface Digital

BasebandMechanical

HMI

Modules:

Power Supply

RF Module

Power Supply

Power Supply

Power Supply

Figure 2, WOCCS Interaction Diagram

2

Page 9: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

WOCCS: Human Machine Interface (HMI)

2009 2012

2010 2011

Basic Telemetry and Control Telemetry, Control andLow Speed Data

Telemetry, Control andHigh Sped Data

Command (ie. joystick with buttons)LED | LCD for feedbackLittle to no Application supportGeneric Text application for Receive Output of information / tracking

More advanced Command TX / RXSimple Application supportSimple GPS / BFT OTA RF parameters programmingDigital controlActive BIT / Post for error checking

Little to no analog controlCustom GPS / BFT app with Map navSupport Cloning / Swarm technologyVoice command ideal, Voice responseGeneric APIs for ease of programmingRemote diagnostic support

2010Start Phase II

2011Start Phase II

HMI Introduction

This section of the document pertains to the Human Machine Interface, or HMI. HMI is defined as "...The way a person interacts with a computer or electronic device. It comprises the screen menus andicons, keyboard shortcuts, command language and online help, as well as physical buttons, dials andlevers. All input devices, such as a mouse, keyboard, touch screen, remote control, joy stick, gamecontroller or data glove, are also included." [FreeDictionary by Barflex]

The HMI for the Wireless Open-Source/Open-Architecture Command and Control System (WOCCS) isenvisioned to allow the user to fully program and prepare a base station setup and the vehiclecommand system. These are to be configurable such that they will work together and communicatetogether to facilitate the use of the vehicular systems, be they air, ground, or sea based systems. Inaddition, the HMI should facilitate the sending and receiving of data to and from the vehicle in question.This data may be diagnostic in nature, for actual directional command, or even locational in content(such as GPS coordinates). The interface shall be equipped with a mechanism to download andprogram firmware to the platform. The intent of this mechanism is to provide convenient yet basicembedded programming over a wired connection or attached memory device (i.e., Flash drive).

Performance is a critical operational parameter. The device should be responsive to the user’s actions.This means that there should be no excessive delay between a selected action and the recumbentresponse. Any delay should show an indication of progress to the user. Usability is one of the primeconcerns of HMIs in general, and there needs to be significant investigation into this arena. The HMIshould be usable to most anyone not familiar with the internals of the system. Appearance is the thirdarea of interest, as the HMI must have logical organization to the commands and layout.

3

Page 10: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

The HMI will also require interfacing with other modules of the WOCCS system. These interfaces arenot just the physical connection points, but actual logical communication that will need to beundertaken to have a complete, coherent system for a user. These interfaces are concerned with thePower Supply, the Digital Baseband, the RF, and the CCDI connections modules. All of these will havean impact on the HMI for the WOCCS, as well as the HMI having a potential impact on them. Themodule development teams will require at least minimal communication to have the system besuccessfully completed.

HMI Phase Development

The HMI development has several phases suggested by Harris RFCD. These phases range from the leastcomplex to the most complex systems. These phases are not in selectable order, and set basedconcurrent design would suggest that all three could be undertaken (at least investigated) to discoverwhich has potential and which is achievable in a given time frame and with the technologies available.

HMI – Phase I

The first phase, as described above, is to be the easiest fallback position that a team should undertake.This is the minimum required that would be essential for controlling wireless connected vehicles. Theobjective of this means is to establish a basic functional interface between the WOCCS platform and anoperator. The interface should be basic and easy to operate. For this phase control may be establishedusing simple analog metaphors, such as a traditional video game style joystick. Status feedback shall beminimal, utilizing a small liquid crystal display and/or light emitting diode indicators. Positional andtracking data shall be logged in a file or on a text based display.

The development strategy of this approach would be to gather the minimum inputs and outputs thatthe system requires to achieve the minimal operation with the Human controller. This should lead tothe discovery of how those inputs and outputs should be conveyed to the controller and to the vehicleitself. The analysis of the usability needs might be only superficial, or discarded, depending on the setof variables for control.

The Harris goals for this phase are reasonably minor in scope. The students would be expected tobecome minimally familiar with controls and interface programming (creation of LEDs, or ASCII).

RIT goals for this approach would be the use of electrical skills and creativity of solution from thestudents in creating the controls system.

HMI – Phase II

This phase builds upon the basic HMI by adding function enhancements and features. One objective isto separate the physical user control mechanisms from the WOCCS platform. Through this,implementers shall explore the development of a separate user interface application by utilizinganother platform such as a laptop, PDA or Game Boy.

4

Page 11: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

The phase is to allow the control of the vehicle from an application that is running on a PC. Thisapplication would take the place of the analog control that was created in Phase I, and would facilitateremoval of any analog controls on the WOCCS base station. This phase introduces Over-The-Air (OTA)programming of the system parameters and firmware to the vehicle. This allows easier programming,eliminating necessity to have the vehicle return to the base station. Situational Awareness is introducedby linking GPS to some easy to integrate navigation system (such as Google's Maps web page). This willallow for introductions into the world of Blue Force Tracking and GPS navigation. Active Built-In-Test(BIT) and / or the use of Power-On-Self-Test (POST) type testing is also suggested for this stage, allowingthe team members to become accustomed to quality control, and verifiable systems. Position datashall not be transmitted in the clear; therefore basic encryption concepts will be introduced.The development strategy of this approach would be to examine the best way to configure the controlsthrough the digital interfaces and to investigate the integration of the more advanced features. Theapplication would entail a usability study that would be more in line with what team members may facein the real world, and the use of the OTA programming leads to the study of Bit-Error-Rates (BER). It ispossible for implementers to create their own protocols at this stage.

The Harris goals for this phase are more involved in scope than the previous phase. The students wouldbe expected to become more familiar with programming Application Programming Interfaces (APIs),and the use of integrating with 3rd party technologies. The use of OTA programming would be ofinterest as this is duplication of the cloning features of radio to radio to facilitate in the fieldprogramming.

RIT goals for this phase would be the application learned programming skills, and the involvement ofresearch into the 3rd party technologies for GPS, BFT. In addition RIT would be interested in having lessspecialized hardware for the WOCCS platform.

HMI – Phase III

The third phase is the most complex, yet possibly most rewarding of the three phases. This could be themost time consuming of the three approaches, with intensive research and development.

The phase is intended to remove all use of analog control interfaces into the WOCCS. The system isexpected to be able to utilize waypoint navigation in conjunction with the locational system that shallbe developed for the system. The application that would be controlling the vehicle would be expectedto be platform agnostic (ala Java), and to entail more Object Oriented style programming skills to allowmore compartmentalization of the system to facilitate reuse of various components.

The development strategy of this approach would be far more intensive then the other two phases.These phases would require a great deal of usability study, as well as investigation into how to create awaypoint navigation system and how to link that into a GPS system. In addition this phase would bemore involved with the Object Oriented Design, and Object Oriented Analysis (OOD and OOArespectively) that is being currently taught by RIT. This would also allow more comprehensive designwork to be started and used by the students over the phase of the project. This exposes students to theutilization of more formal development cycles that are common in the commercial market place (suchas waterfall).

5

Page 12: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

The Harris goals for this phase are more in line with technologies that are requested or required of thecurrent customer base. This would potentially bring out new ideas for GPS navigation assistance for /from radios to systems. This will stress greater creativity and talent for HMI development of controlsystems.

RIT goals for this approach would also be more in tune with preparing the students for their future livesas engineers. These real world applications prepared students for real world assignments that would begiven to them once hired by companies such as Harris.

6

Page 13: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

WOCCS: Command and Control Data Interface

2009 2012

2010 2011

Basic Telemetry and Control Telemetry, Control andLow Speed Data

Telemetry, Control andHigh Sped Data

Separate Control & Sensor BusAnalog Control / Digital Sensor FeedbackHigher bandwidth / Streaming VideoReliable Digital Control & DataWireless Sensors

Higher bandwidth / Streaming VideoReliable Digital Control & DataSeparate BusesWireless Sensors

Single wireless digital bus for control and sensorsDedicated control bandwidthLow Latency on ControlEncryptedDynamic addressing of sensors

2010Start Phase II

2011Start Phase II

CCDI Introduction

The Command and Control Data Interface (CCDI) subsystem of the WOCCS provides both physical andprotocol level means for the user to control the various functions of the remote vehicle as well as forsensors to return their data to the controller. While there is some challenge in developing the physicalmedium used for transmitting this information, the real challenge is at the protocol level due to theamount and type of data the sensors need to send. The roadmap defines three distinct phases for thismodule, each increasing in complexity. In the first phase, the module assumes that the control of thevehicle is done via a commercially available RC controller while sensor data is limited to telemetry andsent over a wired bus. Phase II introduces a separate wired bus for digital command data received viathe RF and Digital Baseband modules and converts the sensor bus to a wireless medium capable ofhandling more data. Phase III requires a combined command and data bus that can handle high levels ofdata throughput and intelligent manages sensor throughput.

7

Page 14: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

CCDI Module Functions, Phase I

Analog RC Receiver

Analog Control Devices

(wheels, flaps, etc)

Digital Data Interface Module

Position Sensor(Low Bandwidth)Wired BUS

Other Sensor(Low Bandwidth)

Phase I

Control

DataDigital

Baseband

The Phase I CCDI Module is required to provide a wired bus to the sensors that will be transmittingtelemetry data back to the controller. The module will include all of the physical bus hardware and thesoftware protocol required to provide this bus including, but not limited to:

• Wired medium (RS-232, RS-485, USB, Ethernet, Custom Solution, etc)

• Communications Protocol that supports:

o Individual addressing of the sensors.

o Best effort data delivery (Dropped packets are lost)

• Physical connectors to the medium

• A conversion module that will allow the physical medium to change while not requiring achange on the CPU or sensor modules.

The module is required to support information payloads required to provide one-way data delivery fromthe vehicle’s sensors to the controller. The Phase I implementation is to provide a reliable sensor databus and form the basis for future enhancements as outlined in the roadmap.

The sensor bus design must utilize only open-standard communications protocols. For this initialdesign; the team is strongly encouraged to keep the requirements of future phases in mind whenchoosing the underlying data communications protocol as choosing the wrong protocol will result inadditional work for future groups. While initially requiring best effort data delivery, future phases willrequire that this protocol be able to support guaranteed linearly ordered data delivery. The overheadthat this protocol requires should also be taken into consideration as future phases will require largerbandwidth which this overhead will eat into.

In phase I, any physical medium is acceptable. The communications protocol will be restricted to onethat allows for the expansion mentioned both in this and in future phase descriptions. The fundamentalprotocol should not need to be changed in future phases (expansion of this protocol is allowed). Thedevelopment team may wish to look at low level protocols such as Ethernet or higher level protocolssuch as IP which provides both best effort (UDP) and guaranteed (TCP) data delivery protocols. Theseare just possible suggestions and the development team is encouraged to explore as many differentcommunications protocols as possible as this phase impacts and restricts future phases. The teamshould only implement the portions of the communications protocol that are required for this phasebut incorporate methods that allow this protocol to be easily expanded.

8

Page 15: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

Once developed, the team should stress this data bus to its limits with throughput and loading tests.Additional expected deliverables are outlined in the CCDI Module Deliverables Summary section below.

CCDI Module Functions, Phase II

Digital Data Interface Module

Digital Control Devices

(wheels, flaps, etc)Wired BUS

Position Sensor(Low Bandwidth)

Control

Still Picture(Med. Bandwidth)

DataDigital Baseband

Phase II

At phase II of the WOCCS roadmap it is expected that the CCDI module maintains all of the functionsand features of the previous phase (Minus the physical bus). This phase will add a digital wiredcommand bus, convert the medium used for the sensor data bus to a wireless medium, and expand thecapabilities of the sensor bus. Interfaces to the CPU and to the sensors should remain unchanged due tothe use of the converter modules introduced in Phase I.

The protocol selected in Phase II will allow for expansion to include new features. The selection of thewireless medium for the sensors should consider the following:

• Maximum number of sensor nodes• Worse case required throughput (All sensors transmitting simultaneously)• Interference from/with the RF module• Power consumption

While determining which wireless medium should be utilized, the team should keep in mind thatfeatures such as higher data rate and transmitter output power creates some constraints on the othermodules like power supply module. Also, the frequency chosen may cause interference with or mayreceive interference from the RF module. The team will need to verify that the Digital Baseband and RFmodules will be able to support the same or better throughput that the sensor bus supports. This phasewill require that the sensor bus becomes more flexible in order to make the addition and removal ofsensors easier for the end user. To support this, the communications protocol used should be expandedto allow sensors to dynamically obtain an address as well as to report what type of sensor they are(Telemetry, still image, etc).

The command bus is relatively straightforward. The team may wish to consider reusing the physicalmedium that was selected in Phase I for the sensor data. The team will need to develop a standardinterface that will allow the converter units to be developed for the devices being controlled so thedigital commands can be translated into signals that are useful for the control of the device. The devicesbeing controlled should be statically addressed as it is assumed that these devices will not be varyingsignificantly over the life of the vehicle.

9

Page 16: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

The communications protocol selected in Phase I should be enhanced to also provide a guaranteedlinear in-order delivery of command data. This is a critical requirement as the loss of command dataand/or delivering the command data in any other order could result in significant risk to both thevehicle and to any object or person near the vehicle.

CCDI Module Functions, Phase III

Digital Data Interface Module

Digital Control Devices

(wheels, flaps, etc)Wired or Wireless BUS

Position Sensor(Low Bandwidth)

Control / Data

Streaming Video(High Bandwidth)

Phase III

Digital Baseband

Still Picture(Med. Bandwidth)

At phase III of the WOCCS roadmap it is expected that the CCDI module maintains most of the functionsand features of the previous phase. This phase will combine the command and sensor buses into asingle unified bus and will expand the bandwidth of this bus to allow for streaming video data inaddition to the previous types of data allowed. Interfaces to the CPU, controlled devices, and sensorsshould remain unchanged due to the use of the converter modules introduced in previous phases. It isleft to the team to determine if a wireless or wired bus will meet the requirements of this phase,though the team is strongly encouraged to consider a wireless solution.

This phase is the most challenging of all three phases. In determining the physical medium to use for thecombined bus the team needs to carefully consider:

• Bandwidth that the medium supports

• Any interference to/from the RF module (If wireless is used)

• Reliability of the medium

It is imperative that sensor data does not interfere with the delivery of command data. This implies thatthe protocol chosen will need to be expanded, or the lower level protocol associated with the medium(if one exists) needs to be designed, so that a portion of the available bandwidth is statically allocated tothe transmission of command data.

While previous phases required the user to ensure that the data sourced from all of the sensorscombined would not exceed the bandwidth provided by the sensor bus, this phase will incorporate thatintelligence into the bus itself. Individual sensors will now be required to not only identify what type ofdata they will be sourcing, but also the amount and type of bandwidth (burst or streaming) they willrequire. A bus controller shall need to be developed (if not done in previous phases) that will use thisinformation to negotiate this bandwidth with the individual sensors. Should these negotiations fail, thebus controller should send a NACK to the individual sensor as well as sending an allocation failuremessage to the vehicle’s controller that includes the identification information provided by the sensoralong with a message indication the reason for the failure.

10

Page 17: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

CCDI Design Interfaces

CCDI / MechanicalThe CCDI module is required to occupy the mechanical packaging provided by the mechanical designteam. To that end, the CCDI and Mechanical module teams will collaborate on key mechanical designelements of the CCDI module and the system as a whole. For each, consideration needs to be paid tohow the CCDI / Mechanical interface will influence each team’s designs.

• Size of the CCDI module, mounting requirements

• Environmental

o Operating and Storage Temperature

o Shock and vibration requirements and the components used in the RF module

o Environmental sealing

• EMI Shielding Requirements

• Thermal Management

• Safety

CCDI / Power Supply ModuleThe CCDI module may require electrical power depending on the physical bus selected. To that end, theCCDI and Power Supply module teams will collaborate on key electrical power design elements of theCCDI module and the system as a whole. For each, consideration needs to be paid to how the CCDI /Power Supply interface will influence each teams’ designs including, but not limited to:

• Operating voltages required

• Peak and average current draw of voltage supply or supplies

• Noise immunity / filtering requirements

CCDI / Digital Baseband ModuleThe CCDI module will require close collaboration with the digital hardware for the Digital BasebandModule. To that end, the CCDI and digital baseband teams will collaborate on key design elements ofthe CCDI bus module and the system as a whole. For each, consideration needs to be paid to how theCCDI / Digital Baseband interface will influence each teams’ designs including, but not limited to:

• Interface Control Document (ICD)

• Control Timing

• Data format, physical interface information

11

Page 18: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

CCDI / RF ModuleThe wireless bus will be integral to the WOCCS system. Although there will be no direct interfacingbetween these modules, the teams should collaborate to ensure RF compatibility with anyimplementations of the data interface. Care should be taken to make sure the following is considered:

• RF Interference between the analog RF control and digital RF data stream

• RF waveform support for the data stream bandwidth

CCDI / HMI ModuleThe CCDI module will receive messages and send them to the user interface. To that end, the CCDI andHMI module teams will collaborate on key design elements of the CCDI module and the system as awhole. For each, consideration needs to be paid to how the CCDI / HMI module interface will influenceeach teams’ designs including, but not limited to:

• Interface Control Document (ICD)

• Protocol for both command and data links

• Types of sensor devices and feedback

CCDI Module Deliverables Summary

Documentation and Design Deliverables1. Trade study of available interfaces and data rates (USB, FireWire, TCP/IP, Bluetooth)

2. Schematic drawing of circuit designs

3. Interface Control Document (ICD)

a. Power Supply

b. Digital Baseband (physical interface)

c. WOCCS HMI (protocol)

4. Packaging requirements of CCDI module

5. CCDI Design Verification Test (DVT) Report

6. Functional demonstration of integrated system with other design teams

12

Page 19: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

WOCCS: Digital Baseband ModuleSubsystem

2009 2012

2010 2011

Basic Telemetry and Control Telemetry, Control andLow Speed Data

Telemetry, Control andHigh Sped Data

Off the Shelf boards1 Hr battery lifeExample – Microcontroller or MicroITX

Custom BoardsSmaller Size, form factorPower management 3 hour battery lifeSoftware Upgradeable - USBExample – Embedded DSP/GPP

High bandwidth dataPower Management – 8 hour battery lifeComponent power down – sleep/sniffExample – FPGA Softcore

2010Start Phase II

2011Start Phase II

Digital Baseband Introduction

The Digital Baseband Module subsystem of the WOCCS provides the command and control of all othersubcomponents (except the User Interface) in the WOCCS system. Developing this module is achallenging task in several elements of digital hardware design, software design, packaging, cost, power,and in collaboration with fellow teams. The roadmap defined for the digital baseband module hasestablished three design phases that offer a progression of features and functionality and lays a pathtowards more robust and feature rich implementations. In the first phase, the module provides simpleone-way control communication to allow wireless control of the vehicles. Phase I provides a simpleimplementation with little regards to power management, hardware layout, easy of softwareupgradability or modularity of software architecture. Phase II incorporates a custom printed circuitboard utilizing off the shelf components. The software in phase II will be upgradable via a readilyavailable interface such as USB, and rudimentary power management techniques employed. Phase IIshould be concerned with overall power consumption of the digital baseband component and chose itssubcomponents with an eye towards battery life. Phase III will be the most challenging with theincorporation of advanced power management techniques such as sleep/sniff, and the ability to processlarge amounts of data for sensor data streaming, audio and video.

The digital baseband design must utilize commercial off-the shelf components to reduce cost whereverpossible. Off the shelf software components that have licenses that can be utilized for commercial,academic, personal is encouraged. The implications of the software licenses should be considered withparticular attention to how these licenses may affect the ability of commercial applications to adopt this

13

Page 20: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

technology. Additionally, royalties of any sort for commercial components should be avoided toencourage the hobbyist user to adopt this technology.

Digital Baseband Module Functions, Phase I, COTS Hardware

The Phase I Digital Baseband Module is required to provide control of all other modules in the WOCCSsystem with the exclusion of the User Interface. The module will include all of the digital basebandhardware and software required to provide this control including:• RF Transceiver control

• Control of the Data Interface module

• Translation of data from the Data Interface Module to the RF subsystem

The module is required to support the information payload required to provide one-way wirelessremote control of the vehicle. The Phase I implementation is to provide a reliable control link and formthe basis for future enhancements as outlined in the roadmap.

In phase I, any digital baseband technology is acceptable, provided it can be used on the largest Phase IWOCCS vehicles available. A microcontroller could be utilized, as well as micro–ITX style PC boards.The digital baseband development team should work closely with the power supply and RF teams toensure that the life of the battery exceeds 1 hour.

Digital Baseband Module Functions, Phase II, Simple Power Management

The Phase II Digital Baseband Module is required to provide control of all other modules in the WOCCSsystem with the exclusion of the User Interface. The module will include all of the digital basebandhardware and software required to provide this control including:

• RF Transceiver control

• Control of the Data Interface module

• Translation of data from the Data Interface Module to the RF subsystem

The module is required to support the information payload required to provide wireless remote controlof the vehicle and feedback.

In phase II, low power components must be chosen that can fit in the size and weight constraints ofother components in the system. The software in phase II should be upgradeable via a readily availableinterface such as USB. Programmable general purpose processors, or DSPs built on a custom PCB wouldbe recommended. Clock scaling techniques should be utilized to reduce overall power requirements.The digital baseband development team should work closely with the power supply and RF teams toensure that the life of the battery exceeds 3 hours.

14

Page 21: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

Digital Baseband Module Functions, Phase III, Advanced Power

Management

The Phase II Digital Baseband Module is required to provide control of all other modules in the WOCCSsystem with the exclusion of the User Interface. The module will include all of the digital basebandhardware and software required to provide this control including:

• RF Transceiver control

• Control of the Data Interface module

• Translation of data from the Data Interface Module to the RF subsystem

The module is required to support the information payload required to provide wireless remote controlof the vehicle and feedback. The Phase III implementation is the most advanced phase it is expectedthat this architecture will support all the high bandwidth data interfaces available in other Phase IIImodules.

In phase III, the lowest available power components must be chosen that can fit in the size and weightconstraints of other components in the system. An FPGA utilizing softcore technology would berecommended. Clock scaling techniques should be utilized to reduce overall power requirements aswell as component power down techniques and sleep/sniff technology. The digital basebanddevelopment team should work closely with the power supply and RF teams to ensure that the life ofthe battery exceeds 8 hours.

Digital Baseband Design Interfaces

Digital Baseband / MechanicalThe digital baseband module is required to occupy the mechanical packaging provided by themechanical design team. To that end, the digital baseband and mechanical module teams willcollaborate on key mechanical design elements of the digital baseband module and the system as awhole. For each, consideration needs to be paid to how the Digital Baseband / Mechanical interfacewill influence each team’s designs.

• Size of the digital baseband module, mounting requirements

• Environmental

• Operating and Storage Temperature

• Shock and vibration requirements and the components used in the digital basebandmodule

• Environmental sealing

• EMI Shielding Requirements

• Thermal Management

15

Page 22: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

• Safety

Digital Baseband / Power SupplyThe digital baseband module will require electrical power for the electronics to function as designed.To that end, the Digital Baseband and Power Supply module teams will collaborate on key electricalpower design elements of the Digital Baseband module and the system as a whole. For each,consideration needs to be paid to how the Digital Baseband / Power Supply interface will influence eachteams’ designs.

• Operating voltages required

• Peak and average current draw of voltage supply or supplies

• Duty cycle required for operation

• Noise immunity / filtering requirements

• Efficiency, energy storage, and operating life of the system

Digital Baseband / RFThe RF module will require support and interface from the digital hardware for the electronics tofunction as designed. To that end, the RF and Digital Baseband module teams will collaborate on keycontrol interfaces of the RF module and the system as a whole. For each, consideration needs to bepaid to how the Digital Baseband / RF interface will influence each team’s designs.

• RF Module control interface

• RF Control State Machine / Transition Diagram

• Control Timing

• Interface Control Document (ICD)

• Data format, baseband information

• Frequency planning, mitigating interference between RF and digital clocks, etc.

Digital Baseband / Data and Control InterfaceThe Data and Control Interface module will require support and interface from the digital hardware forthe electronics to function as designed. To that end, the Data and Control Interface and DigitalBaseband module teams will collaborate on key control interfaces of the Data and Control Interfacemodule and the system as a whole. For each, consideration needs to be paid to how the DigitalBaseband / RF interface will influence each team’s designs.

• Buffering of data from external components

16

Page 23: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

• Initializing firmware on the Data and Control Interface Board

Documentation and Design Deliverables• Trade study of available processors and power consumption

• Schematic drawing of circuit designs

• Interface Control Document (ICD)

• Power Supply

• Data and Control Interface, RF Module state transition diagram

• Mechanical, connectors, etc.

• Packaging requirements of digital baseband module

• Digital Baseband Circuit Design Verification Test (DVT) Report

• Functional demonstration of integrated system with other design teams

17

Page 24: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

WOCCS: RF Module SubsystemPhase I, II, III Implementation Summary Requirements

2009 2012

2010 2011

Basic Telemetry and Control Telemetry, Control andLow Speed Data

Telemetry, Control andHigh Sped Data

1 way communicationAnalog500mExample - RC Controller

2 way communicationAnalog / Low Speed Digital500mdigital or analog control + FSK data

2 way communicationHIgh Speed Digital, 1 km rangeExample – digital or analog control + networked high speed data

2010Start Phase II

2011Start Phase II

RF Module Introduction

The RF Module subsystem of the WOCCS provides the critical wireless link between the controller andthe remote vehicles. Developing this module is a challenging task in the elements of RF design,packaging, cost, power, and challenge in collaboration with fellow teams. The RF module will providethe wireless link which carries the information payload required by the system. The roadmap definedfor the RF module has established three design phases that offer a progression of features andfunctionality and paves a path towards more robust and feature rich implementations. In the firstphase, the module provides simple one-way control communication to allow wireless control of thevehicles. Phase II provides for two-way information exchange between the controller and remotevehicles for not only control, but wireless information fed back from the remote vehicle. Phase III seekshigher information bandwidth to allow more advanced data features such as real time sensor datastreaming, audio, video, etc.

RF Module Functions, Phase I, Basic Telemetry and Control

The Phase I RF Module is required to provide a wireless link between the control and remote modulesthat allows for remote control of the vehicle. The module will include all of the RF hardware requiredto provide this link including, but not limited to:

• Antenna and antenna system

• RF Transmitter at the controller

• RF Receiver at the vehicle

• RF Modulation / Demodulation and associated interface to the digital hardware

18

Page 25: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

• Adjacent support circuits

The RF module is required to support the information payload required to provide one-way wirelessremote control of the vehicle. The Phase I implementation is to provide a reliable control link and formthe basis for future enhancements as outlined in the roadmap.

The wireless design must utilize only open-standard communications protocols that can operate overopen, available, and legal frequency spectrum within the bounds of NTIA/FCC regulations. The initialdesign is encouraged to strongly consider the implications of choosing which frequency band tooperation from both a technical and logistical standpoint. Bands such as the 900MHz, 70cm, 1.25meter, 2m, 4m, 6m, and other unlicensed bands should be evaluated to trade off their merits againstthe operational requirements of the module and the WOCCS system as a whole. Emphasis should alsobe placed on the commercial availability of wireless components for the intended application.

In phase I, any wireless protocol is acceptable and should be considered provided it can meet theinformation payload requirement for the control of the vehicle and meets the spectral requirements ofthe chosen frequency band. This includes analog FM, frequency, or phase shift keying (FSK/PSK). Theoperating range of the link should meet or exceed 500 meters in the phase I module. An RF link marginanalysis based on the RF hardware performance, RF propagation modeling, and intended operatingenvironment should be considered to validate range along with verification through field testing of thehardware. Additional expected deliverables are outlined in the RF Module Deliverables Summarysection below.

RF Module Functions, Phase II, Telemetry, Control, and Low Speed Data

At phase II of WOCCS roadmap it is expected that the RF module maintain all functions and features ofprevious phases with the addition of a communication channel from the vehicle to the controller fortelemetry. Initially, this return communication channel can be implemented as an analog channelsimilar to the control channel. But, ideally, a low speed digital communication channel should beconsidered to provide the ability to transfer small amounts of data. All interfaces to the DigitalBaseband Module remain unchanged.

Additional RF hardware required to provide the return communication capability includes, but is notlimited to:

• RF Receiver at the controller• RF Transmitter at the vehicle

It is required that the return analog communication channel provide acknowledgments of receivedcommands in addition to simple telemetry data. It is also a requirement that the commands andacknowledgements be treated as higher priority than the telemetry data. Some options to provide thiscapability include but are not limited to half-duplex communication, full-duplex communication orTDMA (Time Division Multiple Access).

Support for a low speed data channel may require the addition of a digital communication channel. It isanticipated that this digital channel will initially be utilized for transmission of a small amount ofsupplementary data, such as audio data or still pictures. The analog channels may remain for the

19

Page 26: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

control and telemetry functions. Consideration should be given to the relocation of the command andcontrol functions to the digital channel, but this is not a requirement of this phase of the project.

If the design provides both analog and digital channels at the same time, consideration must be given tomanaging the interfaces. It is important that the addition of the digital channel does not affect theperformance of the analog channel. Some of the factors that will be affected by the dual channelapproach may include power consumption, frequency interference, and battery life.

If the design replaces the analog channel with the digital channel, consideration must be given to theuse of the channel so that control and telemetry maintains a higher priority than the supplementarydata. It may be possible to define the interface to multiplex the control and data over the interface.

RF Module Functions, Phase III, Telemetry, Control, and High Speed Data

At phase III of WOCCS roadmap it is expected that the RF module maintain all functions and features ofprevious phases and add support for data streaming and improve the communication range to morethan 1 km. All interfaces to the Digital Baseband Module remain unchanged.

This phase is the most challenging compared to the previous two phases. Additional features ofextended communication range and full motion video requires careful selection of the following:

• Antenna and antenna system

• RF Transceiver at the controller

• RF Transceiver at the vehicle

• RF Modulation / Demodulation and associated interface to the digital hardware

• Adjacent support circuits

• Modulation topology

• Operating Frequency

• Higher Date Rate

• Transmitter Output Power Level

Features such as low power operation, small size, and low cost have become the dominant designcriteria by which wireless products in general are judged. As a result, new circuit techniques must besought to allow increased integration of radio transmitters and receivers, along with new radioarchitectures that take advantage of such techniques. Motivated by the above goals, a low power andhigh performance transmitter for wireless communication is a goal for this phase. As a drivingapplication, phase III is to meet the needs of a wireless video system. Such a system may require digitalmodulation to be performed at data rates in excess of 1 Mbps.

Enhanced features such as higher data rate and transmitter output power creates constraints on theother modules like power supply module. Higher transmitter output power may require higher current

20

Page 27: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

provided by power supply. Depending on the selected modulation topology, radio architecture designor operating frequency new antenna is required which impacts mechanical enclosure. These modulesmight also be redesigned to support the new features like full motion video stream. Selection of videocamera and its power requirements adds to the constraints of power supply and also mechanicalenclosure design as it must provide a proper housing for the camera.

In this phase the range is a critical factor that refers to the coverage area between the wirelesstransmitter and the receiver. The range can be strongly correlated with the power of the signal.

RF Module Design Interfaces

RF / MechanicalThe RF module is required to occupy the mechanical packaging provided by the mechanical designteam. To that end, the RF and Mechanical module teams will collaborate on key mechanical designelements of the RF module and the system as a whole. For each, consideration needs to be paid to howthe RF / Mechanical interface will influence each team’s designs.

• Size of the RF module, mounting requirements

• Environmental

o Operating and Storage Temperature

o Shock and vibration requirements and the components used in the RF module

o Environmental sealing

• EMI Shielding Requirements

• Thermal Management

• Safety

• Packaging and influence on the antenna system

RF / Power Supply ModuleThe RF module will require electrical power for the electronics to function as designed. To that end, theRF and Power Supply module teams will collaborate on key electrical power design elements of the RFmodule and the system as a whole. For each, consideration needs to be paid to how the RF / PowerSupply interface will influence each team’s designs including, but not limited to:

• Operating voltages required

• Peak and average current draw of voltage supply or supplies

• Duty cycle required for operation

21

Page 28: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

• Noise immunity / filtering requirements

• Efficiency, energy storage, and operating life of the system

RF / Digital Baseband ModuleThe RF module will require support and interface from the digital hardware for the electronics tofunction as designed. To that end, the RF and Power Supply module teams will collaborate on keyelectrical power design elements of the RF module and the system as a whole. For each, considerationneeds to be paid to how the RF / Power Supply interface will influence each team’s designs including,but not limited to:

• RF Module control interface

o RF Control State Machine / Transition Diagram

o Control Timing

o Interface Control Document (ICD)

• Data format, baseband information

• Frequency planning, mitigating interference between RF and digital clocks, etc.

RF / Command and Control Data InterfaceThe wireless bus will be integral to the WOCCS system. Although there will be no direct interfacingbetween these modules, the teams should collaborate to ensure RF compatibility with anyimplementations of the data interface.

22

Page 29: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

RF Module Deliverables Summary

Hardware Deliverables1. Transmitter module for controller

• Antenna system

• RF amplification

• RF modulation

• Baseband interface

• Module control / all necessary support circuitry

2. Receiver module for remote

• Antenna system

• RF receiver / low noise amplifier (LNA)

• RF demodulation

• Baseband interface

• Module control / all necessary support circuitry

Documentation and Design Deliverables1. Trade study of available RF spectrum

2. Analysis of frequency planning options to accommodate and coexist with the rest of the system

3. Schematic drawing of circuit designs

4. Interface Control Document (ICD)

a. Power Supply

b. Digital / Baseband, RF Module state transition diagram, control specification

c. Mechanical, connectors, etc.

5. Link margin analysis of wireless system

6. Power Budgeting (Phase II, III)

7. Packaging requirements of RF module

8. RF Circuit Design Verification Test (DVT) Report, including but not limited to:

23

Page 30: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

a. Transmitter Performance

i. power output

ii. efficiency

iii. spectral compliance

iv. thermal design

b. Receiver Performance

i. sensitivity and noise figure

ii. power efficiency

9. Field test report of real world performance/range with intended information payload

10. Functional demonstration of integrated system with other design teams

24

Page 31: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

Figure 3, US Amateur Radio Spectrum Allocation Plan

Page 32: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

WOCCS: Power Module SubsystemPhase I, II, III Implementation Summary Requirements

2009 2012

2010 2011

COTS Power Supply Energy Harvesting Rapidly Replenishable

COTS Battery and external chargerCOTS DC/DC Supply for power railsVisual indication of battery capacity Example – Li-Ion Battery

Energy Harvesting Technology InvestigationCreate a recharge mechanism to use reclaimed energyExample – Seebeck effect using RF Power Amplifier and chassis

Rapidly Replenishable Power SourcesExample – Fuel Cells

2010Start Phase II

2011Start Phase II

Power Supply Introduction

The Power Module subsystem of the WOCCS provides the power sources for all other modules in theWOCCS whether it is in a remote vehicle or the base controller. The development of this moduleinvolves knowledge of power supply design, packaging, cost, and challenges in collaboration with otherteams involved in the project. The roadmap defined for the Power Module consists of three designphases. The first phase involves developing the core of the supply with COTS technologies includingbatteries, charger, and DC/DC converters with filtering. The second phase adds energy harvestingtechnologies to extend the mission life of the WOCCS. The third phase introduces alternative powersources to replace/supplement the COTS battery from phase 1.

Power Module Phase I: COTS Power

The Phase I Power Module is required to provide power to all other modules. The power module isresponsible for energy storage, regulation of voltage for all required power rails and providing thenecessary filtering to ensure the delivery of clean power to all subsystems. The module must alsocontain some sort of mechanism for monitoring the current level of the power source.

The energy storage medium for phase I of the power module will be a rechargeable battery. The powermodule team must research a variety of commercially off-the-shelf (COTS) rechargeable batterysolutions and select the best choice for the application.

The DC/DC converter/filtering module must be a researched to determine the best solution. Theconverter must be able to provide all required system voltages at a noise level that is acceptable to themodules using the power. The team must collaborate with other module teams to determine therequired power budget for the entire system.

Page 33: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

Finally, a visual indication of the current battery level must be designed by the team. This indicationmust allow a user to quickly approximate how much battery life is remaining so that they can determineif recharging is necessary.

In summary, the requirements for the Phase I power module are:• Research, specify and purchase a rechargeable COTS battery solution• Collaborate, research, specify and purchase a COTS filtered DC/DC converter to feed all other

modules • Design a circuit to provide a visual indication of current battery life

Power Module Phase II: Energy Harvesting

The objective of this phase is to investigate, develop, and integrate energy harvesting and other non-traditional power technologies for the purpose of maximizing mission time and delaying the need torecharge from a primary electrical source. Successful designs will need to capture, convert, and storeenergy from environments/experiences the vehicle is subjected to in the course of its travels and usethis energy to either recharge or supplement the primary power supply for the WOCCS. Technologiesto investigate may include, but are not limited to, the following:

• Solar energy• Seebeck Effect (ex. temperature differential of RF Power Amplifier and chassis)• Motion (ex. wave motion, rotation of tires, vibration due to propeller)• Human power (ex. hand crank, shake-to-charge)

Power Module Phase III: Rapidly Replenishable Power Source

The objective of this phase is to investigate, develop, and integrate a rapidly replenishable powersources to replace/supplement the COTS power source developed in phase one. Successful designsshould consider the amount of time required to fully replenish the power source, operating lifeexpectancy, operating temperature, size and weight, ability to deliver high transient current for radiotransmissions, and others. Technologies to investigate may include, but are not limited to, thefollowing:

• Fuel Cells• Ultracapacitors• New battery technologies (e.g. Toshiba Super Charge ion Batteries (SCiB))• Fluid Fuels (e.g. Hydrogen)

Power Supply Design Interfaces

Power / MechanicalThe Power Module must fit within the space defined by the mechanical / packaging design team.Therefore, the power module and mechanical team must collaborate on the key elements that existbetween these two modules including:

Page 34: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

• Space allotted for the entire power module• Physical mounting of the regulation/filtering module and battery• Connectors – Input for battery recharging, battery status indication• Thermal dissipation considerations• EMI Shielding Requirements• Safety• Environmental

o Operating and Storage Temperatureo Shock and Vibrationo Environmental SealingPower / RF

The Power Module must be able to satisfy the power requirements of the RF transceiver module.Therefore, the power module and RF module teams must collaborate on the key elements that existbetween these two modules including:

• Connectors between the modules• Any special filtering requirements• Required operating voltages• Peak current draw / Inrush current requirements• Overall power consumptionPower / Digital Baseband

The Power Module must be able to satisfy the power requirements of the digital basband module.Therefore, the power module and digital baseband module teams must collaborate on the keyelements that exist between these two modules including:

• Connectors between the modules• Any special filtering requirements• Required operating voltages• Peak current draw / Inrush current requirements• Overall power consumptionPower / Command and Control Data Interface

The Power Module must be able to satisfy the power requirements of the CCDI module. Therefore, thepower module and CCDI module teams must collaborate on the key elements that exist between thesetwo modules including:

• Connectors between the modules• Any special filtering requirements• Required operating voltages• Peak current draw / Inrush current requirements

• Overall power consumption

Page 35: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

Power Supply Deliverables Summary

Phase I: COTS Power• Matrix summarizing the different battery technologies that were researched and the

characteristics of each (chemistry, power density, recharging characteristics…etc)• Costed BOM for all materials used in this phase• Electronic and Hard Copies of schematics for all circuits created / purchased (when possible)• Power supply efficiency, noise level and thermal performance should be characterized for

various levels of loading• Battery performance should be characterized• Lessons learned : summarize all lessons that you learned during the course of this phase that

might be useful to future students

Phase II: Energy Harvesting• Matrix summarizing the different energy harvesting technologies that were researched and the

characteristics of each• Costed BOM for all materials used in this phase• Electronic and Hard Copies of schematics for all circuits created / purchased (when possible)• Lessons learned : summarize all lessons that you learned during the course of this phase that

might be useful to future studentsPhase III: Rapidly Replenishable Power Source• Matrix summarizing the different rapidly replenishable power source technologies that were

researched and the characteristics of each• Costed BOM for all materials used in this phase• Electronic and Hard Copies of schematics for all circuits created / purchased (when possible)• Lessons learned : summarize all lessons that you learned during the course of this phase that

might be useful to future students

Page 36: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

WOCCS: Mechanical Module Subsystem

2009 2012

2010 2011

Basic Mechanical Package CNC Machined Housing Injection Molded Housing

Readily Available (COTS)Simplify IntegrationThermally ConductiveEMI/RFI Shielded

Full Customization CapabilityLighter Weight/Reduced SizeThermally ConductiveEMI/RFI Shielded

High VolumeSmaller/LighterEMI/RFI CoatingThermally Conductive

• Carbon Core• Metal Bonding

Integrated Circuitry / Antenna

2010Start Phase II

2011Start Phase II

Mechanical Module Functions, Introduction

The Wireless Open Command and Control System (WOCCS) will require an enclosure to house theelectronic components, provide a means to divert heat from them, prevent EMI/RFI interference toother devices, and protect them from the environmental conditions when operating in the field. Theinitial roadmap is broken up into three phases spanning 3 academic years at RIT. The mechanicalpackage design in Phase 1 is intended to provide the basic needs for the system allowing focus on thedesign/development of the electronic modules and interfaces. Phase 2 will take a more active approachallowing for size and weight reduction as well tightly integrated with the components and overallsystem. Phase 3 is intended to push the envelope, utilizing more recent and emerging technologies asthey relate to electronic packaging and thermal management. At the end of the 3-year period theWOCCS system will be a platform demonstrating state of the art wireless and mechanical packagingtechnologies.

Mechanical Module Functions, Phase I, Basic Mechanical Package

Phase 1 mechanical enclosure is intended to provide a basic platform for the initial development of theWOCCS. Commercially available of the shelf (COTS) technology should be considered so that the teamcan focus on the more challenging electronics and software design and development aspect. There areseveral OEM suppliers of electronics housings in the market place. One such supplier is BUD Industrieslocated in Willoughby, Ohio. They have been providing the electronics industry with enclosures for over80 years. They have a wide selection of catalog products and will customize applications to provide aturnkey solution as well if needed. During this phase, size and weight are not critical parameters. Thisapproach is simplistic in nature, allowing for focus on the more critical tasks yet providing the basicneeds for a successful electronic enclosure. It will house the electronics and, by adding relatively simple

Page 37: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

sheet metal components, it can be compartmentalized as needed to provide isolation between thevarious modules. Holes can be added to the enclosure to provide means by which the I/O can beintegrated into the system. It also provides a thermal mass for heat dissipation and, in some cases, willprovide EMI/RFI suppression.

Mechanical Module Functions, Phase II, CNC Mechanical Housing

Phase two will allow a more tightly coupled mechanical design of the electronics enclosure now that thebasic functionality of the wireless system, developed in phase 1, is functional. Moving away from theCOTS enclosure to a custom CNC housing will open the design up to be more closely integrated with theelectronic modules. A CNC machined housing can be fully customized allowing reductions in both sizeand weight while still providing the basic functionality required for thermal management,environmental protection, EMI/RFI shielding and as an I/O mounting platform. A machined housingopens up the possibilities to use different engineering materials like aluminum, magnesium or titaniumallowing trade studies involving size, weight, cost and thermal performance. Today’s CNC machiningcenters can machine complex and intricate shapes with extremely tight tolerances allowing tighterintegration of the modules within the housing. It is an excellent choice of fabrication method for low tomid volume production runs as it provides both reduced cycle times as well as flexibility if a need for achange affecting the housing arises.

Mechanical Module Functions, Phase III, Injection Molding Housing

Phase 3 will investigate and implement newer and emerging technologies in the electronic packagingfield. Size, weight, and power dissipation are parameters that are constantly in conflict with oneanother in the packaging of electronics. Because the world is continually demanding smaller and lightersystems, the need for plastic use in electronic housing designs is on the rise but challenges remainhowever. Many of the engineering plastics today do not perform well in the dissipation of heat. Thereare some new compounds out on the market that do provide a significantly higher level of powerdissipation, but still nowhere near that of a aluminum equivalent. Newer technologies showing promiseinclude hybrid systems where an aluminum or carbon core is integrated with a polymer with fairly highthermal conductivity. The thermally conductive polymer provides electrical isolation while it conductsheat to the metal or carbon core. This core distributes the heat laterally providing increased thermalperformance versus plastic alone. Another challenge in the use of plastics in housing electronics isrelated to EMI/RFI shielding effectiveness. A means by which this can be mitigated is through the use ofpolymers containing additives and fillers that increase the EMI/RFI shielding characteristics. A metalizedcoating can be applied as well, coupled with the use of an EMI/RFI enhanced polymer, furtherimproving the shielding effectiveness. Metallization and the application of conductive inks and epoxiesare taking the use of plastics in electronics packaging to a higher level. Selective metallization coatingcan be applied to the plastic housings and function as the antenna. The combining of functionseliminates the need for a separate component (antenna) and reduces cost.

Page 38: Wireless Open-Source/Open-Architecture Command and Control ...edge.rit.edu/content/R12003/public/Report year 2008 OSOA Wireless... · Wireless Open-Source/Open-Architecture ... The

Mechanical Module Functions, Summary

This roadmap philosophy allows the decoupling of the mechanical design of the housing from theelectrical and software development. The first phase allows teams to focus on the electrical designaspect early on without the need or burden to develop a complex mechanical package design. It allowsthe team to investigate phases 2 and 3 early on in the development cycle if they choose. Minimizing thenumber of constraints early on I the development phase frees up resources to investigate alternativeswith the knowledge that they can always fall back to the more simplistic approach if needed. This is thekey characteristic of a set based concurrent engineering philosophy. Flexibility early on in thedevelopment process allows the team to maintain multiple options throughout and converging to afinal design solution that meets the requirements.

Mechanical Module Deliverables Summary

Documentation and Design Deliverables1. Trade study of all mechanical packaging technologies investigated/traded

2. Detailed component and assembly drawings

3. Analysis Summary

b. Structural

c. Thermal

4. Final test report

5. Functional demonstration