fbpx
Industrial IoT (IIoT) edge solution for railway operators – a Kapsch ObjectBox Case Study

Industrial IoT (IIoT) edge solution for railway operators – a Kapsch ObjectBox Case Study

Executive Summary of IIoT Edge Case Study

The biggest challenge railway providers face today is digitization to increase operational efficiency. Issues like unscheduled downtimes or track repairs are very costly and have a strong impact on customer satisfaction. On top, railway providers constantly need to work on ensuring and improving passenger security. The problem behind these issues is that railway operators are often still lacking data when it comes to knowing what is happening on the tracks, in the tunnels and trains.

This case study looks at how Kapsch and ObjectBox collaborated on a Kapsch Industrial Internet of Things (IIoT) edge solution for the railway industry. The project enables railway operators to optimize their operational efficiency and asset management via rapid processing of real time mission critical data, ensuring extremely reliable asset operations and timely decision-making.

Kapsch

Founded in 1892, today this family-owned company headquartered in Vienna is a globally-operating technology group with offices and subsidiaries on all continents. The Kapsch Group focuses on peoples’ requirements in the fields of communication and mobility. With innovative products and solutions, Kapsch BusinessCom and Kapsch TrafficCom make a significant contribution to the digital transformation and a sustainable future in public and private transportation.

ObjectBox

ObjectBox makes real time data consistently accessible from sensor to server – including sensors (client), Android and iOS devices, IoT gateways, on-premise and cloud servers. ObjectBox is 10 times faster than any alternative, smaller than 1 MB and uniquely designed for IoT and Mobile settings.

Kapsch and ObjectBox

Kapsch is a longtime partner of railway operators and is thus helping the industry with digitization. By integrating ObjectBox’ database and synchronization solution into the Kapsch railway offering, Kapsch can provide superior speed and data continuity to their railway customers. This means critical data is available when needed and can be interacted with in real-time. This heightens operational efficiency and passenger security, because speed matters in that environment. It also decreases networking costs significantly. Last not least, keeping data locally as much as possible increases data security.

The challenge: Having data up to date – fast, reliably, across devices

As a long-term partner of railway providers across the world, Kapsch addresses their major pain points with its new IIoT solution. Central to optimizing railway providers’ operational efficiency and security is having real-time information about tracks and trains available when needed where needed.

Project requirements at a glance:

    • Performance and operation on all kinds of platforms from sensor to IoT gateway to server to iOS and Android devices
    • Reliable data synchronization between devices
    • Fast (near real-time) and network-connection-independent operation on all devices, meaning on the edge. Therefore, a superfast database across entities is required.
    • Possibility of opening the APIs for external developer projects in the future.

What we developed in the course of our digitalization initiative, was an end to end solution for IIoT, and with this we have an edge computing solution. We were looking for possible partners and one of them was ObjectBox. When we saw their synchronization methodology, we understood it was a perfect fit.

Jochen Nowotny

Vice President of Product Management, R&D, Delivery & Support, Kapsch

The project environment

Developed in a co-creation process with railway operators, the Kapsch IIoT-solution is uniquely tailored to the main needs and challenges of the railway industry: Passenger experience, operational efficiency and safety / security.

The Kapsch railway cross-platform solution applies mission-critical data to avoid costly downtimes and repairs, reducing maintenance times and delays. Thus, timetables can be kept more accurately up-to-date, making travelling a better experience for end users.

At the core of the solution lies the Kapsch mission-critical network. Another essential part of this solution is the storage, processing and delivery of data, so data is accessible where it is needed, when it is needed. Doing this efficiently provides a competitive edge to railway operators. Having the data needed to make decisions in real time – across any part of the railway network – improves operational management and the experience for both employees and customers.

ObjectBox’ solution

This is where ObjectBox comes in. ObjectBox offers a fast data storage and synchronization solution that works seamlessly across devices, from sensors to mobile (iOS and Android) to server to cloud. Because of its out-of-the-box synchronization solution, it also saves time to market and costs. On top, ObjectBox’ easy APIs could easily be extended to external developers. Therefore, Kapsch decided to implement and benchmark the startup’s solution.

 

How did Kapsch find ObjectBox’ solution?

Sourcing new innovative approaches is like finding a needle in the haystack. That is why Kapsch runs the later stage accelerator program Factory1. Factory1 focuses on piloting startup solutions at Kapsch. In a rigorous process, Kapsch’ top management and experts from around the world assess startups and define pilot projects together with them. In the final evaluation step, the startups pitch these pilots to the Kapsch board. After going through this thorough process, ObjectBox convinced the board of their solution’s great potential and usefulness for Kapsch.

