|
항목 |
DCS 제어기 |
PLC 제어기 |
1. 메모리 구조 |
사용자 정의 방식 |
고정 레지스터 방식 |
2. 태그 단위 |
구조체 단위 |
접점 단위 |
3. 프로그래밍 방식 |
FB을 사용한 Flow Chart 방식 |
접점을 사용한 Ladder 방식 |
4. 아날로그 데이터 처리 |
주로 실수형으로 사용 |
주로 정수형으로 사용 |
5. 통신 |
XR, Broadcast 또는 Multicast 등의 방법을 주로 사용 |
Polling 방식을 주로 사용 |
6. 기능성 |
중요 기능별로 분산 처리 |
CPU 집중 처리 |
7. 진단 기능 |
접점, 모듈, 노드, CPU 등의 내용을 상세하게 파악할 수 있음. |
메이커에 다라 약간의 기능이 지원되기는 하나 거의 사용하지 않음 |
8. 특수 기능 |
Scan Off, Manual Entry, Alarm Suppression 등의 특수 기능을 지원 |
- |
물론 이것은 일반적인 것을 나타낸 것이지 절대적인 것을 나타낸 것은 아닙니다. 일부 DCS 메이커에서도 저가의 DCS를 개발하기 위해 고정 레지스터 방식의 메모리 구조를 사용하기도 하며, 일부 PLC 메이커에서는 고기능을 지원하기 위해 사용자 정의 방식의 메모리 구조를 사용하기도 합니다. 최근에는 이러한 경향이 두드러져서 앞으로는 둘 사이의 경계도 없어질 날이 올 것 같습니다.
어찌 되었거나 이러한 기능적인 차이로 인하여 PLC에서는 태그라 하면 포인트와 동등하게 사용되지만 DCS에서는 태그라 하면 FB의 태그와 동등하게 사용됩니다. 이로 인한 차이는 아주 큽니다. 예를 들어 압력 계측기와 압력을 조정하기 위한 밸브가 있을 때 PLC에서는 압력 값, 밸브 입력, 밸브 출력 등 사용되는 접점에 따라 태그가 3~7개 정도가 사용됩니다. 하지만 DCS에서는 하나의 접점을 위해 사용되는 태그는 7~32개의 아이템을 가지며 그것이 2~3개가 사용되어 결국 적게는 14에서 많게는 90여개의 속성이 사용됩니다. 결국 이 속성을 PLC 측에서는 태그로 보게 되는데, 이처럼 DCS와 PLC에서 이야기 하는 태그 개념의 차이가 수의 차이로 나타나게 됩니다. 다행히 DCS에서도 필요한 아이템만을 태그로 사용함으로써 이로 인한 문제는 발생하지 않을 수는 않습니다. 하지만 DCS를 위한 전용 툴을 개발할 때는 이를 고려해야 합니다.
또한 이 차이는 프로그래밍 관습에도 차이를 가지게 되었습니다. PLC의 경우에는 메이커에서 아예 데이터 타입별로 메모리를 고정하여 사용하기 때문에 인접한 레지스터에서 서로 다른 데이터 형의 변수는 찾을 수가 없었습니다. 하지만 DCS에서는 FB마다 가지는 속성이 틀리고 그 수도 틀리기 때문에 만약 FB의 속성들이 서로 다른 레지스터에서 사용하거나 또는 분리가 되어야 한다면 프로그래밍에 많은 어려움을 가졌을 것입니다. 그래서 DCS의 태그에서는 마치 C언어의 구조체처럼 다양한 데이터 형을 가진 변수들을 포함하게 되었습니다.
통신에 있어서도 그러한 특성 때문에 최대의 효율을 나타내기 위해서 DCS는 Exception Report라는 기술이 사용되었습니다. 반면에 초기 속도를 고려하지 않았던 PLC의 경우에는 Polling 방식을 사용하였던 것입니다. 그래서 PLC를 사용할 때는 더욱 더 최적화가 필요한 것입니다.
그런데 최근의 추세는 이러한 경계가 점점 없어지고 있습니다. 예전에는 PLC 시장과 DCS 시장이 완전히 달랐는데 지금은 PLC 하던 사람도 DCS 시스템을 접하게 됩니다. 기술적으로도 요즘 PLC들은 FB, SFC 등의 프로그래밍 방식도 지원을 하고 있습니다. 문제는 이렇게 성격과 특성이 다른 두 시스템이 만나면서 발생을 합니다. 물론 초기부터 잘 고려를 한다면 별 문제는 없습니다. 하지만 서로 상대방의 시스템을 고려하지 않는다면 시스템적인 문제가 발생할 수밖에 없습니다. 위의 차이로 인하여 주의해야 할 사항을 정리하면 다음과 같습니다.
1) I/O Point 수
자동화 역사를 살펴보면 DCS는 대규모 시스템에 적용이 되었기 때문에, DCS의 엔지니어들은 역할이 완전히 구분이 되어 있었습니다. 전산을 하는 사람은 전기에 대해서는 전혀 신경을 쓰지 않았습니다. 따라서 전산을 하는 DCS엔지니어에게 태그 수를 물어보면 FB 태그의 수를 말합니다. 반면에 PLC는 소규모 시스템에 적용되면서 PLC 엔지니어들은 전기 및 전산을 모두 하였습니다. 그들에게 태그 수를 물어보면 접점에 기반을 둔 개별적인 태그 수를 말합니다. 여기에는 큰 차이가 있습니다. DCS의 FB이 가지는 파라미터는 적게는 5,6개에서 많게는 30개 이상을 가지고 있으며, 이 중에서는 1~4개의 실제 접점이 FB의 입력 또는 출력으로 사용이 됩니다. 여기에서 바로 서로간의 이해의 차이가 있습니다.
우리는 서로간의 이해의 차이를 해결하기 위해서 용어의 통일을 먼저 해야 합니다. 그래서 다음과 같이 용어를 정리하도록 하겠습니다.
- 접점 수 (IO Point) : 전기적인 결선에 의한 물리적인 접점 수를 의미합니다. 즉, FB에서 하나의 태그 또는 파라미터가 아니고 DI/DO/AI/AO 모듈의 접점 수로 계산을 합니다.
- 태그(변수) : 내부 변수, FB의 각종 파라미터 등을 모두 포함하여 변수로 사용될 수 있는 모든 것들을 개별적으로 분리하여 기본 데이터 형(Boolean, Byte, Integer, Float, String 등)으로 사용되는 변수를 의미합니다.
- FB : 하나의 모듈화된 기능의 블록을 의미합니다.
일반적으로 FB의 수와 태그의 수는 최소 16배의 차이가 있습니다. 하지만 HMI에서 모든 FB의 파라미터를 감시하지는 않습니다. 주로 Tuning 등의 기능에서 모든 파라미터를 사용하게 되는데 그것은 DCS 차제에서 사용하게 됩니다. 결국 사용자는 어느 정도 수준까지 사용할 것인가를 결정해야 정확한 포인트 라이센스가 산정될 것입니다.
2) 통신
앞에서 설명한 것과 같이 DCS와 PLC은 대체로 다른 통신 방식을 사용하고 있습니다. 하지만 최근 PLC 업체들은 통신 사양은 바뀌지 않으면서(기본 방법이 바뀌지 않음) 프로그래밍 방식은 DCS 스타일을 쫒아가고 있습니다. 여기서 발생할 수 있는 문제점은 Blocking 통신에 문제가 생길 수 있다는 것입니다.
과거 PLC 업체들은 Polling 방식의 통신을 지원하면서 한 번에 많은 데이터 처리를 할 수 있도록 '시작 번지', '데이터 개수'의 정보를 가지고 Block으로 데이터를 읽을 수 있도록 하였습니다. 그리고 그 통신 사양은 아직도 유효 합니다. 그런데 프로그래밍 방법은 DCS와 같은 방법을 적용하면서 메모리 정의를 구조체 처럼 서로 다른 데이터 형(Boolean, Interger, Float, String 등)을 섞어 사용할 수 있도록 하였습니다. 바로 여기서 프로토콜과 프로그래밍과의 차이점에 의한 문제가 발생하게 됩니다.
이 문제는 제어기를 프로그래밍 하는 사람으로 하여금 반드시 언급이 되어야 합니다. 고속 통신을 위해서 어드레스 맵은 같은 데이터 형으로 인접하게 하도록 해야 합니다. 그렇지 않으면 block으로 통신할 수가 없고 1개씩 통신을 해야 합니다. 특히 대규모 시스템에서 이러한 체크는 기본이라고 할 수 있습니다.
첫댓글 좋은 정보 감사합니다.
감사합니다
감사합니다.