... These pages are intended as a living way of developing a specification for an on-competition-site data capture system as [outlined in the paper|cimaPlenaries:2012 documents & reports^ANNEX_B_CIMA_Plenary_Agenda_2012_real_time_data_collection_proposal v1.pdf] presented to the 2012 CIMA Plenary.
*Suggestions for improvement welcome\!*
Refer to the [ABG 2012 system|cimaWiki:The ABG system] for a detailed description of something which inspired the idea.
h3. The problem
* In any competition it is desirable to be able to produce results as quickly as possible.
* It is also desirable to be able to produce in-competition data, eg an elapsing time, count of targets hit thus far.
* Fundamental to this objective is *data collection*; none of the above can be achieved in anything like real time without some sort of electronic data collection system. (Compare this to the paper forms traditionally used to collect performance data, none of the content can get into the scoring system until all the the forms have physically been delivered to the scoring centre.)
* A solution to our requirement is not as simple as purchasing or renting some equipment used in some other sport, eg a ski-timing system, because that would only collect one element of the data we need to produce a score.
* However it is done, the hardware needs to be cheap or it won't be used.
h3. The proposed solution
* An app which works on common hand-held devices.
* Configurable to the data collection task in hand.
* Transmits data in a standard format.
* CIMA has approved a small budget to move this project forwards.
h3. The app
* Core to the system is an app which works on common hand-held devices, primarily tablets, but should also be functional on smaller devices like phones. (the data *terminal*)
* It is proposed the initial work on terminals should be directed at [Android devices|http://www.android.com/] since this is an open-source OS and the hardware is just as prevalent and generally much cheaper than the equivalent offerings from Apple, but there is no reason why the same thing can't be ported to iOS or Windows at a later time.
* One solution might be to look at cross-platform systems such as [phonegap|http://www.phonegap.com/], [Appcelerator Titanium|http://docs.appcelerator.com] or [Adobe AIR|http://www.adobe.com/uk/products/air.html]. Tribal have published an interesting [analysis of modern cross platform systems|http://www.mole-project.net/images/documents/deliverables/WP4_crossplatform_mobile_development_March2011.pdf] (paid for by the US navy)
* The app should be a touch-screen centric application capable of:
** Displaying means of collecting all the data as may be required to score all pilots in a task. (except, for the time being, logger derived data).
** Interacting with USB connected hardware designed as alternative means of collecting data (eg button-box for stopwatch-like timing functions).
** Sending that data in near-real time to a remote server which can further process it into a score or result.
h3. Functional overview
A typical competition consists of many *tasks*, normally at least 6 (somewhat dependent on the length of the whole event and the weather). Each task is 'stand-alone' in as much as it is scored independently of any other task. The purpose of this system is *NOT* to do any scoring, just collect and deliver data associated with a task which can be used in many ways, one of which will be scoring.
Thre are many different tasks, but a relatively small number of different kinds of 'data item' which need to be collected, the precise number and combination of data items required to successfully score a task will vary with each task.
The app must be simple to use by inexperienced operators in a relatively stressful environment. The solution is therefore not as simple as having an app which the operator can unilaterally choose from many options the kind of data they are supposed to be collecting. Instead, the app must be externally configurable so each operator is only shown what they must be collecting for that task, and the workflow must be organized so this is as 'idiot-proof' as possible. This implies that the collection of a data item may trigger another, for example a strike on a stick which adds one to a counter may also start a timer.
Several tasks may be happening simultaneously, or data for a task may be being collected from several different sources simultaneously, but there is no requirement for the _same_ data item to ever be collected from more than one source. A single data item can therefore said to be defined as *Task > Competititor > Element* where the element is one part of the competitors' performance in task which must be recorded so the whole performance in task can eventually be compared to all the other performances in task.
The ABG system was disadvantaged by being hard-coded, which made it only usable in a very specific set of tasks without re-writing and re-installing the terminal software.
This system must be as 'universal' as possible, it is therefore proposed that the app is arranged in the form of a 'framework' consisting of:
* Overall graphic layout
* Universal settings, communications and other core services
* Many data-collection / graphical sub-components, ideally designed as as a kind of 'add-in' so more can be added later without intefering with the core app;
** login component
** Task location identification
** Task name and description
** Pilot start list
** Active pilot display
** Count-up timer
** Count-down timer
** Strike counter
** Distance input
** Lap input
** Penalty selector
** Button-box input translator
** Etc.
h5. Task configuration
This framework then makes it possible to collect all the data as may be required to score a task by applying a *configuration script* to the app which sets the app up to display all the required sub-components in the right place within the overall graphic layout, that those sub-components know how to interact with each other, and what data to collect.
It is not a dissimilar idea to a web page which is rendered within a software framework (the browser) according to a script (html). The difference is that there is only one script for a number of 'pages' and the components which go into building each page already exist as fully integrated entities within the app so security between the os and app (eg clock) and interaction between components is already configured rather than having to manage them dynamically from the script.
Configuration scripts are in a recognized format eg *xml* or *JSON* to a precisely defined schema which implies there should be an online *task builder* which can be used to interactively build suitable scripts, and a *library* where scripts known to work with a particular task can be saved for re-use.
Scripts are saved from the builder or library to each device to be loaded into the app ready for the start of a task.
h5. Data-in
Some sub-components must be capable of collecting external data such as a start list. (Names, comp no., task start order). This implies there must be a *standard data-structure* (xml or JSON) with a detailed specification for each sub-component of this type, which in turn means there must be at least one simple method of generating it. It is proposed that the simplest way of initially achieving this is to produce an *Excel add-in* similar to the one already demoed with the [WLC results|cimaContinentalCup:WLC Results 2012], but other systems can be made available at a later time as necessary.
Worth a look: An interesting excel REST library at [mcpher.com|http://ramblings.mcpher.com/Home/excelquirks]
h5. Timing
It is important that timers are consistently accurate.
* The solution is probably never to implement elapsed time counters in the App but to always record real times sourced from the underlying OS which can then be manipulated later. (Maybe source time data from GPS if the device is so equipped?)
* The app must include a simple means of checking and synchronizing system time between different devices. (So if device A is being used to record a start time and device B a finish time, the elapsed time is not just a relative result between devices A and B but is a real result comparable to the data collected from devices C & D being used to collect the same data but from different competitors on a parallel course.)
* While current standards state that manually collected times should be accurate to 1/10th sec. and automatically collected times 1/100th sec, the system should be future-proofed to be capable of managing times accurate to 1/1000th sec should the hardware become available to make this a realistic possibility.
h5. General operation
Possible problem... could be disastrous if user inadvertently presses a button on the device which switches him into a different app, phone rings, or something. Is it possible to lock user into the app so it continues to run and they must confirm they want to leave it?
h5. Data-out
This too requires a *standard data-structure* (in xml or JSON) which is managed by the app in association with its communication protocols, but the sub-components must know what data they need to supply so the data is complete.
The app is useless unless the data it produces can be read by something. As with data-in, it is proposed an *Excel add-in* is initially produced which is capable of reading the supplied data and inserting it into the appropriate place in the scoring spreadsheet. Other systems can be made available at a later time as necessary.
Two variants of data-out?
* Full version: A full record of everything so it also contains logging info such as the current configuration, sequence of keypresses Etc. Continuously saved locally but sent to server only rarely.
* A 'reduced' version containing only key data for normal transmission to server.
Two types of data out
* Provisional: Sends data whilst the performance being measured is actually happening, mainly useful for scoreboard, commentator and TV caption displays.
* Confirmed: As soon as possible after the performance is completed, physical action by the operator (eg '*send* button') transmits all collected data including 'extras' eg penalties which must be applied. Can be repeated (ie an update).
Since the provisional type of data definitely needs special softwares on the receiving end this need not be present in early versions of the app. but the concept should be borne in mind for introduction into more developed versions.
h5. Communications
The core app should be capable of communicating with:
1) Simple: A file system on the local subnet (wi-fi capability of the device)
2) Via http to a server on the local subnet (wifi)
3) Via https, wifi and a router on the local network to a remote internet based server.
4) Via mobile data network to a remote server. Could be file-based (eg dropbox) or https.
[MQTT|http://mqtt.org/] might be a better option than http? Much lighter weight protocol highly suited for this type of requirement, but does need a broker and translation services to other protocols (eg [Mule ESB|http://www.mulesoft.org/]).
The choice of which system is used is dependent on the sophistication of the user. Variant 1 should require nothing more than a single computer connected to a wireless router in access-point mode which is within range of the terminals in use.
It is fundamental to the system that current communication state is known to the app and the operator, if communication is not currently possible to the configured data source then the app must cache data until comms are re-established. Equally, the operator must be made aware of current comms state so he can do something about it if comms are lost (eg move back into range of the wi-fi signal).
Note that option 1) above might be more difficult to achieve than having some sort of web server on the receiving end. If it is, then the web server must be available in its most basic form as a really simple thing to install on a host computer.
*Problem?* Phones and tablets usually hop amongst wifi providers depending on the best signal. The system in use may be a single AP, may be a mesh system, may have several different APs, hopping amongst them is desirable, but probably there will be other APs in the vicinity too (eg for public internet access). Is some special arrangement necessary to ensure it will only lock onto the designated network?
h5. Synchronization
System should be capable of supporting several operators collecting task data simultaneously on different terminals. There are many occasions when two or more tasks may be occurring simultaneously (eg 2 parallel courses), or a task requires more than one source of data due to physical disposition of where the people operating the terminals must be (eg eco-laps). In both cases they are the same task and the data needs to be consolidated into one destination source so a current standing in task or score can be produced.
This is not the same thing as having a second operator collecting 'backup' data which can easily cause the dilemma: who is correct when there is a difference? It is not proposed the system should be 'dilemma-resolution capable' so backups, if collected, should be done manually in the traditional manner and corrections entered into the terminal if necessary.
Since the simplest variant of maintaining data-out data should require no special software on the receiving server, at its simplest it is thought this might be possible to achieve at at the file system level:
* Terminal A has data to send. First it retrieves the current data file on the server, adds its latest data to it and sends it back, maintaining a lock on the file during the whole process.
* Terminal B also wants to send data, but must wait until terminal A has unlocked the file before it can retrieve the file.... Etc.
Whilst this appears to be a relatively inefficient synchronous way of doing it, it does mean every terminal has the ability to be constantly updated with the latest data from every terminal, and it should prevent conflicts of data. If all terminals are always looking for the newest file to update, timeouts (ie unreleased locks) could be controlled by a terminal creating a new file on the receiving server after a reasonable delay, eg 30 sec. Other terminals then carry on updating that file.
Systems using http connection which is intrinsically asynchronous will need some level of software at the receiving end not just to do something with the data (eg write it to a file or db) but which can also manage the same sync protocol in an orderly manner.
|
This page
Other pages
