공정이 정밀하고 복잡해질수록 공정을 제어하는 장비들 사이에 데이터를 전송하는 제어 통신의 비중이 증가하는 반면, 통신 프로토콜은 장비 제조사마다 서로 달랐기 때문에 옛날에는 공정에 필요한 모든 장비를 같은 통신 프로토콜을 사용하는 동일 제조사의 제품으로 통일하거나, 메이저 제조사의 프로토콜들을 통합한 비싼 인터페이스 제품을 사용하는 방법으로 통신 문제를 해결했었습니다.
(공정에 필요한 모든 장비들을 같은 통신 프로토콜을 사용하는 동일 제조사의 제품으로 통일해버리기)
이 비싼 통신 인터페이스 프로그램들이 바로 인터치나 싸이먼, 싸이텍과 같은 HMI 프로그램들이죠. ^^
공정 제어 인터페이스 프로그램인 HMI 입장에선 장비 간 통신은 필수사항이었기 때문에 장비 제조사와 제휴를 통해 통신 프로토콜을 수집하는데 집중 투자하여 인터페이스 역량을 늘려 나갔고, 사용자는 공정 관리의 편의성과 통신의 부담을 줄이기 위해 비싸지만 HMI 프로그램을 구입하여 사용했습니다.
(HMI의 대두로 통신에 유연성이 증가 하였고, 공정 제어 기술도 발달)
이렇게 통신 문제를 해결해 왔지만
여전히 사용자는 HMI와 연계되는 메이저 제조사의 제품만 강요 당하거나, HMI가 필요 없는 환경에서도 통신을 위해 비싼 라이센스를 구매해야 한다는 문제점과
소규모나 후발 장비 제조사는 메이저 제조사와 HMI 업체에 의한 통신 진입 장벽의 문제로 인해 HMI가 아닌 범용성 높은 표준 통신 프로토콜의 필요성이 부각되었습니다.
이러한 수요는 결국 1996년 공정 제어 디바이스 간 통신 표준 탄생의 원인이 되었고, 이때 탄생한 통신 규약의 이름이 바로 OPC입니다.
OPC의 등장으로 이제 통신이 필요한 모든 장비들은 OPC 프로토콜만 지원하면 OPC를 지원하는 다른 모든 장비와의 통신이 보장되는 편리함을 가져다주었고, 이러한 변화는 기존의 메이저 제조사와 HMI 업체의 가세 후 더욱 빠르게 성장하여 이젠 전 세계를 지배하는 프로토콜이 되었습니다.
(OPC 안에서 모두가 평등해진 평화로운 세상 ^^)
OPC 프로토콜을 사용하는 통신 과정을 좀 더 자세히 알아보면
제어 장비들을 OPC 통신을 통해 서버와 연결한 다음, 통신이 필요한 장치 내부 태그를 서버에 등록하면 사용자는 원하는 제어나 데이터를 서버에 접속하여 사용하는형태 입니다.
유지와 보수 또한 태그들이 등록된 서버만 관리하면 되니 운영도 매우 간단해집니다. ^^
HMI 환경은
다른 장비와 동일한 OPC 클라이언트 구조로 되어 있지만 OPC 서버를 HMI이 관리하게 함으로 사용자에게 좀 더 편의성을 제공합니다.
OPC 서버는 지금 현재 라이센스 유무를 떠나 매우 다양한 제품군이 있으며 프로토콜의 강력함 만큼 제어 공정 전반에 널리 사용되고 있습니다.
(무수히 많은 Free OPC 서버 리스트 1)
산업 표준인 만큼 이를 활용한 제품이 많아 구글에 간단한 검색만으로도 테스트나 학습용 OPC 서버를 쉽게 구할 수 있습니다. ^^
(무수히 많은 Free OPC 서버 리스트 2)
(Free OPC 서버 리스트 3)
OPC에 대한 간단 설명을 끝으로 이번 편을 마치며 이제 본격적으로 C#을 활용한 OPC 서버와 클라이언트 구성, 관리에 대한 내용으로 돌아오겠습니다. ^^
긴 글 봐주셔서 감사합니다!
와우 좋은 정보 공유해 주셔서 감사합니다
답글삭제쉬운 설명 감사합니다.
답글삭제OPC에 대해서 쉽게 설명해주셔서 감사합니다.
답글삭제C#을 활용한 OPC 서버와 클라이언트 구성, 관리에 대한 내용으로 돌아오시겠다고 하셨는데 혹시 관련내용 올리실 계획 없으신가 궁금합니다..