Requirements Docs - Plant Ops

I made significant progress on the Plant Ops requirements docs in the last couple of days.

Requirements Docs - Plant Ops

I've started putting together the requirements docs for the Plant Ops. project. It's broken down to three layers. I will expand the description of it more after I've done my course-work.

Customer Meeting - U.W. Formula SAE - Will Chan

We had another meeting with Will from Formula SAE today. I was late for it because of an emergency MEF board meeting that ran late.

Noting interesting happened, we saw the car and talked with Will.

Customer Meeting - U.W. Formula SAE - Will Chan

We met with Will Chan (3B Mech) from the U.W. Formula SAE team today at 5:30 pm in DC. I don't think that the meeting went well. Will is a mechanical guy, so he couldn't tell me anything that I needed to know. That's fine; I don't expect much from first meetings. They are mostly so that I can find a technical contact to elicit requirements from.

I don't think Will saw the value to his team that we were offering. He was mostly of the mind-set of "how can we help you?" He didn't seem to see how what we were offering could help him. I think we can offer huge advantages to them by adopting our technology. We can streamline their existing workflow, and exponentially increase their abilities by allowing them to gather data and make adjustments to the vehicle on-course. Hopefully speaking to someone more involved in the systems will yield better results.

NOTES:

Current System:

• have data acquisition system: Pi Research's Pi System 1 (reseller, PDF)
  • captures
    • linear potentiometers
    • velocity
    • RPM
  • self contained / dash interface
  • completely embedded system with proprietary interface and software
  • looking to upgrade to Aim Evo 3
• engine control system: Advanced Engine Management's Wolf 3D Version 4
  • can adjust engine controls via pendent (fuel injection, timing etc)
  • completely embedded system with proprietary interface and software

Course characteristics:

• 20 minute runs
• 1 km length
• speeds: top: 100 kph, avg: 40 kph

Application Ideas:

• telemetry past access point
• monitor fuel consumption
• record lap data / split times
• would like bi-directional for driver communication
• pit crew must make judgement on vehicle changes

Durability testing for us:

• high vibration
• high noise

We have another meeting scheduled with them for Tuesday, July 27 @ 5:30 pm in E3 2107.

Customer Meeting - Guelph G.H.

The team met with suits from Guelph G.H. today @ 11:00 am in Guelph. This was our first meeting with Guelph G.H. Robert is a U.W. accountancy grad and Jason is U. Guelph computing grad.

We have two directions with these people. Either take an existing wireless application and make it run over our technology via an adaption layer, or write a simple application like a vitals recorder.

Robert F. Biron, CA*IT, MHSc, CHE
     Vice President, Diagnostic & Support Services
     Chief Financial / Information Officer
     Ph:  (519) 837-6440 x 2792
     Fax: (519) 822-2170
     email: robert.biron (at) guelphgeneralhospital (dot) com

Jason Winter
     Manager - Information Technology
     Ph:  (519) 837-6440 x 2292
     Fax: (519) 837-6434
     email: jason.winter (at) guelphgeneralhospital (dot) com

NOTES:

In early stages of wireless use:

• feasibility study (technology and legal)
• long term (electronic health record)
  • no paper on floor (tablet or PDA) (18 to 36 months)
  • want "right info at the right time to the right people"

Concerns:

• RF interference with existing equipment
• high density materials in building causes dead zones
• security - data must stay in building, can't leave premises
• reliability - can't frustrate front line staff
• physician time
  • get through rounds quickly
  • do documentation later
• when in hospital, users must use our technology

Currently have one access point.

Applications:

• health info system: Meditech - legacy system
  • modules
    • lab, radiology orders
    • demographics
    • diagnosis
    • billing
    • and others
  • speaks HL7
  • access through telnet over VPN
  • 2k3 terminal services - kiosk environment
• will be looking at wireless application separately from technology
• there are HL7 Pocket PC applications
  • Mercury MD
  • Patient Keeper
  • DrugMart.ca

