세계 산업용 이더넷 프로토콜 중 상당한 시장점유율을 가진 EtherNet/IP는 날로 그 이용도가 높아지고 있다. 향후 PROCESS 계장 분야에서 두각을 나타내는 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 장치를 위한 성능 테스트 방법론을 요구하거나 2005년 3월 14일 PUB00081R1 제품을 개선 하므로 해당 항목을 포함하도록 선택할 수도 있다. 다른 공급업체는 동일한 항목을 생략할 수 있다.

모든 필수 및 모든 요구 사항을 충족하는 이러한 성능 시험의 구현은 무조건 완료[unconditionally complete]라고 한다. 모든 필수 요건은 충족하지만 모든 필수 요건을 충족시키지 못하는 이러한 성능 시험의 구현은 “조건적으로 완전해야 한다”고 한다. 이러한 성능 시험의 구현이 하나 이상의 필수 [MUST] 요건을 충족하지 못하면 불완전[incomplete]으로 간주된다. ^[3]

2. 테스트 설정[Test Setup]

2.1 시험 장비 배치

테스트 아키텍처의 기본 레이아웃은 아래 그림 1에 나와 있다. 그림 1에 표시된 레이아웃은 테스트 아키텍처의 가장 기본 적인 유형의 하나일 뿐이다. 더 복잡한 레이아웃은 부록 A, 테스트 아키텍처 범주에서 추가 테스트 장비 장치 및 네트워크 인프라 장치를 포함하며, 일부는 DUT에 직접 연결된다.

성능 시험을 실시할 때, 시험에 사용된 다양한 장치에 대한 설명과 함께 배치에 대한 설명을 제공해야 한다. 시험 아키텍처 레이 아웃을 선택할 때, 시험에 참여하는 기기가 모두 식별되고 특별한 설정이나 프로그램이 기록되는 한, 이 문서의 부록에 표시된 레이아웃을 참조할 수 있다.
 
2.2 시험 및 네트워크 인프라 장비의 성능

시험의 복잡성을 최소화하고 오류가 시험 결과에 미치는 영향을 줄이기 위해 최소 수의 시험 장비와 네트워크 기반 시설 장비 장치를 사용하는 것이 권장된다. DUT에서 테스트를 수행하기 전에 테스트 및 네트워크 인프라 장비의 성능을 이해해야 한다. 테스트 장비가 다른 산업용 장치인 경우, 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 장치에 대한 가장 일반적인 성능 테스트 방법 2005년 3월 14일 데이터 생성을 위한 5 PUB00081R1 모드를 순환 생산이라고 한다. 주기적 생산 동안, 생산자는 요청 패킷 간격[RPI/Requested Packet Interval)이라고 불리는 특정 속도로 데이터를 전송하려고 시도할 것이다. RPI와 해당 API[Application Programming Interface]는 실제 데이터 값이 변화하는 속도에 관계없이 네트워크를 통해 생성되는 데이터의 속도를 지시한다.

데이터를 생성하는 다른 모드는 조사 및 상태 변화이다. 조사된 데이터의 경우 한 장치가 다른 장치에 특정 데이터 조각을 명시적으로 요청한다. 두장치 간의 대화를 위해, 이것은 데이터 교환을 달성하는 간단한 방법이지만, 동일한 정보가 여러 다른 장치에 전달되어야 할 때, 많은 양의 추가 통신이 발생한다. 데이터를 생성하는 마지막 모드를 상태 변화라고 한다. 즉, 값이 변경될 때만 한 장치가 다른 장치로 데이터를 보낸다.

이는 네트워크 트래픽을 쉽게 감소시킬 수 있지만, 수신 장치는 생산 장치가 보고해야 할 새로운 것이 없는지 또는 여전히 활성 상태 인지 알지 못하기 때문에 문제를 야기할 수 있다. EtherNet/ IP는 순수한 형태의 상태 변화를 구현하지 않지만, 수신기로 가는 이 “심장박동” 신호를 유지하기 위해 일정한 간격으로 일부 데이터를 전송하는 수정된 버전을 구현한다. API는 EtherNet/IP를 통한 대부분의 실시간 I/O 통신의 기초가 되기 때문에 기기 성능으로 볼 때 자연스럽게 시작할 수 있는 장소이다.

