Return to overview

Pillar 4: Integrations

The Fourth Of Our 7 Industrial Internet of Things Platform Pillars Series

You might be thinking yes, these Industrial IoT platforms all sound amazing.

But how is my 15 year old legacy system going to deal with this sudden influx of data; it’s surely not possible to upgrade my organisation with this vast array of new processes and sensors without older systems just falling apart?!

That is where IoT integrations comes into play. Consolidating your diverse set of systems and processes to create a rich application is a key component of the Davra platform.

So what exactly does IoT integration encompass? According to Gartner, it involves “making the mix of new IoT devices, IoT data, IoT platforms and IoT applications — combined with IT assets (business applications, legacy data, mobile, and SaaS) — work well together in the context of implementing end-to-end IoT business solutions.”

At Davra, we’re keen to consistently focus on the business outcomes and how you apply IoT applications to business logic in order to improve your organisation. Integration means working with what you have, both internally and externally to the company, adding our platform to your capabilities and enhancing the communication between these applications and systems.

The Gartner Industrial IoT Magic Quadrant named Davra’s connected industrial assets integration platform capabilities as a major positive for these types of use cases, along with application enablement and administration.

Data Flow Architecture

Data sources we come across are IoT gateways, LPWAN sensors, web-enabled APIs (REST, SOAP, etc.), video (overlaying video frames with IoT data), voice, adapter, ETL (extract, transform and load), as well as traditional data sources such as SQL, OLAP and other databases and map/reduce.

We also deal with realtime data plugins. You can’t change it at the source so we use an adapter on the fly to pull that data into the platform.

Headend integrations include feeding information, so you may need to forward it to another system. This feeds data in realtime, placing it into a database somewhere, or if you need to put it into an operational or IT system that’s already in place in the customer’s network. Davra can then feed notifications in, and whoever needs to take action from these insights can then align with their internal structures. For example, tickets in the queue or an email that needs a quick response.

The Edge

At the edge we talk about the various important protocols. There are different categories and we can write adapters for the varying protocols.

There are general purpose protocols such as MQTT and HTTP. The SDK can handle all of these. There are also industrial standard protocols such as OPC and Modbus for vehicles. There may be lots of different vendors in different environments but these protocols are standard so they’re much easier to roll out.

Proprietary protocols are more niche and can be done for one vendor. These are not open, nor are they standard because they are specialised for just one vendor. For example the Siemens train time is proprietary as the protocols vary, but is possible to implement in the Davra platform.

Davra has out-of-the-box adapters for these types of protocols.

Integrating Systems

You can integrate data into the platform and also integrate systems. The tool used to do the integration depends on your use case, for example we can use RESTful API. Customers can consume all our own underlying data in the platform that we use to build our own platform.

If there’s a third party system to integrate our data, devices, sensor data or digital twins into a third party system, you can take the data using our open API. We have a JSON platform.

You can also create your own API on our platform. Perhaps you need to format the data slightly differently, in which case you can do that using our Microservices tools. These are useful if you also want to expose a topic like the Publish-Subscribe mechanism.

From the edge we have an SDK two way message bus by default; MQTT and HTTP. These call down and use our SDK like a helper. This takes care of the set up of communication between the edge and the head in server. You can capture specific functionality like carrying out analytics or a protocol at the edge and then build those into agents.

For example, if you wanted to communicate with legacy equipment, you’d have an agent capturing the logic to do that and use the SDK to communicate back to the head in server to send the data.

From our SDK you can send data to the Davra platform but you can also send it to other end points, it doesn’t have to be just our platform that this data is sent to.

Data Integrations; HTTP Forwarder

These are post formats; if you have an endpoint that you want to receive the data on, you can set up a forwarder and filter the forwarder down so you’re not forwarding all of the data. The data can be narrowed down to a subset of devices depending on the labels as they’re highly customisable. Post or put can be used, depending on the end point you’ve set up to receive. The endpoint of course needs to be able to consume the IoT data.

Clients can create integrations based on exceptions, for when there’s a problem in your organisation and the processes. In this case, ruling is more suitable.

We have a trigger, which could be looking at the CPU for example. The action could be a HTTP push on an exception or an alert in the system. This then sends a message to another system, notification or ticketing system. The HTTP push is used to create that integration.

Other Integration Types

We do support other types of integrations besides data; Email, IM such as Cisco Webex or Slack, and stripe payments.

An example of integrations on the Davra platform is in a vehicle system that comprises Google Street View, video footage in the car, GIS; the location, and an alert saying that you’re going over the speed limit using HERE maps. The HERE maps are in GPS format to watch the speed limit of the vehicle, and we can then produce a process that alerts the driver or other system when the vehicle is going over the limit.

Accident response use cases are also of high value in integrations. Police officers can wear Hexoskin wearables on the body when in serious situations while out accident response. These wearables are also linked to the vehicles to give system users visibility to see where the vehicle may be driving to and what’s in front of the vehicle. These integrations are made up of GIS, vehicle cameras and sensors, and wearing a Hexoskin vest to get user biometrics, such as assessing the stress level of the officer.

A high-value use case involves using sensors on emergency vehicles to coordinate the traffic lights. This ensures that when they are driving towards lights, they will turn green for them to move with the traffic, enabling them to get to the scene in a smoother and safer way. The technology used is broadcast radio technology from the vehicle and connected to all of the traffic lights in the city.

Network Performance Monitoring

Because we’re on IoT gateways; gateways for the application and sensors, the other gateway for the network connectivity must be able to reliably send data back to the cloud.

FCAPS is a type management of devices and the networking ability. We ensure our clients are aware of the reliability of that network because otherwise it could impact the application.

Other use cases Davra are working on maintain solid network activity and systems integrations are:

Gas Safety

Tracking workers in confined spaces whilst wearing chest-mounted android devices to keep them away from harm. These devices are the actual gateway and connect to the drivers.

Workers have a gas detector on their leg which can detect hazardous gases in the environment and alert those who are monitoring in another area.

They can also be tracked through digital permitting, which checks whether they have the permission to be in that location. Another system integration is the push-to-talk communications and two-way video to see where everyone is for their safety.

Smart Bikes

LoRa bikes powered by the dynamo, they never needed to be charged because they have a small electrical generator.

There are hot spots on the map (GIS) of where the bikes are, which helps for the planning and capacity for where the bike lanes should be. This use case also uses analytics to send messages back to the council when there are potholes because our system can detect the accelerometer of the cyclists. If there is a sudden stop or loss in speed of more than a few cyclists in the same location, it’s most likely to do with the road surfacing.

Our system also detects intersections that are dangerous, due to tracking cyclists and analysing them to see if they are cycling erratically around the junction. This allows councils to check if perhaps there’s something wrong with the way bike lanes are set up there.

Integrating with our Customers

We work with the customer from day one, to find what technologies best suit your use case, prove these technologies really work and bring the application along to a more scalable level. Our platform enables you to build on what you already have, both internally and externally to your organisation so you can efficiently carry out safe and secure business processes. All within one single platform that’s highly tailored to your needs. If you would like to chat to us today about your current systems and how you can benefit from bespoke Industrial IoT solutions, please don’t hesitate to contact us.