올바른 산업 자동화 컨트롤러 선택: 종합 가이드

산업 자동화 컨트롤러를 선택할 때 PLC, PAC, IPC라는 단어가 들어간 용어뿐만 아니라 몇 가지 중요한 용어를 고려해야 합니다. 애플리케이션 요구사항을 명확히 정의해야 하며, 확장성 니즈도 선택 전에 고려해야 합니다.

우선 장비의 운영 니즈를 분할하는 것이 좋은 시작점입니다. 이는 사용자가 기계 제작자가 지정한 컨트롤러 범위를 평가하는 데 도움이 됩니다. 자동화 시스템은 제조 시나리오에 어떻게 적합하느냐에 따라 종합 솔루션 또는 개별 제어를 제공할 수 있습니다.

프로그래머블 로직 컨트롤러(PLC), 프로그래머블 자동화 컨트롤러(PAC), 산업용 개인 컴퓨터(IPC)는 단일 스테이션, 기계, 조립 라인, 심지어 전체 플랜트 플로어에 대한 제어를 제공할 수 있습니다. 통합 제조 시스템의 경우 이더넷을 통해 통신하는 원격 입/출력 베이스를 갖춘 단일 대형 컨트롤러를 사용해 엔드투엔드 제어를 제공할 수 있습니다. 그러나 자동화 시스템을 논리적 섹션으로 분해하는 모듈식 접근이 더 적합한 때도 있습니다. 그런 경우 자동화는 구획화되어 작업량에 따라 더 작은 PLC들 사이에 분산됩니다.

일부 자동화 전문가는 이 두 결정을 완전히 별개로 보며, 각각 다른 플랫폼이 필요하다고 결론 내립니다. 하지만 이는 사실이 아닐 수 있습니다. 일부 제조업체는 동일한 프로그래밍 소프트웨어와 호환되는 다양한 크기 옵션의 컨트롤러를 제공합니다. 단일 프로그래밍 환경의 존재는 시스템 내에 유연성을 심어주며, 프로젝트를 한 PLC에서 다른 PLC로 이식할 수 있어 프로그램 개발 관련 비용을 절감할 수 있습니다.

그러나 정작 어려운 결정은 대형 PLC를 단일 프로그램에 사용할지, 모듈식 접근을 사용할지 결정하는 것입니다. 이 결정은 PLC, PAC, PC 기반 컨트롤러를 선택하는 것보다 훨씬 더 복잡합니다. 다음 요소들을 고려하면 좋은 기반을 구축하는 데 도움이 될 수 있습니다:

• 신규 또는 기존 시스템
• 이산 장치(Discrete devices)
• 환경 이슈
• 루프 제어(Loop control)
• 아날로그 장치
• 특수 모듈(Specialty modules)
• I/O 위치
• 통신(Communication)
• 프로그래밍(Programming)

시스템이 신규인지 기존인지 여부는 많은 혼란을 해소하고 나머지 선택 요소에 영향을 줄 수 있습니다. 이미 제품이 설치되어 있다면 호환성이 최우선이 되어 쓸모없는 여러 제품을 배제합니다.

컨트롤러 선택은 환경 조건에도 의존합니다. 온도, 습도, 먼지 등과 관련된 극한 조건이 있다면 컨트롤러는 작동을 유지하기 위해 이를 충족해야 합니다.

I/O의 수, 유형, 위치

I/O 개수 정의와 현장 장치 유형이 다음 순서입니다. 스프레드시트에 모든 이산 입력과 출력을 나열하며 각 유형(디지털 센서, 아날로그 센서, 액추에이터, 제어 밸브 등)을 정의하는 것으로 시작하세요. 적어야 할 파라미터에는 통신 프로토콜, 전력 환산 등이 포함됩니다.

I/O 포인트의 유형과 개수는 제어 플랫폼 선정에 큰 영향을 미칩니다. 기계 제작자는 종종 미래 확장을 위한 여지를 남기지 않고 즉각적인 니즈만 충족하는 컨트롤러를 선택하는 실수를 범합니다. 최소 20%의 확장 여지를 포함하면 향후 큰 위기를 예방할 수 있습니다. 일부 컨트롤러는 아날로그, 고속 입력 등 제한된 I/O 유형만 가질 수 있어 향후 문제가 될 수 있습니다.

