LAHMP TM : Open Standards For Sensors And Data Acquisition For Health Monitoring

1. LAHMPTM: Open Standards For Sensors And Data Acquisition For Health Monitoring Chris Coughlin, Russell Austin ASNT 15th Annual Research Symposium Orlando Florida 14-16 March 2006

2. Outline • Introduction • Condition-Based Maintenance (CBM) • Requirements • Standards • Example: LAHMP • Summary And Conclusions

3. Introduction • LAHMP: Large Area Health Monitoring Processor • Processor => Platform ? • Self-contained embedded data acquisition and analysis platform built on (open) standards and open source • More later • Purpose of presentation • Convince you as an OEM to use standards • Don’t have to convince buyers... • Discuss several relevant standards to NDE and CBM • Provide an example (LAHMP)

4. CBM • Health Monitoring • distributed in-situ sensor networks that assess current condition of • structure • engine • bearing • pressure vessel • pipes, tubing, etc. • Prognostics, On-Condition Maintenance, etc. • given current condition, assess future likely condition, plan for maintenance based on assessment • maximize maintenance ROI-repair when you have to

5. CBM Prognostics • 1. Predicting The Future • simple extrapolation? • complex pattern recognition? • neural networks, etc. • “Past performance may not be an indication of future returns…” • 2. System Assessment • statistical modeling (neural nets etc.): run many tests and measure • did you test all possible modes of failure? • did you test for aged sensor performance? • did your test include realistic operating environment? • physics-based modeling: established relationships between sensor measurements and physical phenomena, i.e. strain gauge

6. CBM Requirements • Sensors (surprise!) • Pressure, Temperature, Humidity • Corrosion • Crack Detection / Propagation • Strain • Vibration, etc. • Sensors (usually) require • Power • Communications • Validation

7. CBM Requirements, cont... • Power • internal power • draw from vehicle • inductive power, power harvesting (immature / Holy Grail), etc. • Communications • communicate with user • (optional) communicate with other systems • Validation • System monitoring • (optional) redundancies

8. CBM Requirements, cont... • Bringing it all together: sample CBM installation • But why use standardized • Sensors? • Communications? • Anything?

9. Why Use Standards? • Development Costs • Why (pay to) reinvent the wheel? • Reliability Issues • “Many eyes make all bugs shallow” • Standards have been tested much more than any in-house solution ever could • Flexibility Of Design • Avoid “vendor lock” • What do you do when your vendor goes out of business? • Rapidly adjust to new market conditions / “flavor of the month” • Your customers will thank you!

10. When To Not Use Standards? • Realism: not everything can or should be wide open • Protect IP • algorithms, patents, etc. • Security • protection against attacks, encrypted communications, etc. • Licensing Issues • e.g. you don’t have the rights to your components • Expense (always a favourite) • No standard • Nothing fits, nothing exists, etc. • Start your own?

11. Relevant Standards • Most Important: Communications And Data Exchange • Communications between user and system, system and sensor, system and other systems • Data exchange-how do I get my data out of there? • Useful standards to consider, now and in the future • IEEE 1451 • Zigbee • Usual commercial suspects: CAN, WiFi, WiMax, Bluetooth, etc. • Usual avionics suspects: ARINC 429, MIL-STD-1553, etc. • XML, XML-RPC, SOAP, etc.

12. IEEE 1451 • Courtesy IEEE: • “describes a set of open, common, network-independent communication interfaces for connecting transducers (sensors or actuators) to microprocessors, instrumentation systems, and control/field networks” • An “open” ($ from IEEE) standard for smart sensor networking • One fieldbus to rule them all: Wikipedia currently lists 10 commercial fieldbus systems (CAN, DeviceNet, …) • Doesn’t include the vast number of “home grown” fieldbus protocols • Limited industry support for now, but could be big

13. Source: Zigbee Alliance, www.zigbee.org Zigbee • addresses the unique needs of remote monitoring & control, and sensory network applications • enables broad-based deployment of wireless networks with low cost, low power solutions • provides the ability to run for years on inexpensive primary batteries for a typical monitoring application Zigbee In A Nutshell

14. XML And SOAP • XML: Extensible Markup Language • Similar structure to HTML • Becoming the data exchange protocol • Buzzword Compliant • XML-RPC: Remote Procedure Calls with XML • “It's remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned.” (xml-rpc.com) • SOAP: formerly Simple Object Access Protocol • Not so simple any more • Big Brother to XML-RPC, also uses XML for encoding

15. Example: LAHMP • COTS-based generic data acquisition and analysis system • Modular system • add / subtract hardware as required • OS is customized Linux: full source code • add / subtract software as required • Current modules: AE, Ultrasonics

16. LAHMP Characteristics • Base model specs: • 6"x6"x2", 2 lbs. with ruggedized aluminum enclosure • Power draw is less than 10 W (typical) / 15 W (maximum) • 10 Million samples / second / channel acquisition • Typical sensor configuration: 2-4 sensors with 12"-36" cable length • Full data analysis • condition and recommended course of action / RUL • 0% to 95% relative humidity (non-condensing) operating range • 0-70 C base temp operating range (-40 to +85 C optional)

17. Standards In LAHMP • “Out Of The Box” Communications • With User: standard WiFi, Ethernet, USB, etc. • e.g., can be controlled by any web-enabled device • With Sensors: generic analog voltage, digital outs • Optional Communications • With User: Zigbee, Bluetooth, etc. • With Sensors: Zigbee, IEEE 1451, CAN, etc.

18. Image courtesy Larry Ewing, lewing@isc.tamu.edu Standards In LAHMP, cont... • Operating System: Customized Linux • Shamelessly code-named “Coughlinux” • Full OS source code to customers • End-user can add/subtract hardware and functionality as desired • Add “hard” real-time capability, GPS, even full-blown MATLAB for signal processing • LAHMP acquisition / analysis software • Runs on LAHMP and conventional PC; proprietary (closed-source) • not everything can be wide open... • Uses open standards for data exchange • ASCII text, HTML / XML, published binary formats, etc.

19. Realized Benefits • What did TRI gain from using open standards in LAHMP? • Small company, even smaller development group, originally a small project • Demonstrated working prototype in under six months • Flexible • started as DOS-based, moved to Linux with same hardware, now considering Windows implementation • We can rapidly adapt to new CBM applications and opportunities • Easy Integration • reporting / control can be done by anything from anywhere • Sponsor loves Blackberry-we deliver a system that works with his existing tools... • ...but we aren’t locked in!

20. Sample LAHMP Application • Acoustic Emission Health Monitoring • COTS AE transducers acquire raw data • Stored and analyzed in LAHMP • LAHMP assesses health of vehicle, recommends a course of action (if req’d) • Reports to larger HUMS/HMS

21. Summary And Conclusions • NDE and CBM systems can greatly benefit from using standards where possible / appropriate • lower development / support costs, greater flexibility • Customers will start to demand it • “Why can’t I use my Blackberry?” • “Why should I buy Yet Another Black Box?” • Customers and OEMs both benefit • Unless you’re a monopoly… • TRI/Austin has developed, continues to develop a family of systems to implement standards-based V/S/PHM for a variety of applications