Thingsee Operations Cloud has a central role in all phases of a thing lifetime. Thingsee Operations Cloud deployment is always independent per customer deployment, and it is possible to run Thingsee Operations using a customer's AWS account.
Thingsee Operations require Amazon Web Services as all operations are implemented using server-less technology for easy scalability and cost-effective operation despite the number of sensors. All Thingsee Operations installations (“Thingsee Operations Profiles“) are connected to the global Thingsee Master Inventory database, so that manufactured devices, certificates, and other inventory data are properly transferred to the specific profile.
Thingsee IoT Platform has been build by using Amazon Web Services (AWS). The following key requirements are fulfilled by using AWS serverless technology.
Application Cloud integration is called cloud extension. It adds a new type of cloud support to existing Thingsee Operations Cloud. A cloud extension is an add-on within the upper layers of Thingsee Operations Cloud, that implement all the specifics that are required to authenticate and send data to customer-defined API endpoint. As soon as the initial integration is done, getting the IoT data is as easy as powering on the sensors and receiving data to that specific endpoint.
The data integration is always done so that Thingsee Operations Cloud integrates to application cloud. This way, the only implementation required by application cloud, is to have a logic for parsing incoming sensor data. There are exceptions when more application cloud changes are required; for example when the application remotely configures sensor parameters or if some service is used from the Thingsee Services API.
A cloud extension is always tailored, but typically based on an existing implementation, and so far we have following integrations available
The Application Cloud receives sensor data as a JSON payload, and the content is specified for each of the sensors as Thingsee message profiles. It is possible to convert Thingsee message JSON messages to a customer-specific message content, but that requires planning to find out the correct mapping of the APIs and parameters.
The Application Cloud has an option to use Thingsee Service API to change parameters of Thingsee sensors remotely. This is an optional functionality and can be used to change the behaviour, thresholds, and other parameters of a specific sensor device.
This is the single most important subprocess of Thingsee Operations. The only way to guarantee “99.9%” uptime of the devices is to have solid and active monitoring system in place to detect symptoms of problems, and to react to failures proactively before they become problems for customers. This is especially important when device volumes are high, they are deployed multi-regionally, and they consist of a complex combination of gateway and sensors with mesh networking options.
Thingsee Operations is designed to monitor following diagnostics, and more product specific diagnostics are added based on project requirements. Most of these diagnostics areas are created based on the experience gained during the development of ThingseeONE, Snowfox, and new Thingsee gateway and sensor products.
Thing diagnostics are built-in monitoring, logging, and reporting service within a device firmware. This may contain crash reports in case of an uncontrolled device reset, or diagnostic events in case of a device state where behaviour is not as expected. This can be, for example, a case where Thingsee Gateway device suddenly loses all its mesh network sensors; this doesn't cause a crash log and the gateway device must have built-in logic to analyse whether the problem is in Bluetooth, connectivity stack or in the sensor-nodes themselves.
Thing self-recovery is built-in as a safeguard for the most obvious error cases. For example, losing the cellular connectivity, sensor connectivity, mass-storage errors, etc. expected errors that the device must recover by itself. These self-recovery events are reported to Thingsee Operations so that the info can be used to analyse if there is a wider issue upcoming for example with cellular connectivity. Each thing must have own self-recovery logic depending on use. For example Snowfox, ThingseePRESENCE and Thingsee Gateway all have different requirements for diagnostics and self-recovery.
Cellular diagnostics are used when there is a suspicion that cellular network or cellular modem (a hardware module within a thing) is not operating correctly. There are various methods that can be done to diagnose, analyse, and recover cellular network related problems and configuration issue remotely using SIM partner remote APIs. This also requires support from the thing itself. Some problems can be fixed fully on the network side, but there are some more complex cases where SIM subscription, network parameters on a live network, and a cellular modem with embedded or standard SIM needs to be re-configured in a perfect sync.
Mesh diagnostics is a new feature for upcoming Thingsee sensor devices. This diagnostics allow Thingsee Operations to fetch power-levels and signal strength information from a sensor network to help to debug and analysing problems if a network is not deployed optimally for best coverage and energy saving, or if there is some sensor node loosing its connectivity to rest of the nodes. Mesh diagnostics allow also analysis of bottlenecks in a mesh network topology.
Cloud diagnostics take care of data flow to a customer's cloud, so that there is sufficient recovery and retry procedures available if the customer cloud is not available for short periods of time.
Operations diagnostics are Thingsee Operations Cloud internal diagnostics and monitoring services and tools to follow and coordinate behaviour and performance of Thingsee Operations cloud service and the external APIs and services it uses.
Some aforementioned diagnostic services are enabled always, but especially a thing related diagnostics options are run-time configurable because otherwise they would drain the sensor battery or generate a high amount of data traffic causing higher connectivity cost. All diagnostic services need to be power and cost optimised.
Thingsee Operation comes with remote firmware update functionality, and it is integrated, tested and deployed to products already during development phase. Without remote firmware update it is practically impossible to maintain Internet-of-Things devices even in low volumes.
Thingsee Operations uses device inventory to group devices into logical manageable groups so that firmware update can be done in a controlled way and gradually deploying to all applicable devices.
Each Thingsee product will have its own hardware/operating system specific firmware update method, and it may include an update for peripheral firmware as well. For example, Thingsee gateway firmware update may update cellular modem, WiFi, bluetooth etc. hardware modules to their latest versions.
As the products are commercially used and deployed in live operations, each firmware update needs to be carefully planned and evaluated before deploying to the devices. In addition, the content and changes in each firmware update needs to be documented according to the requirements of type approval process (CE/FCC and others).