계장기술(PROCON)

특별기고 <제1부>EtherNet/IP 성능 시험법(Version 1.0)

페이지 정보

작성자 최고관리자 댓글 0건 조회 719회 작성일 22-10-12 15:09

본문

6e466f9932d46e1552f0de875673b50a_1665554353_5016.png
세계 산업용 이더넷 프로토콜 중 상당한 마켓셰어를 가진 EtherNet/IP는 날로 그 이용도가 높아지고 있다. 향후 프로세스 계장 분야에서 두각을 나타내는 EtherNet/IP CG 프로토콜도 EtherNet/IP를 근간으로 한다.
그러면 점점 용도가 많아지는 EtherNet/IP 장치는 어떤 시험법을 갖는가? 이에 대하여 아직까지 국내에 소개된 바가 전혀 없다. EtherNet/IP 장치의
성능 시험법에 대해 엔드유저들이 궁금증을 갖고 있을 것 같아 축약 논문 형식으로 본고에 소개한다.


1. 소 개

네트워크 장치의 성능 특성을 정의하는 데 사용되는 사양은 종종 일반 공급업체와는 다른 방식으로 작성이 된다. 따라서, 사용자는 매뉴얼을 통한 고된 검색 작업을 하지 않고, 공급업체의 엔지니어에게 연락하여 서로 다른 성능 특성이 어떻게 관련되는지 확인을 하지 않고서는 유사한 기기를 비교하는 것이 쉽지가 않다. 이 문서에서는 공급업체가 EtherNet/IP 장치의 성능 특성을 측정하고, 보고하는 데 사용할 수 있는 특정 테스트 세트를 정의하기로 한다.

이 시험의 결과는 기기를 평가할 수 있는 다른 공급업체와 비교 가능한 데이터를 사용자에게 직접 제공한다.[2] 이전의 문서인 “EtherNet/IP 장치용 성능 용어”[1]에서 이 문서에 사용되는 많은 용어를 정의했다. 이 문서를 사용하기 전 용어에 관한 문서를 참조해야 한다.

1.1 실행해야 할 시험   
이 문서에는 여러 가지 테스트에 대해 설명이 되어 있다. 모든 테스트가 여러 유형의 테스트 대상 장치(DUT/Device Under Test)에 적용되는 것은 아니다. 공급업체는 특정 유형의 제품에서 지원할 수 있는 모든 테스트를 수행해야 한다. 이 문서를 작성하면서 어떤 테스트가 어떤 장치 유형에 잘 적용되는지 표시를 하려고 시도했다. 이것은 다만 권장 사항일 뿐이다. 특정 DUT에서 실행할 수 있는 추가 성능 테스트를 수행해야만 한다. 이 문서의 현재 버전은 CIP 클래스 1 연결에 적용되는 성능 테스트만 지정한다. 이런 연결은 여러 EtherNet/IP 장치 간에 실시간 메시지를 전송하는 데 사용되는 주요 방법이다. 향후 이런 테스트는 연결된 네트워크 및 연결되지 않은 네트워크 성능 테스트를 포함하도록 확장될 수가 있다.

1.2 결과의 평가
권장 테스트를 모두 수행하면 많은 데이터가 생성된다. 이 데이터의 대부분은 각 상황에서 기기의 평가에 적용되지 않는다. 특정 네트워크 설치와 관련된 데이터도 평가를 하려면 즉시 사용할 수는 없으나 무언가 경험이 필요하다. 또한 실행할 시험의 선택과 시험 데이터의 평가는 반복성, 분산성 및 소수 시험의 통계적 중요성과 관련하여 일반적으로 허용되는 시험 관행을 이해하여 수행되어야 한다.[3]
1.3 요구사항
이 문서에서는 각 특정 요구사항의 중요성을 정의하는 데 사용되는 단어는 대문자로 표시한다. 이들 단어들은 다음과 같다.
• 필수(MUST) : 이 단어나 필수 단어와는 해당 항목이 사양의 절대 요구사항임을 의미한다.
• 권장 사항(RECOMMEND) : 이 단어 또는 형용사는 특정 상황에서 이 항목을 무시할 수 있는 타당한 이유가 있을 수 있음을 의미해야 하지만, 다른 과정을 선택하기 전에 전체 의미를 이해하고 사례를 신중하게 검토해야 된다.
• 메이(MAY) : 이 단어 또는 형용사 선택 사항은 이 항목이 정말로 선택적이라는 것을 의미한다. 한 공급업체는 특정 시장에서 EtherNet/IP 장치를 위한 성능 테스트 방법론을 요구하거나, 제품을 개선하므로 해당 항목을 포함하도록 선택할 수도 있다.
다른 공급업체는 동일한 항목을 생략할 수 있다.
모든 필수 및 모든 요구사항을 충족하는 이러한 성능 시험의 구현은 무조건 완료(Unconditionally complete)라고 한다. 모든 필수 요건은 충족하지만, 모든 필수 요건을 충족시키지 못하는 이러한 성능 시험의 구현은 “조건적으로 완전해야 한다”고 한다. 이러한 성능 시험의 구현이 하나 이상의 필수(MUST) 요건을 충족하지 못하면 불완전(Incomplete)으로 간주된다.[3]


