# Agilent Technologies # Fri Sep 9 2005 # Palo Alto Attending: Jay Warrior, Jeff Burch, Jerry Liu Niel C, Tony Fountain Glenn engle, Glen purdy Andrew Chase, Duane Edgington, Kevin Gomes, John Graybeal Tom O'Reilly Jay Warrior: Large systems new business creation taking tech (inside and outside Agilent) and moving them forward, more than lab usually does Jerry Liu: JDDAC, NEtbeams distrib data tony fountain: cyberinfr lab for NSF, LOOKING, NEON...natl scale infrastruct Niel Cotofana:san diego supercomputing center Arno Puder: SFSU,Corba, web svcs, sensor networks, netbeams, rick baer: sensor nets, imaging, local image processing bruce hamilton: clock sync over ethernet, automatically computing metadata jeff burch: 1588, 1451.0,.5 glenn engle: jddac sw glen purdy: jddac sw matthew arrot: Looking lead engineer and project mgr # agilent overview (warrior) - from sensor nets to infranet - NIST relationship - plug and play, 1451, 1588: building blocks - pervasive information systems (emergency, transport, GIS archive, environment - info gen from heterogen sources - levarage existing systems - federated, grid models of data handling - gateways: pass through - modeling and analyzing probably approximately correct systems (Bruce hamilton, Jay warrior). - guided mobility, create economic motivation for individuals to contribute to infrastructure (e.g., traffic monitoring system via cell phone) - what is generic metadata model, generic measuremnt model - Berkeley motes at UCLA - camera net (rick baer): machines looking at cameras to gather information, rather than as images. Cyclops, crossbow mote, agilent cam module. Imaging as a new modality. cheap,low power. ucla, mit, stanford, sandia labs, yale, epfl, umass, wichita state. # mbari overview (headley) way too long # jddac, netbeams (liu) SFSU prof. arno puder, Romberg Tiburon Center collect and disseminate environmenal data SFBeams, orig. use jddac to automate processing oceanographic data (CTD, met) -scalability, reliability, modularity, portability, user access - continuous, pervasive monitoring - probes: instrument/computing device+gps-phone NCAP, STIM inside the phone - feasibility->ruggedization - m2m: machine to machine - soft stim wrapper for non-1451 devices; about 1 week to wrap a non-1451 device - jddac server, netbeams server, java jxta - probe runs j2me, server runs j2ee, simulator runs on j2se - HTTP GET, XML via HTTP POST - using XML on probes under j2me! ? what processor on probes? numerical rss (NRSS) used to subscribe to news. feed provides metadata and measurement pointer values nrss is namespace and tag based: must be able to skip past metadata not understood, to enable local processing - must know semantics - "specialization after deployment" * standardize ontologies using namespaces -- eliminate big battle over what a transducer is * granularity of the instrument was not useful, but notion measurement channel is. metadata associated with meas channel. - big discussion to be had on meas relationships and contexts... - being able to take Goole and inject your own data is a big deal. * Need to get the masses to contribute to infrastructure (e.g. SETI) * progressive opt in, clouds of available slightly different * give them more value than they're putting in - noaa weather feeds scraped off web and made into 1451 data streams - still hard coded analog sensor config (seabird with analog sensors can't self ID analog sensors) - probe phone publishes data on an RSS topic - 1451 supports events and pub/sub - 1451 stops at virtual model of communication - RSS feeds come as XML; can use XSL, style sheets to put transform represention of data. Apache has a module to do this, since many browsers can't do it. JDDAC: meas communication->processing->acquisition-> ? J2ME and floating point on probes? data vs metadata # lunch+looking architecture ...managing environment as resource WetSideOPNet: ShoreSideOPNet: RMont, C&C, OP, Pub, Arch, digital representation of WSOP instrument services Apps, Humans: NCAP~LOOKING digital representation of instrument OpenView, Tivoli, CA... Burch: Applications want different things; the instrument gets in the way of the measurement can also represent "the ocean floor", rather than just instuments. "the ocean floor" can represent instruments, archives, etc. lifecycle management-> operations, monitoring 1451.1 goes only as far as logical communications, must make lots of engr decisions to build something real STIM, TEDS, TII, NCAP WSDM+GGF+DMTF DMTF CIM CDDLM lifecycle, communication patterns, applications comes back to: what is minimal set of functionality that I can put in my system? come back to smaller subset. Web Services<-SOAP<-RMI<-HTTP # jxta # PUCK update (O'Reilly) # Next steps Topics/todo: - pucks get a system and make it plug and work, demo scalability bench top prototype (not fully deployable) netBeams good candidate? we'll have 10 SBEs... 1451's goal is to eliminate the need to write the driver: common commands to operate any instrument higher threshold of pain softstim currently is a driver Agilent has long history of ascii commands to instrument w/ diff commands, syntax, semantics across generations of same instrument explore 1451 TEDS in puck payload (great idea) open source implementation of PUCK protocol (turn PC into PUCK) give it away multiple payloads=USB drive Open Source implementations of standards are key to adoption - 1451 family probe=NCAP+TIM(s), connection/PHY layerx neutral ncap not 1:1 with TIM 1451.1 (Txdcr Application): measuremnt and control 1451.0 (Comm Svcs): communication abstraction 1451.X: Key thing is that there is a measurement model (meas channel, transducer...) 1451.0 is a common driver that is independent of PHY layer - measurement data model autonomous event detection and response: MBARI needs framework for data handling on wet side JDDAC looks processing overlap w/ SSDS too (have same problem of handling data) common data measuremnt model has great value; absolutely key a lot to say about encoding measuremnts, values came from generalizing the processng of data in order to send it throw away contrstraint of metadata vs other data; it's an artificial line. RMODP: what is dynamic, variant, invariant, its about when to store it and when to send it seminar topic it doesn't stop at the measurement: what about groups of measeurements? measurements-> records-> measurment groups, time series... - generic application models, communication models svc oriented arch vs object minimal set of architectural, functional etc., concepts needed to do X minimal viable architectural framework restriction vs extension to constrain metamodel seminar topic - collaboration on puck export - metadata (vs data, etc...) issues marine metadata project scientists see distinction between data and metadata min metadata needed for interoperability semantic standards, ontologies, vocabularies ontology breaks scalability: how to eliminate/get around ontologies mapping between dictionaries/ontologies (infer meaning) Bruce's work on measuremnt calculus lifecycle issues what happens when ontology changes intractable class of problem: instruments working together to do an experiment, metadata needed to interpret results. taxonomy is extreme case of ontologies and mapping issues seminar topic *** Agilent needs to show business impact Who, When, How: - mini workshop/meeting on topics - LOOKING meetings bi-weekly phone conf (try one or two times to see how topics form) (webex?) - assess whether or not to get together - meet 1/2-1 day - threads: LOOKING/Agilent re Metadata MBARI/Agilent re puck+1451 - need conf calls - plan for neat face to face when appropriate - WSRF presentation Next steps: - discuss puck functionality, NCAP/STIM functionality, TEDS - - @ notion of semantic boundaries--where to semantic transitions occur? # open discussion # close ----------------------------------- after meeting JDDAC presentation