The Internet evolution has achieved the level when it is simply here for us at all times. We don’t even think of how we connect to a network, nor analyze the connection technical details, as well as we don’t care about who our communications service provider is. All-round Wi-Fi penetration and gradual IPv6 extension enable thousands of simple devices and trackers to interoperate continuously and send data “to the cloud”. Fast infrastructure advancement resulted in substituting the older Machine-to-Machine (M2M) term for more up-to-date Internet of Things (IoT) one.
Building up sort of distributed intelligence, IoT devices yet need centralized management, a system or service able to fine-tune the devices, provide storage and interpret collected data. Being the “brain” of the device cloud infrastructure, the management system also enlarges machine knowledge bases and updates device software.
Operators study data aggregated by groups or time periods and visualize it. This data is then delivered to various Business Intelligence Systems for more detailed analysis. Curiously enough, even if we speak about personal devices (e.g. fitness trackers), almost every cloud service operator analyses the collected data usage statistics anonymously for further device/service development.
Development of IoT devices becomes simpler and cheaper enabling small companies to enter the market. Plenty of businesses realize the need of building a management system, but they underestimate its development complexity and ignore the need of using industrial server technologies (such as failover clustering and multi-server distributed architecture). Typically, such a development starts in house. IoT devices successfully introduced in the market lead to rapid growth of users, causing long-term problems with service scaling and performance.
Anticipating further problems and being unable to form a server-based software development team quickly, IoT operators usually outsource the central system development focusing on devices only. Yet, it doesn’t solve the problem as third-party developers start building the system from scratch with lack of time and resources to apply serious technologies.
AggreGate Platform was born in 2002. At that time we were producing serial-over-IP converters and needed a central server that would transmit data between converters hidden by firewalls or NAT and having no chance to communicate directly. The first product version called LinkServer was written in C++ and was available only as a service simply transmitting data flows without any processing.
Short while later our converters developed into freely programmable controllers. They “understood” data flowing through them, thus we wanted the central server to do the same thing. At about the same time we realized that 90% of time spent for developing a monitoring and device management system was reinventing the wheel with very little effort put into solving certain business problems.
Since 2004 the system ported on Java has evolved as a framework for device management. For quite a few years we worked without clear understanding of the result we want to achieve. Fortunately, we have avoided work with a single customer or in a single industry by keeping our system flexible.
Now AggreGate Platform is applied to a great variety of industries, including Remote Monitoring and Service, IT Infrastructure and Network Monitoring, SCADA/HMI and Process Automation, Access Control, Building Automation, Fleet Management, Vending Machine and Self-service Kiosk Management, Sensor Network Monitoring, People and Vehicle Counting, Centralized Event and Incident Management, Digital Signage and Mobile Device Management.
Major Platform Tasks
Figuratively speaking, AggreGate is a LEGO constructor for prompt device cloud interface development. Allowing IoT solution architects to focus mainly on hardware and business logic, it solves the following infrastructure tasks:
- Maintaining communication between servers and devices connected via unreliable cellular and satellite links
- Unified approach to device data regardless of its physical meaning
- Storing large volumes of collected events and historical data in various databases (relational, round-robin, NoSQL)
- Visual building of complex source data analysis and event correlation chains
- Modeling multiple device data integration and all infrastructure KPIs calculation processes
- Fast operator and system engineer interface building using out-of-the-box “bricks” without any coding
- Implementing integration scenarios via ready-to-use universal connectors (SQL, HTTP/HTTPS, SOAP, CORBA, SNMP, etc.)
System Unification
Being universal, AggreGate Platform unites various monitoring and management systems. It helps avoid extra integration points and decreases the number of integration scenarios. For example, the integrated monitoring system has a single integration point with Service Desk/ITSM/Maintenance Management systems for incident (alert) delivery. It also integrates with Inventory/Asset Management systems for collecting information on available physical assets and their influence on business services.
In such cases, role-based access control provides various departments with customized system scenarios and unique operator interfaces.
Platform Architecture
The Platform includes the following essential components:
- Server is a Java-based application providing communication with devices, data storage and its automated processing. Servers can group into clusters for high availability and keep peer-to-peer relations in distributed installations. AggreGate Server manages an embedded web server which in its turn supports web interfaces.
- Unified Console is a crossplatform desktop client software ensuring simultaneous work with one or several servers in administrator, system engineer or operator mode.
- Agent is a library that can be integrated into an IoT device firmware to ensure communication with servers, device setup unification, performing operations with a device and asynchronous event sending. There are a lot of libraries (Java, .NET, C/C++, Android Java, etc.). No need to deploy an agent if communications with the server are performed using standard or proprietary protocols. In the latter case a separate device driver is developed for the server. The agent can be also implemented as a separate hardware device (gateway).
- Open-source API for extending functionality of all other components and implementing complex integration scenarios.
The Server supervises device data reading and writing changes. This process is called bidirectional synchronization. The server creates a device snapshot containing last values of device metrics and changes carried out by operators or system modules and not written to a device due to communication downtime. Configuration changes are delivered to devices on the “best effort” basis enabling to configure device groups, even if some devices are offline.
The Server also provides receiving and processing incoming device connections that have no white static IP addresses.
Device data and events merge into a unified data model. Within this model, each device is represented as a so-called context in a hierarchical context structure. Each context includes a set of formalized data elements of three types: variables (properties, settings, attributes), functions (methods, operations), and events (notifications). A context also contains metadata describing all available elements. Therefore, all context data and metadata are entirely stored in the current context. This technology is called device normalization. Device drivers and agents create a normalized presentation of various device types.
There are some parallels with object-oriented programming, where objects typically have properties, events and methods. Properties are internal device variables, methods are operations performed by a device, and events describe how a device notifies the server of internal data or environment changes.
Virtually any device can be described as a set of properties, methods and events. For example, a remotely controlled water tank can have a “water level” property to show the current amount of water in the tank and “turn valve on/off” methods to control the valve letting the water into/out of the tank. This smart water tank may also generate a number of notifications, such as “nearly empty”, “nearly full” and “overflow”. We have developed more than 100 Java-based drivers, and the normalization concept has also proved to be an advantage. Moreover, a lot of current “universal” protocols (such as OPC UA, JMX or WMI) use similar data models.
All Server contexts are a part of a hierarchical structure called context tree. Though the contexts match diverse objects (devices, users, reports, alerts, etc.), they have a unified interface and can interoperate within the server context tree, offering a high level of flexibility. The same principle enables various servers to interact in a distributed installation.
Every connected device allows operators to perform direct configuration (device configuration reading and modification), direct management (forcing device operation performance manually), and direct monitoring (viewing the device event log in near-real-time mode).
Events and changes of device metric values are stored in the server storage. Depending on the system task, the storage type can vary. For example, if it’s the Raspberry Pi microserver, the simplest file storage is used, while the central server of a distributed installation can use NoSQL-based Apache Cassandra cluster storing dozens of thousands events per second out of original stream with hundreds of thousands events per second.
However, in most cases a regular relational database is used as storage. Using ORM layer (Hibernate) provides compatibility with MySQL, Oracle, Microsoft SQL Server, PostgreSQL, and other DBMS.
Device data and events affect the life cycle of active server objects allowing the server to react to environmental condition changes. These active objects include:
- Alerts converting a particular seamless object state or event chain to a new event type called incident
- Models converting source events and values into user-defined events and value types by using business rules
- Scheduler assuring task performance on schedule even when the server is shut off
- Sensors and several other object types
Active objects are able to add new types of variables, functions and events in the unified data model, send custom variables and event changes to storage, and invoke device and other object operations in automated mode.
You can use widgets for building data entry forms, tables, dynamic maps, charts and HMIs. They can be combined in dashboards, both global (based on aggregated KPIs and showing the whole infrastructure state) and object-oriented (displaying a single device or infrastructure component state).
Widgets and report templates are built in specialized visual editors seamlessly integrated in the Aggregate Platform ecosystem. The GUI Builder helps design complex interfaces consisting of multiple nested containers with visual components. In addition to absolute layout typical for editors, you can use grid layout familiar to those who came across table editing in HTML page. The grid layout makes it possible to build scalable multi-size data entry forms and tables.
As a result, first-line or second-line operator interfaces developed by using data visualization tools include dashboards with widgets, forms, tables, diagrams, reports, HMIs, and navigation between them.
The GUI Builder supports dozens of out-of-the-box components, such as captions, text fields, buttons, checkboxes, sliders as well as spinners, lists, date/time selectors, scales, and pointers. Among more complex components are trees, video windows, dynamic vector SVG images, geographical maps based on Google Maps/Bing/Yandex/OpenStreetMap. The list of supported diagrams includes classic charts, statistics charts, Gantt charts, and polar charts.
All widgets designed in the GUI Builder operate via web interface, including non-Java browsers, i.e. on mobile devices. You only need HTML5 and JavaScript support.
Properties related to server objects (devices, models, alerts) and UI components are linked together using bindings. Such bindings define when and where data should be taken, how to process it and where to place the results. While processing data, the bindings use expression and query languages.
A binding using an expression resembles Microsoft Excel formula. Such a formula takes data from several cells, applies mathematical operations or data processing functions to it, and places the result into the current cell. An expression is also a formula describing where data should be taken from and what sort of changes to apply to it.
The query language is very similar to regular SQL. It also aggregates data from various tables into one by using filtering, sorting, grouping, etc. The difference between the classic SQL and the embedded query language is that the latter uses virtual tables built on-the-fly from diverse unified model data as a source. Every query checks operator/system object access permissions automatically. With this in mind, the query language has an obvious advantage over direct SQL queries to the server database.
To solve more challenging data processing tasks, you can easily write a script in Java or even a dedicated plugin. However, every script written for data processing by any of our partners is a warning for us: why does one need A platform if classic development out of familiar environment (such as Eclipse or Idea) is still required?
And finally, a few words about the distributed architecture technology. Our concept implies customization of peering relationships between servers so that a server (provider) links a part of its unified data model to the other server (consumer). This allows the consumer server objects to equally interact with the provider server objects. A single server can have unlimited links, moreover, such a server can be both a provider and a consumer towards neighboring servers.
Distributed architecture ensures solving various large-scale system tasks:
- Horizontal system scaling.
- Distributed monitoring with local monitoring server installations and intermediate data storage at remote sites.
Vertical scaling, dividing functions between servers into several logic levels.