2. 테스트 설정

2.1 시험 장비 배치
테스트 아키텍처의 기본 레이아웃은 그림 1에 나와 있다. 그림 1에 표시된 레이아웃은 테스트 아키텍처의 가장 기본적인 유형의 하나일 뿐이다. 더 복잡한 레이아웃은 “4. (부록 A) 테스트 아키텍처 범주”에서 추가 테스트 장비 장치 및 네트워크 인프라 장치를 포함하며, 일부는 DUT에 직접 연결된다. 성능 시험을 실시할 때, 시험에 사용된 다양한 장치에 대한 설명과 함께 배치에 대한 설명을 제공해야 한다. 시험 아키텍처 레이아웃을 선택할 때 시험에 참여하는 기기가 모두 식별되고, 특별한 설정이나 프로그램이 기록되는 한 이 문서의 부록에 표시된 레이아웃을 참조할 수 있다.
 6e466f9932d46e1552f0de875673b50a_1665554494_8474.png

2.2 시험 및 네트워크 인프라 장비의 성능
시험의 복잡성을 최소화하고, 오류가 시험 결과에 미치는 영향을 줄이기 위해 최소 수의 시험 장비와 네트워크 기반 시설 장비 장치를 사용하는 것이 권장된다. DU T에서 테스트를 수행하기 전에 테스트 및 네트워크 인프라 장비의 성능을 이해해야 한다. 테스트 장비가 다른 산업용 장치인 경우, DUT에서 테스트를 실행하기 전에 해당 장치를 적절한 EtherNet/IP 성능 테스트로 특성화해야 한다. 테스트 장비가 다른 유형의 장치인 경우, 사용 가능한 성능 특성은 테스트 결과와 함께 기록해야 한다. 네트워크 기반 시설 장비의 경우, 적절한 IETF(Internet Engineering Task Force) RFC(Request For Comments) 문서에 기반한 장치 성능을 결정해야 한다. 이러한 테스트 결과는 네트워크 인프라 장치의 제조업체에서 구할 수 있다. 그렇다면 데이터를 입수하여 DUT의 성능 시험 결과와 함께 제출해야 한다. 그렇지 않은 경우 적절한 RFC 테스트를 수행해야 하며, DUT의 성능 테스트 결과와 함께 결과를 제출해야 한다. DUT의 성능에 대한 최종 보고서는 시험 및 네트워크 기반 구조 장비 성능 시험 결과를 나타내는 메모를 포함해야 하지만, 실제 성능 시험 결과 자체를 포함할 필요는 없다.

2.3 사용자 프로그래밍
EtherNet/IP 장치를 테스트하는 동안 테스트에 관련된 장치 중 하나 또는 모든 장치에서 사용자 수준 프로그래밍을 사용해야 될 수 있다. 이러한 사용자 수준 프로그램의 한 예는 입력 신호를 처리하고 네트워크 패킷을 생성하는 데 필요한 DUT의 래더로직(Ladder logic) 프로그램일 수 있다. 다른 예는 DUT로부터의 응답을 자극하기 위해 패킷 생성기에 구성된 특수 패킷이다. 이런 프로그램은 테스트 결과와 함께 문서화해야 한다. 사용자 수준 프로그램은 기기 성능에 가장 작은 영향을 미치도록 길이와 복잡도 모두에서 최소화하도록 권장된다.

2.4 DUT 설정
성능 테스트를 시작하기 전에 공급업체가 제공한 지침에 따라 DUT를 구성해야 한다. 특히 시험을 준비할 때 모든 특별 지침 또는 사용자 수준 프로그래밍을 따라야 한다. DUT 설정은 테스트의 각 시행마다 일관성을 유지해야 하지만, 다른 테스트에서 변경될 수 있다. 예를 들어, 래더로직 프로그램 1은 무부하 주기/API 지터 테스트를 수행하는 데 필요할 수 있지만, 래더로직 프로그램 2는 응답 지연 시간 테스트를 수행하는 데 필요할 수 있다. 프로그램 2의 추가 기능은 무부하 사이클릭/API 지터시험(Jitter Test)을 수행하는 동안 측정된 성능 결과에 영향을 미칠 수 있으므로, 래더로직 프로그램 1에는 포함되지 않는다. 또 다른 예로는, DUT가 ALSF(Action Latency Single Output Frequency) 테스트 대 ALLB (Action Latency Loop Back) 테스트를 수행하기 위해 다른 하드웨어 구성을 필요로 하는 것이다. 하드웨어 구성은 ALSOF(Action Latency Single Output Frequency) 테스트의 각 평가판을 수행하는 동안 유지되어야 하지만, ALLB 테스트를 수행하기 전에 변경할 수 있다.