The solution: A unique hardware/software stack with out-of-the-box synchronization

While the rigorous sourcing process already ensured a good paper and personal fit, in software projects it always comes down to the nitty-gritty details of the technology stack.

Working together – from technology fit to project-setup

The Kapsch project was developed mainly in Java for the operating systems centOS, Android and iOS. ObjectBox supports all platforms and languages used.

So the first step was to integrate the ObjectBox database for storing data, which meant replacing the persistence layer with ObjectBox. When exchanging a database (the data persistence layer) in an existing project, four cases can be distinguished:

SQL database with abstraction layerNoSQL database with abstraction layer
SQL database without abstraction layerNoSQL database without abstraction layer

In this project, a NoSQL database with an abstraction layer needed to be exchanged.

The second step was to synchronize data between IoT edge gateways and central servers.

Each IoT edge gateway (located along the tracks and in the trains) collects local sensor data and makes it accessible to local devices like smartphones, as well as centralized locations (e.g. on the headquarter’s servers). This setup allows high speed operations independent of the availability and quality of network connections.

This is not a simple case of “sending data one way” or “full replication”, rather a more sophisticated technology referred to as “data synchronization”. It is transactionally safe (aka ACID compliant), meaning no data is lost in transit. The network and gateway can go down any time – once everything is up again, data is safely transmitted. This data synchronization is a built-in feature of ObjectBox and therefore does not require any additional, costly software development efforts from Kapsch.

The third step was to compare ObjectBox to alternatives. Therefore, KPIs were defined and a benchmarking application was set up. The KPIs used in this evaluation were: internal project goals, ease of use, the performance of the database, the speed and efficiency of synchronization, and data consistency across devices.

Pilot project results

Together, ObjectBox and Kapsch achieved their goals and created a solution that adds a competitive edge.

“ObjectBox integration in our IIoT solution has enabled significant performances improvement … far beyond other databases. More, we’ve learn a lot on how to operate efficiently a database from the collaboration with ObjectBox team.”

Farid Bazizi

Head of R&D Development - Mission Critical Communication & Industrial IoT Technologies, Kapsch

Overall goals

More specifically, the following goals were met in the 3 month project:

  • There was a successful integration of the ObjectBox database, demonstrating how fast and easy it can be implemented. Because ObjectBox is flexible and easy to use, it can help ensure that will be usable and maintainable for 10+ years.
  • The performance benchmarks done in the project clearly showed that ObjectBox outperformed the alternative solution, which was based on Couchbase, with regards to speed (CRUD operations), as well as CPU and memory (RAM) usage.
  • Last but not least, ObjectBox Synchronization proved to be easy to implement, transferring data seamlessly and reliably between devices. Benchmarked against the existing solution, measurements showed that ObjectBox synchronized the data 61 to 94 times faster.

Benchmarks

Please note, the benchmarks done here are project-specific. The benchmarks simply compare the internal existing Kapsch implementation, which is based on Couchbase, to the ObjectBox implementation. Thus, they should be read as project-specific results only.

Database Performance (CRUD), higher is better

ObjectBox is faster on all basic database operations within this project. This means you can process more data faster, and run more complex applications, like artificial intelligence or machine learning applications on the device – and respond to incidents faster, before it gets costly or dangerous.

 

CPU & Memory Usage, lower is better

All hardware comes with limited CPU and memory resources. These resources are shared between all the apps running on the device. The less CPU and memory that the data storage solution and sync uses, the more is left for other uses.

This means it is possible to:

  • install smaller (and often cheaper) hardware
  • run more applications and do more complex computing (e.g. edge AI) on the existing hardware, allowing you to capitalize on existing infrastructure.

Both are huge cost factors in the project settings.

Synchronization speed

ObjectBox’ synchronization implementation was much faster than the alternative, processing 37,629 objects in one second, as compared to the 400 synchronized by the alternative. In practice this means that in the given setup, ObjectBox supports 10 times more clients (nodes) for every server. This translates to huge cost savings on hardware as servers are expensive and only one server is now required where before 10 were needed.

Startup-Corporate Collaboration: A win-win situation

As this case study shows, it pays off for projects to evaluate solutions independent from their provider’s company maturity level.

