kyoungminp00 님의 블로그

OT-IT convergence: IoT 프로젝트 (2)

kyoungminp00 — Fri, 13 Mar 2026 00:30:31 +0900

Building a Smart Factory IoT Platform: AWS + Terraform + OPC UA + AI

Introduction

This is Part 2 of my IoT pipeline series. In Part 1, I covered the hardware setup — wiring the DHT22 sensor to a Raspberry Pi 5 and confirming sensor readings.

In this post I'll cover connecting the Pi to AWS, storing data in DynamoDB, adding AI-powered anomaly detection with Lambda, provisioning infrastructure with Terraform, and finally adding an OPC UA industrial protocol layer.

Part 1: Connecting to AWS IoT Core

I created an IoT Thing (rpi-dht22-seoul-001) in the AWS Console and attached a least-privilege IoT Policy. AWS generates X.509 certificates during this process (a device certificate, private key, and Root CA), which I transferred to the Pi using scp.

The endpoint address is retrieved via CLI:

aws iot describe-endpoint --endpoint-type iot:Data-ATS --region ap-northeast-2

The main script (sensor_to_aws.py) uses the AWS IoT SDK's mtls_from_path() to establish an MQTT connection over TLS port 8883, authenticated with the X.509 certificates. Every 60 seconds it reads the sensor and publishes a JSON message to sensors/dht22/data.

I verified live data in the MQTT test client in the AWS Console.

Part 2: Storing Data in DynamoDB

I set up an IoT Rules Engine rule to automatically write every incoming message to a DynamoDB table (dht22-sensor-data, partition key: device_id, sort key: timestamp).

Troubleshooting: DynamoDB vs DynamoDBv2

The first attempt used the "DynamoDB" action type, which bundled all fields into a single payload column. Switching to DynamoDBv2 fixed this immediately, writing each field as a clean separate column:

device_id            | timestamp   | humidity | temperature
rpi-dht22-seoul-001  | 1772548058  | 32.1     | 22.8

This was the only significant issue encountered in the entire cloud setup.

Part 3: Infrastructure as Code with Terraform

All AWS resources were then codified into Terraform — IoT Core, DynamoDB, IAM roles, Lambda, and EventBridge — split across five .tf files.

Since some resources already existed from manual setup, I imported them first:

terraform import aws_dynamodb_table.sensor_data dht22-sensor-data
terraform import aws_iot_thing.dht22 rpi-dht22-seoul-001

The full infrastructure can now be reproduced in any AWS region with:

terraform init
terraform apply

I also replaced root account usage with a dedicated IAM user (terraform-admin) following least-privilege principles.

Part 4: AI Anomaly Detection with Lambda

An AWS Lambda function runs every 5 minutes via EventBridge, performing Z-score statistical analysis on the last 24 hours of sensor data:

Z = (current value - mean) / standard deviation

Readings with a Z-score above 2 are flagged as anomalies and stored in a separate anomaly-alerts DynamoDB table. This simulates the kind of predictive maintenance logic used in real factory monitoring systems — detecting abnormal equipment behaviour before it becomes a failure.

Test result from the Lambda console:

{
  "severity": "NORMAL",
  "temp_z_score": 0.3,
  "hum_z_score": 0.84,
  "anomalies": []
}

Part 5: OPC UA Industrial Protocol Layer

To make the project genuinely industrial-grade, I added an OPC UA layer. OPC UA is the standard communication protocol used in smart factories — it structures data in a factory hierarchy following ISA-95:

Factory_Seoul → ProductionLine_A1 → Equipment_EnvMonitor_01 → Sensors

Two scripts run on the Pi:

opcua_server.py: reads the DHT22 and exposes data as a structured OPC UA object tree with equipment metadata and status logic (RUNNING / WARNING / ALARM)
opcua_client.py: navigates the hierarchy, reads sensor values, and forwards them to AWS IoT Core via MQTT with an enriched industrial payload including equipment_id, location, and protocol: OPC-UA

This is the same edge gateway pattern used in real manufacturing environments for connecting field devices to cloud infrastructure.

Final Architecture

DHT22 Sensor
     ↓
OPC UA Server (ISA-95 hierarchy)
     ↓ opc.tcp
OPC UA Client (protocol translation)
     ↓ MQTT/TLS + X.509
AWS IoT Core → DynamoDB
     ↓ EventBridge (every 5 min)
Lambda (Z-score anomaly detection)
     ↓
anomaly-alerts DynamoDB table

All infrastructure → Terraform → GitHub

Key Takeaways

