PLC Structure란? 관련 데이터를 하나로 묶는

2026년 9월 11일 읽는 시간 약 8분

PLC Structure란 서로 관련된 BOOL·INT·REAL 등 여러 데이터형을 하나의 구조로 묶어 관리하는 방법입니다. 장비·센서·레시피 데이터를 체계적으로 구성하는 원리를 알아봅니다.

PLC Structure란 무엇이며 왜 사용할까?

PLC Structure는 서로 관련된 여러 Variable을 하나의 논리적인 Data Group으로 묶어 관리하는 Data Structure입니다. Array가 일반적으로 같은 Data Type의 여러 값을 Index로 관리하는 방식이라면 Structure는 서로 다른 Data Type을 하나의 그룹에 포함할 수 있다는 특징이 있습니다. 예를 들어 하나의 Motor를 관리하려면 Run Command는 BOOL, Speed Setpoint는 REAL, Alarm Code는 INT, Total Runtime은 DINT처럼 서로 다른 Data가 필요할 수 있습니다. 이를 각각 독립적인 Variable로 만들 수도 있지만 Motor라는 Structure 안에 Run, Speed, AlarmCode, Runtime 등의 Member를 구성하면 모든 관련정보를 하나의 장비 Data로 관리할 수 있습니다. PLC 제조사에 따라 STRUCT, UDT, DUT, User-defined Type 등의 명칭이 사용되며 선언방법에도 차이가 있습니다. Structure를 활용하면 Variable Name만 보아도 Data가 어떤 Equipment와 관련되어 있는지 쉽게 파악할 수 있어 대규모 PLC Program의 가독성과 유지보수성을 높이는 데 유용합니다.

Structure의 Member는 어떻게 구성할까?

Structure 내부에 포함된 각각의 Variable을 Member 또는 Field라고 합니다. 하나의 Structure에는 BOOL, INT, DINT, REAL, WORD와 같은 기본 Data Type뿐 아니라 PLC가 지원한다면 Array나 다른 Structure도 Member로 포함할 수 있습니다. 예를 들어 Motor Structure를 구성할 때 Command.Start, Command.Stop, Status.Running, Status.Fault, SpeedSetpoint, CurrentValue와 같은 형태로 Data를 계층적으로 구성할 수 있습니다. 실제 접근 Syntax는 Programming Environment에 따라 다르지만 일반적으로 Motor1.Speed처럼 Structure Variable 이름과 Member 이름을 조합하여 특정 Data에 접근합니다. 이 방식은 M100, D200과 같은 Absolute Address만 사용하는 것보다 Data의 의미를 쉽게 파악할 수 있다는 장점이 있습니다. 다만 Structure 내부의 Memory Layout에는 Data Type별 Size와 Alignment가 영향을 줄 수 있으므로 외부 Device와 Memory를 직접 Mapping하거나 Communication Data를 구조체로 변환할 때는 제조사의 Packing과 Alignment 규칙을 확인해야 합니다.

Array와 Structure는 무엇이 다를까?

Array와 Structure는 모두 여러 Data를 하나의 단위로 관리하지만 구성목적이 다릅니다. Array는 Temperature[0], Temperature[1]처럼 같은 종류의 Data가 반복될 때 유용하며 Index를 이용해 Element를 선택합니다. 반면 Structure는 하나의 Equipment나 Process를 설명하는 서로 다른 종류의 Data를 묶는 데 적합합니다. 예를 들어 20개의 Temperature 값은 REAL Array로 구성하기 좋지만 하나의 Pump에 필요한 Run Status, Pressure, Current와 Alarm Code는 Structure로 관리하는 것이 자연스럽습니다. 두 방식을 결합하면 더욱 효율적인 Data Model을 만들 수 있습니다. 먼저 MotorType이라는 Structure를 정의하고 그 안에 Command, Status, Speed와 Alarm Data를 넣은 다음 Motors[0..9]와 같이 Structure Array를 구성하면 10대의 Motor를 동일한 형식으로 관리할 수 있습니다. 이렇게 구성하면 FOR Loop를 이용하여 여러 Equipment의 Data를 반복 처리하거나 HMI 화면과 연결하기도 쉬워집니다. 결국 Array는 반복되는 Data Collection, Structure는 관련 속성의 Grouping이라는 차이로 이해할 수 있습니다.

사용자 정의 데이터형 UDT는 Structure와 어떤 관계일까?

PLC Programming에서는 반복해서 사용할 Structure의 형식을 User-defined Data Type, 즉 UDT로 정의하는 경우가 많습니다. UDT는 실제 Data 값 자체라기보다 어떤 Member와 Data Type으로 구성할 것인지를 정의한 Template에 가깝습니다. 예를 들어 MotorData라는 UDT를 만들고 RunCmd: BOOL, Running: BOOL, Speed: REAL, AlarmCode: INT를 정의하면 Motor1, Motor2와 Motor3 모두 동일한 Data Structure를 사용하도록 선언할 수 있습니다. 이후 새로운 Status 항목이 필요할 때 Type Definition을 수정하면 관련 Variable의 구조를 일관되게 관리하기 쉬워집니다. Function Block과 결합하면 효과가 더욱 커집니다. Motor FB의 Input·Output Interface에 MotorData Structure를 사용하면 Equipment Logic과 Data Interface를 표준화할 수 있습니다. 다만 PLC 제조사마다 UDT 변경 시 기존 Instance Data를 처리하는 방법이나 Online Change의 제한사항이 다를 수 있으므로 운전 중인 설비에서 Structure를 변경할 때는 영향을 확인해야 합니다.

PLC Structure를 설계할 때 무엇을 주의해야 할까?

Structure는 Data를 체계적으로 정리할 수 있지만 너무 많은 정보를 하나의 Structure에 넣으면 오히려 Dependency가 커지고 Program을 이해하기 어려워질 수 있습니다. 따라서 Equipment의 Command, Status, Parameter와 Alarm처럼 의미 있는 기준으로 Member를 구성하는 것이 좋습니다. Variable Name도 Run, Ready, Fault, SpeedSet처럼 일관된 Naming Convention을 적용하면 여러 장비에서 동일한 의미로 사용할 수 있습니다. HMI, SCADA 또는 다른 PLC와 Structure Data를 Communication할 때는 양쪽 System이 동일한 Data Type과 Memory Layout을 사용하는지 확인해야 합니다. 특히 BOOL Packing, Padding, Byte Order와 32-bit Data의 Word Order가 다르면 Structure 전체를 그대로 전송했을 때 Data가 잘못 해석될 수 있습니다. 외부 Interface에서는 필요한 경우 명시적인 Mapping Layer를 구성하는 것이 안전합니다. 또한 Retentive Parameter와 실시간 Status를 같은 Structure에 무조건 섞기보다 데이터의 수명과 저장목적을 고려하여 분리할 수 있습니다. 결국 PLC Structure는 관련 Data를 하나의 의미 있는 단위로 묶어 프로그램을 구조화하고 장비별 Data Model을 표준화하는 핵심적인 PLC Data Management 방법입니다.