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

Customer Meeting - Plant Ops - Donna McCracken

Geoff and I met with Donna McCracken of Plant Ops. today to discuss their system and how we might be able to help them

Donna McCracken
     888-4567 x2018
     GSC 257
     dmccrack

Things didn't look too great. They have a closed system that is housed offsite, and I managed to stick my foot in my mouth at least twice... I need to get Geoff to kick me under the table when I need to stop talking. We also need a real PDA to show customers. My Palm V is too old and beat up, and Geoff's Zaurus SL-5500 is awkward looking. It wasn't terrible, but I'm glad that she is an internal customer. I need to treat these first meetings as pre-sales and not as requirements discovery.

NOTES:

Environment:

• approx 100 workers with shared resources

Workflow:

• all maintenance calls are made to x3793/4 which is a centralized 24 hour hotline
• all requests are logged and entered into a database as work orders (except for very small items like light bulbs needing replacement, which are batched)
• the operator at x3793/4 calls the tradesman directly to notify them of the work order
  • the worker uses pads to record the orders
• the order is printed and sent to the foreman
• the worker records remarks / hours worked on the order when the task is complete
• the work order is returned to the office staff where the worker's remarks and hours are entered into the system
• they also have a preventative maintenance program
• when a job spans multiple trades the work is assigned as one request but has multiple activities
• job lists are checklists of tasks that need to be preformed regularly (check exit lights, fire extinguishers, etc.)
  • going to PDF

Problem with dispatch system: the worker might be busy and not able to respond... but they will eventually respond... or the dispatcher will recall.

Concerns:

• primary concern is over the time of tradespeople
• don't want workers to have to type
• worker's do not have access to a computer
• some workers may/may not prefer PDAs
• concern over ruggedness of devices... must withstand high drops
• concern over cost

System notes:

• the system is a Datastream 7i "asset performance management system"
• it is based on Oracle Developer 6i and "makes full use of Oracle's Internet Application Server (iAS)"
• it is hosted by datastream offsite in the U.S.A.
• the system was moved off-site in April 2004. Primary reasons:
  • automatically get all upgrades
  • Plant Ops does not have dedicated high end I.T. staff (i.e. DBAs)
• system is based on java applications
• work orders and reports can be exported as Excel documents
• work orders can be linked to schematics, but they aren't because of the current dispatch system
  • currently printed if needed
  • currently housed on-site
• vendor's website offers "Application Program Interfaces (API)" as product feature
• vendor's website offers Mobile Solutions as additional module. Datastream 7i Mobile Solutions brochure.

Donna wants a written proposal including who absorbs costs. I asked Prof. Keshav to call her on Monday

Direction

• Speak with x3793/4 people
• track down Paul and interview him
• examine datastream's API

Documents

Potential Customer - Guelph G. H. - Robert Biron

We heard back from Robert Biron at Guelph G.H.. We have a meeting with them for July 16th at 11:00 am.

Potential Customer - U.W. Formula SAE 2004

I forwarded Prof. Keshav the article about disconnected systems in racing, and he met the U.W. Formula SAE team at a demonstration on Canada Day. They need our system to adjust fuel/air ratios while the car is on track in race conditions.

We have a meeting scheduled with them on Tuesday July 20th @ 5:30pm in DC3335

Group Meeting - Statistical Modeling

Today's group meeting was about statistical measurements in relation to simulations and modelling.

It was mostly about Markov Chains, the Poisson Distribution, and Poisson Process. The big thing to take from a Markov chain is that the probability of moving to state A from state B is independent of the previous state. It simplifies the math in the models a lot.

It was interesting to her "Poisson" pronounced as "poi'zən" rather than as "pwä-'sOⁿ-".