스마트 제어 및 HMI 소프트웨어: 엔지니어가 차세대 IIoT 네트워크 구축 지원
파커 하니핀의 마리사 터커, 선임 편집자 패트릭 와우르지니아크와 인터뷰
마리사, 산업용 사물인터넷[IIoT]에서 모션 컨트롤러의 역할은 무엇이며 어떤 소프트웨어가 관련되나요?
모션 컨트롤러를 넘어 프로그래머블 자동화 컨트롤러[PAC]가 IIoT에서 가장 큰 역할을 한다고 말하고 싶습니다. 기계 로직 외에도 PAC에는 루틴의 일부로 모션 제어가 포함되고 종종 임베디드 인간-기계 인터페이스[HMI]도 갖추고 있기 때문입니다. 이 접근법의 장점은 구성 요소가 동일한 로직을 사용하는 같은 장치에 있으므로 프로그램 간에 태그를 공유할 필요가 없다는 것입니다. 이는 프로그래밍 시간을 단축할 뿐만 아니라 IIoT 기능도 용이하게 합니다.
예를 들어 보겠습니다. 위치 오차는 과거 모션 컨트롤러에 매우 특화되어 있었지만, 임베디드 HMI에서 자동으로 접근 가능합니다. 그 임베디드 HMI에 웹 서버 기능이 있으면(많은 경우 그렇습니다), HMI가 현장 작업자와 플랜트 관리자에게 이메일이나 SMS[단문 메시지 서비스]로 즉시 경보를 보낼 수 있습니다. 이는 모션 컨트롤러가 오류를 PLC[프로그래머블 로직 컨트롤러]로 보내고, PLC가 데이터를 처리한 후 HMI로 보내야 하는 기존 접근법보다 훨씬 낫습니다. HMI에 웹 서버가 있을 수도 있고 없을 수도 있습니다. 장치 간 복잡한 데이터 전송이 제거되며, 로직은 하나의 프로그래밍 소프트웨어에 작성되어 하나의 하드웨어 장치에 다운로드됩니다. 너무 긴밀하게 통합되어 정보를 어디서나 쉽게 얻을 수 있습니다.
임베디드 HMI를 만드는 개발자가 다양한 사용자 그룹과 자격 증명을 만들 수 있도록 보장하는 것이 중요합니다. 이를 통해 프로그래머는 사용자에 따라 HMI의 맞춤형 인스턴스를 만들 수 있습니다.
기계 내 정보 흐름의 용이성도 중요하지만 기계 간 정보 흐름의 용이성도 중요합니다. IEC 61131-3 프로그래밍 표준은 한 제조업체가 개발한 기계가 다른 제조업체가 사용하는 동일한 언어를 사용하도록 보장합니다. 이는 통합업체가 두 개의 서로 다른 기계 시스템이 서로 통신하게 더 쉽게 만들기 때문에 큰 이점이며, IIoT로 가는 필수 단계입니다. OMAC[기계 자동화 및 제어 조직] 같은 조직은 PackML 표준을 추진하며, IEC 61131-3을 다음 단계로 끌어올려 시스템이 어떻게 프로그래밍되어야 할지를 권장할 뿐만 아니라 네트워크의 다른 기계가 사용할 수 있도록 기계가 제공해야 할 표준 태그 세트를 개발합니다.
공압 밸브와 위치 센서 같은 저수준 장치는 어떻습니까? 모든 것이 IoT의 일부가 되어야 하지 않나요?
과제는 저수준 장치에서 데이터를 가져와 유용한 정보로 바꾸는 것입니다. 한 가지 접근법은 이러한 장치 수준에서 처리를 수행한 다음 결과를 고성능 제어 버스를 통해 보내거나 직접 클라우드로 보내는 것입니다. 이는 매우 비싼 접근법이며 데이터 수집이나 중앙화에 도움이 되지 않습니다. 대안으로 IO-Link의 인기가 크게 증가하는 것을 보고 있습니다. IO-Link는 온도 센서, 솔레노이드, 공압 밸브 매니폴드 등에서 기본 데이터를 비싼 오버헤드 없이 수집할 수 있는 시리얼 기반 프로토콜입니다.
버스를 단순하게 유지함으로써 이 데이터를 수집하고 PAC 또는 모든 기계 시스템에 반드시 존재하는 PLC에서 처리하여 유용하게 만들 수 있습니다. 임베디드 HMI를 웹 게시용으로 갖춘 PAC를 사용하면 해당 정보를 네트워크 어디든 필요한 곳으로 보낼 수 있습니다. 데시벨 단위로 소리를 지속적으로 모니터링하는 센서가 있는 공압 시스템을 상상해보세요. PAC IO-Link로 보낼 유일한 데이터는 현재 dB입니다. PAC는 제조업체가 개발한 맞춤형 IEC 61131-3 함수 블록을 가질 수 있으며 여러 컨트롤러에서 작동할 수 있습니다. 이 함수 블록은 소음의 이상한 패턴을 확인하여 '아, 누출이 있을 수 있다'고 말할 수 있습니다. 프로그래머는 그 경보를 HMI의 유지보수 수준 사용자에게 보내 공압 장치가 고장 나기 전에 알릴 수 있습니다.
정보가 기계에서 클라우드로 어떻게 전달되며, 관련된 소프트웨어는 어떻습니까?
여전히 공장 현장과 IT 사이에는 큰 간극이 있습니다. 특히 여러 주나 국가에 여러 시설을 둔 제조 기업의 경우, 데이터를 외부 서버나 클라우드에 저장하는 것이 이상적입니다. 소프트웨어 측면에서 컴포넌트 제조업체는 기계 제조업체가 IT와 작업할 때 삶을 최대한 쉽게 만들어야 합니다.
대부분의 기계 제조업체는 IEC나 유사한 언어로 PLC나 PAC를 프로그래밍하는 데 익숙하므로, 기계 제어에 통합적 접근을 취해 정보 흐름을 쉽게 만들고 IT 서버와 정보를 쉽게 공유할 수 있게 하는 제조업체를 찾아야 합니다. 유럽에서 추진되는 또 다른 표준은 OPC-UA[OPC 통합 아키텍처]입니다. 이 클라이언트-서버 프로토콜은 크게 확장되어 기계 간, 기계-SCADA 간, 기계-서버 간 데이터 전송의 보편적인 방법을 허용합니다. 유연성 덕분에 OPC-UA는 급속히 IoT 표준이 되고 있습니다. IEC 61131-3 프로그램 내에서 몇 개의 태그를 공유하는 것만으로 데이터를 간단히 공유할 수 있도록 몇 번의 클릭으로 OPC-UA 연결을 쉽게 생성하는 내장 소프트웨어 도구가 있는 공급업체를 찾으십시오. 서버에서 접근 가능해지면 나머지는 IT가 처리하게 하십시오.
클라우드에서 정보가 유용합니까? 중요한 데이터가 현장 작업자의 손에, 플랜트 현장에 어떻게 전달됩니까?
사용 사례에 따라 다릅니다. 기계 작업자, OEM 기계 제조업체, 공장 소유자 등 IIoT를 생각하는 누구든 먼저 사용 사례를 개발해야 합니다. 예를 들어 공장 현장 관리자는 전체 설비 효율[OEE] 정보를 원할 수 있습니다. 이런 유형의 정보는 일반적으로 더 넓은 공공 영역과 공유할 것이 아니므로 내부 서버를 사용하는 것이 가장 좋습니다. 그러나 공장 현장 관리자는 종종 기계에서 멀리 떨어져 있거나 책상에 있지 않지만 여전히 OEE를 봐야 할 수 있습니다. 사용 사례가 솔루션을 주도합니다: 기계에 웹 서버가 있는 임베디드 HMI가 있으면 사용자는 iOS나 안드로이드 플랫폼에서 연결하고 자격 증명을 입력하여 기계의 OEE를 볼 수 있습니다. 외부 클라우드 필요 없습니다. 이 공장 내 네트워크는 종종 '포그(fog)' 컴퓨팅이라고 불립니다.
또 다른 예는 여러 위치의 여러 공장 라인의 수율 데이터를 모니터링해야 하는 구매 담당자입니다. 외부 서버가 유일한 답입니다. 민감한 회사 정보 노출 위험을 최소화하기 위해 프로그램은 수율 대신 총 출력만 게시할 수 있습니다. 이 솔루션은 클라우드 서버 사용을 요구하지만, 두 가지 이유로 외부 서버로 데이터를 보낼 때 자제해야 함을 보여줍니다: 일반적으로 내부 또는 '포그' 네트워크에 보관하는 것보다 덜 안전하고, 대부분의 플랜은 회사에 외부 클라우드로 데이터 전송 및 저장에 대해 요금을 부과합니다.
마케터들은 인더스트리 4.0을 훌륭하게 홍보했지만, 각 사용자는 '이 정보를 어떻게 활용할 수 있을까?'라고 물러서서 물어야 합니다. 클라우드는 당신이 생각하는 것만큼 필요하지 않을 수 있습니다.
이 모든 연결성이 비용을 증가시키지 않나요?
증가시킬 수 있지만, 반드시 그렇지는 않습니다. 3~4년 후 당신의 회사가 IoT 준비가 되었지만, 웹 서버나 OPC-UA를 통한 통신을 어렵거나 불가능하게 만드는 장치를 지정했거나, 데이터 흐름을 훨씬 쉽게 만드는 단일 기계 PAC 대신 전통적인 단편적 설계를 선택했을 때 비용이 많이 듭니다. 이 실수를 완화하려면 온도 제어에서 외부 클라우드로 바로 가는 엄청나게 비싼 센서를 구입하여 기계의 다른 모든 장치를 우회할 수 있습니다. 거기서부터는 다른 사람의 소프트웨어를 사용하여 전체 맞춤형 레이어나 웹사이트를 프로그래밍하여 데이터를 유용하게 만들어야 합니다. 당신은 그 사람이 되고 싶지 않을 것입니다.
대신 IIoT를 스마트하게 배포하십시오: 첫날부터 기계 설계의 일부로 만드십시오. 새로운 애플리케이션을 구축 중이라면, 당신의 조직이 지금 고려하지 않더라도 전환할 완벽한 위치에 있습니다. 오늘 당신이 하는 선택이 나중에 수십만 달러를 절약할 수 있습니다.
또한 IO-Link 같은 버스를 지원하는 저수준 장치를 선택하여 저렴하게 데이터를 꺼내십시오. 많은 소스에서 데이터를 사용할 수 있게 하는 비용 효율적인 표준 프로토콜을 사용하십시오. 단일 컨트롤러에 단일 프로그래밍 소프트웨어를 사용하여 프로그래밍을 단순화하십시오. 기계 컨트롤러가 반드시 추가 게이트웨이를 요구하지 않고 클라이언트-서버 관계를 가질 수 있는지 확인하십시오. 그렇게 하면 다른 위치로 정보를 라우팅해야 할 때 IEC 기반 프로그램에서 바로 할 수 있습니다. 포그 컴퓨팅을 잊지 마십시오. 웹 서버 기능이 있는 임베디드 HMI를 갖춘 PLC가 있다면 클라우드를 전혀 사용하지 않고 모든 IIoT 사용 사례를 충족할 수 있을지도 모릅니다. 그리고 클라우드가 필요하다면, IT가 가장 잘하는 일을 할 수 있도록 OPC-UA 서버로 공유하기 쉽게 만드는 소프트웨어가 있는 컨트롤러를 선택하십시오.
현명한 선택은 IIoT 전환을 매우 저렴하게 만들지만, 선택은 지금 해야 합니다.