January 31, 2006

1. January 31, 2006

2. ICE is High-Tech • High-Tech Manufacturing: • Measuring and Control Instruments • - Instrumentation • - Controls • Computers & Peripheral Equipment • Communications Equipment • Consumer Electronics • Electronic Components and Access • Semiconductors • Defense Electronics • Photonics • Electromedical Equipment • Communications Services: Wired, Wireless, Satellite • Software and Tech Services: Software Publishers, Computer System Design, Internet, Engineering ICE

3. ICE is Membership

4. Target Market Primary Customers (at the present time): • Industry – existing members: • ABB • Rockwell • Keithley • Orbital • Industry – new members • NASA • Moon, Mars • Test bed • Manufacturing in space

5. Academic Involvement • Primary Partners • Case, Akron, CSU • Secondary Partners • NASA, OSU, Kent State • Developing/Expected Partners • University of Dayton, University of Cincinnati, Youngstown State, Toledo, Zane State, Stark State, Cleveland Institute of Art Mark Tumeo

6. Research, Products, and Services • Pieces Already In Place • “Translational Research” fund in place: • Initially funded by Federal grant and private donors • Board of Directors led by business • Venture Capital access: • Through Ohio Innovation Fund provide direction and guidance on accessing venture funds • Through Jumpstart, Inc. provide professional review, support and potential funding for most promising Start-ups

7. Research, Products, and Services • Pieces Already In Place • Pre-arranged Intellectual Property Agreements for Ohio ICE Members: • Sets mutually accepted terms on ownership, licensing and royalty arrangements for ALL types of research funding • Eliminates uncertainty and reduces “administrative” delays for research contracts • Network of higher education institutions across Ohio: • Provides access right at industry’s “back door” • Leverages the 3rd Frontier “Dark Fiber” Network to provide access statewide

8. ICE is research • Industry-University Consortium • Integration of computing, communication, measurement, and control • Align the technology needs of industry with the multifunction needs of academia • Increase research support for electrical engineering and computer sciences • Research • Perform industrially relevant research that improves industrial capacity, production and efficiency • Perform research that develops new concepts, processing methods, and new analytical techniques

9. Research Products & Services Research is 100% industry driven! • Technical Advisory Committee (TAC): • Representation from industry and academia • Confirm focus of the research is in alignment with needs of ABB, Keithley, Rockwell, and other Industrial Partners • Review, refine, approve proposals submitted by associated Universities • Process tested over the last six months: Case/Akron proposal • Industry Benefits: • New talent trained in fields of instrumentation, controls, and electronics • Help advance state-of-the-art and provide new employees with these state-of-the-art skills. • Neutral workshop with competitors where can work on compatibility between products and develop industry standards

10. Research Needs • Sensor issues • Advanced Motion Control issues • Networked, Distributed Control issues • Hard to separate these three areas as each impacts the bigger issues that companies such as ABB, Rockwell, etc. are trying to solve

11. Networked Control

12. Computing in the physical world Components Sensors, actuators Controllers Networks Enables Operations in hazardous environments Timely remote support Continuous operations Remote monitoring Troubleshooting Reduce time, effort, cost to develop and upgrade applications Merge cyber- and physical- worlds Networked Control

13. Example • Physical environment • Pipes, levers • Switches • Sample task • Close lever • Robot • Actuators • Arm, gripper • Sensing • Force feedback • Visual feedback • Control • Local compliant control • Remote supervision (Joint work with W. Newman, A. Al-Hammouri)

14. Hardware Security Networked Control Software Engineering Diagnostics

15. Prof. Steven L. GarverickX. Yu, L. Toygur, Y. He, M. Crane Hardware Wireless Sensor Platform for Harsh Environments

16. Wireless Sensor PlatformObjectives and Applications • Objectives • Low-power and robust, wireless microsensors • Unobtrusive sensing • Harsh operating conditions • High temperature • Mechanically/chemically active environments • Applications • Automotive, aerospace, and geothermal industries • In-vivo tissue and blood sensing for health monitoring and treatment • In-situ monitoring of liquids and gasses for contamination control and security

17. Wireless Sensor PlatformApproach

18. Decimator VCO Sigma-Delta Modulator Bias Rm Amp Test Structure SOI Test ICDie Microphotograph