On the journey, both companies learned and benefited from each other’s expertise. Apart from solving the concrete technological challenges, the project yielded further positive side effects. Sebastian Opitz, Head of Controlling and ObjectBox’ project mentor, gives an example: “ObjectBox helped to quickly identify a faster way forward with a new technical solution. It would have taken us much longer doing it on our own and probably only would have been discovered much later.”

From the startup perspective, the collaboration gave ObjectBox access to new departments and new markets. “Kapsch has a deep market knowledge and a lot of experience with digitization projects. This experience helped ObjectBox to reach the next level”, concludes Vivien Dollinger, ObjectBox CEO.

Why Android developers should care about Edge Computing 🚀

Why Android developers should care about Edge Computing 🚀

What is edge computing? 🤔

Today, over 90 percent of enterprise data is sent to the cloud. In the next years, this number will drop to just 25 percent according to Gartner. Where is the rest of the data going? It’s not going anywhere. It is being stored and used locally, on the device it was created on. This is edge computing.

Mist, fog, edge, cloud – the terms ☁️

To bring some light into the terminology mess: The terms “mist” and “cloud” constitute the ends of a continuum.

Mist covers the computing area that takes place on really tiny, distributed, and outspread devices, e.g. humidity or temperature sensors. To make it a bit more tangible: These devices generally are too small to run an operating system locally. They just generate data and send it to the network.

As opposed to this, the cloud refers to huge centralized data centers.

The terms “fog” and “edge” fall within this continuum and – depending on whose definition you follow – can be used interchangeably.

Adapted from Peter Livine (Andresseen Horrowitz)

Why is the edge cycle happening again just now? 👇

The underlying megatrend enabling this shift is cheaper and more efficient hardware, as well as the emergence of edge databases. Edge databases are specifically designed to run on the edge and therefore lean and efficient. Both the number of mobile and IoT devices, and alongside data volumes are exploding at exponential rates. At the same time computing capabilities on the edge level are advancing faster than those on the cloud level. So, the edge has increasingly more power – power that is currently often underused.

New applications and requirements drive the shift to the edge:

 

 

Advantages of setting your project up in the cloud ☁️

 

So, what about the cloud; do we still need it in this era of Edge Computing? Setting up your project in the cloud has some advantages: First of all, the setup itself is comparably easy, as the cloud servers are managed by another organization. This also means that you do not need to worry about scalability of your servers or data loss, i.e. the need for redundancy, reducing overall downtimes. Additionally, cloud systems also are well tested, automatically updated and often encryption mechanisms are provided natively. This eases up on administration.  Generally, you can use the cloud rather quickly without worrying about lengthy and error-prone setup tasks. Using servers also centralizes the logic: clients will just call a unified interface (e.g. Web/REST).

 

A typical IoT-setup would often be centralized and look like this today:

 

Advantages of running your application on the edge 🗡️

 

Running an application on the edge, e.g. your Android phone, a Smart Home Server, or in the car, has a couple of advantages:

  • The application works everywhere, all of the time (offline / online)
  • Great supersmooth User Experience (UX) as the app can respond in (near) realtime
  • Data stays where it was produced and belongs, the user maintains data ownership
  • Cloud / Connectivity costs go way down

 

 Some tangible use cases for edge computing: 

  • Many Mobile Games run on the edge. As a game developer you really want your users to be able to engage with the game whenever they feel like it and have the time. And as a gamer, you may well want to play when offline, for example when commuting on the underground. Also, gamers really care about the user experience with very smooth animations and high-fidelity visuals.
  • Autonomous driving as well as any human safety application needs to work independent from an Internet connection and in realtime. Imagine crashing because the car was trying to connect to the cloud or still waiting for the database to respond.
  • Smart home or smart health applications should work even when there is no connection, but moreover: Why should you personal health data leave your private space? You probably would want to own that data and keep it safe in the local environment. That way it is much less likely that s.o. will try to hack your individual data versus millions of centrally stored data.
  • Predictive maintenance apps usually need to process tons of data or high-fidelity data like video streams. Transferring all this data to the cloud usually means such high cloud costs that the project becomes unprofitable. Therefore, they usually are run on the edge and only aggregated data transferred to a central server.
  • In Industry 4.0 / smart factory / Industrial IoT (IIoT) settings you often lack connectivity, so applications need to run on the edge.

Is the edge eating the cloud? 🍴

