Advos is a REST service layer. All roles enforcement, authentication and business rules are carried out in the service. Advos is built on elastic cloud servers. It is built using a Big Table No-SQL backend, a JDO data abstraction layer and employs Spring to provide the service endpoints. The admin console, customer gateways and mobile apps are all clients of the service layer.
The System Setup app is a mobile application that allows you to setup and configure zones for each store front. With the System Setup app you can associate Smart Tags and Smarts Zones to a site, adjust the tuning from 0 to 150 feet and test the whole system. You can download the System Setup on Google Play and the Apple App Store.
Advos also provides a number of triggers that will notify external systems of events as they occur. The SDK’s provide a callback on every major action. You can use these callbacks to display information to the user in your app code. In the service, a client can set up objects called Signals. Signals are created at the organizational level and modified by the zone objects in the Advos system. A Signal represents a call to an external system and holds all the information needed to connect to that system. When a system event occurs in Advos we cycle through the applicable Signals and a call is made to each according to the information contained in the Signal object. We have some standard signals that can be configured easily, and we also support a custom signal construct, allowing Advos to connect with a clients internal systems.
To learn more about the SDK package, contact us today.
Due to the large amount of data processing needs for an enterprise, it is critical that Advos is able to scale for any situation. We have designed the Advos system with the best available elastic cloud systems to ensure we can grow along with the data needs of your business. We continually monitor our system for load and performance to ensure we can provide you with optimal performance at all times.
Extreme Data Example
Imagine a system which tracks temperature of coolers in a grocery store. There are 50 coolers in each store, and the company has 600 stores nationwide. The cooler needs a temperature reading every 15 mins in order to detect problems. Monitoring these coolers 24/7 would mean sampling cooler temperatures 4,800 times per store per day. That creates over 2.8 Million recorded data points across the company every day. If you were to record this information for a year it would account for over a billion data points annually.
We only build with careful consideration of customers scale needs and performance, which is why we have attained 100% uptime since our launch. Our development team continually monitors and performs load tests on the system to ensure its future scalability. Here is a sample from our latest load testing effort:
In the next few years we will see an explosion of IoT devices that share and store data. This technology is only beginning to take shape and is constantly changing. In order to handle this rapidly changing landscape, an IoT solution must be flexible. Advos is designed around concepts of what IoT will do, and not specific to only one set of technology solution.
The problem with many IoT solutions is that they are tied to only one type of location coordinate. Advos defines the physical boundaries of a zone by one or many location coordinates. These can represent a Beacon ID, GPS, WiFi triangulation, or any other location-based reading. This means that when a new technology becomes available, Advos will have the compatibility to work with it. We can simply switch to the new technology and all historical data is maintained.
Advos defines a device as a machine which senses and records environmental conditions and/or carries out instructions. The device can be owned by an organization, site, zone, or user. Thus as machines evolve, they will still be able to communicate with the Advos platform.
IBeacons are a bluetooth device that can be used to mark a location in space and tie it to a database object representing that space. They are just one of a number of possible ways you could define an area in space. You could also use GPS coordinates, triangulate on WiFi signals or a number of other solutions. IBeacons are the most viable solution at this time but this may and probably will change.
An extensible platform needs the ability to communicate to the other systems already in place at your company. The system must also have the ability to trigger an action for your service needs. We support cross-system communications with Advos through API Access and System Event Triggers.
When you sign up with Advos, we generate an API access key that will give your Dev teams access to all information at any given time. Advos is a number of Restful Web services, meaning that all of the data Advos maintains for you can be accessed over a common HTTP protocol.
We also set up system events to send information to your internal systems. The concept of signals in Advos allows you to define what information you would like sent and the system information required to send the information. Thus, when a system event happens inside the Advos Platform, we use the configurations stored in the signal object to notify your systems of the event. This provides you with a convenient trigger to act on.
Machine to Machine (M2M) interaction is the ability for one machine to respond to the conditions detected by another. Advos supports M2M communication through a construct we call Instructions. An Instruction is a configurable object that contains a set of commands. When a certain condition is met in one device it will create an Instruction object. The second device will call the server to fetch any instructions that exist. It will then receive the initial Instruction object from the first device. The second device will know what action to take with the communicated instructions.
Imagine if your lights could respond to the your actions. You could unlock your front door, and the lights in the entryway would come on automatically. When the door is unlocked, it creates and sends an Instruction Object in the server. The light bulb in the entryway checks the server for any applicable instructions. The light bulb receives the instructions by the door lock, and is triggered to turn on.