산업 자동화 분야에서 래더 로직은 가장 일반적으로 사용되는 프로그래밍 언어 중 하나로 남아 있습니다. 그러나 더 복잡한 제어 객체의 경우 객체{0}}지향 프로그래밍이 확실히 매우 효율적인 접근 방식입니다. 먼저 객체지향 프로그래밍에 대해 논의해 보겠습니다.-
객체{0}}지향 프로그래밍은 고급 컴퓨터 언어의 고급 프로그래밍 패러다임입니다.- 이러한 설계 철학은 산업 제어 시스템의 PLC 프로그램에도 적용될 수 있습니다. "상속"과 같은 객체{4}}지향 프로그래밍-의 우수한 기능 중 다수를 구현할 수 없고 PLC 언어가 객체지향 프로그래밍 언어의 특성조차 갖지 못할 수도 있지만{7}}객체지향 프로그래밍의 기본 개념은 클래스와 클래스 인스턴스(즉, 객체)입니다. 우리는 이러한 개념을 활용하기만 하면 됩니다. 컴퓨터 프로그래밍에서는 클래스를 정의하기 위해 특정 엔터티를 추상화하고 일반화해야 합니다. 그러나 산업용 제어 시스템에서는 모터 및 밸브와 같은 제어 개체가 명확하게 정의된 제어 범주입니다. 추상화할 필요 없이 직접 클래스를 정의할 수 있습니다. 다음 섹션에서는 Siemens의 Step7 프로그래밍 언어와 Schneider의 Unity 프로그래밍 언어를 사용하여 PLC용 객체 지향 프로그래밍을 설명합니다.
I. 구현 방법
7단계의 객체{0}}지향 프로그래밍은 함수 블록(FB)을 사용하여 구현됩니다. 이 주제가 나오면 사람들은 종종 Siemens가 제안한 모듈형 프로그래밍을 떠올립니다. 사실 이는 같은 개념이지만, 지멘스가 도입한 '모듈화', '백그라운드 데이터 블록', '다중 배경' 등의 용어로는 사용자가 이 뛰어난 디자인 철학을 항상 명확하게 이해하고 적용할 수 있는 것은 아니다.
그러나 객체지향 프로그래밍의 관점에서 접근하면 이 디자인 패턴을 훨씬 더 잘 이해할 수 있습니다. "FB 블록"은 "클래스"로 간주됩니다. 이는 유사한 제어 개체에 대한 코드 그룹으로 볼 수 있습니다. 예를 들어, MM440 가변-주파수 드라이브의 경우 "MtrMM440"이라는 FB 블록을 작성할 수 있습니다. 객체지향 프로그래밍에서는 이를 "클래스"라고 합니다. 특정 모터에 대한 제어를 프로그래밍해야 하는 경우 객체 지향 프로그래밍에서-백그라운드 DB 블록을 여기에 할당할 수 있습니다. 이를 클래스 구현이라고 합니다(즉, 클래스의 인스턴스 생성: 객체). 여러 모터를 제어해야 하는 경우 이 FB 블록에 서로 다른 백그라운드 DB를 할당할 수 있습니다. 이는 클래스의 여러 인스턴스를 생성하는 것과 같습니다.
Step7에는 또 다른 유형의 프로그램 블록인 FC 블록이 있습니다. 주로 FC 블록을 사용하는 프로그래밍을 Siemens 시스템의 구조적 프로그래밍이라고 하며, 이는 컴퓨터 프로그래밍-즉, 순전히 함수 기반 프로그래밍의 절차적 프로그래밍과 유사할 수 있습니다-.
Schneider의 Unity 소프트웨어를 사용하여 프로그래밍하면 객체 지향 프로그래밍을 더 잘 이해할 수 있습니다.{0}} DFB 정의에는 입/출력 매개변수, 개인/공용 변수, 코드 구현이 포함됩니다.-이는 정확히 컴퓨터 객체 지향 프로그래밍에서 '클래스'의 기본 요소입니다.{3}} 클래스(객체)의 인스턴스를 생성하는 것은 일반 "부울" 변수를 생성하는 것만큼 간단합니다. "펑션 블록"에서 이 "클래스"의 변수를 정의하기만 하면 됩니다.
Step7과 Unity는 모두 절차 지향 프로그래밍 접근 방식과 객체 지향 프로그래밍 접근 방식을 모두 지원합니다.- 이 두 접근 방식의 차이는 C 프로그래밍과 고급 컴퓨터 언어 C++ 프로그래밍의 차이와 유사합니다.-
다음 설명에서는 Step7의 FB와 Unity의 DFB를 "클래스"라고 하며, Step7의 백그라운드 데이터베이스와 결합된 FB 및 Unity의 DFB 인스턴스를 "객체"라고 합니다.
II. 객체-지향 프로그래밍 아키텍처
위의 논의에서는 구현 세부 사항을 다루고 있지만 프로그래밍 철학은 프로그램 아키텍처를 기반으로 합니다. 단순히 코드의 특정 부분에 객체지향 메서드를 사용한다고 해서 전체 프로그램이 객체지향이라는 의미는 아닙니다.- 이러한 유형의 프로그래밍에는 다음 측면을 기반으로 한 접근 방식이 필요합니다.
1. 구조화된 회로 설계.
이 섹션에서는 주로 자동화된 생산 라인에 중점을 둡니다. 독립형 공작 기계의 경우 단순화된 구조를 사용할 수 있습니다.
<1>자동화된 생산 라인 레이어: 이 레이어는 그 아래의 다양한 구역을 제어하는 메인 PLC를 갖춘 가장 높은 레벨입니다.
<2>프로젝트 레이어: 이 레이어에는 독립적인 전력 분배 시스템이 있지만 PLC는 없습니다. 자동화된 생산 라인에 의해 제어되는 분산 모듈로만 구성됩니다. 이름에서 알 수 있듯이 독립성이 높고 별도의 프로젝트로 설계 및 제작이 가능합니다. 자동화된 생산 라인이 상대적으로 작은 경우 이 레이어는 생략될 수 있습니다.
<3>기능 그룹 수준: 프로세스 요구 사항에 따라 특정 프로세스 기능을 수행하는 장비 세그먼트가 기능 그룹으로 그룹화됩니다. 이 그룹은 엔지니어링 수준에 속합니다. 엔지니어링 레벨을 생략하면 자동화 생산 라인 레벨에 속합니다. 객체{2}}지향 프로그래밍이 반드시 위 구조를 사용해야 하는 것은 아니지만, 잘 설계된 전기적 구조가-객체지향 프로그래밍에 더 도움이 됩니다.
2. 모든 제어 개체 논리는 "클래스" 내에서 구현됩니다.
이를 위해서는 제어 객체와 관련된 정보를 분석하는 것이 필요하다. 예를 들어, 모터의 경우 다음 관련 정보를 고려해야 합니다.
입력 정보:
<1>,모터의 회로 차단기, 열 계전기 등 회로 보호 정보.
<2>,모션 모터용 리미트 스위치, 팬용 압력 스위치, 오일 펌프용 오일 레벨 스위치와 같은 기능 보호 정보.
<3>시작 및 중지 조건: 위에 언급된 회로 보호 및 기능적 보호로 인해 모터 작동이 중지될 수 있고 재설정으로 인해 다시 시작될 수 있지만 여기에 언급된 조건은 순차 제어 프로세스의 단계와 같은 정상 작동 중-시작 및 중지 조건과 관련이 있습니다.
<4>제어 모드: 수동 및 자동과 같은.
<5>오류 재설정: 재설정 신호를 통해 시스템을 다시 시작합니다.
출력 정보:
<1>,모터를 제어하는 주 접촉기와 같은 제어 출력.
<2>,상태 정보 출력
<3>,오류 출력
상태 저장 정보:
코드 구현에 사용되는 중간 변수와 HMI에서 읽을 수 있는 상태 변수입니다. 위의 모든 정보를 단일 클래스로 통합하고 클래스 매개변수를 최대한 표준화합니다. 그러나 고급-수준 프로그래밍 언어와 비교하면 여전히 몇 가지 차이점이 있습니다. Step7의 경우 따라야 할 표준은 다음과 같습니다. 다음 구조적 프레임워크(전기적 구조는 위의 소개를 기반으로 함)에 설명된 것처럼 프로그램 구조는 FC를 사용하여 구현되고 개체 제어는 FB를 사용하여 구현됩니다. 이는 단지 대략적인 PLC 프로그램 아키텍처일 뿐입니다. 좋은 아키텍처는 더욱 포괄적이고 과학적이어야 합니다.
3. 데이터 구조를 신중하게 계획하세요
데이터 구조를 정의하는 것은 매우 중요하며, 저장 공간에 대한 걱정 없이 이러한 구조를 최대한 통합하도록 노력해야 합니다. 최신 PLC 메모리는 많은 양의 데이터를 수용하기에 충분합니다. 7단계에서는 가능하면 클래스 외부에서 사용자{2}}사용자 정의 유형(UDT) 정의를 피해야 한다는 점은 주목할 가치가 있습니다. 대신 클래스 내에서 정의하세요. 이로 인해 여러 클래스에 걸쳐 동일한 구조에 대한 중복 정의가 발생할 수 있지만 클래스의 독립성은 향상됩니다.
다음 섹션에서는 이러한 두 가지 프로그래밍 접근 방식을 비교해 보겠습니다.
객체지향 프로그래밍의 장점{0}}래더 논리와 비교하여 객체지향 프로그래밍은 다음과 같은 장점을 제공합니다.
• 코드 이식성 및 재사용 용이성;
• 수학 함수, 루프 및 기타 구성을 쉽게 사용할 수 있습니다.
• 객체{0}}지향 프로그래밍은 거의 모든 컴퓨터 프로그래밍 과정에서 가르칩니다.
• 코드는 다양한 하드웨어 플랫폼에서 실행될 수 있습니다.
객체지향 프로그래밍을 마스터하려면 먼저 객체의 개념과 사용 방법을 이해해야 합니다. 객체나 클래스가 작성되면 여러 호출을 통해 쉽게 재사용할 수 있습니다. 예를 들어, 모든 입력, 출력 및 오류를 처리하는 모터를 제어하는 개체를 만듭니다. 필요한 경우 이 단일 제어 개체를 여러 번 인스턴스화하여 여러 모터를 제어할 수 있습니다. 이를 주문형-인스턴스화라고 합니다. 여러 모터를 제어해야 하는 경우 이 단일 개체를 반복적으로 사용할 수 있습니다. 필요할 때 호출되며, 사용되는 대로 인스턴스가 생성됩니다.
각 모터의 각 인스턴스에는 모터 정지, 모터 작동, 모터 속도 및 모터 과부하와 같은 고유한 특성이 있습니다. 대부분의 프로그래밍 작업은 객체가 처음 생성될 때 완료됩니다. 이는 래더 로직과는 다른 사고방식으로, 일단 객체를 구축하면 사용 및 재사용이 쉽기 때문에 더욱 강력합니다. 객체-지향 프로그래밍을 사용하면 복잡한 수학 함수, 루프 계산, 배열 및 중첩 서브루틴을 더 쉽게 수행할 수 있습니다. 고등학교, 대학교, 온라인 튜토리얼 등 거의 모든 컴퓨터 프로그래밍 과정-에서-이 개념을 가르칩니다. 생성된 코드는 이식 가능하며 다양한 하드웨어 플랫폼에서 실행될 수 있습니다.
"래더 로직은 릴레이 제어 시스템에 사용되는 전기 래더 다이어그램의 형식을 따르며 대부분의 사람들이 이를 빠르게 배우고 익힐 수 있습니다."
그러나 래더 논리에 비해 객체{0}}지향 프로그래밍에는 다음과 같은 단점이 있습니다.
• 더 높은 비용;
• 더욱 가파른 학습 곡선;
• 유지보수 담당자에게는 문제 해결이 특히 쉽지 않습니다.
• 일반적으로 소스 코드를 프로세서에 업로드하기 전에 컴파일이 필요합니다.
래더 로직에 비해 객체{0}}지향 프로그래밍에는 더 많은 메모리와 처리 능력이 필요한 경우가 많아 비용이 더 많이 듭니다. 객체지향 프로그래밍 언어를 배우는 데는 시간이 더 오래 걸릴 수 있습니다. 교실 수업이 필요할 수 있으며 핵심 개념을 익히려면 상당한 시간, 연습, 테스트 및 적용이 필요합니다. 프로그래머는 추적 프로그램을 사용하여 코드를 추적하거나 디버거를 사용하여 논리를 디버그하기 위해 객체 지향 프로그래밍을 자주 연구해야 합니다. 이러한 유형의 고급-프로그래밍으로는 실시간 온라인 모니터링 기능을 구현하기가 어려울 수 있습니다.-
소스 코드를 컨트롤러에 다운로드하려면 먼저 컴파일해야 합니다. 일반적으로 소스 코드는 프로세서의 메모리에 저장되지 않습니다. 이는 컴파일된 코드는 일반적으로 편집할 수 없으므로 소스 코드를 백업할 때 주의를 기울여야 함을 의미합니다. 객체{3}}지향 프로그래밍에서는 라이브러리 파일을 컴파일 프로세스 중에 사용되는 다른 리소스와 연결해야 합니다. 연결과 리소스에 대한 이해가 없으면 프로그램을 실행하기가 어렵습니다.
래더 로직의 장점:
래더 로직은 간단하고 자체적으로 -문서화되는 코딩 방법-으로 일부에서는 프로그래밍 언어로서의 자격이 있는지 의문을 제기하기도 합니다. 이는 릴레이 제어 시스템에 사용되는 전기 래더 다이어그램의 형식을 따르며 대부분의 사람들이 빠르게 배우고 익힐 수 있습니다. 수십 년 동안 기계 자동화 분야에서 널리 사용되는 유일한 프로그래밍 언어였으며, 가까운 미래에도 자동화 산업의 주요 프로그래밍 언어 중 하나로 남을 것입니다.
시간이 지나면서 다양한 배경과 분야의 사람들이 업계에 진출하면서 다양한 프로그래밍 언어가 산업 자동화 툴킷에 도입되었습니다. 여기에는 기능 블록 프로그래밍, 구조화된 텍스트, 상태 프로그래밍 및 순차 기능 차트가 포함됩니다. 이 네 가지 프로그래밍 언어는 래더 로직과 함께 IEC(International Electrotechnical Commission) 표준 IEC 61131-3에서 정의한 표준 프로그래밍 언어를 구성합니다.
IEC 61131의 논리는 모든 공급업체가 이 표준을 준수한다면 -적어도 어느 정도는-사람이 이 5가지 프로그래밍 언어만 배우면 여러 공급업체가 제공하는 플랫폼 간에 쉽게 전환할 수 있다는 것입니다. 그러나 이는 사실이 아니다.
기본 래더 논리(예: 릴레이 접점 및 코일 사용)는 동일한 방식으로 작동합니다. 그러나 프로그래밍할 때 각 공급업체의 구문과 사용자 경험은 물론 프로그래밍 플랫폼을 사용하는 방법에 대한 구체적인 내용도 배워야 합니다. 표준화가 부족함에도 불구하고 래더 로직은 객체지향 프로그래밍에 비해 다음과 같은 이점을 제공합니다.
• 이는-기계 및 프로세스 제어에 매우 적합합니다.
• 본질적으로 자체적으로-문서화되므로 이해하기가 더 쉽습니다.
• 제어되는 시스템의 문제 해결을 용이하게 합니다.
• 디버깅이 쉽습니다.
• 소스 코드는 일반적으로 프로세서에 저장될 수 있습니다.
래더 로직은{0}}기계 및 프로세스 제어, 특히 다수의 개별 입력 및 출력(I/O)이 있는 자동화 시스템에 매우 적합합니다. 수년에 걸쳐 래더 로직은 아날로그 I/O를 처리하기 위해 지속적으로 개선되어 수많은 프로세스 제어 애플리케이션에 더욱 적합해졌습니다.
기계 제어 애플리케이션에 비해 프로세스 애플리케이션은 아날로그 I/O의 비율이 더 높은 경우가 많습니다.
래더 로직은 객체지향 프로그래밍보다 사용하기가-쉽기 때문에 많은 숙련된 기술자와 엔지니어가 빠르게 배울 수 있습니다. 논리는 매우 체계적이고 체계적이며, 자체 문서화 특성으로 인해 이해하고 숙달하기가 더 쉽습니다.- 장치를 활성화하려면 모든 코드 줄이 true로 평가되어야 합니다. 제어할 모터가 5개라면 최소 5줄의 코드가 필요하므로 프로세스가 크게 단순화됩니다.
"래더 로직 소스 코드와 설명자는 일반적으로 컨트롤러에 저장되므로 소스 코드에 액세스할 필요가 없으므로{0}}프로그래머가 컴파일된 프로그램을 이해하려고 할 때 종종 겪는 좌절감을 없앨 수 있습니다."
전기 엔지니어와 유지 보수 담당자에게 래더 로직은 매우 직관적입니다. 래더 논리에는 객체지향 프로그래밍과 다른 사고 방식이 필요하지만, 약간의 연구를 통해 빠르게 익힐 수 있으며 다른 사람이 작성한 코드를 이해하는 데 시간이 덜 걸립니다. 논리문이 참일 때와 거짓일 때 명확합니다. 프로그래밍 경험이 부족한 사람이라도 켜짐/꺼짐, 코일 에너지 공급, 비교 변수, 일반적인 수학 함수 등의 개념을 쉽게 이해할 수 있습니다.
간단하고 사용하기 쉬우며 문제 해결 및 디버깅이 간소화됩니다. 로직을 모니터링하면 현재 작동 상태를 쉽게 이해할 수 있습니다. 소프트웨어 학위나 고급 프로그래밍 기술이 필요하지 않습니다. 래더 로직을 사용하면 유지 관리 및 엔지니어링 담당자가 쉽게 프로세스를 추적하고 무슨 일이 일어나고 있는지 이해할 수 있습니다. 래더 논리는 진리표로 생각할 수 있습니다. 즉, 왼쪽 논리가 참이면 오른쪽 논리가 활성화됩니다.
래더 로직 소스 코드와 설명자는 일반적으로 컨트롤러에 저장됩니다. 이는 프로그래머가 소스 코드에 액세스하지 않고 컴파일된 코드를 이해하려고 할 때 자주 경험하는 좌절감을 없애줍니다.-객체 지향 프로그래밍에서도 흔히 발생하는 문제-입니다.
그러나 객체지향 프로그래밍과 비교할 때 래더 논리에는 다음과 같은 단점도 있습니다.
• 컴퓨터 프로그래머와 IT 전문가는 래더 로직에 익숙하지 않습니다.
• 수학적 기능, 텍스트 처리, 데이터 처리가 어렵다.
• 스캔 시간에 따라 달라집니다.
• 이를 실행하려면 프로그래밍 가능 논리 컨트롤러(PLC)와 같은 특수 하드웨어가 필요합니다.
사다리 논리는 컴퓨터 프로그래머와 IT 전문가가 학교에서 배우지 않기 때문에 익숙하지 않은 기호 언어입니다. 래더 로직에서 수학 함수, 텍스트 문자열 및 데이터를 처리하는 것은 어려울 수 있습니다. 주된 이유는 래더 로직이 원래 이러한 기능을 처리하도록 설계되지 않았기 때문입니다.
래더 로직도 스캔 시간에 따라 달라집니다. 프로그램이 클수록 로직을 스캔하고 처리하는 데 더 많은 시간이 필요합니다. 래더 로직을 실행할 때 시스템은 입력을 읽고, 로직을 스캔하고, 데이터 테이블과 출력을 업데이트하고, 통신을 수행한 후 사이클을 반복합니다. 특정 로직의 더 빠른 실행을 보장하기 위해 인터럽트 및 기타 프로그래밍 기술과 같은 기능을 구현할 수 있습니다.
래더 로직으로 구성된 소프트웨어{0}} 기반 PLC는 PC에서 실행될 수 있지만 하드웨어(예: PLC)는 일반적으로 프로그래밍 소프트웨어와 호환되어야 하며 동일한 공급업체에서 두 제품을 모두 구입하는 것이 가장 좋습니다. 이렇게 하면 호환성이 보장되지만 공급업체를 전환하려는 경우에는 특히 편리하지 않습니다.
사용자는 래더 로직과 객체지향 프로그래밍의 장단점을 비교하는 것 외에도 이러한 프로그래밍 언어가 배포될 환경에서 어떻게 사용될지 평가해야 합니다. 공장이나 시설이 이미 래더 로직으로 표준화된 경우 객체지향 프로그래밍으로 대체하는 것은 권장되지 않습니다. 후자가 애플리케이션에 더 적합하더라도 마찬가지입니다. 객체지향 프로그래밍의 사용이 계속 증가함에 따라 향후 수십 년 동안 래더 로직과 공존할 것으로 예상됩니다. 미래 지향적인-생각을 갖고 있는 자동화 전문가라면-두 언어를 모두 마스터하는 것이 좋습니다.