Unlikely. Often you want some data accessible from anywhere. Synchronizing parts of the data to the cloud (or an on-premise central server) allows you to combine many of the advantages from edge and cloud computing. Thus, the edge is a natural extension of the cloud that makes applications all the more powerful. We believe that future scenarios will often look like this:

 

 

 

This line of reasoning is supported by the fact that all major cloud companies, e.g. Amazon, Google, Microsoft, are pursuing an edge strategy. 

 

Why should Android developers care about Edge Computing? 🚀

Edge computing and improved speed for Android, Android libraries and related products for developers were two clear sub-themes at the 2019 I/O conference – obviously low latency is a major competitive advantage.

Here is why designing your app to run on the edge will help you be successful on the Play Store: There are roughly 2.1 mill. Android Apps to choose from today in the Play Store. To stand a chance in that market you need to delight your users and get good app store ratings. Edge Computing delivers on the app traits users care about most: performance, security, and availability.

 

Users care about performance – a lot 💨

Whenever an app responds to a query directly instead of taking a round-trip to the cloud and back, it should be faster. More importantly, you can measure and optimize more reliably, as the latency is independent from the network connection. This enables the fast high-quality digital experience consumers want.

  • Reliable performance was found to be the second most important trait for app users in a study by PacketZoom.
  • Most mobile users, namely 96%, say app performance, such as speed and responsiveness, is important for them.
  • A study by appdynamics found that more than eight out of ten respondents had deleted or uninstalled at least one mobile app because of performance issues.
  • The same study found that 44% of respondents closed the app when experiencing poor network performance, but even worse: 32% even uninstall the app altogether. They also found, the reverse is true for fast performing and reliable apps with usage increasing.
As an Android developer you also know that many consumers cannot or do not care, why an app is not working. If the application is not working or just responding very slowly, users are dissatisified and annoyed. Therefore, as the developer you need to make sure your app always performs well.

“When your app depends on a network, latency is out of your control.”

Now, you might need to query data from the network. That’s fine; if most of your app is running independent from a connection, there are tons of ways to optimize user experience for connectivity loss and network latency.

 

 

Security is a hot topic and can be a USP 🛡️

Users care about security, and this is a trend that will – in the face of the loss of huge amounts of personal data by tech giants – only continue to grow. When you leave data at the edge, on the device of the user, data security is much easier to provide. On top, data ownership is clear, easing up on data privacy.

 

Data is much more secure stored in one place  than when transferred over the network – possibly again and again and again. Android provides a good basis for keeping internally stored data safe. If data security and privacy are important for you, your app, or your users, think about keeping data locally and then only synchronizing data you really need accessible from anywhere. Last not least, while an individual phone may be hacked, it is less likely to occur and only an individual dataset is compromised (as opposed to millions of datasets).

 

 

Offline first – deliver an always-on-feeling 🔌

Users do not care about connectivity, they simply want to use the application when they want to – at home, in a department store, in a train, on a flight, on vacation. And when they can’t access an app, their user experience is bad. Even today in a highly connected world, there are lots of times where people have no connectivity or need to switch data off to save battery. The app that supports them in these times ;), is the one they will love and use

The most important advantage of doing an offline-first app is the availability of the app. Google translate is a great example of an app that you want to be offline-capable. Chances are that when you need it most you are in a place where you do not have a (affordable) connection. But you might also appreciate being able to read and search through your mails when you are on a plane too. Or type WhatsApp messages that go out when connected again, or just enjoy a round of Subway Surfers.

Offline-first apps make it possible to move content off the server and onto the phone. If an app only has to go to the server when it needs to, rather than all the time, it will be faster and more reliable. This is particularly significant where content doesn’t change often, but users require fast access.

The improvements in Android Q to Android’s Neural Networks API (NNAPI) and the size reduction of the model means Android phones are Edge AI ready and open tons of new possibilities for fast apps running on the edge.

With the recent changes in the Play Store rating, boosting the technical performance of your app will have an even greater impact than before.

But what about 5G?

First of all the 5G rollouts and uptake still will take some time, but if you are reading this you are building a business now. Secondly, while it will bring a faster network connection to many areas, there are caveats to a central cloud-based application that won’t change:

  1. When you are mobile, at some point you will be offline or your connection flaky.
  2. Storing and transferring data to the cloud is costly.
  3. Storing and transferring data unnecessarily to the cloud is wasteful.
  4. Storing data centrally yields higher security risks for your user’s data; transferring data is an additional security risk. Any data you can just keep locally is safest.
  5. If you leave the data with the user, data ownership is clear and you do not need to worry about privacy.

