Design/Requirements

Objective

DerbyOS is a protocol to allow cooperative computerized data entry by NSO for a roller derby bout.

Goals

DerbyOS is based on the existing model of communication, roles, and workflow used by NSOs during a bout:

•There is no single point of failure. As such, there is no single centralized server - rather the entire network is based on a peer-to-peer model. Even if the network goes down, each NSO node (or “NSOde”) can continue to work and any information will be shared when the network comes back

•Initial (pre-bout) configuration can be done using a single “CHSNOde”, which is no different than a CHSNO handling out pre-populated paperwork containing rosters

•Information from peer NSOdes augments and assists other peers. For example, if the lineup tracker records the jammer number, the scorekeeper would get that information automatically filled in. However, if the lineup tracker is slow/unavailable, the scorekeeper can still fill in that information manually. It may even be that one of the two misreads the jammer’s jersey and records the wrong number - this must not stop progress (and ideally, should warn both parties that there may be an inconsistency).

•The entire bout does not need to be automated using DerbyOS - more is better, but even two nodes would work together.

•If one (or more) NSOdes goes down, when it comes back up, it can fill in past information, as well as get information from other NSOdes. If a battery dies, switch to paperwork and fill in the information at halftime.

•No NSOde is the singular source of “truth” - mistakes will be made. Specific NSOdes can be determined as the “de-facto truth” (for example, the lineup trackers could know best as to what the current jam number is).

•NSOdes should also record time stamps for all events, which would augment information currently recorded on paperwork for future data analysis.

•NSOdes are expected to have some sort of unique identity (such as the name of the NSO operating it)

•DerbyOS is built using DerbyXML as the lingua-franca, which is event oriented in an xml tree hierarchy, not a database of fixed records

•NSOdes are trusted - there is nothing in the DerbyOS protocol that has any sort of “access control” (though client applications usually only expose a small subset of the information that it can edit). This is partially derived from the fact that there is not a formal database.

•Security is provided by the network - it is assumed that the public can not access the network (via the appropriate access control on the network access point itself).

•Not all NSOdes are required to connect to all other NSOdes (especially since the exact configuration of NSOdes is not required - for example, one penalty timer probably doesn’t need to know the activity of the other penalty timer).

•The protocol must be documented and available for all to use - there can not be a single dependency on software (or a bottle neck on bug fixing)

•Support for both native code as well as binding for languages such as Python, Java and/or node.js are required. The goal is to allow for both “closed” third party clients (which may require either native code for iOS or Java for Android), as well as to have “open” sample code/experimental code done in Python or node.js.

Usage Case Examples

•Penalty box timer probably wants to get the jam number from somewhere. It can get when the jam starts/stops which it can get from either the scoreboard or jam timer to automatically start/stop the penalty timing. Either the penalty tracker or inside whiteboard can combine with the lineup tracker information to help to suggest who the skater is that is about to serve a penalty.

•Inside whiteboard could be simulated by taking penalties from the penalty tracker, combined with “skater sits” events from either the lineup tracker or penalty timer/manager.

•Scorekeeper can get jammer number from lineup tracker, and listen to penalty tracker and mark “lost” when the penalty tracker indicates there is one that is lost. It can get the an “end of jam” time from either jam timer or scoreboard and, if it was less than 2:00, know that their jammer called it (if their jammer had lead).

•If a jammer calls the jam and gets a penalty while the four whistles are being signaled, the scorekeeper paperwork would show both “call” and “lost”. Since there are timestamps, it knows that the lost happened after the call, so there shouldn’t be an additional illegal procedure penalty. If the jammer lost lead before calling it, a notification for the penalty tracker could indicate that there should be an illegal procedure.

•If a penalty timer still has the skater in the box, the lineup track could automatically have that skater marked as starting in the box in their paperwork

•Announcers could have a special “listen only” NSOde that gather bout time stats

•Even if there is no network, every NSOde can produce an DerbyXML file with their corresponding information, which can be merged after the bout to reconstruct all the events.

•