Today, over 90 percent of enterprise data is sent to the cloud. In the next years, this number will drop to just 25 percentaccording 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 – e.g. cars, trains, phones, machines, cameras. This is Edge Computing – and since the Corona outbreak it is more relevant than ever. Edge Computing is a topology rather than technology and spans devices as well as industries.
The benefits of edge computing stem from its underlying paradigm: Edge Computing is a decentralized computing architecture as opposed to a centralized computing model (today typically cloud computing).
Data ownership / privacy: With Edge Computing data can stay where it is produced, used and where it belongs (with the user / on the edge devices)
Networking costs / Cloud costs: Reducing data transferrals and central storage reduces networking and cloud costs significantly
Bandwidth constrains: Bandwidth is limited and the data volumes are growing much faster than the bandwidth can be expanded (e.g. with 5G networks); it therefore puts a hard stop on many applications that can be overcome by building on the edge
Application / Data speed: Processing on the device – instead of sending data to the cloud and waiting for an answer – is way faster (latency)
Offline-capability: With Edge Computing, devices operate independent from a network / cloud connection, so the application always works and data parts that are needed centrally can be synced when convenient, needed, connected
The decentralized edge: Edge devices can communicate between each other directly. This decentralized Edge Computing approach more efficient (usually translating to speed) due to the short distances and because the power and information of several devices can be combined (for more info see: ultra low latency networks, peer-2-peer, M2M actions). On top, it adds resilience.
Security: A central instance with millions of data is more attractive to hack; also the data transferral adds an additional vulnaribility.
From mist to fog to edge to cloud – a short overview
To bring some light into the terminology mess: The terms “mist computing” and “cloud computing” 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.
From 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.
Edge Computing has been around for 20 years, see a quick history here:
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.
Edge computing allows data to be stored and used on local devices. Integrating Edge Computing directly within electric vehicle charging infrastructure improves station usability and also allows for real-time energy management.
Car charging and electric vehicles
The era of electric vehicles (EV) is coming: Already one in every 250¹ cars on the road is electric. While it is uncertain when electric vehicles will overtake traditional combustion engine vehicles, electric is clearly the future. Car charging infrastructure is critical for electric vehicle expansion – and one of the largest bottlenecks to EV adoption. Range anxiety is still one of the primary concerns for potential EV customers,² and charging station proliferation is still far behind traditional gas stations.
State of the electric vehicle charging Market
The electric vehicle charging infrastructure market is still very divided, with many players vying for this large-growth sector – some predictions forecast over 40% CAGR for the car charging infrastructure market in the coming years.³ Car manufacturers, gas & oil, OEMs, and utilities companies (e.g. Tesla, VW, BMW, Shell, GE, Engie, Siemens, ABB) are actively taking part in the development of the market, recognizing the need to support future EV customers and the huge growth potential. Startups in the space like EcoG, Wirelane, flexEcharge and Elli offer solutions that focus on accessibility, efficiency and improving end user experiences.
Why Car Charging Stations need Offline Capability (Edge Computing)
First, let’s look at the challenges a vehicle charging provider needs to solve from a basic data perspective: Customers interfacing with charging stations require an account linked with basic information and payment methods. In order to charge a car, the user needs to be verified by the charging station, and is often required to have a pre-booked charging slot. Typically, a user would create a new account via a website or mobile phone beforehand, but not on the spot at the car charging station. Also booking slots are handled via a mobile app or website. However, the car charging station needs this information to allow a car to be charged.
This is only the most basic necessity. In the future, charging stations will provide more services to users, e.g. identifying users preference like cost over speed of charging, or choosing to charge with green energy.
Depending on where the car charging station sits, it can be offline more or less often, e.g. in France there are quite many electric car charging stations in the country site, where the connection is typically flaky – and might not be available for days. On the other hand, there are stations that reside within a parking house or hotel and use a fixed land line for connectivity. In the latter case, your uptime can be very consistent, but typically you cannot guarantee the car charging station will be connected.
If the charging station tries to access this data only when it needs it, because a car is trying to charge, it may or may not have an internet connection at the time and thus the likelihood of failure is rather high. Accordingly, any new information should be pushed to the car charging stations when a connection is available and stored on the station. The hardware of a car charging station is capable enough to hold a lightweight database and persist data as is needed and useful.
Choosing a data persistence layer (database) over a simple caching ensures not only that no data is lost, but can also allow more processing to happen on the station and allows for autonomous reactions. In combination with edge synchronization, which enables persistence layers to synchronize between car charging stations (that share a data space), fast data persistence allows for efficient load balancing as well as easily updating the configurations of all car charging stations.
Smart Energy Load Management – the need for fast response on the Edge
Managing energy is one of the greatest challenges for EV infrastructure providers. The difficulty here is less about overall energy consumption increasing – rather managing, predicting and preparing for high-demand peaks. Imagine everyone needs charging during a large public event, or at charging stations during holiday travel times – peak demands like these need to be anticipated and planned for. The future with electric cars needs to balance demand with a combination of smart chargers, efficient energy grid management, Vehicle-to-Grid (V2G) solutions, and perhaps even on-site batteries at larger charging stations to improve time-to-charge and optimize for electricity prices.
Edge computing will play an important role in providing real-time, accurate energy load control, necessary for maintaining grid stability, particularly in emergency situations.⁴ At charging stations where many EVs plug in, smart edge nodes can balance charge schedules in real-time, optimizing based on EV owner requirements without overloading local transformers.⁵ On a larger scale, smart energy meters can use real-time edge computing to shift energy quickly to high-demand locations, cutting energy from low-priority appliances, limiting charge speeds, or pulling excess energy from V2G networks.
Thinking about energy management, the conversation fluidly moves from EV charging infrastructure to thinking about smart mobility, utilities, and smart city infrastructure on a larger scale. Car charging systems will be complex, interconnected and will progress in alignment with other ongoing digitization efforts to create data drive infrastructure across cities and the world. Edge computing, and base technologies like ObjectBox that enable working on the edge, are important enablers to ensure that real-time computing can happen anywhere and digitization is affordable, scalable, and sustainable.
With EdgeX Foundry just reaching v1.1, we continue to provide ObjectBox as an embedded high-performance database backend so you can start using ObjectBox EdgeX v1.1 right away. If you need data reliability and high-speed database operations, ObjectBox is for you. Additionally, starting with ObjectBox EdgeX 1.1, you can use it on 32-bit ARM devices.
Combining the speed and size advantages of ObjectBox on the EdgeX platform, we empower companies to analyze more data locally on the machine, enabling new use cases.
With ObjectBox-backed EdgeX we’re bringing the efficiency, performance and small footprint of the ObjectBox database to all EdgeX applications. It is fully compatible, so you can use it as a drop-in replacement: you call against the same REST and Go EdgeX APIs. As simple as that;no need to change any code.
Performance comparison of EdgeX database backends
EdgeX Foundry comes with a choice of two database engines: MongoDB and Redis. ObjectBox EdgeX brings an alternative to Redis and MongoDB to the table. Because ObjectBox is an embedded database, optimized for high speed and ease of use while also delivering data reliability, it enables a new set of use cases. As we all know, benchmarks are hard to do. This is why all our benchmarks are open source and we invite you to check them out for yourself. To give you a quick impression of how you could benefit from using ObjectBox, let’s have a look at how each compares in basic database operations on “Device Readings”, one of the most performance intensive data points.
Note: The Read and Write operations (all CRUD (Create, Read, Update, Delete) operations are measured in objects / second). The benchmarks test internal EdgeX database layer performance, not the REST APIs throughput.
These benchmarks provide a good perspective why you should consider ObjectBox with EdgeX. Benchmark sources are available publicly in ObjectBox EdgeX github repo.
So, why is ObjectBox EdgeX faster?
First of all, you are probably aware of the phrase “Lies, damned lies, and statistics benchmarks”. Of course, you should look at performance for yourself and consider based on your specific use case needs. That’s why we make our benchmarks available as open source. It is a good starting point.
To make it easier to compare ObjectBox (in addition to our open source benchmarks) here are some of the high-level “unfair advantages” that make ObjectBox fast:
Objects: As you can derive from its name, ObjectBox is all about for objects. It’s highly optimized for persisting objects. The EdgeX architecture and Go sources are a great fit here as it puts Go’s objects (structs) in the center of its interface. This means, we can omit costly transformations and this helps with speed.
Embedded database: Redis and MongoDB are client/server databases running in separate processes. ObjectBox, however, is running in the same process as EdgeX itself (each EdgeX microservice, to be precise). This has definite efficiency advantages, but it also comes with some restrictions: Whereas you can put Redis/MongoDB in separate Dockers or machines, this option is not available for ObjectBox yet.
Transaction merging: ObjectBox can execute individual write operations in a common database transaction. This means, we can reduce the costly transactions for a number of write operations. This is a great way to add on performance, delaying the transaction end by single digit milliseconds.
Get started with ObjectBox EdgeX
The simplest way to get started is to fetch the latest docker-compose.yml and start the containers:
1
wget https://raw.githubusercontent.com/objectbox/edgex-objectbox/fuji/bin/docker-compose.ymldocker-compose up -d
You can check the status of your running services by going to http://localhost:8500/. At this point, you have the REST services running at their respective ports, available to access from your EdgeX applications.
If you’re new to EdgeX, find out all about the open source IoT Edge Platform here. The EdgeX project is led by the Linux Foundation and supported by many industry players, including Dell, IBM, and Fujitsu.
We love to hear from you ?
We’re very interested to hear about the challenges you are facing on the edge and in IoT. As performance experts, we are always embracing a tough challenge. Reach out to us to set up a pilot project.
Is there something you are missing? Please do reach out to us. We want to make ObjectBox the best edge data persistence layer available. We love to receive your feedback.
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 an 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. In the following we are sharing the project details and accomonying benchmarks.
A solution for the railway industry
Kapsch is a longtime partner of railway operators 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
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 several 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 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 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
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 layer
NoSQL database with abstraction layer
SQL database without abstraction layer
NoSQL 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 projectclearly 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.
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.
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.
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:
Edge Computing needs to work within an ecosystem from very small to medium sized devices in order to be scalable.
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
E.ON, one of Europe’s leading energy companies, started a cooperation with Microsoft for designing a Home Energy Management system based on Azure Sphere devices.
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 will solve that out-of-the-box for you.
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).
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.Ok