3. 테스트 설명

3.1 시험(정의 형식)
• 목표 : 테스트 목적에 대한 기본 설명이다.
• 절차 : 테스트 방법론에 대한 전체 설명이다.
•보고 형식 : 데이터가 계산되고 보고되는 방법에 대한 설명이다.
•테스트 대상 장치 : 이 테스트의 대상이 되는 일부 장치 목록이다. 이 목록은 완전하지 않을 수 있지만 테스트 담당자는 어떤 장치가 테스트 대상인지
파악할 수 있다.
3.2 무부하 사이클릭/API 지터 테스트
•목표 : DUT의 주기적/수용된 패킷 간격(API) 지터를 결정한다.
•절차 : EtherNet/IP에 대한 생산자/소비자 모델은 실시간 데이터 교환을 위해 여러 통신 모드를 선택할 수 있다.[4] EtherNet/IP 장치에 대한 가장 일반적인 성능 테스트 방법 데이터 생성을 위한 모드를 순환 생산이라고 한다. 주기적 생산 동안, 생산자는 요청 패킷 간격(RPI/Requested Packet Interval)이라고 불리는 특정 속도로 데이터를 전송하려고 시도할 것이다. RPI와 해당 API(Application Programming Interface)는 실제 데이터 값이 변화하는 속도에 관계없이 네트워크를 통해 생성되는 데이터의 속도를 지시한다. 데이터를 생성하는 다른 모드는 조사 및 상태 변화이다. 조사된 데이터의 경우 한 장치가 다른 장치에 특정 데이터 조각을 명시적으로 요청한다. 두 장치 간의 대화를 위해, 이것은 데이터 교환을 달성하는 간단한 방법이지만, 동일한 정보가 여러 다른 장치에 전달되어야 할 때 많은 양의 추가 통신이 발생한다. 데이터를 생성하는 마지막 모드를 상태 변화라고 한다. 즉, 값이 변경될 때만 한 장치가 다른 장치로 데이터를 보낸다. 이는 네트워크 트래픽을 쉽게 감소시킬 수 있지만, 수신 장치는 생산 장치가 보고해야 할 새로운 것이 없는지 또는 여전히 활성 상태인지 알지 못하기 때문에 문제를 야기할 수 있다. EtherNet/IP는 순수한 형태의 상태 변화를 구현하지 않지만, 수신기로 가는 이 “심장박동” 신호를 유지하기 위해 일정한 간격으로 일부 데이터를 전송하는 수정된 버전을 구현한다. API는 EtherNet/IP를 통한 대부분의 실시간 I/O 통신의 기초가 되기 때문에 기기 성능으로 볼 때 자연스럽게 시작할 수 있는 장소이다. 장치가 다른 조건에서 해당 API 값을 유지하는 능력은 제어 시스템에 매우 중요할 수 있다. 어떤 장치도 완벽하게 작동한다고 볼 수 없어, 이러한 테스트는 특정 장치가 얼마나 밀접하게 API 값을 유지할 수 있는지를 보여준다. 합격 또는 불합격 값을 결정하지 않는다. 이는 사용자에 의해 결정되어야 하며, 기기의 성능 특성이 애플리케이션의 요구를 충족하는지 여부를 결정해야 한다. 사이클릭/API 테스트의 기본 전제는 특정 API 값으로 장치의 최대 처리량을 결정하는 것이다. 생산자와 소비자 장치 모두 테스트 될 것이다. 기기는 공개된 기능이 외부에서 수행한 시험에 대해 불이익을 받지 않는다. 테스트 결과 최대 처리량 대 API 값의 2D 매트릭스가 생성된다. 테스트에 대한 의사 코드(Pseudo-code)가 다음에 나와 있다.
•주기적 API 테스트의 의사 코드
1. 테스트에 대한 RPI 및 연결 크기 설정
2. 테스트 대상 장치(DUT)와의 연결 설정
3. 한동안 DUT와 통신한다.
4. 패킷 손실 확인
5. API 통계(최소, 최대, 평균, 표준편차, 히스토그램 등) 계산
6. 패킷 손실이 있을 경우 RPI 값을 높이고(빈도 감소) 계속한다.
7. 또는 API 및 통계를 보고한다.
이 유사 코드를 구현하는 것은 생산자 장치를 테스트하는 데 비교적 쉽다. 임의의 장치는 DUT에 의한 패킷 생성을 자극하기 위한 트래픽 생성기로 사용될 수 있다. 이를 통해 네트워크 분석기는 DUT에서 생성된 패킷만 수신하면 되므로 테스트에서 수동 구성요소로 남을 수 있다. EtherNet/IP 장치에 대한 성능 테스트 방법론을 제거함으로써 네트워크 분석기로 인해 보고된 오류를 최소화할 수 있었다. EtherNet/IP는 프로토콜에서 시퀀스 번호를 사용하므로, 4단계에서 패킷 손실(또는 시퀀스 외 패킷)은 DUT에 의해 생성된 시퀀스 번호에 따라 결정될 수 있다. 5단계에서 계산된 통계는 선택한 API의 처리량과 처리량 값의 지터와 관련이 있다. 테스트에서 패킷 손실이 나타나지 않으면 테스트가 성공하고 값이 보고된다. 그렇지 않으면 더 큰 RPI 값(낮은 RPI 주파수)에서 테스트를 다시 실행해야 한다. 생산자 장치에 대한 시험 구현은 비교적 간단하지만, 소비자 장치에 대한 구현은 더 복잡하다. 소비자 장치는 API 속도로 패킷을 수신해야 하며, 패킷 손실을 보고하지 못할 수도 있다. 이는 Ether Net/IP 장치가 하트 비트를 제외하고, 양방향 통신을 가질 필요가 없기 때문이다. 또 다른 어려움은 네트워크 분석기가 1단계부터 3단계까지의 트래픽 생성을 담당해야 한다는 것이다. 그렇지 않으면 다른 테스트 장비가 자체 지터에 오류를 발생시킬 수 있다. 이 오류는 위에서 설명한 생산자 테스트를 사용하여 DUT에서 테스트를 수행하기 전에 반드시 확인해야 한다. 이러한 유형의 오류를 제거하는 유일한 방법은 네트워크 분석기를 트래픽 발생기로 사용하는 것인데, 이는 DUT의 최소 RPI보다 최소 10배 더 정확한 타이밍을 가져야 하며, 일정한 간격으로 데이터를 생성할 수 있다.[5] 장치가 여러 EtherNet/IP I/O 연결을 지원하는 것은 일반적이다. DUT의 성능을 완전히 테스트하려면 다양한 연결 수를 사용하여 DUT를 테스트해야 한다. 이것은 무부하 또는 경계 내 시험이므로 연결부의 수, 속도 및 크기는 제조자의 규격 내에 있어야 한다. 통계적으로 유의미한 결과를 제시하기 위해서는 DUT에서 많은 수의 패킷을 생산 또는 소비하고 일련의 시험을 수행해야 한다[각 시험의 패킷 수 결정에 대한 자세한 내용은 “6. (부록 C) 통계적으로 유의미한 샘플 수 계산” 참조]. 데이터 패킷 수가 많으면 표준 편차 및 히스토그램을 계산하기 위해 각 개별 시행마다 통계적으로 많은 수의 API가 제공된다. 여러 번의 시행을 통해 한 번의 시행이 그러한 시행과 마주치기에 충분히 길지 않은 경우에 통계적 이상 징후를 확인할 수 있다.
•보고 형식 : 이 테스트 동안 기록된 데이터는 API 타이밍과 패킷 시퀀스의 측정값을 나타낸다. API 타이밍을 위해 기록된 데이터는 평균 API 타이밍, 최소 API 타임, 최대 API 타임, API 타임의 표준 편차, API 타이밍 값의 히스토그램 등을 포함한다. DUT에 의해 생성되거나 소비되는 각 패킷은 패킷 손실 또는 시퀀스 외 패킷을 결정하기 위해 기록된다. 장치에 대한 API 타이밍에서 지터를 결정하기 위해, 여러 값이 제시될 것이다. 이 모든 값은 EtherNet/IP 장치를 위한 성능 테스트 방법론 및
각 개별 평가판으로서 전체 평가판에 대해 표시가 된다. 전체 시행 시퀀스를 계산할 때 각 개별 시행 중에 기록된 포인트 수를 포함하는 것이 중요하다. 평균 API 값은 API 값의 합을 테스트의 패킷 수로 나눈 값이다. 최악의 경우 지터는 최대 API 값에서 최소 API 값을 뺀 값으로 계산된다. 표준 지터는 2개의 표준 편차(하나는 평균 API보다 위 및 아래)로 계산된다. 지터/가변성의 히스토그램은 각 빈(Bin)의 패킷 수와 API 값인 빈(Bin)을 비교한 것이다.

