Jump to: Difference Manage Technical Geeky details Low code Works with Pricing Customers.
The goal of both is the same: service management for IoT. Helping companies who are deploying connected devices to manage them effectively, to deliver a great customer experience, to reduce operating costs and to grow faster. The difference with Core is that it delivers service management at a much bigger scale - into the millions of devices - and at lower cost which makes it viable for use in B2C applications.
Technically, both services provide stateful streaming analytics, which is the raw processing work that service management requires. Classic DevicePilot does this analysis work “on the way out” by firing-up thousands of servers for a few seconds while a user waits in front of their web browser, and this can become unwieldy at scale because of the sheer amount of data. In contrast, DevicePilot Core does the majority of its analysis work “on the way in”, as the data arrives from devices and before it is stored. This early data-reduction delivers maximum efficiency.
Core also unbundles various technologies, for lowest cost and maximum flexibility and re-use. So for example whereas in DevicePilot classic a user can construct dashboards only within the DevicePilot SaaS product itself, with Core the user can visualise results using any dashboarding tool such as Dash, or their existing BI tool, and can choose a variety of databases downstream to store results before visualisation, e.g. AWS Timestream or OpenSearch, providing any balance of flexibility, performance and operating cost.
DevicePilot Core ingests real time telemetry from devices via the customer's existing cloud endpoint. It also ingests metadata about devices which may come from a database. This data is usually already flowing through some kind of queue such as AWS Kinesis for application purposes, so Core can just subscribe to this same queue. By applying stateful transforms (see below) to this data stream, Core emits a real-time picture of all key performance metrics across the device estate, and grouped by customer, site etc. It also emits events when it detects situations on individual devices or across the device estate, which merit automated action.
Action can then be taken in response to events by integrating with more than 200 common business applications. For example, Core can raise a case in Salesforce Service Cloud, enrich that case with a summary diagnosis of the issue, send it to the correct team for resolution, and then mark it as resolved once it detects from telemetry that the resolution has occurred. Equally well it can talk to ZenDesk, Hubspot, Slack - you name it, anything with a REST interface.
This simultaneously makes customer support teams much more productive and delivers much more responsive fault resolution to the end customer.
The type of analytics done by DevicePilot (classic or Core) is called “stateful streaming analytics” which goes beyond the capabilities of a typical SQL or time-series database, because it can maintain an internal picture of the state of each device, and subsequent analysis on that device or across devices, as time passes.
For example, imagine that your devices send a 5 minute heartbeat message, and if you have not heard from one of them for 15 minutes then you want to deem it as “offline” until you next hear from it. We need a way to mark that device as offline as the 15th minute expires - even though no data changes at that moment. And if we then want to report uptime for that device over a day, we need to measure the amount of time for which the device was deemed to be online, and express it as a fraction of the day. This is a simple example of the kind of question that must be answered for effective service management - for which stateful streaming analytics is needed, as classic databases (even time-series databases) are not capable of this kind of query.
DevicePilot Core uses Apache Flink as its stateful streaming analytics engine. Apache Flink is a mature open source project used by Netflix, Uber etc. to analyse millions of events per second. Flink is extremely powerful but fairly arcane so only really usable by Java developers. DevicePilot Core gives access to this power with a higher-level conceptual model which is much easier to understand.
Core's analytics processes for service management are built-up from four types of calculated property, each able to operate on both incoming telemetry/metadata and also on other calculated properties:
Technically, DevicePilot compiles the complete analytics pipeline into a Flink job, which is deployed into the customer AWS account and run for example in a Kinesis Data Analytics pipeline in real time.
This term describes a modern way to declare requirements without “programming” in the conventional sense, which means that it can be done by many businesspeople, not just developers. It still requires some level of technical understanding, but more at the level of using a spreadsheet than of writing code. From a technical perspective, DevicePilot provides as declarative specification rather than an imperative one, which decouples the declaration of what the customer wants from the technical implementation by DevicePilot, which leaves a lot of freedom for DevicePilot to continually improve its engine without the customer needing to change their process definitions.
DevicePilot (both classic and now Core) works with any kind of connected device - it is entirely agnostic and can have any format and any schema. Because data is accessed in the cloud, the devices' security profile remains unaffected. Existing DevicePilot customers are in verticals as diverse as water treatment, food waste management, traffic management and electric vehicle charging. The company’s main sales and marketing focus is in enabling the transition to Smart Energy, where it has considerable experience.
The ability to deploy Core direct into the customer’s AWS account enables DevicePilot to offer a new pricing structure, including lower overall costs at scale.
Previously DevicePilot classic was offered purely as a SaaS product, with monthly fees based on the number of devices. While this pricing has the benefit of simplicity, it could make some customers feel trapped on an escalator as their device estate grew, without any levers to pull to control their service management cloud costs.
Because Core can run in the customer’s account, the customer pays the machine costs directly, providing 100% transparency on cost. The customer then pays DevicePilot a license fee, plus a support fee.
The other stack features used around Core - such as data storage and dashboarding - are now “unbundled”, giving the customer huge choice over which technologies to use. This means a customer can maximise re-use of existing platforms (and know-how) and avoid duplication of data and work. This all helps to keep costs down, and for most applications, including large-scale B2C applications, a total machine cost of circa £0.01/device/month is achievable at scale (Core plus all the other pieces needed to deliver a complete service management solution).
The customer can further control costs by pruning the telemetry that they put into Core, and also by moving analytics from elsewhere into Core. For example, in the early days one might set up Core to output metrics “by device” - so metrics for every device are emitted into a downstream store such as Elastic or a TSDB. This is very flexible because it allows interactive aggregation such as “group by customer” or “filter by device type” - but that flexibility comes at a cost. Once it is clear exactly which metrics are required for day-to-day operation, and how they should be grouped and filtered, the analytics can be moved back into DevicePilot Core, which then emits metrics just in those groupings (not for all devices), significantly reducing machine cost.
Watch this space!
Trusted by
Sign up to receive our monthly newsletter about IoT
© 2022 DevicePilot™. All rights reserved.