앞서 언급한 스프레드시트에는 모든 아날로그 장치의 기능과 신호 레벨, 전류/전압 루프, 저항 온도 감지기(RTD) 입력, 열전대(thermocouple) 등의 개별 합계를 포함해야 합니다. 컨트롤러 사양이 이러한 요구사항과 일치해 모든 아날로그 입출력과 신호 유형을 지원해야 합니다.

또한 특수 I/O도 스프레드시트에 나열해야 합니다. 여기에는 고속 입/출력, 카운터, 실시간 클록, 서보/스테퍼 모터 등이 포함될 수 있지만 이에 국한되지 않습니다. 일부 컨트롤러는 특수 기능이 없을 수 있으므로 결정 전에 철저한 분석을 수행해야 합니다. 컨트롤러의 역량과 애플리케이션 요구사항을 이해하는 것이 필수적입니다.

I/O 단자의 물리적 위치는 현장 장치에 상대적으로 정의되어 스프레드시트에 기록되어야 합니다. 이러한 요구사항을 더 작은 모듈로 분해하면 로컬 및 원격 I/O 니즈를 이해하는 데 도움이 되며, 이는 어떤 실시간 통신 프로토콜이 필요한지 결정하는 데 도움이 됩니다. 일부 설치는 로컬을 선호하는 반면 다른 것들은 원격 I/O에 크게 의존합니다.

컨트롤러와 서브시스템 간 거리가 상당하다면 각 현장 장치를 케이블로 연결하는 시련을 겪는 대신 원격 I/O가 좋은 선택이 될 것입니다. 또한 통신 방식과 속도가 지원되어야 합니다. 시리얼(Serial) 또는 이더넷 기반 I/O 여부와 관계없이 말입니다. 오늘날의 산업 환경에서는 이더넷/IP(EtherNet/IP) 같은 이더넷 프로토콜이 모드버스(Modbus) 같은 오픈소스 프로토콜의 특수 개발 버전과 함께 인기를 얻고 있습니다.

통신(Communications)

주변 장치, 분산 I/O, PLC, 엔터프라이즈 시스템 간의 통신은 일부 플랜트 플로어에서 필수적일 수 있습니다. 이 범위는 초기에 정의해야 하며, 앞으로 나아갈수록 더 복잡해질 것임을 고려해야 합니다. 일부 컨트롤러는 1~2개 포트만 제공하며, 그 중 하나는 프로그래밍용으로 예약되어 있을 수 있고, 다른 것들은 미션 크리티컬 애플리케이션에 필요한 특정 프로토콜을 지원하지 않을 수 있습니다.

컨트롤러와 HMI 또는 현장 장치 간에 이루어질 통신도 명시해야 합니다. 사물인터넷의 등장으로 통신 옵션을 열어두는 것이 필수적이 되었습니다. 따라서 컨트롤러에 추가 이더넷, 시리얼, USB 포트가 있는지 확인해야 합니다.

모드버스 TCP(Modbus TCP), 이더넷/IP(Ethernet/IP), 프로피버스(Profibus) 등 이더넷 프로토콜 사양은 현재 요구사항과 미래 확장을 모두 고려해 수행해야 합니다.

하드웨어(Hardware)

반드시 고려해야 할 일반적인 하드웨어 고려사항에는 스캔 타임 속도, 메모리 양, 배터리 백업이 포함됩니다. 컨트롤러는 프로그램 요구사항과 데이터를 모두 지원할 만큼 충분한 시스템 메모리를 가져야 합니다. 이러한 추정은 시스템의 장치 수를 파악해 할 수 있습니다. 데이터 메모리는 동적 데이터 조작과 변수 저장에 사용되며, 예로는 사전 설정값, 타이머의 내부 플래그, 누적 시간/카운트 등이 있습니다.

데이터 테이블 크기는 컨트롤러에 히스토리컬 데이터를 저장해야 하는 경우 커질 수 있습니다. 데이터 로깅, HMI/SCADA 인터페이스, 접근 방식, 히스토리언 데이터베이스는 모두 명확히 지정되어야 하며, IIoT 시나리오에서는 네트워킹, 프로토콜 정의, 메모리 니즈도 중요해집니다.

