All MissionOS data is loaded and stored directly on the cloud based platform. A local staging server may be used for data collation as required. MissionOS processing is multi-layered. The final public site will show the data which passes built-in audit filters and manual review. Administrators can see all the data. We have developed very sophisticated tools to deal with imperfect data and avoid spurious warnings and alarms from being generated. All processing steps are completely transparent so that users can compare with manufacturers recommendations.
All data management can be undertaken online and is two tiered. Changes and edits and new data are first published to an intermediate layer where the implication of the change can be viewed and approved before releasing to the general user base.
All processing steps are completely transparent and processed data can be saved at each stage so that the implications of each processing layer can be seen and evaluated.
Manual data can be entered directly into the database from anywhere connected to the internet by GPRS, 3G or better. This means that data can be presented and audited from site.
Files of various types can be presented to the MissionOS which has audit on entry functions to identify and deal with file and data errors.
All original files are saved as part of the process. Files modified by the user are also saved in history database.
Files upload can be by:
Real time data sources which are ODBC compliant can be loaded by the MissionOS. If the sources are web addressable ie web databases or ftp sites then the information can be parsed and loaded directly and automatically.
If the sources are not web addressable then a staging server is required. This staging server runs a windows application MISSION CONTROL along with schedulers to send information to the web systems for assimilation into the database. The MISSION CONTROL runs systems which manage the extraction only of updated data and send this to web servers in this way limiting the FTP traffic to manageable levels.
Filters can be set based on credible magnitude, rate of change (spike detection) and persistence. Data falling outside predefined ranges will be quarantined and will not give rise to alarms and will not appear in the public area. Data can also be quarantined manually.
Quarantined data will be presented for action in the audit report and the MissionOS will require data managers to action quarantined data. All filters are agreed with the client before being implemented.
Audit – Automated audit reports can be run by MissionOS at regular intervals to identify missing or incorrect information.
These audit reports are export to excel and can be reloaded to update the data.
The system provides a number of post-processing stages including:
All data entered into MissionOS goes through a two level system – at administrator level the user can see all the data including data entered by staff for approval. This must be reviewed and approved before release to the public site. The ability to upload and review data in the field improves the quality of data
Correct – Incorrect data can be corrected in the system and the system will track the changes in the data with the name of the originator of the change and change date. In addition to simple corrections to typographic errors MissionOS has built in ergonomic feature and functions to address many common sources of error in instrumentation data to ensure minimal delay getting data to end users.
Part of the shift recording process involves identifying which of several contemporaneous activities is the critical one i.e. the reason why production is not being advanced each bar is coded using classic black ball chart schemes
In additional to the technical aspects of construction the MissionOS tracks production progress in two ways:
Simple Progress vs Programme |
Each site is given a simple proforma with a subset of the programme activities. Each day they fill out the proforma with the work done that day along with the Date time, chainage, comment |
Full Activity Shift Reports |
Each activity defined from the programme is assigned a shift report. Each report is assigned tasks. Each task can then be assigned codes based on codes originated in 1990 as part o the Channel Tunnel operations. These tasks comprise a main task such as probing or grouting and a subtask delay code identifying the cause of the delay eg. normal, hydraulic, mechanical, electrical etc etc. |
Labour and Plant |
Labour and plant lists are assembled by the head office and distributed to sites. |
The MissionOS construction data management system has been implemented on a number of tunnel projects within SE Asia – the systems started out with basic screens operating on LAN which are being replaced by fully web enabled screen designed for tablet use on site. In addition to screen entry the MissionOS can accept excel or other formatted files containing the relevant data. Technical data in the MissionOS CDMS includes:
The system entry screens have evolved to promote a standardised approach to recording. This ensures that quantities are reliable and can be cross correlated with other jobs. With accurate dimensions for geological classifications encountered the influence of particular ground types can be evaluated and this has impact on Geotechnical Baseline Report evaluations.
Alarms are summarised on the main page via the AAA list which the user can interrogate to analyse the results. For admin users quarantined data is also shown
Figure 1 - Alarm lists
Alarms are sent to email and SMS using configurable messages. Alarm recipients can be set by the admin according to region and user level. The admin can set a variety of factors including:
Most staff are now familiar with the use of blogs via social media and left to their own devices often set up non-secure WhatsApp groups to communicate via mobile phone. Maxwell Geosystems exploit this familiarity by sending alarms to secure blogs hosted on the MissionOS and accessible by the same devices.
Figure 2 - Alarm blogs
In many cases when there is an instrument breach the Main Contractors are required to produce an AAA report for submission to the Supervising Consultant. An example of the general content of the report is stated in Table 1.
| Stage | Item |
|---|---|
| 01 | Immediate Response |
| 02 | Details of construction activities |
| 03 | Result of inspection |
| 04 | Site instructions |
| 05 | Summarise the results of adjacent instruments which may be affected |
| 06 | Review of subsequent monitoring |
| 07 | Other actions |
| 08 | Action plan |
| 09 | Report conclusion |
The report is prepared with input from the contractor’s instrumentation team, construction team, design & technical team and supervising consultant to conclude the actions/recommendations to be taken at site due to this instrument breach. This report will be circulated within a stipulated time so that timely and appropriate actions can be taken. Due to the large scale of projects and instrumentation numbers installed, a good database management system is needed to ensure that these reports can be easily created, generated and distributed with easy access to the system.
Using blogging technology, the MissionOS was able to automate almost 90% of the report and furthermore keep track of the timing of responses. The time requirement for generating this kind of report is reduced as all related parties involved in contributing to the report can access and register their input via a web-based portal at their convenience. he system also prompts the users to input their comments when needed.
The implementation of live reports online means that content can continue to be added as instruments worsen or additional information is provided without the need for duplicate report revisions
Instrumentation
Shift Report
Technical
Construction Data
Alarms and Blogs