19. SOI SD ADCDC Tests at Room Temperature Nominal operating conditions DC transfer characteristics at room temperature Performance summary

20. SOI SD ADCAC Tests at Room Temperature FFT magnitude of the  output SNR vs. input amplitude @ nominal conditions Number of points = 16384 The 16, 48, 80 .. kHz dither

21. 60 50 40 30 SNR (dB) 20 Instruments Hot Plate 10 Connector Tube . . . . 0 Thermal grease -10 27 50 100 150 200 250 300 Thermocouple Temperature (°C) DIP SOI SD ADCHigh Temperature Test SNR versus temperature High-temperature test setup @ nominal conditions

22. SOI Rm AmplifierTest Setup Measurement setup for Rmamplifier Ceramic-on-gold Module • DIP package • Pin coupling > 15 fF caused oscillation at ~1 MHz • Gold-on-ceramic module using bare die • Oscillations continue • With CL = 100 pF, oscillations stop and BW  700 kHz Tunnel diode Resistor SOI IC Capacitor

23. SOI Rm AmplifierHigh Temperature Test Results Magnitude response vs. frequency ~500 kHz Rm = ~ 8 MW

24. SOI Rm AmplifierHigh Temperature Test Summary Passband gain vs. Temperature Passband bandwidth vs. Temperature • The frequency response for temperatures up to 250 C is nearly ideal: Rm = 8.3 Meg, fL = 1 kHz, fH = 500 kHz • The transimpedance gain decreases at temperatures above 250 C • The amplifier continues to function well at temperatures up to 300 C

25. Kenneth A. Loparo Diagnostics Diagnostics and Prognostics: Sensor and Algorithm for Health Monitoring in Industrial Systems

26. Motor and Gearbox Diagnostics and Prognostics Gear Diagnostics Motor Diagnostics: -rotor unbalance -rotor bar faults -stator winding faults Motor and Gearbox Health Monitoring System Lube Diagnostics Bearing Diagnostics

27. Lubricant Health Monitoring: Signal Processing, Diagnostics and Prognostics MEMS Sensor Feature Extraction Data Level Fusion Lubricant Failure Space Decision Level fusion Temperature TAN ElectroChemical Conductivity Feature vectors Water contamination Estimation of Lubricant Health Indicators Indicator 1(1) Data Association Decision fusion Machine Health Assessment Sensor 1 Indicator m(1) preprocessing overheating Machine Health Prediction Sensor n Indicator 1(n) preprocessing Lubricant Health Estimation History Indicator m(n) Remaining Useful life Estimation History Lubricant information History History

28. Experimental Results (Prognosis) HMM Probabilities given HMM for Normal Condition • SKF6204 Bearings • Failed in 50 days • Speed = 10012 rpm • Load = 340 lbs (axial) • T = 260oF • Fs = 24 kHz Log Probability

29. Michael S. Branicky Networked Control Networked Control Systems

30. Networked Control Systems • Numerous distributed agents • Physical and informational dependencies • Control loops closed over heterogeneous networks

31. h Plant h1(t) Plant Delay Delay Controller Controller h(t) . . . Plant Network Controller r hN(t) Plant Plant Controller Controller Fundamental Issues • Time-Varying Transmission Period • Network Schedulability • Network-Induced Delays • Packet Loss [Branicky, Phillips, Zhang: ACC’00, CSM’01, CDC’02]

32. h1(t) Plant Controller . . . Network hN(t) Plant Controller Control and Scheduling Co-Design • Control-theoretic characterization of stability and performance (bounds on transmission rate) • Transmission scheduling satisfying network bandwidth constraints Simultaneous optimization of both of these = Co-Design [Branicky, Phillips, Zhang: CDC’02]

33. Packet queueing and forwarding Network dynamics Visualization Plant agent (actuator, sensor, …) Controller agent (SBC, PLC, …) Router Bandwidth monitoring Plant output dynamics Simulation languages Co-Simulation Methodology [Branicky, Liberatore, Phillips: ACC’03] Co-simulation of systems and networks

