Jump to content

Vasilina Sterlyakhina

Registered
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Vasilina Sterlyakhina

  • Rank
    Participant
  • Birthday November 16

Personal Information

  • Organisation Membership
    IEEE

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Vasilina Sterlyakhina

    AggreGate Server on Nanopi NEO

    We’ve tested AggreGate Server on Nanopi NEO, one of the smallest Linux-based single-board PCs. Despite its small size, this device simply rules! It has RAM 512 Mb on board, 1,2 GHz quad-core CPU, 10/100M Ethernet network interface, and many other interfaces to connect the world. AggreGate possibilities on the NEO board are similar to Linux-based Tibbo Project System. It can act as a simple close-knit protocol gateway with intermediate data processing. Check it infrastructure monitoring tools, industrial automation software and other AggreGate IoT solutions on our website.
  2. Victor Polyakov, TIbbo Systems CEO, will answer these questions at the webinar dedicated to energy management transformation influenced by the IoT. You will learn that: - SCADA and Smart Metering systems will become extinct - IoT Platforms are already changing the digital energy landscape - Smart Grid will use dedicated software instead of cross-industry software platforms June 6, 2017. 05:00 AM - 06:00 AM. (12 midday AEST - Sydney) Join the webinar: http://iot.engineersaustralia.org.au/calendar/event/99-power-engineering-transformation-with-iot/?utm_source=social-media&utm_medium=referral&utm_campaign=Webinar_Australia
  3. March 31, 2017 - Taipei, Taiwan - Tibbo, a leading manufacturer of IoT devices and intelligent device management software, announced release 5.4 of AggreGate IoT Integration Platform. We've achieved great results in optimizing AggreGate server performance, especially event and value update storage performance. From now on, a single server can process and persistently store up to a hundred thousand events/updates per second, which is almost equal to 10 billion events per day. Such performance figures don't even require any high-end server hardware. A new chapter has been opened by this release, presenting AggreGate's graphical and textual programming languages inspired by IEC 61131-3 standard, also known as "SoftPLC". Millions of engineers are now able to use AggreGate as a process control logic development environment. One innovative feature of AggreGate's automation languages is tight integration of runtime with the Tibbo Project System hardware. Your programmed logic can access and control all Tibbit modules of a Linux-based TPS board/box. Currently available languages are: Function Block Diagram (graphical), Structured Text (graphical), Sequential Function Chart (textual). Widget capabilities are no longer limited by the standard set of components. Now it can be easily extended. New Widget Component SDK allows to implement custom visual components in Java and use them in AggreGate widgets. Extend AggreGate's wide component palette with UI controls best suited to your needs! We continue making our UI interface clearer and more user-friendly. The next step is lightweight icons. We redesigned them to be up-to-date with modern flat paradigm. New color coding assists users to navigate over various available toolbar actions. Other major improvements include: · Built-in timestamps and quality for data tables. · Component connectors that allow to visually link UI components with each other. · Secure and reliable Agent communications. Agent-Server communications now can be SSL-protected. When transferred data amount is critical, data compression can be enabled in parallel to encryption. · Granulation, a brand-new highly customizable data aggregation and consolidation tool. The granulation engine allows to combine datasets into compact representation that contains all important aspects of original information in virtually any form suitable for later processing. This allows to reduce memory and storage consumption along with boosting data processing performance. · Server remote upgrading. To reduce company's expenses, a remote AggreGate server upgrade operation is now supported. You can use our Unified Console application to connect to a remote server, upload a server upgrade bundle file and wait while the upgrade process is finished. That's it! All operations, including database backup, stopping server, upgrading and restarting will be performed at the server side automatically. We are bringing our IT & Network Management solution (AggreGate Network Manager) to a new level by turning it into a full-fledged IT Service Management System. In this release, we introduce several essential instruments for that: Configuration Management Database (CMDB), metrics engine and topology-based root-cause analysis tools. Another ITSM functionality - IP address management module - is now available and you can use it out-of-the-box. AggreGate 5.4 includes new device drivers: CoAP, MQTT, IEC 104, DLMS/COSEM, SMI-S. You can get detailed information on the new 5.4 release, download and try the updated AggreGate IoT Platform on our website: http://aggregate.tibbo.com/news/release-54.html.
  4. In this article, Victor Polyakov, Managing Director, Tibbo Systems will keep introducing AggreGate IoT Platform-based products. In 2010, two years after AggreGate Network Manager release, we started AggreGate SCADA/HMI project ‒ fourth-generation SCADA system.\ So what is fourth-generation SCADA? Wikipedia suggests the following definitions: First-generation SCADA are monolithic systems that had been developed before the Internet expansion became widespread. Such systems do not operate anymore. Second-generation SCADA solutions are operating in enterprise local systems. They are supposed to employ IP network for connection between controllers, data collection servers, controlling servers, and APM operators. Third-generation SCADA architecture enables coordination of geographically-distributed automatic process control systems. These systems include multiple manufacturing sites and remote monitoring objects. Until recently, third-generation SCADA was a cutting-edge SCADA product with the possibility of HMI launch in mobile device browsers, remote project editing right on the production server, and testing without server shutdown and project file copying. Finally, fourth-generation SCADA should fit the Internet of Things. It implies decentralization and unification at a greater extent, i.e. possibility of algorithm execution point shift between SCADA servers and controllers. Another indispensable feature is operation via cellular and satellite network avoiding VPN (controllers with no static IP address can connect to SCADA servers operating in a cloud). Naturally, every SCADA vendor develops their products evolving from generation to generation, while the previous versions become stagnant for not being compatible with the latest trends. IoT Platform-based AggreGate SCADA/HMI (http://aggregate.tibbo.com/solutions/scada-hmi.html) has inherited all functions of fourth-generation SCADA: · Built on Java platform, the system operates on Linux perfectly, which allows SCADA core running on embedded systems. Our OEM partners supply systems built on Raspberry Pi, BeagleBone Black and similar low-priced microcomputers. In addition, there is an option for SCADA core to access IP communications, serial ports, as well as discrete and analog inputs, etc. · The same solution operating on regular servers provides centralized data collection and HMI handling. Servers based on unified architecture establish peering relations for data interchange with PLCs. · The system is fully compatible with all Tibbo programmable controllers and modules. · HMIs can be launched on Linux or Windows PCs, touch boards, or opened in web-browsers. · There are no such concepts as “development environment” or “runtime environment” in our solution. Development is implemented via remote connection right on a production server considering role-based permissions. In addition, there are a lot of ways of cloning the whole project or its parts. Platform capabilities for designing reference projects and derived products will be described in a separate article. · AggreGate Platform is tailored to work with M2M devices. The server with controllers connecting to it by themselves operates perfectly. In our terminology, such controllers connecting to the server themselves are called agents. There is still a question left: why have we developed another SCADA? The international market is saturated with such solutions. The point is that AggreGate SCADA/HMI as an AggreGate Platform add-on is technically a set of drivers for data collection and typical HMI vector images. All features necessary for SCADA are AggreGate Platform components: GUI (widget) builder, report editor, alert and event control tools, tag modeling system, failover clustering technology, SDK with DDK, etc. Our investment to SCADA system development was not so great comparing to the development of such a system from scratch. To implement industrial and building automation projects, we developed the drivers for standard process control protocols (Modbus, OPC, OPC UA, BACnet, DNP3, etc.) and designed several thousands of vector images. Along with standard SCADA system functions, AggreGate Platform fills it with exceptional features, for instance: · Statistics storage in Round-Robin Database (RRD) and NoSQL database (BigData) · Unlimited horizontal and vertical system scaling based on AggreGate distributed architecture · Data collection and control via both IT monitoring protocols (SNMP, FTP, JMX, SSH, WMI) and generic ones (SQL, SOAP, CORBA, LDAP…). These features allow you to apply the system in multiple projects, not typical for SCADA solutions. AggreGate SCADA/HMI, in particular, is used for manufacturer fleet telemetry, MES replacement, cell tower and data center engineering infrastructure monitoring (included into AggreGate Data Center Supervisor solution). In terms of AggreGate architecture and project building concept, AggreGate SCADA/HMI resembles most of other products. A typical project development cycle includes: · Deploying a server or several servers in a failover configuration · Connecting to a storage that can be either a standard relational DBMS or integrated Apache Cassandra DMBS saving dozens of thousands tags per second · Connecting controllers and other data sources (e.g. external databases), configuring tag polling period · Configuring automated tag processing algorithms on a server side. These can be models determining additional calculated tags, alerts delivering e-mail and SMS notifications, schedules for performing certain jobs, etc. · Developing HMIs, dashboards, and navigation between them · Setting user roles, access, and external authentication via LDAP/AD configuration. Running on Linux, AggreGate server collects data from OPC servers running on Windows. This procedure is implemented via IP network and DCOM protocol. As a result, there is no need for installing SCADA server and OPC server on a single computer anymore. There are no such notions as “project”, “development environment”, and “runtime environment” in AggreGate SCADA/HMI. According to its concept, a single primary server is installed on a worksite. During the initial deployment phase, system engineers can connect to the server locally or remotely for developing HMIs, create PLC user accounts, set up data storage, and so on. After this phase, the same server will be utilized during commissioning and further on a regular basis, although the system migration to another server is possible and simple. Unified environment enables to introduce modifications into the production server without any interruptions. In this case one should: · Make temporary copies of one or two system components (for example, HMIs or alerts) · Introduce changes in the copy and test them · Replace the original component with the successfully modified copy. One of the vital SCADA system parts is GUI Builder. Inherited from AggreGate Platform, GUI Builder assists in drawing and animating any HMIs containing both simple components (buttons, captions, text fields, lists, etc.) and complex ones (tables, multi-layer panes, tabbed panes, charts, geographical maps, dynamic SVG images, video windows, etc.). Even though AggreGate GUI Builder is similar to other system editors of this kind, it has an outstanding feature. Alongside with standard visual component absolute layout, any pane can utilize a grid layout similar to an HTML table. Plus, in case of a complex form with multiple tabbed panes (simple, multi-layer, tabbed, split panes), every pane can employ both absolute and grid layouts. Grid layout allows designing HMIs, data input forms, and dashboards that seamlessly adjust to any screen resolution. In case of absolute layout, component proportional scaling is used. In this case, component height also increases, which leads to unacceptable results for almost all forms and dialogs. HMIs are animated through bindings that allow data copying between server object properties and visual component properties in response to server and HMI events. AggreGate expression language brings aid in applying any operations to replicated data on the fly (processing numbers, strings, dates and time, tables, etc.). Any data processed by AggreGate can be utilized for reporting. Expression builder and integrated SQL-like query language help retrieve necessary indicators, and the system creates the optimal template for their visual representation. After this, you can customize the template using the report builder. As for the KPIs, you can configure alerts raised in response to critical object state events or event chain retrieving. The system sends alert notifications in almost any way (popup windows, sound notifications, E-mail messages, SMS). Automatically launched corrective actions can run both autonomously and under operator control. The alert module supports other typical industrial control features: flapping detection, hysteresis, prioritization, acknowledgement, escalation, etc. AggreGate SCADA/HMI automates industrial processes, displays all necessary data in the operator center, provides visualization, saves information into a database, and creates reports ‒ in fact, everything that is expected from SCADA. The system promptly analyzes technological process efficiency and takes important decisions on its optimization, i.e. it partially performs MES software functions. Usually, there are several SCADA installations operating simultaneously at large enterprises. Every installation has its own function in a certain workshop. The systems are logically bound by the production chain. Thus, their integration and automated KPIs transmission to MES/ERP levels are required. In AggreGate ecosystem, this is carried out by exchanging unified data model parts between servers with the help of distributed architecture (http://aggregate.tibbo.com/technology/architecture/distributed-architecture.html). It often happens that on a single object/within a single project, it’s necessary to implement not only SCADA, but also IT infrastructure management system, building automation, access control and physical access control, automatic system for commercial accounting of power consumption, and other solutions in various combinations. AggreGate has all these features implemented within one installation and possibility of binding modules on a single server. Where can you run across it? For example, in data centers where active networking equipment, climate sensors, UPS, DGU, conditioners, water-cooling system, personnel access, time and attendance should be monitored. Some more examples: cell towers, where radio-relay equipment of transport network, sector antenna parameters, intrusion detection sensors, and other systems must be controlled. In large warehouses, it is vital to monitor personnel access, loader behavior, ventilation and lighting systems. Almost all large-scale objects can gain an advantage from merging various monitoring and management systems. In our upcoming articles, we will describe distinguishing features of our SCADA solution, various industrial automation problems and their described solutions, as well as newsworthy projects we’ve taken part in. Victor Polyakov, Managing Director, Tibbo Systems
  5. 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.
×