장치가 다른 조건에서 해당 API 값을 유지하는 능력은 제어 시스템에 매우 중요할 수 있다. 어떤 장치도 완벽 하게 작동한다고 볼 수 없어, 이러한 테스트는 특정 장치가 얼마나 밀접하게 API 값을 유지할 수 있는지를 보여준다. 합격 또는 불합격 값을 결정하지않는다. 이는 사용자에 의해 결정되어야 하며 기기의 성능 특성이 애플리케이션의 요구를 충족하는지 여부를 결정해야 한다. 사이클릭/API 테스트의 기본 전제는 특정 API 값으로 장치의 최대 처리량을 결정 하는 것이다. 생산자와 소비자 장치 모두 테스트 될 것이다. 기기는 공개된 기능이 외부에서 수행한 시험에 대해 불이익을 받지 않는다. 테스트 결과 최대 처리량 대 API 값의 2D 매트릭스가 생성된다. 테스트에 대한 의사 코드[Pseudocode]가 아래에 나와 있다.

주기적 API 테스트의 의사 코드[Pseudo-code]
1. 테스트에 대한 RPI 및 연결 크기 설정 
2. 테스트 대상 장치(DUT)와의 연결 설정 
3. 한동안 DUT와 통신한다.
4. 패킷 손실 확인 
5. API 통계(최소, 최대, 평균, 표준편차, 히스토그램 등) 계산 
6. 패킷 손실이 있을 경우 RPI 값을 높이고(빈도 감소) 계속한다.
7. 또는 API 및 통계를 보고한다.

이 유사 코드를 구현하는 것은 생산자 장치를 테스트하는데 비교적 쉽다. 임의의 장치는 DUT에 의한 패킷 생성을 자극 하기 위한 트래픽 생성기로 사용될 수 있다.

이를 통해 네트워크 분석기는 DUT에서 생성된 패킷 만 수신하면 되므로 테스 트에서 수동 구성 요소로 남을 수 있다. EtherNet/IP 장치에 대한 성능 테스트 방법론을 제거함으로써 2005년 3월 14일 6 PUB00081R1은 네트워크 분석기로 인해 보고된 오류를 최소 화할 수 있었다. EtherNet/IP는 프로토콜에서 시퀀스 번호를 사용하므로, 4단계에서 패킷 손실(또는 시퀀스 외 패킷)은 DUT 에 의해 생성된 시퀀스 번호에 따라 결정될 수 있다. 5단계에서 계산된 통계는 선택한 API의 처리량과 처리량 값의 지터와 관련이 있다.

테스트에서 패킷 손실이 나타나지 않으면 테스트가 성공하고 값이 보고된다. 그렇지 않으면 더 큰 RPI 값(낮은 RPI 주파수)에서 테스트를 다시 실행해야 한다. 생산자 장치에 대한 시험 구현은 비교적 간단하지만 소비자 장치에 대한 구현은 더복잡하다. 소비자 장치는 API 속도로 패킷을 수신해야 하며 패킷 손실을 보고하지 못할 수도 있다. 이는 EtherNet/IP 장치가 하트비트를 제외하고 양방향 통신을 가질 필요가 없기 때문이 다. 또 다른 어려움은 네트워크 분석기가 1단계부터 3단계까지의 트래픽 생성을 담당해야 한다는 것이다. 그렇지 않으면 다른 테스트 장비가 자체 지터에 오류를 발생시킬 수 있다.

이 오류는 위에서 설명한 생산자 테스트를 사용하여 DUT에서 테스 트를 수행하기 전에 반드시 확인해야 한다. 이러한 유형의 오류를 제거하는 유일한 방법은 네트워크 분석기를 트래픽 발생 기로 사용하는 것인데, 이는 DUT의 최소 RPI보다 최소 10배 더정확한 타이밍을 가져야 하며, 일정한 간격으로 데이터를 생성할 수 있다. ^[5] 장치가 여러 EtherNet/IP I/O 연결을 지원하는 것은 일반적이다. DUT의 성능을 완전히 테스트하려면 다양한 연결 수를 사용하여 DUT를 테스트해야 한다. 

이것은 무 부하 또는 경계 내 시험이므로 연결부의 수, 속도 및 크기는 제조자의 규격 내에 있어야 한다. 통계적으로 유의미한 결과를 제시하기 위해서는 DUT에서 많은 수의 패킷을 생산 또는 소비하고 일련의 시험을 수행해야 한다[각 시험의 패킷 수 결정에 대한 자세한 내용은 부록 C 참조]. 데이터 패킷 수가 많으면 표준 편차및 히스토그램을 계산하기 위해 각 개별 시행마다 통계적으로 많은 수의 API가 제공된다. 여러 번의 시행을 통해 한 번의 시행이 그러한 시행과 마주치기에 충분히 길지 않은 경우에 통계적 이상 징후를 확인할 수 있다.

보고 형식