3.3 부하 사이클릭/API 지터 테스트
•목표 : 순환/A에 대한 백그라운드 트래픽 및 기타 경계 밖 조건의 영향 확인 DUT의 PI 지터이다.
•절차 : 많은 EtherNet/IP 장치들은 제한된 자원을 가진 플랫폼 상에 구축되기 때문에, 백그라운드 트래픽 또는 기타 경계 밖 조건이 장치에 미치는 영향을 확인할 필요가 있다. 부하 사이클릭/A에 대한 절차 PI 지터 테스트는 무부하 테스트와 매우 유사하지만, DUT는 노이즈가 많은 네트워크 또는 공개된 사양 밖에서 데이터를 생성하거나 소비하도록 요청 받을 것이다. 테스트는 테스트 중에 백그라운드 트래픽 생성을 위한 추가 하드웨어가 있을 수 있다는 점을 제외하고, 무부하 테스트에서 설명한 것과 유사한 방식으로 설정된다. 다음 섹션에서는
테스트할 개별 변형에 대해 설명한다.
•보고 형식 : 다음에 나열된 모든 테스트에서 설정된 I/O 연결의 성능은 위에 표시된 무부하 사이클릭/API 지터 시험(Jitter Test)에 표시된 형식을 사용하여 나열된 다른 값과 함께 보고되어야 한다.
•테스트 대상 장치 : 무부하 사이클릭/API 지터
테스트 대상 장치는 로드 동작도 테스트해야 한다.