Desired rollout:

• 1st phase: non-physician users: nurses
  • have one hour verbal hand-off at shift changes
  • have to gather information from different sources
  • workflow: scrap -> chart -> electronic
• 2nd phase: physician - order entry

Applications:

• checking vitals
• order entry - lab orders (want less error)
• voice recognition not good enough yet (being tested elsewhere)
• they like "push"
  • for abnormal results
    • currently: nurses loop up results and have to locate doctor to report
    • want doctors to be able to respond directly
  • like audit trail
    • remove nurses as info relay
  • makes turn-around shorter
• clinical decision support
  • drug conflicts / allergies

Customer Meeting - Plant Ops - Lisa Huard

I met with Lisa Huard of Plant Ops today @ 3:30pm in the Plant Ops reception area. Lisa handles the x3793/4 hotline during the afternoons.

Lisa Huard
     x2934
     GSC 262
     lkhuard

NOTES:

Incoming call workflow:

• logged
  • Caller name
  • extension
  • building
  • room number
• decide on area
  • mechanical / plumbing
  • building - locksmiths / furniture / carpentry
  • electrical - air / environment / electric
• create work order in database
  • assign to tradesman
  • has more info than jab card
• call tradesman directly (page) (referred to as a unit)
  • pass info of request to them
  • sometimes call more than once
• manually print the job card (goes downstairs to the "tool crib")
  • tradesmen get them there, fill out info
• emergency / urgent vs. maintenance requests are handled by same process.
• off hours calls are emergency only and those workers hae access to the same system.

Building requests (non-maintenance) are handled by Chico Silvestri, x3366, GSC 255.

No reports are generated at end of day.

The had a different system in April. It's now a java app. Overall response of new system is slower.

Direction:

• ask Bob to clarify workflow
• get datastram api

Customer Meeting - Plant Ops - Paul Poetker

I met with Paul Poetker of Plant Ops today @ 1:10pm in front of the DC library.

There is confusion surounding how a job is dispatched to a mobile worker. The offics staff insist that they dispatch it to the worker directly, thile the workers say that their foreman dispatches tasks.

NOTES:

Buildings requests workflow:

• call goes to 24 hour hotline -> foreman -> tradesman
  • emergencies: fast tracked through process
  • non-emergencies: printed to paper jobcard which is picked up in morning of next day by worker

Paperwork:

• Contains local customer contact info
• record time/materials on job card when finished

If additional trades are required to finish a task, then can be contacted:

• directly. They will require their own work request.
• through the remote foreman.
• through the local foreman.

Work Order approvals:

• work requests (new construction): architect/department head (carpentry)/foreman/trdesman
• maintenance: foreman/tradesman

Concern with pager:

• can't call anyone back right away
  • must secure tools

Concern with understandability of voice recordings:

• work can be done in noisy environments
• some workers have accents
• have to write things down eventually

Work duration:

• jabs range from 1/2 hour to all week (work is timed on 1/2 hour increments
• groups of related requests can be batched (moving all offices in a hallway)
  • sometimes need to be co-ordinated with other units
    • you move out the contents
    • someone else installs a wall/shelving/furniture
    • then move someone else in

Requirements elicitation (yeah!):

• device displays complete job card (with contacts)
  • contains attached schematics / blue prints / drawings / diagrams (electrical and plumbing)
  • possible scanned drawings from customers (furniture locations)
  • notes from customers
  • ability to record time and materials and return from field
    • quick materials list would be nice for common tasks (install whiteboard)
• have the ability to order more work
  • track task ownership (who needs to work on task now) (like problem tracking)
• have the ability to communicate with lead hand
  • for materials/tools left behind
  • lead hand enters pricing of materials

Paul had a pad of paper that he keeps notes in:

• had extensions / radio frequencies of co-workers
• work orders and job numbers and who helped on those tasks
• dimensions on drawings for materials with room numbers
• tasks upcoming / checks on orders for customers
• open tasks and priority tasks