Use DynamoDBv2 (not DynamoDB) in IoT Rules Engine for clean separate columns
Always run terraform plan before terraform apply to preview changes safely
OPC UA with ISA-95 hierarchy transforms a basic sensor project into an industrial-grade platform
Z-score anomaly detection requires no ML framework: simple statistics are effective for time-series sensor data

Full source code: github.com/h3566652/Edge-Cloud-Gateway-Project

Kyoungmin Park | LinkedIn

OT-IT convergence: IoT 프로젝트 (1)

kyoungminp00 — Fri, 6 Mar 2026 16:43:11 +0900

Building a Real-Time IoT Pipeline: [Raspberry Pi + DHT22] + [AWS IoT Core + DynamoDB]

Introduction

This post documents my end-to-end journey building a real-time IoT data pipeline from scratch.

From my prior post, I stated that I will start a side project with a topic related to OT-IT convergence, and utilizing cloud features.

I bought the hardware (Raspberry Pi), bought sensors for collecting live data(DHT22), and permanently stored the data in AWS cloud. If you're interested in IoT, cloud engineering, or just want a hands-on AWS project for your portfolio, this is a great starting point for gaining experience and learning new skills.

Sharing my current result: a Raspberry Pi 5 reads temperature and humidity from a DHT22 sensor every 60 seconds, sends the data to AWS IoT Core over a secure MQTT/TLS connection, and stores it in DynamoDB automatically. The automation was done by Python scripts.

Part 1: Buying the Hardware

The first step was simple. I ordered from "Device Mart (디바이스마트, https://www.devicemart.co.kr/main/index)":

Raspberry Pi 5 (8GB)
DHT22 temperature & humidity sensor (AM2302)

What I didn't anticipate was that these two components alone weren't enough. When the parts arrived, I quickly realized that I needed additional electronics to actually wire everything together.

What I ended up buying additionally:

Breadboard: for prototyping without soldering
10kΩ resistor: required as a pull-up resistor for the DHT22 data line
Male-to-Female (M-F) jumper wires: to connect the Pi's GPIO pins to the breadboard
Female-to-Female (F-F) jumper wires: just in case of wire length issues

These were all easily bought from Coupang(쿠팡) and arrived quickly.

I think what I made is a common beginner mistake. One should always check what supporting components a sensor needs before ordering. However, the decision and arrival of the electronics were fast, for which I can conclude the response solution was quick and adequate.

Part 2: Wiring the DHT22 to the Raspberry Pi

The DHT22 I bought was the bare 4-pin version (not the breakout board), which meant I needed the 10kΩ pull-up resistor. The resistor ensures the data line properly returns to a HIGH state between readings. Without it, the readings become unreliable or fail entirely.

When using the 3-pin DHT22 sensor with the breakout board, it already has the resistor built in which doesn't require any additional resistors just like this step.

Here's the wiring I used, referencing the Raspberry Pi GPIO datasheet:

Raspberry Pi 5 --- DHT22

3.3V --- Pin 1 (VCC)

3.3V --[10k ohm] -- Pin 2 (DATA)

GPI04 --- Pin 2 (DATA)

---- Pin 3 (NC - not connected)

GND --- Pin 4 (GND - ground)

Part 3: Connecting to the Raspberry Pi via SSH

[I received assistance from Claude for coding, downloading adequate patches/extensions and writing python scripts]

Rather than connecting a monitor and keyboard to the Pi(for which I have to buy additionally), I accessed it remotely from my Mac using SSH.

First, I used the Raspberry Pi Imager software for configuring the rPi, downloaded the OS to a micro SD card, and then installed the SD card into the rPi5 for a start.

Next, I found the Pi's hostname(which I set up), then connected from my Mac terminal:

ssh kpark30525@kmpark.local

Once connected, the terminal prompt changed to confirm I was inside the Pi:

kpark30525@kmpark:~ $

From here, all commands run on the Pi remotely.

Part 4: Setting Up the Python Virtual Environment

Before writing any code, I created a Python virtual environment(venv) inside the project folder:

mkdir ~/iot-project
cd ~/iot-project
python3 -m venv venv
source venv/bin/activate

Why use a virtual environment?

The Raspberry Pi runs Raspberry Pi OS, which has its own system Python with pre-installed packages. If new packages are installed directly, there is a risk of version conflicts that can break OS-level tools.

A virtual environment creates an isolated Python installation just for the project. Packages installed inside it don't affect anything else on the system. It also makes your project reproducible; anyone can clone your repo and recreate the exact same environment.

Once activated, the terminal prompt shows (venv) to confirm it's active:

(venv) kpark30525@kmpark:~/iot-project $

Important: The venv resets every time you SSH into the Pi. Always run source ~/iot-project/venv/bin/activate first before working on the project.

