Excellence in New Product Development Wireless Open-Source / Open-Architecture Command and Control System (WOCCS) Roadmap Presentation

Leadership New Product Development (NPD) Set Based Concurrent Engineering (SBCE) Course Objectives: Leadership in NPD  Learn/Apply principles of effective leadership to product development issues  Understand best practices in the management of product strategy/development  Identify general “failure modes” of task oriented teams, anticipate and prevent potential problems. Course Objectives: SBCE  Understand basic concepts of lean production systems  Review emerging best practices in lean NPD and SBCE  Demonstrate “leadership from below”  Develop a roadmap for future technology research  Improve product development/innovation skills

Traditional Point Based Approach Attempt to rigidly define solution at beginning of development. Serial approach with defined stages. “20 questions” without feedback  Is it a animal, vegetable or mineral? Animal  Is it a muskrat? No  Is it a goldfish? No  Is it a lion? No  Is it a bird? No  Is it a crocodile? Yes A point is picked and tested. Open loop with no feedback from previous efforts.

Set Based Concurrent Approach End solution is initially undefined, multiple concurrent solutions are pursued simultaneously. Iterative approaches yield progressively more information Interfaces are defined early to permit concurrent development of discrete components. Benefits:  Decisions can be deferred until later  Risk can be more easily managed by trying multiple approaches which are simultaneously explored  Design converges more quickly versus point based approach

Example of Set Based Concurrent Development Power supply  Initial design: 70% efficient, ship date 6 months  2nd design: 80% efficient, ship date 12 months  3rd design: 85% efficient, ship date 24 months All three options concurrently pursued  Guaranteed shippable product in 6 months  If 2nd design is ahead of schedule, it may be incorporated into the first design in lieu of the first proposal.  Second and third iterations will be 'ready to go' for the next iteration of the product.

Wireless Open-Source/Open-Architecture Command and Control System (WOCCS) Technology based on open hardware/software architecture  Communication backbone for multiple vehicles (air, land, sea) controlling motion, collecting and retrieving data Develop future Harris talent  Engage up to 36 RIT engineering students annually  Exposure to complex embedded systems/environments  Provide a talent base for future Harris RF needs  Mirror Software Defined Radio (SDR) architecture used extensively by Harris Advanced Development  Provide a basis for future technological advances in design/development of communication products Continues the strong relationship between R.I.T. and Harris

WOCCS Roadmap

Power Module Roadmap Rechargeable Battery COTS DC / DC converter COTS Filtering Visual Battery Status Display Environmentally rugged Small, modular package Phase 1 Phase 2 Phase 3 Investigate Various methods for reclaiming wasted / available energy Ex. Thermal, Solar, Wind, Vibration, Motion. Implement one method into the power supply module Design circuitry to allow reclaimed energy to trickle charge the battery COTS Battery + DC/DC Supply Energy Harvesting Rapidly Replenishable Power Sources Investigate alternative energy sources as the main supply Ex. Fuel cells, liquid fuels, Toshiba Super Charge ion Battery (SCiB), Ultra/Super Capacitors Integrate one alternative fuel source into the design

Mechanical Roadmap Readily Available (COTS) Simplify Integration Thermally Conductive EMI/RFI Shielded Phase 1 Phase 2 Phase 3 Full Customization Lighter Weight/Reduced Size Thermally Conductive EMI/RFI Shielded BUD Box (Bud Industries) CNC Machined Housing Injection Molded Housing High Volume Smaller/Lighter EMI/RFI Coating Thermally Conductive Carbon Core Metal Bonding Integrated Circuitry / Antenna

Digital Baseband Readily Available (COTS) Evaluation board 1 hr Battery life Phase 1 Phase 2 Phase 3 Smaller form factor Power Mgmt - Clock Scaling 3 hr Battery Life Software Upgradeable Off the Shelf Custom Board High Bandwidth Data Power Mgmt – Sleep/Sniff Component power down 8 hr Battery Life Supports High bandwidth data Utilize COTS development board of students choosing to provide RF control, signal processing and interfaces to other components Architecture must be software reconfigurable Interfaces to other components must be defined in Phase I and be utilized in Phases II and III Team must collaborate with other WOCCS teams to determine power, size and weight requirements

RF Subsystem – Major Functions Transmit / Receive Data Payload Link between control and remote vehicle System interfaces  Mechanical  Power Supply  Digital Baseband  Command and Control Data Interface Key Parameters  RF Performance a)Range b)Efficiency  Cost  Open Standards / Frequencies

RF Subsystem Roadmap Phase 1  Simple Analog communication  1 way communication  Provides control of remote vehicle Phase 2  Add low speed digital communication  Analog still used for control and telemetry  2 way communication  Digital used for data a)Enables transfer of still pictures b)Enables transfer of small audio files Phase 3  Add high speed digital communication  Move control and telemetry to digital communication  Remove analog communication capability

Command and Control Data Interface Phase I  Separate Command Interface  Analog Remote Control for Commands 1)COTS Hobbyist RC 2)Check for interference with WOCCS RF link  Wired bus for sensor communication  Statically assigned addresses  Low bandwidth, best effort

Command and Control Data Interface Phase II A.Separate Command Interface  Digital wired bus a)Statically assigned address b)Protocol supports guaranteed delivery c)Command modules take digital input B.Wireless bus for sensor communication  Dynamically assigned addresses  Allows for Plug and Play configurations

Command and Control Data Interface Phase III  Combined Command & Data Interface  Wireless or Wired Digital Bus  Dynamically assigned address  Command  Dedicated command bandwidth  Protocol supports guaranteed delivery  Low latency, in order delivery  Sensor Data  Dynamically allocated bandwidth  Protocol supports best effort

HMI Roadmap Progressively improving stages  Attempt to further automate actions (user or vehicle in nature) Gather new ideas for programming of system, as well as for distributing information to users Generic, scalable interfaces to accommodate new payload & vehicles.

HMI Responsibilites Inputs to Vehicle  Vehicle Feedback / Location  Programming of System Parameters Outputs to User  Vehicle Control (via glove, iPhone, joystick, or touchscreen)  Diagnostics (BIT, POST, BER, etc)  Sensor Information/Collection (Payload Control)  Situational Awareness Programming  Firmware or Application Programming

Questions?