이 테스트 동안 기록된 데이터는 API 타이밍과 패킷 시퀀스의 측정값을 나타낸다. API 타이밍을 위해 기록된 데이터는 평균 API 타이밍, 최소 API 타임, 최대 API 타임, API 타임의 표준 편차, API 타이밍 값의 히스토그램 등을 포함한다. DUT에 의해 생성되거나 소비되는 각 패킷은 패킷 손실 또는 시퀀스 외 패킷을 결정하기 위해 기록된다. 장치에 대한 API 타이밍에서 지터를 결정하기 위해, 여러 값이 제시될 것이다.

이 모든 값은 EtherNet/IP 장치를 위한 성능 테스트 방법론 2005년 3월 14일 7 PUB00081R1 및 각 개별 평가 판으로서 전체 평가 판에 대해 표시된다. 전체 시행 시퀀스를 계산할 때 각 개별 시행 중에 기록된 포인트 수를 포함하는 것이 중요하다. 평균 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 장치 성능 테스트 방법 2005년 3월 14일 9 PUB00081R1 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의 성능과 관련이 있다.

테스트 장비는 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 장치에 대한 성능 테스트 방법 2005년 3 월 14일 16 PUB00081R1 AL-SOF 테스트에 대한 조치 대기 시간은 네트워크 패킷과 해당 물리적 조치 사이의 차이로 계산 된다.