3.3.1 모든 연결 API 변경, 총 처리량 목표 유지
이론적인 총 처리량을 유지하고, DUT에 미치는 영향을 확인하면서 연결 수, 연결 속도 및 연결 크기를 변경한다.
•절차 : 이론적인 총 처리량은 동일하게 유지하되 연결 수 및 연결 속도를 다르게 한다.
•예 : DUT의 총 처리량이 비트 바이트 프레임 바이트 수 프레임 560@128= 71680= 573440이고, 4개의 단방향 연결 @ 10ms API 및 8개의 단방향 연결 @ EtherNet/IP 장치 성능 테스트 방법 50ms API를 위한 5개의 단방향 연결 @10ms API 및 3개의 단방향 연결을 시도한다. 50ms API 또는 10ms API에서 3개의 단방향 연결과 50ms API에서 13개의 단방향 연결 장치가 단방향 연결 수를 지원하거나 장치의 총 처리량을 유지할 수 있는지 확인한다.
•보고 형식 : 보고서는 설정된 연결 수와 해당 연결의 속도 및 크기를 표시해야 한다.

3.3.2 모든 독립 연결 API
•목표 : 특정 연결에 대해 예상되는 API보다 높거나 낮으면 DUT가 어떻게 반응하는지를 결정한다.
•절차 : 지원되는 가장 높은 API 빈도로 DUT에 대한 I/O 연결을 설정한다. 지정된 API 주파수를 사용하여 DUT와 통신을 시작한다. 그런 다음 연결을 다시 설정하지 않고, API의 빈도를 늘리거나 줄인다. API의 주파수는 장치에 대한 타임아웃 승수 이하로 떨어지면 안 된다. 트래픽 생성기는 새 API 주파수를 사용하여 CIP 클래스 1 연결을 재설정하지 않고, API 주파수를 변경할 수 있어야 한다.
이 속도 변화는 스텝 함수일 수도 있고 램프일 수도 있지만, 이 테스트에서 원하는 변화는 API 주파수와 관련하여 크지 않다. 하나의 연결로 장치를 테스트한 후 제조업체가 지정한 연결 수, 크기 및 속도를 사용하여 완전히 로드 된 연결 세트를 설정한다.
그런 다음 위에서 설명한 대로 가장 빠른 연결 중 하나를 변경한다.
•보고 형식 : 보고서는 API의 테스트 및 DUT의 다양한 주파수 처리 능력뿐만 아니라 DUT가 경험한 과부하 동작도 표시해야 한다.

3.4 동작 대기
작업 지연 시간은 장치가 물리적 작업을 발생시키거나, 측정하고 작업과 연결된 네트워크 패킷 사이의 시간을 결정하는 기능을 테스트한다. 장치가 작동 명령을 받고 있는 경우, 이는 장치가 네트워크 패킷을 수신하고 작업이 수행되는 사이의 시간이다. 장치가 데이터를 생성하는 경우 물리적 동작과 네트워크 패킷을 보내는 장치 사이의 시간이다. 이러한 테스트는 기기별로 매우 다르며, 테스터 측에서 애플리케이션 레벨 프로그래밍을 필요로 한다. 또한 시험 장비가 둘 이상의 장치로 구성될 수 있기 때문에, 이러한 시험은 여러 오류 소스의 영향을 받는다

