Practical Sharing: How I Built the Siemens S7-1200 IoT Gateway

Hello, old friends!

Hello everyone, I am Engineer Wang, and I have been engaged in automation and IoT integration for over ten years. Today, I would like to share with you a project experience I recently completed—how to build a reliable IoT gateway using the Siemens S7-1200 PLC.

Do you remember the disastrous situation I faced two years ago when I first tried? Communication protocol mismatches, data loss, customer complaints… That experience made me deeply understand the importance of gateways in IoT projects. The experience I have organized today is intended to help friends who are entering the industrial IoT field avoid unnecessary detours.

1. Hardware Preparation and Environmental Requirements

Core Hardware List:

• Siemens S7-1200 CPU (recommended model 1215C with Ethernet interface)
• PROFINET communication module (to connect industrial devices)
• CP1243-1 communication processor (for connecting to external networks)
• 16GB SD card (for data caching)
• 24V DC power supply

Tip: I initially chose a lower-spec CPU, which often lagged when running complex data processing logic. I recommend selecting a higher-performance CPU model based on the actual number of data collection points and communication frequency!

Software Environment:

• TIA Portal V15.1 or higher
• SIMATIC STEP 7 Professional
• Cloud platform SDK (depending on the specific platform)

I previously used version V14 for projects, and after upgrading, I found that V15.1 offers better support for IoT functionalities, especially when writing data conversion code, as the new version provides more built-in function libraries.

2. Design Ideas and Architecture

Building an IoT gateway essentially addresses the “translator” issue—enabling devices on the industrial site to communicate smoothly with cloud systems.

My design approach is:

1. Adopt a three-layer architecture: data collection layer, data processing layer, data transmission layer
2. Implement protocol conversion, data caching, and security encryption functions on the S7-1200
3. Utilize edge computing capabilities to perform partial data preprocessing on the PLC side

![Architecture Diagram]

Initially, I placed all logic on the cloud platform side, which led to significant data loss during unstable communications. Later, I changed to perform data preprocessing and caching on the PLC side, which improved stability by 80%.

3. Core Function Implementation

Data Collection and Protocol Conversion

The S7-1200 can communicate directly with field devices via the PROFINET interface, but the challenge lies in effectively handling data from different protocols.

Here is the core code logic I implemented for Modbus-TCP to OPC UA conversion:

awk copy

// Define Modbus data block
DATA_BLOCK "ModbusData"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR 
      RegisterValues : ARRAY[0..99] OF WORD;  // Store Modbus register values
   END_VAR
BEGIN
END_DATA_BLOCK

// Conversion logic in the main program
FUNCTION "ConvertModbusToOPC" : VOID
   VAR_INPUT
      ModbusValue : WORD;
      ScaleFactor : REAL;
   END_VAR
   VAR_OUTPUT
      OpcValue : REAL;
   END_VAR
BEGIN
   // Convert based on the characteristics of different devices
   OpcValue := WORD_TO_REAL(ModbusValue) * ScaleFactor;
END_FUNCTION

Tip: Creating a dedicated data conversion function library for different types of devices will greatly improve code reusability. Our team has now accumulated over 20 conversion templates for various devices.

Data Caching and Resuming Transmission

Network interruptions are common in production environments. I designed a circular buffer to store data on the SD card during communication interruptions:

ebnf copy

// Define circular buffer
DATA_BLOCK "DataBuffer"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR 
      Buffer : ARRAY[0..999] OF STRUCT
         Timestamp : DATE_AND_TIME;
         Value : REAL;
         DeviceID : DINT;
      END_STRUCT;
      WriteIndex : INT := 0;
      ReadIndex : INT := 0;
      IsFull : BOOL := FALSE;
   END_VAR
BEGIN
END_DATA_BLOCK

This caching mechanism saved me during a power outage! The client site experienced a power outage for 4 hours, but all critical data was successfully uploaded after the network was restored, avoiding gaps in data analysis.

4. Practical Application Case

In a project I implemented last year for a pharmaceutical company, I connected 30 devices of different brands using the S7-1200, including temperature sensors, pressure transmitters, and flow meters. The key points were:

1. Adopt a unified data model to standardize data from different devices
2. Achieve a collection frequency of 5 seconds per instance, with an error control within 0.1%
3. Cache data for up to 72 hours during network outages

The results were remarkable—previously, the client had to manually record data for 2 hours each day, but now it is fully automated; the product quality traceability time was reduced from an average of 4 hours to 5 minutes.

5. Common Issues and Solutions

1. Communication Instability

Initially, during the project launch, there were several data transmission interruptions each day. After investigation, it was found that network fluctuations were the cause.

Solution: Implemented a heartbeat detection mechanism and added automatic reconnection logic. The core is to set a timer with a 10-second interval; if no response is received for 3 consecutive times, it automatically re-establishes the connection.

2. Data Accuracy Deviation

Some users reported that the temperature values displayed on the cloud platform did not match those on-site.

Solution: Upon inspection, it was found to be a data type conversion issue. In the S7-1200, special attention must be paid to precision loss when converting between REAL and INT types. We modified the conversion function to retain two decimal places, resolving the issue.

3. High Memory Usage

After running for an extended period, the S7-1200 issued a low memory warning.

Solution: Optimized the data structure, reasonably planned the cyclic execution time, and reduced the collection frequency of non-critical data by half. Additionally, we scheduled an automatic restart of the communication module every 24 hours to free up resources.

6. Insights and Reflections

After multiple project practices, I have summarized three key experiences:

1. Stability First: It is better to have simpler functions than to compromise on the stability and reliability of basic communication.
2. Layered Design: Break complex systems into independent modules for easier troubleshooting and upgrades.
3. Reserve for Expansion: Reserve 30% of hardware resources and interfaces for future functional expansions.

In conclusion, I want to say that in industrial IoT projects, the gateway is like the central nervous system of the human body—seemingly inconspicuous but crucially important. I hope my sharing can be helpful to everyone!

If you have any questions or want to exchange experiences, feel free to leave a comment for discussion. After all, in this rapidly evolving field, only by continuously learning and sharing can we keep pace with technological advancements.