Customer Meeting - Plant Ops - Debbie Mustin

I met with Debbie Mustin today. Ms. Mustin is the Davis Centre (DC) contact for non-maintenance plant ops. work.

Debbie Mustin
     888-4567 x2252
     DC 2117
     dmmustin

When a customer has a maintenance issue, they call the campus 24-hour maintenance hotline, x3793. If they want to do anything that is non-maintenance (order furniture, renovations, shelving, etc...) they call Ms. Mustin to have her place a work request. She fills out a standardized carbonless-copy form which is sent via intra-campus mail to "Work Request Supervisor, Plant Operations, General Services Complex." Lately, there has been a lot of people moving offices in DC (I know all about that from working with ISG,) so they are doing some things "electronically." Instead of doing things on paper forms, Ms. Mustin has been emailing work requests. I asked her if there was ever a discussion to give her direct access to the work request and tracking system, and she said that there hadn't been. She said that she didn't see how it would benefit them.

Ms. Mustin serves as the DC contact for work requests. If there are questions regarding work requests, she is the local contact. Paul (whom I met on Tuesday) will come to Debbie with any questions.

Direction

• talk to x3793
• talk to people that get work request form from Debbie

Documents

Group Meeting - Mobile Access Points

Today's group meeting was mostly about our mobile access nodes. The platform for the mobile nodes is the Soekris Net4801 embedded system. They are low-power, compact, integrated computer systems, including 128 Mbyte SDRAM, 266Mhz 586 clone, CF interface, 44 pin UltraDMA IDE, 3 10/100 ethernet ports, a DB9 serial port, a Mini-PCI type III socket, and a PCI connector... among a few other things that don't have headers (USB 1.1).

We got these things running by booting from the CF card, then installing some stripped version of Debian from it to the laptop drive that we installed. It seemed pretty straight forward. It would probably be better to do a network install for these things (easier to mass produce them.)

If we needed to clone four or five units, we should probably use ghost, blast, ghost, dd, or whatever the kids are doing now-days. There are 44pin-40pin IDE adaptors (myCableshop, Tiger Direct) to allow the drives to attach to a standard PC.

Some other guy has a site about running Debian on Soekris systems. It's different from ours, but you might want to read it.

The second half of the meeting was about Crossbow wireless sensor networks. The sensors form themselves into a routing tree rooted at a base station. They go into activity / hibernation cycles and relay data through the tree back to the base station. The idea is to make the base station a DTN AP and relay the data through our system. The sensors run TinyOS (SourceForge) and are programmed through NesC. NesC is a component based language. It centres around modules which connect together through interfaces. The interfaces are composed of commands (inbound) and events (outbound).

Customer Meeting - Plant Ops - Bob Zinger

We had an initial customer meeting with Bob Zinger, Paul, and Larry of Plant Ops. at U.W. today. It appears that we would be best able to improve their workflow if we were to work with them.

NOTES:

Three modes of operation:

• contract work (work order)
• maintenance work (work order)
• emergency work (direct call through pager or radio)

Process observation (work orders):

• request for work made by customer to local contact
• local contact calls central contact to place order
• work order placed in database
• manager allocates work (1 day delay?)
• worker receives work order and performs work
  • worker maintains collection of work orders
  • worker usually verifies details with customer to ensure accuracy
  • worker will need to request additional work if dependencies exist (done through manager)
  • worker reports to manager work status

Process observation (emergency work):

• Emergency call placed to local or central contact
• Relayed via call to manager
• Mobile worker paged or radioed (new pagers can buffer voice message)
• worker may miss call if in noisy environment
• worker may need to go to phone if response required

Process improvement observations:

• work is done asynchronously
• current workflow system is synchronous
• opportunity to improve process by removing synchronization points

Bob's group is involved mostly with building work. Electrical, Plumbing, and Mechanical are separate teams.

Scope and cost observations:

• 70 - 80 tradesmen
• $500 per pager
• $1000 per radio

Contacts:

• Technical purchasing: Bill Carrol x2349, GSC 110A, wcarroll
• Work order placement (central): Donna McCracken x2018, GSC 257, dmccrack
• Work order placement (DC): Debbie Mustin x2252, DC 2117, dmmustin
• Overall Manager: Rick Zalagenas x3932, GSC 224, rszalage
• Building Foreman: Bob Zinger x3650, GSC 105B, rczinger
• Electrical Foreman: Gerd Kursikowski x2836, GSC 109, gkursiko
• Mechanical Foreman: Philip Simpson x3651, GSC 103A, psimpson
• Mechanical Foreman: Michael Wolfe x3850, GSC 103B, mwolfe

Direction:

• Observe Paul's workflow to make scenarios

Potential Customer - Team Ferrari

I read an article about how computers are used in F1 racing titled "Computers chase the Checkered Flag." The quote that caught my attention was:

But as he races, his Ferrari team can track even the most minute aspect of the competition, capturing data in multi-megabyte wireless bursts each time the team's cars flash past the pits, often in excess of 200 miles an hour."

That sounds like a delayed transmition in a disconnected network, which is what we are researching, so I forwarded it to Prof. Keshav. He has suggested that I try to contact team Ferrari.

The Ferrari website has absolutely no contact information. So I've been scouring for potential contacts. I've registered and posted messages on TheScuderia.net Forums > Ferrari Forums > The Ferrari F1 Paddock (thread) and FerrariChat.com > General Forums > Racing (thread). I doubt that either will yeild anything interesting, but it will have to do until I have more time to widen my search.

My request for info reads as follows:

Hello everyone,
I am assisting research in Delay Tolerant Networking at the University of Waterloo in Canada. DTN is concerned with how to address architectural and protocol designs arising from the need to provide interoperable communications within environments where continuous end-to-end connections cannot be assumed.

One of the attributes of DTN technology is that it enables network devices to buffer communications data while disconnected from the network, and to automatically transmit that data when the device rejoins the network. A recent article has highlighted how Team Ferrari is using this technology to transfer onboard telemetry from vehicles to pit-crews during races.

I have been searching for technical contacts to discover more details of the use of this technology in F1, but have not found any sources of information. If you are involved with the use or development of this technology, my research group would appreciate the opportunity to discuss it with you.

Sincerely,
  Jeremy Hilliker
  jthillik at uwaterloo dot ca

Potential Customer - Plant Ops - Bob Zinger

We have a meeting set up with Bob Zinger of Plant Ops. at U.W. scheduled for Tuesday, June 22 @ 1:15 pm in the General Services Building to discuss the possibility of developing an application for him on our architecture.

Bob Zinger
Foreperson, Building Section

Plant Operations
University of Waterloo
General Services Complex
200 University Avenue West
Waterloo, Ontario, Canada  N2L 3G1

519-888-4567x3650
Fax 519-746-6810
rczinger at uwaterloo dot ca

Ruminations - Requirements Engineering

I may have to deal with customers next week, so I have found a few links to refresh my memory on Requirements Engineering.

• Requirements analysis
• Elicitation
• Use Cases
• Requirements Engineering
• When Telepathy Won’t Do: Requirements Engineering Key Practices

Team Meeting - Possible Requirements Contacts

The hope of working with a customer in AHS has mostly fallen through. We are relying on them for contacts to area hospitals.

We have a contact, Robert Biron, at Guelph G.H. who is the VP Information & Decision Support, Chief Financial/Information Officer. Prof. Keshav has a call in to him to determine if we can work with them. Guelph is upgrading their hospital to WiFi. We hope to have a meeting with them next week. There is the concern that they may already have vendors for everything and we will be mostly locked out.

Prof. Keshav has another lead with St. Mary's G.H. in Waterloo. It may be possible for us to observe nurses on Thursday/Friday of next week (right after midterms!)

We are also chasing down Bob Zinger of Plant Operations at U.W. Plant Ops may be a good test for our architecture since they have mobile workers who are not fully connected.

We have also sent mail to UHN, but have received no reply.

Group Meeting - Architecture Overview

Today's group meeting was an overview of the system's architecture.

The architecture solves 3 major issues with tetherless computing:

• Routing - DTN
• Locality - Chord/DHT
• Nature of regions (heterogeneous, non-internet) - DTN

DTN - Delay Tolerant Networks

• overlay
• region
  • admin ids
  • gateways interface with adjacent regions

Chord / DHT (Distributed Hash Table)

• Key ID/value location
• I3 allows names vs IPs
  • only works in the internet

Potential Customer - AHS - Prof. Ian McKillop

We had a team meeting with Prof. Ian McKillop today. He's attached to Health Studies and has his training in IS. He's cross-listed with CS and HS, so he is the bridge between the two departments that we are hoping will make this project go forward. He is a source of domain knowledge and a contact for the kind of systems that health care sites currently use. He is also an excellent source of field contacts for us. He knows people that we should talk to to do requirements discovery, and potential sites to run an experiment.

In Hospital Scenario

Main IS functions:

• Data capture (nurse's data has more structure)
• Movement of data (query / order)

Systems Overview:

• Island systems
  • low integration
  • patient info system (central registry)
  • image archiving (i.e. agfa)
  • pharmacy
    • inventory tracking
    • dispensary
    • order entry
  • lab systems
    • ordering
    • tracking
  • surgical scheduling (workflow)
  • nurse workload choices
  • meal choices
• health systems use HL7 for data transfer... which is based on EDI which predates XML

I.T. People - two types

• buy best of breed individually
  • disparate systems
  • don't integrate well
• purchase all from a single vendor
  • a single vendor to blame
  • integration
    • medical record screen (electronic health record)

Doctors were trained on clipboard/paper systems

• some moving to dicta-phone
• don't like constraints / tethers (bedside terminals suck)

Need to provide interface to existing system

• large scale backend (proprietary)
  • security / user management (1200-1300 employees)

University Health Network (UHN)

• has PDA experiment in place (CRE)
• potential experiments for tetherless
  • pharmacy order
  • medical / nursing order
• proprietary achitecture

Mobile Worker (Homecare) Scenario

Mobile Nurses (Comunity Care Access Centre)

• medical record
• manually chart what they do (data entry)
• enter at end of day

Group Meeting - Process Priority Boosting

Today's group meeting was about process priority boosting. That is, finding ways to alter the kernel to boost network application's priority when in range of a hot-spot. This will ensure that network apps can finish synchronizing with the hot-spot before they go out of range.

The main idea was to listen for socket calls and raise the priority of processes that make them. This is very beneficial in Linux 2.4 kernel, but only marginally useful in 2.6 kernel. This is because 2.6 kernel does a better job or raising the priority of interactive applications, and because a network app will typically block before the end of its time-slice, it is classified as interactive.

There were a couple of schemes for raising priority. Static gives a constant boost. Decreasing gives a large boost, then linearly takes it away to a minimum threshold. Increasing gives a linearly increasing priority to a maximum threshold. The axis against which priority is boosted can be based on time, packets sent, socket calls, or data sent.