This page
Other pages
You are viewing an old version (v. 12) of this page.
<< View previous version | view page history | view next version >>
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^CIMA_2012_Plenary_real_time_data_collection_proposal v1.pdf] presented to the 2012 CIMA Plenary.
Suggestions for improvement welcome!
Refer to the ABG system for a working demo of something which inspired the idea.
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.
- It is proposed the initial work should be directed at Android devices
since this is an open-source OS and the hardware is generally much cheaper than the equivalent offerings from Apple, but there is no reason why the same thing can't be ported to iOS at a later time. - The app should be 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.
Functional overview
The ABG system was disadvantaged by being very hard-coded, which made it only usable in a very specific set of tasks. 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 'add-ins' rather than fully compiled objects in the core source;
- 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.
Task configuration
The idea is that it should become 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.
Configuration scripts are in xml to a precisely defined format 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.
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) 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, but other systems can be made available at a later time as necessary.
Data-out
This too requires a standard data-structure (in xml) 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.
Communications
The core app should be capable of communicating with a file system on the local sub-net (classically using the wi-fi capability of the device) or via http to a server, either through the local wi-fi system to a local server, or wi-fi and a router on the local network to a remote server, or (if fitted) via GPRS / 3g / 4g data connection with a mobile network to a remote server.
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, and the operator must be made aware of currnet comms state so he can do something about it (eg move back into range of the wi-fi signal).
Sync
System should be capable of supporting multiple devices simultaneously. (ie several operators collecting task data simultaneously. While it is not prudent for the same data to be collected by two operators simultaneously, (who is correct when there is a difference?) thre 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 (eg eco-laps). In both cases they are the same task so the data needs to be consolidated into one destination source.
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 ineffecient sequential way of doing it, it does mean every terminal has the ability to be constantly updated with the latest data from every terminal and should prevent conflicts of data. If all terminals are always looking for the newest file to update, timouts (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 which can manage sync.
Licensing
It is proposed CIMA invests in the the original work required to get a basic system up and running. It might therefore wish to retain the source code and even charge a licence fee. While there are quite a few components to the basic system, the overall design is intended to incorporate the core functionality but be expansible from the very beginning. (other OS's, other scoring systems Etc)
By far the best way to achieve this is to make the entire system open source from the very start which might encourage other developers to contribute to the success of the system without the complications of licensing Etc.