34. Co-Simulation Components (1):Network Topology, Parameters ns-2 package used to simulate network at packet level: • state-of-art, open-source software • follows packets over links • queuing and de-queuing at router buffers • GUI depicts packet flows • can capture delays, drop rates, inter-arrival times Our simulations (heterogeneous links, diff. queue sizes): • Fast Ethernet links, switches, 48B packets • T1 line with 1.544 MB/s (from router to controller) • FTP cross-traffic: TCP SACK/DelAck, Internet params.

35. Co-Simulation Components (2):Plant and Controller Dynamics Extension of ns-2 release (written by Liberatore): • plant “agents”: sample/send output at specific intervals • control “agents”: generate/send control back to plant • dynamics solved numerically using Ode utility, “in-line” (e.g., Euler), or through calls to Matlab Our simulations (scalar, NL inv. pendulum, aircraft): • identical unstable plants, sensors sampling periodically • controller stabilizes plant, which is event-based • actuators receive/exert control and are event-based • one (distinguished) plant

36. Analysis and Design Tools • Stability Regions [Zhang, EECS, Ph.D., May 2001] • Traffic Locus [Hartman, EECS, M.S., Jun. 2004] Both for an inverted pendulum on a cart (4-d), with feedback matrix designed for nominal delay of 50ms. Queue size = 25 (left), 120 (right)

37. Summary • Reviewed Networked Control Systems (NCS) • Summarized Fundamental Issues, Co-Design • Introduced a Co-Simulation Methodology, Code • Presented Analytical/Design Tools: Scaling, Heterogeneity (links, traffic)

38. Vincenzo Liberatore Software Engineering Software Engineering: Middleware and Agents

39. Middleware Application (the control application, e.g., close-lever) • Dealing with complex systems • Explicit structure allows identification, relationship of complex system’s pieces • Layered reference model for discussion • Modularization eases maintenance, updating of system • Change of implementation of layer’s service transparent to rest of system • E.g., change in data link doesn’t affect rest of system Middleware (common to multiple applications, e.g., resource discovery) Transport (e.g., TCP, RTP/UDP) Network (convergence layer: IP) Data Link (low level communication, e.g. Ethernet, Infinet, etc.)

40. Resource Discovery • Plug-and-play • Add new resources on the fly • Example: USB • Plug in a USB camera on a USB port • But now we want: on a network, with arbitrary units • Example • Locate a robot on the network

41. Jini • Operations • Discover, Join, Look-up, Use • Programming • Include a library • Use functions • Fault-tolerance • Leases • Join only last for a certain time period • Renew the lease • Multiple look-up servers • JavaSpaces • Distributed shared memory • URL: www.jini.org Courtesy of Sun Microsystems

42. Middleware • Between application and transport • Libraries to provide advanced functionality • Hide communication • Applications • Resource Discovery • Remote Procedure Calls • Security • Interoperability (e.g., since Real-Time Corba) • Scheduling, resource management, performance analysis • Multicast • Software development • Simpler, faster • State-of-the-art functionality • Middleware over IP • Wealth of libraries for IP • Critical advantage of the Internet Protocol

43. Agents: Objectives • Survivability and fault-tolerance • Safety and security • Cope with unstructured physical environments • Unified protocols across human-robotic networks • Software re-use

44. Agent: Objectives (contd) • Tolerate low network Quality-of-Service • Long-haul delays, packet losses • Unit aggregation and cooperation • Evolvability • Re-programmability • Dynamic reconfiguration • Extensibility

45. Vision: Agent-based • Basic properties • Autonomous, mobile • Adaptable, flexible, reactive • Knowledgeable, goal-oriented, learning • Collaborative • Persistent • Agents for robots • Aggregation into task-oriented teams • Evolvable • Re-programmability, reconfiguration, extensibility

46. Virtual Robots: The Core GUI, interface Thin-legacy layer On-board controllers Agent types

47. Hierarchical organization Chain of command

48.  Open/Close  MoveTo   Example Agent-based software RPCS Virtual Supervisor

49. Andy Podgurski Security Security: Post-deployment Validation

50. Vulnerabilities • Vulnerabilities • Possible origin: software defect • Present after deployment • Must identify latent defects early • AAA • Authentication, Authorization, Accounting • Defect and vulnerabilities • E.g., OpenLDAP ITS 1530 “Anonymous user can use ldapmodify to delete user attributes”