DATA-DRIVEN ENVIRONMENTAL SERVICES OPERATIONS

To provide a Command and Control (C2) platform to interface with existing smart solutions used for ES management and operations. The C2 platform shall be the only platform required by SBs or SPs to manage the suite of smart solutions deployed in ES operations in future.

Suggested technical requirements are specified below. Applicants are encouraged to propose beyond the suggested requirements in order to achieve the specified desired outcomes.

1. The platform should have a scalable and extensible architecture that would allow management of devices, connectivity, data and security. It should also offer microservices or web services that could be used by applications to securely access data, devices, etc according to the rights given. Application(s) that is/are to be delivered as part of the platform, should offer the following to the end-users:
   1. Performance tracking and delivery of service(s) from service providers and compute a performance index automatically
   2. Automated generation of performance and service cost analysis reports to aid in activities such as tender budgeting and contract administration
   3. Real-time monitoring of sites’ status via a unified dashboard
   4. Assign and alert service providers of ad-hoc, daily and periodic ES-related tasks (e.g. cleaning of toilet or spillages, clearing of filled bins, rodent detection and elimination, etc) based on audits, sensors data (e.g. cameras, toilet sensors, rodent sensors, etc), predictive analytics, etc. This should enable the automated deployment of robots or manpower.
   5. Automating repetitive backend administrative tasks (e.g. manpower scheduling, monthly service provider performance documentation, calculation of disbursement of contract sums, data collation, etc)
   6. Offer predictive analytics to aid in manpower and resource optimisation (e.g. predicting maintenance needs, optimisation of workflow, easing administrative needs of contract administration and planning)

2. All applications developed should be designed and developed with end-users in mind and take their cognitive load into consideration to ensure that they will be able to operate or use the platform with ease, thus reducing the resistance to adoption. As an example, older cleaning staff might face difficulty in learning digital platform or interpreting messages sent by the platform and this should be addressed.

3. As it is anticipated that different kinds and large number of devices would be connected to the platform, it should provide proper device provisioning and management features. For example, it should enable a systematic and secured approach for users to connect new devices to the platform, enable Over-the-Air (OTA) firmware update to existing connected devices (where applicable), monitoring of devices’ health, determining or updating devices’ location at various sites, etc.

4. New IoT sensors useful for monitoring environment conditions could also be included in your proposal. Some examples include IoT sensors that are able to detect water spillage, defective devices such as automatic faucet, automatic toilet flush, rodent detection, fill-sensors bins, etc. Such devices should be integrated as part of the platform to facilitate testing and evaluation. Aesthetic and practicality of device design should also be duly considered so that deploying the devices would not affect the aesthetic of the building due to protrusion and exposed trunking. It should be easy to deploy, e.g. without need for wirings or tapping into power sources. The IoT sensors should also come with appropriate Ingress Protection rating with respect to the type of environment factors they would be subjected to.

5. An open platform is preferred that could support heterogeneous wireless network supporting different wireless standards such as WiFi, BLE, Thread, Mesh, etc commonly used by IoT devices and messaging protocols such as MQTT, DDS, XMPP, etc. Support for heterogeneous wireless network could be implemented via edge gateways or any other feasible means. It is well known that the different wireless protocols evolve and get upgraded over time and therefore the platform should preferably allow hardware, firmware and software upgrade. The wireless standards and messaging protocols are specified for reference and participants should clearly indicate the wireless standards and messaging protocol supported or why they are not supported. 

6. With the recent advancement in implementing Artificial Intelligence (AI) at the edge to reduce bandwidth requirements amongst others, proposals can also look into the adoption of edge AI in the proposed platform where relevant to process information such as camera images to detect cleanliness, etc.

7. Data management capability to store and manage the collected data so that they could be retrieved later for processing by applications. Sources of data could be coming from deployed IoT devices, smart equipment or from data stored in databases on the cloud. Therefore, it would be necessary to support different data collectors to ingest data from a myriad of data sources. It should be possible to add new data collector plugins to support new data sources when the need arises. Furthermore, it would be desired that the data are processed so that they are structured into common formats such as XML, JSON, etc. for consumption by applications.

8. Connectivity management for management of device connections to the platform. This would be required for platform that plan support connections via wireless networks such as NB-IoT, LoRaWAN to manage activation, provide usage reports, billing, etc.

9. The platform should offer user management functions that enable user role and access permission to be configured. This is necessary to accommodate different level of users such as cleaners, cleaning supervisor, facilities management (FM) staff and managers. This would ensure that they would be given access only to data and information relevant for their job functions only.

10. The platform should offer availability of not less than 99% to ensure minimal downtime in the delivery of the ES in using the platform, and recommend a suitable backup scheme to ensure that the platform and its data could be recovered should the need arise, for example due to an attack or hardware failure.

11. The platform should be capable of scaling up for usage at the FM level.

12. Ensure ease of use whereby the platform could be set up and configured rapidly according to SB or SP requirements.

13. Solvers are to provide an onboarding strategy in their proposal elaborating the strategies and means to bring stakeholders into this project (e.g. smart solution vendors and service providers).

14. The platform shall ensure implementation of end-to-end security measures as recommended in the Singapore Technical Reference, TR 64 (Guidelines for IoT security for smart nation) or otherwise to demonstrate cyber-physical security capabilities in the protection of platform and data from attacks.

15. The platform design could also reference TR 50 (Technical Reference for IoT information and services interoperability for Smart Nation), which was developed to facilitate the sharing of IoT data and information across multiple industry applications.