입력 AL-SOF 테스트의 경우, 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은 디지털 출력과 ALLB(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의 성능을 분석할 때 고려될 수 있다.

4. 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



5. 확인 사항

EtherNet/IP Performance Workgroup에서는 이 문서에 대한 의견을 제공해 준 다음 추가 담당자에게 감사를 드린다.
• 스콧 브래드너[Scott Bradner], 하버드 대학교

부록 A 테스트 아키텍처 범주

이 부록에서는 몇 가지 기본 테스트 아키텍처에 대한 다이어그 램을 제공한다. EtherNet/IP 성능 테스트에 사용할 수 있는 테스트 설정을 분류할 때 시작점이 되어야 한다. 사용된 특정 장비 및 아키텍처는 수행된 각 성능 테스트와 함께 문서화되어야 한다.
 
A. 1 간단한 테스트
가장 간단한 테스트에는 단일 테스트 장비 장치, 단일 네트 워크 인프라 장치 및 DUT가 포함된다.

A. 2 다중 시험장비 장치 (네트워크 연결)
다른 경우는 네트워크 인프라 장비를 통해 DUT에 네트워크로 연결된 다수의 테스트 장비를 포함할 수 있다.

A. 3 다중 시험장비 장치(일반)
이전 설정의 수정은 DUT에 직접 연결된 여러 시험 장비 장치를 포함하는 것이다.

A. 4 다중 네트워크 인프라 장비
또한 복수의 네트워크 기반 시설 장비 장치를 시험에 통합 하는 것이 가능할 수 있다. 이러한 상황은 방화벽, 침입 감지 시스템 또는 라우터와 같은 추가 장치가 테스트 장비와 DUT사이의 네트워크 인프라에 포함될 때 발생할 수 있다.

A. 5 다중 테스트 및 네트워크 인프라장비
시험 설정의 가장 일반적인 형태는 다수의 시험 장비 장치를 다수의 네트워크 기반 시설 장비 장치 및 DUT에 연결하는 것이다.

부록 B 메시지 클래스

이 부록에서는 이러한 성능 테스트에 사용할 수 있는 여 러 이더넷, IP, TCP, UDP 및 EtherNet/IP 메시지에 대해 자세히 설명한다. 먼저, 기본 메시지 구조에 대한 분류가 제공되 고, 그 다음 개별 메시지 클래스가 표시된다. 이더넷, IP, TCP, UDP 및 EtherNet/IP는 계층화된 접근 방식을 사용하여 네트 워크를 통해 데이터를 제공한다. ISO/OSI 7 계층 참조 모델에 대한 기본적인 이해는 이러한 계층이 상호 작용하는 방식을 이해하는 데 필요하다.

인터넷 또는 TCP/IP 상의 모든 좋은 교재는 참조 모델, 인터넷 프로토콜, 메시지 라우팅 등에 대한 매우 상세한 설명을 제공한다. ^[9][10] 이 부록은 본 문서에 설명된 테스트를 수행할 계획 이지만, 프로토콜에 대한 완전한 설명은 아니다.
 
B. 1 기본 메시지 구조

장치가 이더넷을 사용 한다고 말하는 것은 일반 적으로 벤더가 이더넷을 기반으로 하는 프로토콜 스위트를 사용한다는 것을 의미한다. 이더넷 위에 구축된 여러 프로토콜이 실제로 네트워크화된 두장치 간의 통신을 가능하게 한다. EtherNet/IP가 이더넷 및 기타 인터넷 프로 토콜을 통해 계층화하는 방법의 기본 레이아웃은 그림 9에 나와 있다. ^[4]

EtherNet/IP 메시지는 단순히 논리적으로 계층 화되는 것이 아니라, 실제 프로토콜은 각 프로토콜에 대해 헤더를 사용하여 메시지를 계층화해야 한다. EtherNet/IP 메시지에서 계층화의 그래픽적 표현은 다음과 같다.

B. 2 ARP 요청

장치가 이더넷 패킷을 다른 장치로 보내려면 대상의 MAC 주소를 알고 있어야 한다. 대부분의 장치가 MAC 주소가 아닌 IP 주소로 알려져 있기 때문에 주소 해결 프로토 콜(ARP)은 두 주소를 서로 매핑 하도록 설계되었다. 장치는 네트워크에서 ARP 요청을 브로드캐스트 하고, 대상 장치가 요청을 수신하면 ARP 응답으로 응답한다.

이 문서에 설명된 성능 테스트에서는 브로드캐스트 ARP 요청 메시지를 백그라 운드 트래픽으로 사용할 것을 권장한다. ARP 요청은 이더넷 프레임으로 전송된다. ARP 요청의 경우 이더넷 대상 MAC은 모두 1이고 소스 MAC은 장치의 MAC이며 유형은 0x0806이 다. 이더넷 및 IP에 대한 ARP 프로토콜 형식을 보여주는 그림은 다음과 같다. ^[10]

B. 3 이더넷/IP 목록 ID메시지

ListIdentity 메시지는 EtherNet/IP 장치에서 네트워크에 어떤 다른 EtherNet/IP 장치가 있는지 검색하는데 사용된다. 특정 EtherNet/IP 및 CIP 개념이고 모든 EtherNet/IP 장치가 이 메시 지에 응답하는 것이 사양에서 요구되므로 이러한 표준화된 성능 테스트에 사용하는 것이 좋다. 아래 그림은 ListIdentity 메시 지의 메시지 형식을 보여준다. ^[6]

참고: EtherNet/IP에서 기억해야 할 한 가지는 바이트가 little-endian(단어의 바이트는 실제로 가장 작은 것부터 가장큰 것까지 와이어에 놓인다)이라는 것이다. 이것은 빅 엔디언 (단어의 바이트는 가장 큰 것부터 가장 작은 것까지 와이어에 놓인다)인 다른 모든 표준 이더넷 기반 프로토콜과는 반대이다. 예를 들어, 0x63에 대한 2바이트 워드는 실제로 0x0063 대신 EtherNet/IP 메시지에서 0x6300으로 와이어에 표시된다.

부록 C 통계적으로 유의미한 샘플 수 계산

통계적으로 유의미한 수의 샘플을 얻기 위해 특정 측정을 몇번이나 수행해야 하는지 아는 것이 중요하다. 통계의 원리를 사용하여 샘플의 일반적인 관행 수를 비교적 쉽게 결정할 수 있다. 개별 샘플은 서로 독립적이고 랜덤하기 때문에, 그 값은 많은 수의 샘플에 대한 가우스 랜덤변수로 표현될 수 있다. 가우스 무작위 변수는 잘 이해되지만, 복잡성으로 인해 그와 관련된 많은 값을 수치적으로 계산할 필요가 있다.

이러한 값 중 하나는 개별 표본이 특정 범위 밖에 있을 확률을 나타내는 누적 분포 함수(CDF)이다. 가우스 CDF[channel definition format]는 많은 통계 또는 통신 교과서에서 표로 작성되었다. ^[11] 프로세스의 다음 부분은 가우스 테이블에서 결정된 확률 값에서 샘플 수를 결정하는 것이다. ARL(Average Run Length)은 위의 가우스 랜덤 변수의 평균으로부터 계산된 샘플의 정수이다. ARL은 가우스 CDF의 역수보다 크거나 같다.


참고문헌

[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 .
[9] TCP/IP Illustrated, Volume 1: The Protocols, W. Richard Stevens, Addison-Wesley Publishing, 1994.
[10] Internetworking with TCP/IP: Principles, Protocols, and Architectures, Douglas E. Comer, Prentice Hall Publishing, 2000.
[11] Modern Digital and Analog Communication Systems, 3rd Edition, B. P. Lathi, Oxford University Press, 1998.