How do I bring my Android app to the edge?🏃

As an Android developer, chances are, you are already doing Edge Computing in many of the apps you are developing.

First of all, offline-first does not work with typical web pages. Usually, you would go for a native app, or alternatively, a progressive web app (PWA) or similar technology. Apart from multiple UX benefits and speed, most users prefer native apps and users still spend 80% of their mobile usage time in apps.

Secondly, for an offline-first architecture you need a local storage as a primary source of data, e.g. a database. Changes to data are made in this layer. Application also can and usually do have networking components to synchronize data to a server. However, this connection to the backend is mainly used in the background to synchronize the local database.

So, why does not everybody do it all the time? Well, there are use cases where it does not make sense to go the extra mile for the limited functionality that edge computing would bring, e.g. in a parking app. Obviously, most relevant data points like your car and the availability of parking spots are changing all the time. So, you really are dependent upon a constant connection, or rather several constant connections: From the spots to the cloud and from the cloud to the app. However, there is another reason: Offline-capable apps are hard. That is why we developed ObjectBox Sync.

 

Does any app need to run at the edge? ⚖️

As always, there are some cases where the cloud makes perfect sense, indeed is the only option – and the same is true for the edge. You need to assess what you want to achieve and where the value lies for your application and users.

Sustainable Computing: Why the edge is saving the world 🦸

If you do not need to push all the data to the cloud, where large chunks of it might not even be used, you might want to take a step back and consider the broader picture: What do all these billions of mobile and IoT devices (that are quite capable) do while they wait for the cloud to respond? Nothing.
Sending data to the cloud unnecessarily is wasteful in two respects: Use of bandwidth and server capacity (which comes down to infrastructure, electricity and physical space) and the big waste of underused resources.

What is Edge Computing?

What is Edge Computing?

Today, over 90 percent of enterprise data is sent to the cloud. In the next years, this number will drop to just 25 percent according to Gartner. The rest of the data is not going anywhere. It is being stored and used locally, on the device it was created on – cars, trains, phones, cameras etc. This is edge computing. At least in our pragmatic definition.

Obviously, this is cutting the discussion short. With edge consortia springing up like mushrooms, there is no lack of overlapping definitions around the terms Edge Computing and Fog Computing.

 

From mist to fog to edge – a short overview 

To bring some light into the terminology mess: The terms “mist” and “cloud” constitute the ends of a continuum.In our definition, the edge covers everything from cloud to any end device, however tiny and limited it may be. In this definition, there really is only the cloud and the edge.

However, some authors additionally use the terms fog computing and mist computing.

Mist covers the computing area that takes place on really tiny, distributed, and outspread devices, e.g. humidity or temperature sensors. To make it a bit more tangible: These devices generally are too small to run an operating system locally. They just generate data and send that data to the network.

As opposed to mist computing, the cloud refers to huge centralized data centers. The terms “fog” and “edge” fall within this continuum and – depending on whose definition you follow – can be used interchangeably.

Form edge to cloud and back: History repeating itself

If these terms seem familiar to you, that is probably because edge computing is just another cycle in a series of computing developments. Computing has seen constant turns between centralized and distributed computing over the decades, and with recent developments in hardware capacity, we’re again entering into a decentralized cycle.

 

One to rule them all?

Neither the cloud nor the edge is a solution for all cases. As always it depends. There are cases, where the edge makes more sense than the cloud and vice versa. Most cases however, do need both.

 

Read why Android developers should care about Edge Computing.

 

Which edge consortia are there?

Which edge consortia are there?

There is no lack of consortia defining terms around edge computing – it’s a lot like the Judean People’s Front against the People’s Front of Judea. After a year of battle, the most prominent edge consortium emerging currently seem to be EdgeX under the umbrella of the Linux Foundation – fully open source, while also largely supported and driven by Dell, who initiated it. Other notable players trying to get a foothold in this space is the Deutsche Telekom with MobiledgeX and HPE with Edge Worx. A European counterpart, ECCE, formed in spring 2019 and might be worthwhile watching, as it is supported by many industry players like e.g. KUKA, Intel, and Huawei.

ObjectBox on Azure Sphere: Efficient IoT data persistence

ObjectBox on Azure Sphere: Efficient IoT data persistence

