[ETG 잡지기사] 효율성과 신뢰성 - 동전의 양면

 효율성과 신뢰성 - 동전의 양면


  산업 통신은 오류 상황에 영향을 미치는 여러 요인을 다양한 방식으로 수용한다. 발생 여부, 발생 시기, 발생 위치 및 발생 사유를 판단하는 것은 오류가 발생했을 때 신속하게 대답해야 하는(항상 쉽지만은 않은) 핵심 질문이다. 반면, 오류 사례를 다룰 때는 데이터 일관성에 주목해야 한다.

  많은 어플리케이션에서 이더넷은 인기가 매우 높다. 100 Mbit/s(Fast Ethernet)의 견고한 물리적 데이터 전송은 산업 분야에서 매우 성공적이라는 평가를 받았다. 따라서, 신뢰성과 관련하여 물리적 수준 이상의 프로토콜 계층의 효율성이 반드시 논의되어야 한다.



​각 I/O 운영을 위한 단일 프레임은 상당한 오버헤드와 높은 프레임 오류율을 의미

<그림1> 무작위 사이클 오류는 7건 당 6건의 확률로 개별 프레임에 영향을 미친다.


  프로토콜 오버헤드 조사는 평가를 위한 한 가지 접근방식이다. 모든 네트워크 참여자를 위해 개별 이더넷 프레임을 사용하면 최소 프레임 크기에서도 총 84바이트(그림 1)를 전송해야 하기 때문에 상당한 오버헤드가 발생한다. 반면, 일반적인 필드버스 페이로드는 8바이트보다 작기 때문에(예: 1에서 8 사이의 CAN) 90% 이상의 오버헤드가 발생한다.


<그림2> 무작위 사이클 오류는 7건 당 1건 확률로 발생하는 공유 프레임 원리의 프레임에 영향을 미친다.


  일반적인 기계 설정은 통신 시스템의 선형 토폴로지를 보여주는 반면, Fast Ethernet 인프라는 인터페이스의 능동적 결합을 요구한다. 연결은 브리지 LAN 또는 스위칭 이더넷에 의해 수행되는 반면, 스위치는 I/O 디바이스나 드라이브와 마찬가지로 네트워크 노드에 통합된 일부가 되는 경우가 종종 있다. 모든 프레임이 각 노드에서 처리되기 때문에 하나의 공통 프레임에서 전체 사용자 데이터 정보를 교대로 수집할 수 있으며, EtherCAT과 유사하게 프레임이 시스템을 통과하는 동안 처리할 수 있다. 이 프로토콜 처리 방법을 공유 프레임 솔루션이라고 한다(그림 2). 그 결과 연결된 네트워크 노드의 수가 적더라도 50% 미만의 오버헤드가 발생한다. 시스템의 총 페이로드가 400바이트 이상이면 공유 프레임 솔루션의 오버헤드에 10% 미만으로 영향을 미친다.

  일반적으로 이더넷의 물리 계층(PhL)이 견고하더라도 강한 전자파 방해 신호로 인해 통신 오류가 발생할 수 있다. 전통적인 개별 프레임 접근방식에서 그러한 간섭의 영향을 공유 프레임 원리의 영향과 비교할 때, 후자는 네트워크 사이클 내에서 훨씬 더 작은 오류 확률을 보여준다. 일반적으로, 대부분의 네트워크 어플리케이션은 한 번의 오류도 손상 없이 극복할 수 있지만 곧바로 이어지는 두 개의 오류가 있다면 그것은 이미 심각한 상황이다. 따라서, 사이클 당 통신 오류 간의 관계는 임계 상황에 해당된다. 다시 말해, 앞서 언급된 상당히 현실적인 예와 관련하여, 공유 프레임 솔루션과 비교했을 때 개별 프레임 접근방식은 전송 시간의 6분의 1만 사용하기 때문에 훨씬 많은 수의 손상된 프레임을 생성한다. 결과적으로 장애는 6건 당 1건의 확률로만 공통 프레임에 영향을 미친다.


오류 비트 수는 처리 품질에 영향을 미치지 않음

  모션 컨트롤 어플리케이션에서는 단일 통신 오류 발생시 목표값과 실제값을 보간하기 위해 복잡한 알고리즘 사용한다. 개별 프레임 접근법은 특히 여러 축이 결합될때 예측할 수 없는 결과를 초래한다. 따라서 이 접근법에서 오류 사이클의 비율이 훨씬 높을수록 연속적인 오류가 발생하고 결국 임계 상황이 발생한다. 또한 이 솔루션의 낮은 효율성(10%)은 오류 사이클의 비율을 증가시키고 어플리케이션의 신뢰성 있는 제어를 훨씬 더 어렵게 만든다. 속도와 위치 제어는 모션과도 관련이 있다. 위치와 관련해, 값 제어는 작은 증분 변화를 다룰 때 속도보다 훨씬 더 중요하다. 상호 작용에 대한 사전 계획은 오류 발생 시 대비할 수 있는 여유를 줄 수 있다. 또한 프로그래밍 모토인 “변화가 없는 한 가치를 유지하라(keep values as long as nothing changes)”는 것은 일반적으로 오류의 영향을 줄이는 것은 물론 번들 오류도 피하는 데 도움이 된다.


  언급된 상황은 한 사이클의 오류 수와 그에 따른 제어 오류 사이에 직접적인 의존성이 없다는 것을 보여준다. 단일 오류는 번들 오류보다 더 심각할 수 있다.