Installing the required libraries:

pip install adafruit-circuitpython-dht

Part 5: Writing and Testing the Sensor Script

I created a simple Python script test_sensor.py to verify the sensor was wired correctly and returning valid readings:

import board
import adafruit_dht
import time

dhtDevice = adafruit_dht.DHT22(board.D4)

while True:
    temperature = dhtDevice.temperature
    humidity = dhtDevice.humidity
    print(f"Temperature: {temperature:.1f}°C  Humidity: {humidity:.1f}%")
    time.sleep(2)

Running it:

python3 test_sensor.py

Output:

Temperature: 22.6°C  Humidity: 32.5%

The sensor was working. ✅

Part 6: Setting Up AWS IoT Core

With the sensor confirmed working, the next step was connecting it to AWS. I used AWS IoT Core which is AWS's service for connecting IoT devices to the cloud.

Creating an IoT Thing

In the AWS Console (region: ap-northeast-2 / Seoul), I navigated to:

IoT Core → Manage → All devices → Things → Create things

Thing name: rpi-dht22-seoul-001
Certificate: Auto-generated

Creating an IoT Policy

The policy defines what the device is allowed to do. I used a least-privilege policy, which is only granting exactly what's needed:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Connect",
      "Resource": "arn:aws:iot:ap-northeast-2:*:client/rpi-dht22-*"
    },
    {
      "Effect": "Allow",
      "Action": ["iot:Publish", "iot:Receive"],
      "Resource": "arn:aws:iot:ap-northeast-2:*:topic/sensors/dht22/*"
    },
    {
      "Effect": "Allow",
      "Action": "iot:Subscribe",
      "Resource": "arn:aws:iot:ap-northeast-2:*:topicfilter/sensors/dht22/*"
    }
  ]
}

Part 7: Downloading the X.509 Certificates

AWS IoT Core uses mutual TLS authentication — both the device and AWS verify each other's identity using X.509 certificates. During Thing creation, AWS generated and offered four files to download:

xxxx-certificate.pem.crt — Device certificate (identity)
xxxx-private.pem.key — Private key (never share this)
xxxx-public.pem.key — Public key
AmazonRootCA1.pem — Root CA (verifies AWS's identity)

Critical: The certificates are only shown once at creation time, so the user should download all of them before moving on.

I transferred them to the Pi's certs/ folder from my Mac:

scp ~/Downloads/*.pem.crt kpark30525@kmpark.local:/home/kpark30525/iot-project/certs/
scp ~/Downloads/*.pem.key kpark30525@kmpark.local:/home/kpark30525/iot-project/certs/
scp ~/Downloads/AmazonRootCA1.pem kpark30525@kmpark.local:/home/kpark30525/iot-project/certs/

Part 8: Getting the AWS Endpoint

The endpoint is the AWS IoT Core address your device connects to. I couldn't find it in the Settings UI (AWS had recently moved it), so I retrieved it via the AWS CLI instead:

aws iot describe-endpoint --endpoint-type iot:Data-ATS --region ap-northeast-2

Output:

a1x71u4jsfn1px-ats.iot.ap-northeast-2.amazonaws.com

Part 9: Writing the Main Script

With all the pieces in place, I wrote "sensor_to_aws.py" to read from the DHT22 and publish to AWS IoT Core every 60 seconds:

import time
import json
import board
import adafruit_dht
from awscrt import mqtt
from awsiot import mqtt_connection_builder

ENDPOINT = "a1x71u4jsfn1px-ats.iot.ap-northeast-2.amazonaws.com"
CLIENT_ID = "rpi-dht22-seoul-001"
TOPIC     = "sensors/dht22/data"

CERT_PATH = "/home/kpark30525/iot-project/certs/xxxx-certificate.pem.crt"
KEY_PATH  = "/home/kpark30525/iot-project/certs/xxxx-private.pem.key"
CA_PATH   = "/home/kpark30525/iot-project/certs/AmazonRootCA1.pem"

dhtDevice = adafruit_dht.DHT22(board.D4)

def on_connection_success(connection, callback_data):
    print("Connected to AWS IoT Core!")

def on_connection_failure(connection, callback_data):
    print(f"Connection failed: {callback_data.error}")

mqtt_connection = mqtt_connection_builder.mtls_from_path(
    endpoint=ENDPOINT,
    cert_filepath=CERT_PATH,
    pri_key_filepath=KEY_PATH,
    ca_filepath=CA_PATH,
    client_id=CLIENT_ID,
    clean_session=False,
    keep_alive_secs=30,
    on_connection_success=on_connection_success,
    on_connection_failure=on_connection_failure
)

print("Connecting to AWS IoT Core...")
connect_future = mqtt_connection.connect()
connect_future.result()

try:
    while True:
        try:
            temperature = dhtDevice.temperature
            humidity    = dhtDevice.humidity
            message = {
                "device_id":   CLIENT_ID,
                "timestamp":   int(time.time()),
                "temperature": round(temperature, 2),
                "humidity":    round(humidity, 2)
            }
            mqtt_connection.publish(
                topic=TOPIC,
                payload=json.dumps(message),
                qos=mqtt.QoS.AT_LEAST_ONCE
            )
            print(f"Published: {message}")
        except RuntimeError as e:
            print(f"Sensor error: {e}")
        time.sleep(60)

except KeyboardInterrupt:
    print("Stopping...")
finally:
    mqtt_connection.disconnect()
    dhtDevice.exit()
    print("Disconnected.")

How MQTT/TLS works

The connection uses MQTT over TLS on port 8883. I didn't have to configure the port manually, but the "mtls_from_path()" function from the AWS IoT SDK handles it automatically using the certificates. What enables the secure connection is the combination of:

X.509 certificates — prove the Pi's identity to AWS
IoT Policy — grant the device permission to connect and publish
mtls_from_path() — tells the SDK to use mutual TLS authentication

Testing it

python3 scripts/sensor_to_aws.py

Connecting to AWS IoT Core...
Connected to AWS IoT Core!
Published: {'device_id': 'rpi-dht22-seoul-001', 'timestamp': 1772545137, 'temperature': 22.6, 'humidity': 32.5}

I verified the data was arriving in AWS using the MQTT test client (IoT Core → Test → MQTT test client), subscribing to sensors/dht22/data. Messages appeared in real time. ✅

Part 10: Storing Data in DynamoDB

Seeing data in the MQTT test client is great, but it disappears when the browser is closed. The next step was permanently storing every reading using DynamoDB.

Creating the DynamoDB Table

Table name: dht22-sensor-data
Partition key: device_id (String)
Sort key: timestamp (Number)
Capacity mode: On-demand (free tier friendly)

Setting Up the IoT Rules Engine

The Rules Engine acts as the bridge between IoT Core and DynamoDB. Every time the Pi publishes a message, the rule automatically triggers and writes it to the database.

I navigated to IoT Core → Message routing → Rules → Create rule:

Rule name: dht22_to_dynamodb
SQL statement:

SELECT device_id, timestamp, temperature, humidity FROM 'sensors/dht22/data'

Troubleshooting: DynamoDB vs DynamoDBv2

This is where I hit my first real issue. After setting up the rule using the "DynamoDB" action type, data was being saved, but everything was bundled into a single payload column instead of clean separate columns:

device_id          | timestamp  | payload
rpi-dht22-seoul-001 | 1772547541 | {"temperature": {"N": "22.7"}, "humidity": {"N": "32.3"}, ...}

I tried clearing the "Write message data to this column" field in the DynamoDB action settings, but the payload column kept appearing.

After thought process, I found the problem was the action type.

DynamoDB (v1) — always bundles the message into a payload column
DynamoDBv2 — writes each JSON field as a separate, clean column ✅

I removed the original action, added a new DynamoDBv2 action instead, and re-tested. The result was exactly what I wanted:

device_id            | timestamp   | humidity | temperature
rpi-dht22-seoul-001  | 1772548058  | 32.1     | 22.8

The data is much more clear and structured.

DynamoDB from AWS

Final Architecture

DHT22 Sensor (GPIO4)
        ↓
Raspberry Pi 5 — Python script (sensor_to_aws.py)
        ↓ MQTT over TLS / port 8883 / X.509 auth
AWS IoT Core (Thing: rpi-dht22-seoul-001)
        ↓ Rules Engine (DynamoDBv2 action)
DynamoDB (dht22-sensor-data)
├── device_id
├── timestamp
├── temperature
└── humidity

What's Next

The solid pipeline structure is made, so the next step is adding an AI/anomaly detection layer for flagging unusual temperature or humidity readings automatically using AWS Lambda.

Moreover, I will deploy Terraform and utilize IaC. Also, I will use OPC UA and Modbus protocols, using rPi5 as an edge device.

This project is part of my IoT + Cloud portfolio. Full source code available on GitHub.

https://github.com/h3566652

[IoT 프로젝트] #0 OT to IT convergence

kyoungminp00 — Wed, 14 Jan 2026 14:48:17 +0900

자동제어 엔지니어가 클라우드 연결점에 도전하는 이유

저는 현재 건물 자동제어 시스템 업계에 종사하고 있는 엔지니어입니다. 대학교 시절 당시 전기전자공학과 컴퓨터 공학을 공부하며 자연스럽게 전자 디바이스 관련된 업무에 관심을 갖게 되었고 결론적으로는 지멘스 Siemens 사의 여러가지 자동제어 제품군을 다룰 수 있는 업무를 담당하게 되었습니다.

현재 하는 업무는 IEC61131-3 언어를 활용한 PLC programming, Modbus 와 BACnet 등 자동제어 프로토콜들을 활용한 네트워크 관리 및 트러블 슈팅, BAS (Building Automation System)에 활용되는 여러 컨트롤러들의 I/O 포인트들을 configure하고 네트워크 어드레스 맵핑, 스케줄 관리 등 관련된 업무입니다.

학창시절 때부터 디지털 전환 digital transformation 에 대해서 관심이 많았습니다. IoT 엣지 디바이스들을 이용해서 데이터를 빠르고 효율적으로 처리하며 어디서든 접속할 수 있도록 접근성이 좋으면서도 보안에 취약하지 않은 시스템이 개발되면, IT 계열 뿐만 아닌 현재 존재하는 모든 분야의 매니지먼트 형태의 기술 패러다임 자체가 바뀔 것이라고 생각합니다.

거창한 아이디어와 상상력만 가지고 기술 자체에 대한 자세한 지식은 없던 상태에서 AWS Solution Architect-Associate 자격증 취득을 위해 공부하며 클라우드라는 개념을 제대로 접했고, 클라우드 생태계에 대해 자세히 알아가며 점점 매료되기 시작했습니다. 공부를 하면서 기본적인 AWS Services에 관련된 실습을 AWS Free tier로 진행했습니다. 솔루션 아키텍트라는 분야 특성상 Engineering 기술력 자체에만 집중하는 것보다 비용 관련된 cost optimization도 고려하며 아키텍쳐를 구성하는 것이 굉장히 흥미로웠습니다.

On premise -> Cloud

현재 건물 자동제어 관련 업무는 장점과 단점이 명확하다고 생각합니다.

기본적으로 여러 센서들 및 하윗단 장비들의 기본적인 데이터를 불러모아 Modbus 프로토콜 등 전용 프로토콜을 사용하여 데이터를 수집하고 자동제어 시스템을 관리하는 형태입니다. 현장에 알맞는 장비 선택 등 기초부터 탄탄하게 잘 짜여지면 안정적이지만, 기술 진입장벽이 높고 폐쇠적이며 확장 가능성이 적어서 해당 프로젝트를 담당했던 전문가 몇 명 이외에는 유지 보수도 곤란하여 현장 방문이 잦아지고 건물 인프라 확장 시 기존 시스템을 확장 시킬 수 있는 능력이 현저히 부족합니다.

이에 보완하고자 클라우드 서버로의 연결점을 만들고 데이터를 마이그레이션 migration 하며 '디지털 전환 (digital transformation)을 달성하면 원격으로도 손쉽게 실시간 데이터를 접하며 다양한 스케줄링 및 알람 시스템을 관리할 수 있으며, 기술적 결함이 생길때도 실시간 원격으로 처리하며 업무의 효율성 및 가동범위가 굉장히 넓어질 수 있다는 장점이 있습니다.

클라우드 마이그레이션을 하면 생길 수 있는 단점은 더욱 digitally open 되며 보안에 취약해질 수도 있다는 점이 있습니다. 그러나 이는 클라우드가 가진 가장 큰 장점이자 단점이라고 생각하는데, 이 단점을 커버할 수 있는 클라우드 보안 Cloud Security 관련된 내용도 추가적으로 다룰 예정입니다.

우선 AWS SAA 자격증을 취득하며 공부했던 AWS 관련, 그리고 기본적인 클라우드 인프라와 엣지 컴퓨팅 관련된 학습을 진행하면서 관련 프로젝트를 하나 진행할 생각입니다. 가장 직관적으로 현재 하는 업무에서 연결점을 지어서 주제를 정했는데, 실시간 온습도를 센서를 통해 데이터를 엣지 디바이스로 보낸 이후, 클라우드까지 연결 지어서 정리된 데이터를 모니터링을 하거나 원격으로 조정할 수 있는 프로젝트를 진행할 예정입니다.

해당 프로젝트를 통해서 엣지 디바이스와 클라우드에 관련된 기본적인 지식과 직접 다뤄보는 실무 경험, 그리고 이를 바탕으로 다양한 방면으로 IoT와 클라우드를 활용하는 방향으로 프로젝트를 확장할 생각입니다.