Listening to our IoT users, we implemented ObjectBox support for Microsoft’s Azure Sphere. With this extension, you can use ObjectBox on tiny devices now. But let us explain a bit more…

What is Edge computing?

Centralized computing entails a central computer storing and processing all data with multiple machines (clients) accessing it. Decentralized computing has no central instance and data is stored and processed on the machine it is used on. The currently predominant computing paradigm, namely cloud computing, is centralized.

The Internet of Things (IoT) is pushing the industry once again towards a distributed computing paradigm. In this context it is called Edge computing. Edge Computing aims to store and process data on end devices (so called edge devices or nodes) like smartphones, routers, and the IoT end devices. We view Edge Computing as an extension of the cloud, adding value and functionality on the edge of the network. 

Note: Fog Computing and Edge Computing definitions vary and overlap widely. This is just the definition we use.

What is the Azure Sphere?

The Azure Sphere is foremost an operating system for “small chips”, or more exactly, Internet-connected microcontroller units (MCUs). It was developed by Microsoft for Internet of Things (IoT) applications and comes with integrated cloud security services. As of today, it runs on a MT3620 MCU produced by MediaTek in collaboration with Microsoft.

Microsoft Azure, Microsoft’s cloud solution is closely related to the Azure Sphere. Security and user management, configuration and deployment can be analyzed and modified using that web interface.

ObjectBox on Azure Sphere 

There were a couple of reasons why we at ObjectBox support Azure Sphere:

Furthermore, we looked at the lifetime costs: Firstly, we chose Azure Sphere, because it can save maintenance costs. Secondly, because there is one unified interface to the platform, the platform itself may be used for any task imaginable (e.g. facility management, real time inventory, etc.). Thirdly, Microsoft’s security solution provides Over-the-air (OTA) updates. Therefore, it takes care of keeping the operating system up to date for you.

Azure Sphere use cases

These use cases exemplify a key consequence of using the Internet of Things in everyday devices: they may not only read and analyze sensor data, but also control the machine they are attached to, even autonomously. In connection with intelligent algorithms, these devices are able to make far-reaching decisions and thus maximize overall efficiency.

Benefits of ObjectBox on Azure Sphere

ObjectBox can greatly simplify the process of data collection, transmission, and processing. Let’s now see how ObjectBox is able to solve common problems encountered when integrating IoT into any kind of environment.

Let’s now see how ObjectBox is able to solve common problems encountered when integrating IoT into any kind of environment.

Scalability, i.e. integrating new devices into a fleet of existing ones, can be challenging because of the gigantic amount of data it generates and that must be transferred to a high-level entity. ObjectBox’s speed advantage provides a solution to this. Confirmed by 3rd party reviewers, ObjectBox outperforms alternatives in all areas. Thus, it offers higher rates for data transmission, storage and retrieval.

ObjectBox is created from developers for developers. Because ObjectBox’s programming interfaces are exceptionally easy to use, development time can be minimized and first prototypes can be delivered after a very short time.

Additionally, it is necessary to make sure data is always up-to-date and prevent unintentionally storing redundant or meaningless data. Our synchronization feature, coming up soon, will solve that out-of-the-box for you.

Find the full technical description and download on GitHub.

Let us know what you think

Last not least, we are always happy to hear from you. Post any questions you may have on stack overflow tagged ObjectBox. Please share your thoughts on ObjectBox on Azure Sphere with us via Twitter, Facebook, or Mail (contact [at] objectbox . io).

What are the benefits of Edge Computing?

What are the benefits of Edge Computing?

The benefits of edge computing stem directly from the underlying paradigm: Edge Computing is a decentralized computing architecture as opposed to a centralized/cloud computing model. 

 

Benefits of Edge Computing put simply

  • Data ownership / privacy: Data can stay where it belongs – and is produced and used (on the edge devices)
  • Security: Data on edge devices that is not transferred to the cloud is much more difficult to hack
  • Cloud costs: Cloud data volumes and costs can be significantly reduced
  • Rate of data transfer: Less need for bandwidth
  • Speed: Processing on the device instead of sending to the cloud and waiting for an answer is way faster (latency)
  • Offline-capability: Edge devices can operate independent from a network / cloud connection
  • Real-time communication on the edge: Edge devices can communicate between each other directly, which can be done much faster due to the short distances and also more efficient as the power and information of several devices can be combined (for more info see: ultra low latency networks, peer-2-peer, M2M actions)