명령 유형과 프로그램 크기 자체도 메모리 니즈에 영향을 줄 수 있습니다. 프로그램이 여러 시퀀스, 정교한 제어 기능, 결함 로직을 가지면 메모리 증가가 필요할 수 있습니다. 요구사항은 프로그램 렁(rung)과 데이터 파일을 기반으로 추정할 수 있습니다. 컨트롤러 사양도 연구해야 합니다. 일부는 태그명 기반 프로그래밍을 가지고 있고, 다른 것들은 고정되었지만 확장 가능한 데이터 테이블을 가집니다.

프로그램과 데이터 테이블이 소비하는 메모리 양은 컨트롤러 모델에 따라 다릅니다. 좋은 가정은 각 이산 I/O 장치가 5~100워드 메모리를 사용하고, 아날로그 I/O는 25~500워드를 사용한다는 것입니다. 넓은 범위로 인해 복잡한 프로그램의 추정이 어려울 수 있습니다. 더 나은 접근법은 일부 코드 블록을 작성하고 메모리 사용량을 연구하는 것입니다.

빠른 스캔 타임이 필요한 애플리케이션이 있을 수 있으며, 컨트롤러의 CPU 속도와 명령 실행 속도는 이에 대한 결정적 요소입니다.

소프트웨어(Software)

프로젝트의 거의 절반은 소프트웨어 프로그래밍의 품질에 의존하며, 이는 제조업체가 제공하는 소프트웨어에 의존합니다. 컨트롤러 프로그래밍 소프트웨어를 선택할 때 다음 고려사항을 해야 합니다:

• 사용 편의성
• 선호도
• 투자
• 교육 리소스
• 데이터 로깅 및 원격 접근

대부분의 컨트롤러는 타이머, 코일, 접점, 카운터 등 약 20개 지침이 포함된 무료이고 사용하기 쉬운 프로그래밍 소프트웨어를 포함하며, 이는 소규모 애플리케이션에 충분합니다. 하지만 요구사항의 복잡성이 증가하면 문제가 될 수 있습니다. 고급 컨트롤러는 프로그래머를 지원하는 수많은 기능을 통합한 포괄적인 프로그래밍 소프트웨어를 포함하는 경우가 많습니다.

프로그래밍 소프트웨어 선택은 사용자의 컴포트 존에 크게 의존하므로 주관적인 결정입니다. 프로그래머는 소프트웨어 선호도에 대한 자신의 의견을 가질 수 있지만, 이는 종종 상위 경영진이 표준 컨트롤러 프로그래밍 소프트웨어와 방법을 강제함으로써 무시됩니다.

어쨌든 프로그래밍 소프트웨어를 자세히 설명하는 충분한 문헌이 없는 컨트롤러는 선택하지 않아야 합니다. 대부분의 제조업체는 온라인 리소스 트렌드에 적응해 상세한 문서를 제공하고 동료 프로그래머들이 질의를 교환할 수 있는 포럼을 만들었습니다. 하지만 모든 제조업체가 이에 동참한 것은 아니므로 PLC 선택 전 신중한 배경 조사가 필수적입니다.

기술 지원 비용도 고려해야 합니다. 문서가 특정 문제를 해결하는 데 도움이 되지 않을 때가 있을 수 있습니다. 일부 공급업체는 제한된 시간 무료 서비스를 제공하며, 프로그램 개발 일정을 따른다면 도움이 될 수 있습니다.

개발 후 프로그램은 철저히 테스트되어야 하며, 이를 위해 소프트웨어는 PID 루프 응답과 모션 프로파일 형태로 볼 수 있어야 합니다. 이는 하드웨어 연결 없이도 완전한 시뮬레이션 테스트를 가능하게 합니다. 최신 개발 소프트웨어는 시뮬레이터를 통합해 본격적인 테스트를 허용합니다.

결론적으로, 소프트웨어, 하드웨어, 통신 모두에 대해 원-사이즈-핏츠-올(one-size-fits-all) 접근법을 채택하지 않아야 합니다. 선택된 컨트롤러는 자동화 요구사항을 완전히 충족하면서 설계 변경에 따른 발전 여지를 가져야 합니다.