SCADA System Multi-Brand PLC Compatibility: One Development, Universal Access

Driven by the information technology application innovation industry, domestic PLC brands have emerged rapidly. Brands like Nanda Aotuo, Hollysys, Lanpufeng, Xinje, Delta, Inovance, and Haiwell each have unique communication protocols and configuration requirements. Facing this fragmentation, how SCADA software achieves rapid adaptation has become a key bottleneck affecting project implementation efficiency.

The Dilemma of Traditional Adaptation Models: Dual Pressure of Cost and Efficiency

Limitations of Standard Drivers

Most SCADA software uses standard Modbus drivers for device connection, which is a universal solution. However, in practice, engineers face:

• Non-standard function codes: Different manufacturers have various extensions to the Modbus protocol.
• Address mapping differences: The same function point has completely different addresses in different PLCs.
• Inconsistent data formats: Byte order, floating-point representation, etc., vary by manufacturer.

The Pain of Dedicated Driver Development

Developing dedicated drivers for each brand seems ideal but faces:

• High R&D costs: Each driver requires independent development and testing.
• Heavy maintenance burden: Brands and models update frequently, requiring continuous driver updates.
• Code duplication: Basic communication functions are repeatedly implemented in different drivers.

Real pain point: Engineers spend a lot of time consulting address mapping tables of various brands, resulting in low configuration efficiency and infinitely extended project delivery cycles.

Innovative Architecture: Common Code + Configuration File Abstraction Pattern

A leading SCADA provider proposed a layered architecture design that perfectly solves this industry problem:

Core Architecture Concept

Technical Implementation Highlights

Configuration file defines communication specifications:

<PLC Brand="Nanda Aotuo" Model="NA400">
    <DataTypes>
        <Type Name="BOOL" Address="000001" Length="1"/>
        <Type Name="WORD" Address="400001" Length="1"/>
    </DataTypes>
    <Communication>
        <Protocol>ModbusRTU</Protocol>
        <ByteOrder>BigEndian</ByteOrder>
    </Communication>
</PLC>

Common code engine is responsible for:

• Complete implementation of the Modbus protocol stack
• Communication link management and fault recovery
• Data caching and real-time assurance
• Exception handling and logging

Practical Application: Adapting a New Brand in Three Hours

Standardized Adaptation Process

Step 1: Analyze the target PLC’s Modbus mapping table.

Step 2: Write the brand configuration file (average time: 2 hours).

Step 3: Functional verification and stress testing (average time: 1 hour).

Automatic Address Mapping Conversion

Traditional method requires manual query of address mapping tables:

Temperature Sensor 1 → 40001 (decimal)
Pressure Transmitter 1 → 40003 (decimal)

New solution supports tag-based configuration:

# Directly use tag names from PLC programming software
points_config = {
    "Temperature Sensor 1": {"addr": "AI1", "type": "REAL"},
    "Pressure Transmitter 1": {"addr": "AI2", "type": "REAL"}
}

Encapsulation of Complex Protocol Details

Technicians no longer need to deeply understand these professional concepts:

• Register start address differences (0-based vs 1-based)
• Data big-endian/little-endian byte ordering
• Differences between function codes 06 and 16
• Bit addressing/word addressing/double word addressing differences

Quantitative Analysis of Technical Advantages

Development Efficiency Improvement

Lowering the Barrier to Entry

• Configuration efficiency: Improved by 3-5 times, no need to frequently consult manuals.
• Learning cost: New engineers can get started within 1 day.
• Maintenance difficulty: Configuration file updates replace code modifications.

Success Story: Deep Integration Completed in One Week

A large automation project adopted a domestic SCADA system in cooperation with a well-known PLC manufacturer:

Implementation Timeline

• Day 1: Completed basic communication adaptation, achieved data acquisition.
• Days 2-3: Deep integration with PLC programming software, realized online tag table access.
• Days 4-5: Developed rapid point creation function, supporting batch tag configuration.
• Days 6-7: System joint debugging and optimization, completed all tests.

Key Technical Breakthroughs

Automatic tag table synchronization: SCADA directly reads tag definitions from PLC programming software.

One-click configuration: Batch creation of measurement points, avoiding manual input errors.

Online debugging: Real-time monitoring of communication status, quickly locating problems.

Industry Insights and Promotion Value

Implications for SCADA Vendors

• Architecture first: Good abstraction design is more important than feature stacking.
• Ecosystem co-construction: Deep cooperation with PLC manufacturers achieves win-win.
• Standardization promotion: Promote unified industry communication specifications.

Value for System Integrators

• Rapid delivery: Shorten project implementation cycles.
• Risk reduction: Reduce system failures caused by unstable drivers.
• Strong scalability: New brand access costs almost zero.

Synergistic Application with Motion Controllers

It is worth noting that this “common code + configuration file” design concept is highly compatible with the architecture of advanced motion controllers. In complex equipment control systems, SCADA is responsible for upper-level monitoring and data management, while multi-axis motion controllers handle precise bottom-level motion control. The two are seamlessly integrated through standardized interfaces.

Typical application scenarios:

• SCADA system monitors production status and equipment parameters.
• Motion controller executes interpolation motion, point-to-point control, and other core motion functions.
• Bidirectional data exchange achieves full closed-loop control.

This architecture provides an excellent template for integrated solutions of domestic industrial software and hardware.

Conclusion

The prosperous development of domestic PLCs is a boon for the industry, and the rapid adaptation capability of SCADA software is the key to transforming this prosperity into actual productivity. Practice has shown that through architectural innovation and technical abstraction, the unity of “development efficiency” and “universality” can be achieved.

Future outlook: With the development of the Industrial Internet, this configuration-based, modular design concept will expand to more fields. The deep integration of motion control technology and SCADA systems will provide more complete solutions for intelligent equipment.