3.4.1 동작 대기 시간 단일 출력 주파수(AL-SOF) 시험
•목표 : DUT의 작업 대기 시간을 테스트하여 명령을 처리하고, 물리적 출력을 생성하거나 물리적 입력을 수신하고 네트워크 응답을 보낸다.
•절차 : 동작 지연 시간 단일 출력 주파수(AL-SOF) 테스트는 단일 방향 동작 지연 시간을 결정한다.
출력이 있는 DUT의 경우 테스트 장비는 DUT를 자극하여 지속적인 주기적인 물리적 출력을 전송한다.
입력이 있는 DUT의 경우, 테스트 장비는 DUT가 연속적이고 주기적인 물리적 입력을 읽도록 자극한다. DUT 하드웨어는 DUT의 물리적 입력 또는 출력에 하나 이상의 테스트 장비 장치가 연결된 상태로 설정된다. 이 테스트 장비는 DUT에 의해 생성된 물리적 신호를 분석하거나(오실로스코프 등으로), 알려진 물리적 입력 신호를 DUT에 제공할 수 있어야 한다. 이 테스트에서는 비교적 낮은 주파수(ms)를 사용하기 때문에 데이터 수집 또는 신호 발생기 보드가 있는 컴퓨터를 사용하는 것도 가능하다. DUT에 입력이 여러 개이거나 사양이 모두 동일한 출력이 여러 개일 경우, 테스트를 위해 포트 중 하나로만 테스트할 수 있다. 여러 입력 또는 출력의 사양이 다를 경우 각 그룹을 개별적으로 테스트해야 한다. 그림 2는 ALSOF(Action Latency Single Output Frequency) 테스트에 관련된 디지털 출력을 가진 DUT에 대해 가능한 테스트 설정이 어떻게 나타날 수 있는지 보여주는 예이다. 이 예에서 트래픽 발생기(TE1)는 DUT에 명령을 발행하여 디지털 출력 사각파 신호를 시뮬레이션 한다. DUT의 출력 신호의 주파수와 불규칙성은 오실로스코프(TE2)를 통해 모니터링된다. 주파수 변경이나 주기 누락은 스코프 추적에서 분명하며, DUT의 성능과 관련이 있다.

6e466f9932d46e1552f0de875673b50a_1665554698_7376.png
테스트 장비는 DUT가 지원하는 가장 빠른 API를 사용하여 DUT에 대한 CIP 클래스 1 연결을 설정해야 한다. 연결은 적어도 테스트 방향으로 흐르는 실시간 데이터로 설정되어야 한다. 입력 AL-SOF 테스트를 수행하는 경우 실시간 데이터가 DUT에서 테스트 장비로 전송되어야 한다. 출력 AL-SOF 테스트를 수행하는 경우, 실시간 데이터가 테스트 장비에서 DUT로 전송되어야 한다. 다른 방향은 DUT와의 연결을 올바르게 유지해야 한다. AL-SOF 테스트는 테스트 장비와 DUT의 영향을 많이 받기 때문에 테스트 중에 가장 작은 코드를 사용하는 것이 좋다. 많은 EtherNet/IP 장치들은 래더 로직을 사용하므로, 이는 처리 오버헤드를 줄이기 위해 래더 프로그램의 렁(Rung) 수를 제한하는 것을 의미한다. 출력 AL-SOF 테스트 동안 테스트 장비는 DUT에 주기적인 신호를 보낸다. 디지털 출력의 경우 트래픽 발생기는 각 RPI 사이클에 대해 낮은(0) 곳에서 높은(1) 곳으로 변화하는 주기적인 사각파를 지속적으로 전송해야 한다. 아날로그 출력의 경우 트래픽 생성기는 API 주파수의 10배 이상의 주파수로 주기적인 톱니 신호를 전송해야 한다. 입력 AL-SOF 테스트 동안 DUT는 테스트 장비로부터 주기적인 신호를 수신한 다음 네트워크 패킷에서 해당 데이터 값을 전송 한다. 디지털 입력의 경우, 테스트 장비는 주파수가 API 사이클 주파수로 설정된 주기적인 사각파 신호를 전송해야 한다. 아날로그 입력의 경우, 시험 장비는 API 주파수의 10배 이상의 주파수로 주기적인 톱니 신호를 보내야 한다. 두 경우 모두 입력 신호를 처리하고, 네트워크 패킷의 값을 보고하도록 DUT를 구성해야 한다. EtherNet/IP 장치에 대한 성능 테스트 방법 AL- SOF 테스트에 대한 조치 대기 시간은 네트워크 패킷과 해당 물리적 조치 사이의 차이로 계산된다. 입력 AL-SO F 테스트의 경우, Action Latency는 물리적 입력 신호와 네트워크 분석기가 수신하는 해당 네트워크 패킷의 첫 번째 비트 사이의 시간 차이로 계산된다. 출력 AL-SOF 테스트의 경우 동작 지연 시간은 트래픽 생성기에서 나가는 명령 패킷의 마지막 비트와 DUT에서 생성되는 해당 물리적 출력 사이의 시간 차이로 계산된다. 이러한 측정에는 DUT의 성능과 직접 관련되지 않은 지연 시간이 포함된다. 와이어 지연 시간, 네트워크 인프라 지연 시간, 테스트 장비 지연 시간 등.[5][6] 이러한 지연 시간은 RFC 1242, 2544, 2285 및 2889에 기술된 네트워크 인프라 테스트를 사용하여 테스트를 수행하기 전에 추정할 수 있다.[2][3][7][8] 이러한 추정 지연 시간은 반드시 시험결과와 함께 보고되어야 DUT의 성능을 분석할 때 고려될 수 있다.