<그림3> 처리 속도가 느리면 많은 프레임이 영향을 받는다.


개별 프레임 접근 방식은 여러 오류를 방지할 수 없음

  각 노드에 대해 단일 프레임을 사용하는 솔루션의 또 다른 문제는 오류의 분리에 초점을 맞춘다. 일반적으로 이더넷은 각 연결이 특수 송수신기에 의해 제어되기 때문에 장애 전송을 피한다. 오늘날의 이더넷에서 PhL은 버스가 아니라 P2P 연결 집합체다. 예를 들어, 전원 공급 장애는 한 번에 여러 노드에 영향을 줄 수 있기 때문에 오류가 발생할 수 있다. 비교할 만한 오류 발생원에는 직접 차폐 방법을 사용할 때 보호 도체와의 연결 불량이 있다. EtherCAT 문서에서는 이를 권장하지 않지만, 특히 멀티 프로토콜 장치는 그러한 접근방식을 따라야 하며 대체 방법을 사용하지 않을 수 있기 때문에 일부 컨소시엄에서는 의무적이다. 캐비닛의 접지 상태가 예상보다 좋지 않은 경우도 있으므로 케이블 연결의 다른 부분이 결합되는 곳에 차폐 상의 장애가 나타날 수 있다. 이 경우 진단이 매우 어렵다. 따라서 가능하다면 이러한 종류의 장애 전파를 피해야 한다. EtherCAT과 같은 공통 프레임을 사용하면 이러한 유형의 장애 전송은 동일한 프레임에만 여러 번 영향을 미친다.

  IEEE 표준에 의해 정의되고 일반적으로 EtherCAT이 포워딩에 필요한 시간보다 10배 이상 느린 일반적인 스위치 포워딩 방법을 가진 짧은 개별 프레임의 경우, 같은 기간 동안 여러 프레임이 서로 다른 네트워크 참여자에게 전송된다. 그 과정에서 장애 전송이 있는 경우 큰 시간 지연은 여러 다른 프레임에 영향을 미친다. 그 결과, 다른 사이클이나 통신 유형의 데이터가 영향을 받을 수 있다. 이러한 이유로 장애 전송은 거의 항상 일종의 도미노 효과를 수반하는 매우 중요한 요인이다. EtherCAT을 선택하면, 프레임 시작 시 장애조차도 네트워크의 이전 프레임 끝단에 영향을 미칠 수 없을 정도로 포워딩 시간이 짧아진다. 여러 개의 단일 프레임이 영향을 받으면 그로 인한 오류 유형을 정의하기 어렵다. 일부 입력 데이터는 새로운 데이터이며 일부는 오래된 데이터이다. 궁극적으로 그러한 방법에 단 하나의 오류만 있다는 결론은 사실이 아니다. 오히려 특별히 정교하고 복잡한 오류 처리 전략이 필요하다. 또한 대부분의 스위치/브리지는 프레임을 올바르게 수신한 경우에만 송신하며(저장 후 전달) 각 인터페이스의 다른 프레임과 장애 전송으로 이어져 많은 프레임 수에 영향을 미친다.


<그림4> EtherCAT은 즉각적인 피드백을 제공한다.


피드백으로 오류 처리 가속화

  효율성 때문에, 개별 프레임을 사용하는 접근 방식은 일반적으로 즉각적인 피드백을 제공하지 않는다. 출력 데이터 업데이트에 대한 직접적인 피드백은 제어기에서 연결된 디바이스로 전달하고 반송되어야 한다. 이러한 포워딩 시간의 중복은 사이클 시간에 대한 제한 요소를 나타낸다. 따라서 제어 디바이스에 직접 알리지 않는 경우 개별 출력 프레임 손실에 대한 반응은 단일 구성 요소로 제한된다. 이 상황에서 제어기는 어떤 조치도 시작할 수 없다. 그러한 오류가 보고될 수 있는 가장 빠른 시간은 한 번의 수신 사이클 이후이다. 시스템에서 일반적으로 세 사이클 이후에 오류 제한 시간이 트리거된다.

  EtherCAT 및 EtherCAT Technology Group에 대한 자세한 정보는 다음 사이트에서 제공된다.






[출처] 무인화기술 8월호

[원본] https://drive.google.com/file/d/10BL5cmtbWwBRrzd6Ag4NNtulWP7xV99S/view?usp=sharing

댓글

이 블로그의 인기 게시물

[IPC 메뉴얼] BECKHOFF PC 기본 설정 방법

트라이텍, EtherCAT과 DeviceNet [월간CONTROL 2013/11]

[쉽고 간단한 안내서] TwinCAT PLC HMI와 TwinCAT HMI