-
Notifications
You must be signed in to change notification settings - Fork 16
Use cases
For the current implementation (all nodes with the same content)
These are cases in which the devices must access (read and/or write) data even when they are off-line.
Using biometry or cards (for people) or wireless and image recognition (for vehicles)
Having on the db (AergoLite):
- The allowed people / vehicles
- Records of their entrances and exits
It is a good example of an application in which the devices should work even when off-line. If the connectivity between then is down they can still access the table of allowed people or vehicles and record new accesses locally. When the connectivity is reestablished the node will synchronize its local database with its peers, all following node authorization with private key signing of transactions and consensus between the nodes on the final state of the database.
Good for schools, universities, organizations, public and private institutions. All that use more than one device for the access control.
This also includes access control on events/shows that take place far from the city. AergoLite could also be used on handheld devices used for reading tickets or bracelets.
The points-of-sale can continue operating (recording sales) even when the network connection drops. They already have all the data for reading (products, promotions...) and can write the new sales to the local database. When the connection is reestablished the local sales are sent to the network and included in the distributed database.
There is no single point-of-failure when using AergoLite on supermarkets. Each node can continue operating at least for a few hours or as long as the products table is not updated on the network.
Those robots at Amazon and similar logistics companies cannot stop, so instead of a central brain they could use a distributed db on each robot.
The trucks, people and robots making delivery can be out of reach of connectivity but still require to store information about which products were delivered.
Harvesters tracking information about themselves can share a common database and communicate just locally in the field (LoRa, WiFi, RF) without a central server.
Automated robots in agriculture can use the same.
Generally with weak internet connectivity.
Databases on ships and airplanes that must be synchronized to a central system for data analytics and reporting.
Drones making work on the field can synchronize their data between themselves instead of a central server.
Those who accept cash and coins can work off-line. The collected data can be shared between themselves and them synchronized to a central db for reports.
Applications on mobile apps that should work even when off-line and require synchronization of data between them, but just for a private group of allowed users/devices.
Distributed systems with support for relational data could be easily created with AergoLite
Either native or web dApps.
Always measuring, even when off-line. Then they need to share its measurements with the company.
They must work even when off-line, and they must track how much energy was served.
Must work when off-line. The data can be collected on the company for analytics.
Search more cases for:
- Energy
- Food
- Health
- Transportation (cars, trucks, buses, trains, ships, robots - autonomous or not)
- Logistics and delivery
- Supply chain
- Security
- Education
- Industry (automation)
- Mobile Apps
If the devices have a requirement to only work if they are on-line then AergoLite may not be needed.
In these cases the devices can communicate with a private Aergo network in a client/server way. They can even use the public Aergo network.