3.4.2 동작 지연 루프 백(AL-LB) 시험
•목표 : DUT의 작업 지연 시간을 테스트하여 명령을 처리하고, 물리적 출력을 보내고, 물리적 입력을 처리하고, 응답을 반환한다.
•절차 : 동작 지연 시간 루프 백(AL-LB) 테스트는 DUT에서 동작 지연 시간을 결정하기 위해 테스트 장비 장치의 수를 제한한다. DUT는 명령을 처리하고, 물리적 출력을 보내고, 물리적 입력을 처리하고, 테스트 장비에 응답을 보내는 데 필요하다. DUT 하드웨어는 아날로그/디지털 출력 포트가 짧은 와이어 또는 점퍼로 아날로그/디지털 입력 포트에 유선 연결된 상태로 설정된다. 짧은 와이어 또는 점퍼를 사용하면, 이 와이어를 가로지르는 전기전도 관련 지연 시간이 무시될 수 있다. DUT에 여러 개의 출력 또는 입력 포트가 있는 경우, 테스트가 쉽게 수행될 수 있도록 출력 및 입력 포트의 적절한 조합을 선택한다. DUT가 모듈식 또는 랙 기반 장치인 경우, AL-LB 테스트를 수행하기 전에 개별 모듈을 별도로 테스트해야 한다. 또한 DUT에 성능 특성이 다른 입력 또는 출력 포트가 있는 경우, DUT를 완전히 검증하기 위해 이들 포트를 별도로 테스트해야 한다. 그림 3은 디지털 출력과 AL-LB(Action Latency-Loop Back) 테스트에 관련된 입력이 있는 DUT에 대해 가능한 테스트 설정이 어떻게 나타날 수 있는지에 대한 예를 보여준다.
이 예에서 트래픽 발생기 및 네트워크 분석기(TE)는 DUT에 명령을 발행하여 디지털 출력 사각파 신호를 시뮬레이션 한다. 출력 신호는 유선 연결을 통해 입력 포트로 역류한다. DUT는 입력 전압을 나타내는 메시지를 TE에 발행한다. 송신되는 발신 명령과 DUT가 수신하는 해당 입력 메시지 사이의 시간 차이는 DUT의 성능과 관련이 있다.
테스트 장비는 DUT가 지원하는 가장 빠른 API를 사용하여 DUT에 양방향 CIP 클래스 1 연결을 설정해야 한다. 즉, 양방향으로 흐르는 실시간 데이터(즉, 테스트 장비에서 DUT로 실시간 명령 및 DUT에서 테스트 장비로 실시간 데이터)와 연결이 설정되어야 한다. 이러한 테스트는 테스트 장비 및 DUT에서 사용하는 애플리케이션 프로그래밍의 영향을 많이 받기 때문에 테스트 중에 가장 작은 코드를 사용하는 것이 좋다. 많은 EtherNet/IP 장치들은 래더 로직을 사용하므로, 이는 처리 오버헤드를 줄이기 위해 래더 프로그램의 렁(Rung) 수를 제한하는 것을 의미한다. AL-LB 테스트 중에 DUT는 대기 시간을 쉽게 결정할 수 있도록 알려진 패턴의 출력 신호를 변경하기 위한 명령을 전송한다. DUT를 디지털 입력/출력 쌍으로 테스트하는 경우, 알려진 일정한 주파수의 사각파 신호를 사용하는 것이 좋다. DUT를 아날로그 입력/출력 쌍으로 테스트하는 경우, 알려진 일정한 주파수의 삼각파 신호를 사용하는 것이 좋다. 또한 이러한 신호의 주파수는 테스트를 위해 선택한 RPI 주파수보다 훨씬 작은 것이 좋다. 이를 통해 주기적 신호의 각 세그먼트를 독립적으로 분석할 수 있다. AL-LB 테스트의 작업 지연 시간(Action Latency)은 테스트 장비가 명령을 보내는 시간과 DUT가 데이터의 관련 값 변경으로 응답하는 시간 사이의 차이로 계산된다. 디지털 I/O가 있는 DUT의 경우, 트래픽 발생기는 출력을 로우(0)에서 하이(1)로 변경하는 명령을 전송할 수 있다. 작업 지연 시간은 테스트 장비에서 DUT의 응답 패킷의 첫 번째 비트를 남겨두고 명령 메시지의 마지막 비트 사이의 시간 차이로 계산되며, 이는 낮은(0) 곳에서 높은(1) 곳으로 변경되는 것이다. 아날로그 I/O를 갖는 DUT의 경우, 트래픽 발생기는 출력 전압을 램프하는 명령을 전송할 수 있다. 동작 지연 시간은 테스트 장비를 떠나는 명령 패킷의 마지막 비트와 DUT에서 나오는 응답 패킷의 첫 번째 비트 사이의 시간 차이로 계산되며, 이는 적절한 오차 범위 내에서 전압의 변화를 보여준다. 이러한 측정에는 DUT의 성능과 직접 관련되지 않은 지연 시간이 포함된다. 와이어 지연 시간, 네트워크 인프라 지연 시간, 테스트 장비 지연 시간 등.[5][6] 이러한 지연 시간은 RFC 1242, 2544, 2285 및 2889에 기술된 네트워크 인프라 테스트를 사용하여 테스트를 수행하기 전에 추정할 수 있다.[2][3][7][8] 이러한 추정 지연 시간은 반드시 시험 결과와 함께 보고되어야 DUT의 성능을 분석할 때 고려될 수 있다.

