Kevin Gary Release 1 Closeout Notes

From IGSTK

My notes are organized by category of functionality, not by day. I would like to have notes such as these, KC's, and anyone else's boiled down into Requirements.

State Machine

• Some discussion on whether we need different clocks or "ticks" for different state machines. Unsure of the resolution of this, though the discussion ended with a suggestion of using one clock with refresh rates that are multiple of each other, at least at the View representation level. Is this now a Requirement?
• Discussed the relationship between state machines in a base class versus state machines in derived classes.
  • State machines are private, so when you are deriving a class, you do not have access to the parent state machine or its methods.
  • If you override a behavior in a subclass (particularly a RequestXXX method), there is no guarantee the request will be forwarded to the parent class.
  • We had some discussion on this but I do not have a resolution to it.

Threading

• Lots of discussion on whether to be single-threaded, multi-threaded, or support a small bounded number of threads.
  • Concern about applications creating threads were
    • May not be safe
    • Difficult to debug
    • May slow responsiveness of the thread controlling the display (shouldn't ever happen)
  • Concerns about single threads were
    • Application may have long synchronous operations, some of which may block (logging)
    • Framework event-based and state machine architecture suggests some asynchronous, parallel behavior
  • The idea of a bounded thread pool is probably not a good one as it is difficult to implement, difficult provide a processing guarantee for any unit of work, and most of all most processing is not truly independent in IGSTK.
• Related discussion on which "zones" of the application needed their own thread. This would determine where critical sections exist within the framework.
  • Original assumption was to have the tracker in one thread, View Representation (VR) and Spatial Objects (SOs) in another, and GUI-driven events in a third.
  • My understanding of the decision was to use a small number of named threads in the framework

1. one for the main application thread
2. one for the tracker (but deep within the tracker)
3. one for the logger
4. one as a safety "switch"

The comment about the thread being buried deep within the tracker exists so we will not have a bottleneck between critical sections where a visible tracker thread writes to a buffer (push) while the main application thread tries to read that buffer. We prefer to have the tracker thread as close as possible to the hardware.

• Some discussion on whether we should support real-time operating systems (RTOS). Decided that would be an add-on type project.
• Significant issue is what happens if a process action takes longer than a "tick" of the clock. Unsure of the resolution at this point.

Logger

• Had some discussion on logger priorities, roles (development versus production), requirements, and ITK
  • Requirement: do not change logging capabilities during a procedure. Make changes to logging configuration a compile-time process using CMake.
  • Requirement (design): Use a centralized Logger factory to instantiate the various logger objects and call SetLogger on these objects. This way when changing a logging format or configuration one does not have to edit a lot of files.
  • Requirement: Provide some sort of obvious visual flag when a not-for-production-use of IGSTK is in operation in order to prevent accidental deployment in a surgical environment with improper compile-time options.
  • Requirement: VTK and ITK use exceptions (and possibly other unsafe ways of dealing with errors), we need to intercept these.

Hee-Su did a nice job of presenting these requirements Tuesday afternoon

• Continue to work with ITK folks, but realize we have some of our own specific requirements.

Tracker
A lot of the tracking requirements folded into the State Machine and Threading discussion above.

• Requirement: We should be able to support multiple trackers tracking a single body. Luis suggested the best way to do this would be to create a TrackerToolAggregator. This would aggregate events received from individual tools & propagate to a Spatial Object.
• Requirement (Architecture Decision): We decided to go with the cut-and-paste approach to Atamai code integration
• Some amount of discussion on the variations between trackers, such as the data points provided, degrees of freedom, and managing error reporting. This discussion took place in the context of using the state machine shown for the tracker. Unsure of the conclusions with respect to the data points, but we seemed to commit to this state machine for now.
• Also some discussion as to whether a state machine was useful for serial communication.