Architectures and Applications
inSCADA Architecture and Applications
Last updated
inSCADA Architecture and Applications
Last updated
InSCADA architecture and application examples will be examined in this section.
Figure 1 shows the architectural structure and subcomponents of inSCADA. inSCADA is a Spring Boot application and is designed to work in both monolitic and micro service structures. In the middle of the picture, while the inSCADA modules are connected to each other in a monolitic structure, the same modules can serve externally with REST services. inSCADA can work in a cluster structure with another instance, provide load sharing, redundancy and ensure continuity. In is seen in the same figure that, inSCADA is integrated with RDB, Timeseries DB and In-Memory databases. Thus, inSCADA guarantees the highest performance for the basic needs such as the real-time data storage, monitoring, and associating them with meta-data, by constructing them in such a way that they can work fully integrated and compatible with each other on disciplined platforms in the SCADA field.
The inSCADA platform is a RESTFUL application as can be seen from Figure 2. This makes it fully integrated with other ERP/MAS and GIS systems in organizations. Integration with ICodeBetter and IWorkbetter systems in our application is a good solution for all needs of organizations.
The communication architecture on the inSCADA platform has modeled all industrial protocols simply. This allows you to go through similar configuration steps, even if you use different protocols. Dynamically changing configuration forms allow users to intuitively configure configuration settings.
The application shown in Figure 4 is one of the simplest smallest applications in the SCADA field. inSCADA can serve in desktop PCs in control rooms or in Industrial Panel PCs on the Dashboard. It is an economical solution for such applications requiring low hardware resources.
Application in figure 5 has similar features as an application in figure 4. The only difference is that the device (s) in the serial link layer can be accessed via a terminal-server. Rather, it is a technique used to migrate legacy systems to the inSCADA platform.
The application of figure 6 is similar to the application of figure 4. The difference is that the device(s) in the serial link layer can be accessed via a redundant terminal-server. In this way, redundancy of communication lines is ensured. When inSCADA knows that there is a backup(s) of the communication line, it automatically checks and uses the appropriate line for the continuity of communication .
Figure 7 shows the implementation of the inSCADA platform in redundant architecture. Here, inSCADA is run on different computers with their assigned roles (Primary, Standby), informed of each other. Standby roles continuously check the status of the system in the primary role and take over the primary role in the event of an error. In this way, the continuity of the system is ensured. inSCADA also provides synchronization of databases in this application.
Application in figure 8 has similar features as the application in figure 7. The only difference is that the database is maintained on different servers.
Application in figure 9 has similar features as the application in figure 8. The difference is that the redundancy of the database is provided on separate servers.
The application shown in Figure 10 is designed in such a way that all the risks that will affect the continuity of the system are controlled. Network redundancy, inSCADA Application Redundancy and Database Replication are used together.
So far, we have discussed basic classical applications on the inSCADA platform without going into detail. Scalability of the inSCADA platform through cloud-based architecture, distributed load sharing applications, and how-to are shared in our advanced training documents. You can send an e-mail to info@inscada.com for your training requests.
