cRIO는 왜 사용하는 것일까요?
cRIO를 사용하는 이유는 여러 가지가 있을 것인데, 임베디드 시스템을 구성할 때, 정시성을 보장해야 할 때 등이 있을 것입니다. cRIO는 RTOS, FPGA로 구성이 되어 독립적으로 동작이 가능하지만, 일반적으로 Host를 이용하여 cRIO를 컨트롤 및 모니터링 합니다.
이번 포스팅에서는 cRIO를 이용한 기본적인 시스템 구조에 대해 알아보도록 하겠습니다.
이 내용들은 NI에서 제공하는 'NI LabVIEW for CompactRIO Developer's Guide'를 바탕으로 함을 미리 알려드립니다.
1. 기본적인 cRIO의 구조
앞서 언급한 바와 같이 cRIO는 RTOS와 FPGA로 구성이 되어 있고 Host를 이용하여 컨트롤하거나 cRIO의 상태를 모니터링 합니다. 그렇게 하기 위해서는 Host, RTOS, FPGA간의 연결이 매우 중요하게 됩니다. 아래 그림은 일반적인 cRIO의 시스템 구조를 나타내고 있습니다.
<그림 1일반적인 cRIO의 구조>
cRIO 제품 특성상 Host와의 연결은 Ethernet 케이블을 이용합니다.(cRIO와 Host를 다이렉트로 연결해도 되고, 허브를 이용해서 같은 네트워크로 묶어도 됩니다.) 그리고 RTOS와 FPGA는 내부 PCI 버스로 연결이 되어 있고 이 버스를 이용해서 상호간에 데이터를 교환할 수 있게 되는 것입니다. 위의 그림 1에서 주의 깊게 봐야할 것은 3영역 모두 Process 루프가 있고 RTOS의 경우 여러 Process가 존재할 수 있다는 것입니다. 또한 Process간의 데이터 교환이 필요할 수도 있는 것입니다.
1) Process
위에서 RTOS의 경우 하나 이상의 Process가 존재할 수 있다고 이야기 했습니다. 예를 들어서 측정 및 데이터 로깅을 cRIO의 RTOS에서 한다고 생각해봅시다.
이 경우, 측정 Process와 로깅 Process가 생성이 됩니다. 이 두 작업을 하나의 Loop로 구성하면 하나의 Process가 됩니다. 하지만, 두 내용을 하나의 Loop로 구성할 경우 데이터 로깅 시간 때문에 측정 시간에 지연이 발생 할 수 있습니다. 이러한 이유 때문에 서로 다른 작업은 각각 Loop를 구성하는 것이 일반적이로 두 개 이상의 Process가 생성되는 것입니다.
Process가 2개 이상이 생성될 경우 각 Process의 동작시간에 유의해야 합니다. 각 Process별로 우선순위를 매겨서 반드시 정확한 시간에 동작할 수 있도록 보장해야 한다는 것입니다. 예를 들어서 측정에 걸리는 동작시간이 7ms이고 로깅에 걸리는 동작시간이 2ms라고 가정하겠습니다. 만약 측정 Process를 8ms마다 동작하도록 loop 타이밍을 정해줄 경우 측정을 마치고 남는 시간은 1ms입니다. 이 남는 시간에 CPU는 다른 Process를 진행할 수 있는데 로깅 시간이 2ms이기 때문에 그 시간이 부족합니다. 때문에 각 Process가 동작할 수 있도록 동작 시간에 여유를 두는 것이 중요합니다.
<그림 2 Process 동작 시간의 중요성>
2) Data Communication
cRIO에서의 결과 값을 Host에서 모니터링 하거나 Host에서 특정 데이터를 cRIO로 전달할 경우가 있을 것입니다. 이 경우 이더넷 케이블로 전달이 됩니다. TCP/IP와 같은 네트워크 통신 프로토콜, NI에서 제공하는 공유 변수 등을 이용하게 됩니다. 아래 표는 이러한 방법들을 이용하기 전에 데이터 Host와 cRIO간의 데이터 통신 종류입니다.
Communication Type | Fundamental Features | Optional Features | Performance |
Message-Based | Buffering, Blocking(timeout) | Acknowledgement of data transfer | Low latency |
Current Value Data(tag) | Nonhistorical | Dynamic tag lookup, Group management | Low latency, High-channel count |
Updates | Nonhistorical, Blocking(timeout) | Broadcasting | Low latency |
Streaming/Buffered | Buffering, Blocking(timeout) | Multilayer Buffering | High Throughput |
위의 표는 데이터 통신의 방법에 대해 4가지로 분류를 한 것이며 직접 사용되는 함수나 기능은 아닙니다.
2-1) Message-Based
HMI(Human Machine Interface)혹은 Host를 이용하여 cRIO를 제어할 때 어떤 제어 명령을 즉각적으로 처리할 필요가 있습니다. 이러한 명령은 항상 있는 것이 아니라 특정 순간에 전달됩니다. 그리고 명령이 중간에 손실되어서도 안됩니다. 때문에 모든 명령을 놓치지 않도록 버퍼링 기능이 있어야 하며, cRIO는 명령이 전달되는지 계속 확인(Polling 방식)할 필요 없이 명령이 전달되는 그 순간(Blocking) 해당 명령을 처리하면 됩니다.
2-2) Current Value Data(tag)
Current Value Data는 Host측에서 어떤 순간에, 즉 그 시간에 cRIO의 상황 혹은 데이터를 확인하고자 할 때 사용하는 방식입니다. 때문에 이전 혹은 모든 데이터를 버퍼링 할 필요가 없습니다. 하지만 반복적으로 데이터를 확인 할 필요가 있을 경우 사용하는 방법이기 때문에 Polling방식이 적용됩니다. 기능적 글로벌 변수를 응용한 CVT라이브러리나 변수가 그 예입니다.
2-3) Updates
Updated 방식은 Message-Based와 Current Value Data의 혼합으로 보면 됩니다. 데이터를 버퍼링 하지 않으면서 Host측에서 원하는 순간 데이터를 얻고자 할 때 사용하는 방법입니다.
2-4) Streaming/Buffered
Streaming/Buffered 방식은 처리량이 많을 때, 즉 지연시간보다 처리량을 더 고려해야 할 경우 사용하는 방법입니다. 때문에 데이터 전송이 지연되더라도 손실이 있어서는 않되므로 버퍼링 기능이 필요합니다. 주로 RTOS와 FPGA간의 데이터 전송에 사용되는 방법입니다.
2. 일반적인 Host-cRIO의 시스템 구조
위의 설명으로 Host, RTOS, FPGA에는 각각 Process가 존재하게 됨을 알게되었습니다. 그렇다면 Host, RTOS,FPGA 각각에는 어떠한 Process가 구성이 될까요?
<그림 3일반적인 Host-cRIO간의 시스템 구조>
1) Host
Host는 제어 및 모니터링을 관리하기 때문에 UI를 관리하는 Process가 존재하게 됩니다. 이 UI의 조작을 Event적으로 받아서 처리해야 하므로 UI Event Handler가 구성이되고 명령을 전달하는 Command Sender Process가 있습니다. 요약하자면 UI제어와 UI 제어에 따른 명령을 cRIO로 전달하는 Process로 구성이 됩니다.
2) RTOS
cRIO의 RTOS는 Host로부터 전송되는 명령을 파악해야 합니다. 이를 위한 Command Parser Process가 있고 이 명령을 바탕으로 cRIO를 동작시키게 합니다. 이 역할을 Software Control Process가 관리합니다. cRIO의 동작 상황을 Host에서 확인할 필요가 있기 때문에 Host와 통신을 관리하는 Process가 존재합니다.
3) FPGA
FPGA는 샤시에 연결된 I/O 모듈을 제어하게 됩니다. I/O 모듈은 FPGA와 연결되어 동작하게 되고 이 모듈에 대한 제어 신호 전달과 측정값 읽기는 PCI 버스를 통해 RTOS로 전달됩니다.
이번 포스팅에서는 일반적으로 적용되는cRIO와 Host의 시스템 구조를 알아보았습니다.
위에서 언급한 내용은 보편적으로 사용되는 형태이며, 반드시 지켜져야 하는 것은 아닙니다. 하지만 이 내용에서 다루어지는 개념은 나중에서 언급되는 것이며 cRIO를 올바로 사용하기 위해 필요한 것입니다.
댓글