6e466f9932d46e1552f0de875673b50a_1665554762_5526.png

<EtherNet/IP 성능 작업반 구성원>
•브라이언 배트키(Brian Batke), 로크웰오토메이션 babatke@ra.rockwell.com
•제임스 길신(James Gilsin), 국립표준기술연구소(NIST), james.gilsinn@nist.gov
•케빈 마틴(Kevin Martin), HRL실험실 martin@hrl.com
•아몰도반스키(Amoldovansky), 로크웰오토메이션, amoldovansky@ra.rockwell.com
•마크 와이젠본(Mark Weisenborn), 프론트 테스트 장비, mweisenborn@fte.com
•게리 워크맨(Gary. c. workman), 제너럴 모터스, gary.c.workman@gm.com
<확인 사항>
EtherNet/IP Performance Workgroup에서는 이 문서에 대한 의견을 제공해준 추가 담당자에게 감사드린다.
•스콧 브래드너[Scott Bradner], 하버드 대학교


<참조문헌>

[1] EtherNet/IP Performance Workgroup, “Performance Terminology for EtherNet/IP Devices”, v1.0, September 16, 2004, EtherNet/IP Implementors Workshop, PUB00080R1.
[2] Bradner, S. ed., “Benchmarking Terminology for Network Interconnection Devices,” RFC 1242, July 1991, Internet Engineering Task Force (IETF),
http://www.ietf.org/rfc/rfc1242.txt.
[3] Bradner, S., McQuaid, J., ed., “Benchmarking Methodology for Network Interconnection Devices,” RFC 2544, March 1999, Internet Engineering Task Force (IETF), http://www.ietf.org/rfc/rfc2544.txt.
[4] EtherNet/IP Specification, v1.0, June 5, 2001, Open DeviceNet Vendor Association (ODVA),
http://www.odva.org/.
[5] Gilsinn, J., “Real-Time I/O Performance Metrics and Tests for Industrial Ethernet”, Presented at ISA Automation West 2004, April 28, 2004,
http://www.isa.org/.
[6] Lian, F., Moyne, J., Tilbury, D., “Performance Evaluation of Control Networks: Ethernet, ControlNet, and DeviceNet”, IEEE Control Systems Magazine, February 2001, vol. 21, num. 1, pp. 66-83.
[7] Mandeville, R., ed., “Benchmarking Terminology for LAN Switching Devices”, RFC 2285, February 1998, Internet Engineering Task Force (IETF),
http://www.ietf.org/rfc/rfc2285.txt.
[8] Mandeville, R., Perser, J., ed., “Benchmarking Methodology for LAN Switching Devices”, RFC 2889, August 2000, Internet Engineering Task Force (IETF), http://www.ietf.org/rfc/rfc2889.txt.


odva@odva.or.kr 

카테고리

카테고리
현재(2019~)

잡지리스트

잡지리스트

이달의 광고업체

이달의 광고업체