기능성 프로토타입을 만드는 7단계

기능성 프로토타입은 작동 또는 작동을 시뮬레이션하는 제품의 테스트 가능한 대화형 모델로, 하드웨어 또는 소프트웨어를 완성하는 마지막 퍼즐 조각이라 하겠습니다. 설계자와 엔지니어는 기능성 프로토타입을 테스트하여 생산을 시작하기 전에 문제가 있는지 확인할 수 있어 제조 중 또는 출시 후 문제를 해결하는 데 드는 시간과 비용을 절약할 수 있습니다.

종이 설계 도면의 중요성

새롭고 혁신적인 디바이스의 아이디어가 떠오르면 종이에 설계 도면을 작성하는 작업은 건너뛰고 바로 프로토타입을 만들고 싶은 마음이 들 수도 있습니다. 이러한 유혹을 물리치면 장기적으로 시간을 절약하고 품을 덜 들일 수 있습니다. 종이에 설계 도면을 그려놓으면 나중에 큰 도움이 됩니다. 설계 과정에서 흔히 발생하는 여러 가지 실수를 방지할 수 있기 때문입니다. 종이에 설계 도면을 작성하는 작업은 프로토타입의 상세한 설계를 펜이나 연필로 종이에 그리는 것이 아닙니다. 종이에 설계 도면을 작성하는 일은 소프트웨어 코딩 또는 하드웨어 설계 전에 계획을 세우는 일입니다. 종이에 설계 도면을 작성하면 머릿속 아이디어를 종이에 그려둘 수 있고 나중에 실패하기 전에 미리 문제를 파악할 수 있는 것은 물론 조기에 고객의 의견을 물을 수 있다는 것이 장점입니다.

요건을 분명히 규정

훌륭한 아이디어와 간단한 스케치를 자세한 설계 도면으로 작성하려면 어떻게 해야 할까요? 첫 번째 단계는 사용자가 필요로 하는 요건을 리스트로 만들어 목표를 명확하게 규정하는 것입니다. 이러한 요건은 최대한 구체적으로 작성해야 합니다. 초기 단계에서 요건을 충족할 수 있는지 확인하려면 조사가 매우 중요합니다. 설계를 현실적으로 구현할 수 있습니까? 실제로 요건을 충족할 수 있습니까? 설계에 필요한 것과 원하는 것을 구분해야 합니다. 혁신가로서 프로토타입에 꼭 필요하지는 않지만 고급 기능을 추가하고 싶을 수도 있습니다. 목표를 세우고 이를 고수해야 합니다.

요건에서 구성요소 추상화

추상화를 통해 어플리케이션 작성 방법을 규정하지 않고도 이를 설명할 수 있습니다. 추상화는 상위 개념 수준으로, 어플리케이션을 개략적으로 표현할 수 있습니다. 추상화의 주요 타입은 두 가지로, 절차적 추상화와 데이터 추상화가 있습니다. 절차적 추상화는 절차로 수행되는 것과 절차가 구현되는 방식을 분리합니다. 데이터 추상화는 저장하려는 데이터를 데이터를 저장하는 물리적 수단과 분리합니다. 손쉽게 추상화하려면 시스템 요건 문서를 작성할 때 주요 동사와 명사를 제거합니다. 이러한 동사와 명사에서 프로그램이 해야 되는 것과 사용자 인터페이스의 일부가 될 객체를 결정할 수 있습니다. 동사와 명사는 또한 프로토타입을 완성하는 데 필요한 하드웨어 구성요소를 결정하는 데도 도움이 됩니다.

순서도

디바이스 요건에서 추상화된 구성요소 세트를 얻었다면 순서도를 사용하여 추상화된 구성요소를 가지고 소프트웨어를 설계할 수 있습니다. 순서도를 사용하면 어플리케이션을 더 관리하기 쉽게 나눌 수 있어 어플리케이션의 흐름을 이해하기 더 쉬워집니다. LabVIEW는 엔지니어와 과학자의 생산성을 높이는 그래픽 프로그래밍 개발 환경으로, 종이에 작성한 설계 도면을 신속하게 코드로 변환할 수 있는 도구입니다. LabVIEW 블록다이어그램은 순서도와 비슷해서 순서도에서 소프트웨어 코드로 매우 빠르게 전환할 수 있습니다.

^{그림 1: 이 순서도, 상태 다이어그램, 혈압 모니터의 상태 머신 이미지에서 상태 다이어그램에 규정된 5가지 상태가 상태 머신에서 구현됩니다.}

상태 다이어그램

상태 다이어그램은 프로그램의 상태와 상태의 변화를 표시하는 특정 타입의 순서도입니다. 각 상태는 조건을 충족하거나 작업하거나 이벤트를 기다립니다. 상태의 변화는 프로그램이 다음 상태로 옮겨가게 하는 조건, 동작 또는 이벤트입니다. 거의 모든 임베디드 시스템이 상태 아키텍처를 사용하기 때문에 상태 다이어그램은 프로토타이핑에 유용합니다. 즉, 프로토타입이 항상 특정 상태에 있다는 이해를 바탕으로 설계되었습니다. 유휴 상태인 경우에도 마찬가지입니다.

LabVIEW에서 상태 머신은 케이스 구조, While 루프, 시프트 레지스터로 구성됩니다. 초기 케이스가 루프 밖에서 지정됩니다. 상태 다이어그램의 각 상태는 케이스 구조의 한 케이스에 대응합니다. 각 케이스에는 하나의 상태를 구현하는 코드와 다른 케이스로의 변환을 정의하는 로직이 포함됩니다. 이 아키텍처를 사용하면 상태 머신에 더 많은 케이스와 로직을 추가하여 어플리케이션을 확장할 수 있습니다.

사용자 인터페이스 (UI)를 프로토타이핑하기 가장 좋은 시기는 종이에 작성한 설계 도면을 소프트웨어로 전환할 때입니다. UI 프로토타이핑은 이러한 전환 과정에서 설계 아키텍처와 어플리케이션 요건을 검토하는 데 도움이 됩니다. 또한 잠재적인 고객과 투자자에게 실질적인 디바이스 기능을 시연할 수 있다는 점에서도 중요합니다. 프로토타입이 복잡할수록 설계를 지원하고 피드백을 모으는 데 있어 UI 프로토타입의 가치가 더 높아집니다. 마지막으로, 이는 프로토타입 설계자가 구성요소를 설계하고 프로토타입에 기능을 추가할 수 있는 하나의 통일된 플랫폼을 구축합니다. 이러한 UI 프로토타이핑의 장점을 통해 비용을 절감하고 개발 시간을 단축할 수 있으며 궁극적으로 더 나은 제품을 만들 수 있습니다.

^{그림 2: LabVIEW에서 설계된 UI(UI 관심 그룹에서 코드 얻기)}

LabVIEW에는 프런트패널이 내장되어 있으며, 이를 통해 맞춤형 UI를 신속하게 개발할 수 있습니다. LabVIEW를 사용하면 설계와 프로토타이핑 주기를 지나면서 쉽게 기능을 추가할 수 있어 설계를 반복하는 동안 재작업을 최대로 줄일 수 있습니다. LabVIEW를 사용하면 UI를 신속하게 프로토타이핑하고 프로토타이핑 프로세스 전반에 걸쳐 수정하고 완제품에 배포할 수도 있습니다.

목업 생성

LabVIEW에서는 코드를 한 줄 작성하거나 어플리케이션 아키텍처를 완성하기 전에 필요한 모든 입력과 출력을 생성하고 프런트패널을 설계할 수 있습니다. 이 UI 목업은 실제로 필요한 입력과 출력을 결정하는 데 유용하며 요건 문서를 개선하는 데 사용할 수 있습니다.

^{그림 3: LabVIEW의 UI 목업}

기능 추가

UI 프로토타이핑의 다음 단계는 사용자의 프런트패널 사용, 메뉴 클릭, 컨트롤 조정, 샘플 데이터 세트 또는 난수 생성에 따른 결과 확인이 가능하도록 목업에 기능을 추가하는 것입니다. 이 방식의 장점은 소프트웨어 설계 구조를 정의할 뿐만 아니라 UI를 프로토타이핑할 수 있다는 점입니다. 이 두 가지를 제대로 해내면 나머지 프로토타이핑 프로세스에서 구조를 구축할 수 있습니다.

버추얼 프로토타이핑은 기계 모델링과 시뮬레이션을 컨트롤 설계와 결합하여 더 효율적으로 임베디드 컨트롤 시스템과 디바이스를 설계하고 프로토타이핑할 수 있는 혁신적인 방법입니다. 버추얼 프로토타이핑을 통해 소프트웨어 설계와 컨트롤 알고리즘을 3D CAD 기계 모델에 연결하여 실제로 첫 프로토타입을 만들기 전에 시스템의 메커니즘을 테스트할 수 있습니다.

^{그림 4: 버추얼 프로토타이핑 메소드}

버추얼 프로토타이핑의 필요성

버추얼 프로토타이핑은 고객 요건을 더 자세히 이해하고 설계 프로세스를 단축하며 디버깅을 간소화하여 머신 설계 시 위험을 낮춥니다. 버추얼 프로토타입이 없으면 제품의 작동과 관련된 실질적인 피드백을 고객에게 받기 전에 실제 전체 프로토타입을 만들어야 합니다. 버추얼 프로토타이핑을 사용하면 고객에게 기계 역학을 디지털화하여 설명하고 실제로 머신을 만들기 전에 더 빨리 피드백을 받을 수 있습니다. 이렇게 하면 고객이 설계 프로세스에 더 많이 참여할 수 있고 고객의 피드백을 기다리느라 프로토타이핑 프로세스가 너무 늦어지는 것을 막을 수 있습니다.

또한 버추얼 프로토타입을 생성하면 더 빨리 제품을 시장에 출시할 수 있습니다. 이러한 프로토타입은 버추얼 설계를 개념화하고 반복하는 데 도움이 되어 실제 프로토타입을 만들었을 때 처음부터 제대로 된 결과를 얻을 수 있습니다. 컨트롤 소프트웨어를 3D CAD 모델에 연결할 수 있어 일반적으로 실제 프로토타입을 만들기 전에 발견할 수 없는 문제를 찾아 수정할 수 있습니다. 2D 및 3D 모션 프로파일과 같은 모션 컨트롤 코드를 작성한 후 그 코드가 3D 모델에서 어떻게 구현되는지 확인할 수 있습니다. 부품이 너무 커서 충돌을 일으킬 수 있거나 컨투어 이동과 선형 이동의 차이를 확인하려는 경우 버추얼 프로토타이핑을 사용하여 문제를 해결하고 차이를 확인할 수 있습니다. 버추얼 프로토타이핑은 기존의 설계 방식과 비교했을 때 프로세스 초기에 설계와 관련된 주요 결정을 내리는 데 도움이 됩니다.

NI 버추얼 프로토타이핑의 장점

LabVIEW를 사용하여 모든 기계적 시스템을 시뮬레이션할 수 있습니다. LabVIEW Control Design and Simulation Module을 사용하면 개루프 모델 동작을 분석하고 폐루프 컨트롤러를 설계하며 온라인과 오프라인 시스템을 시뮬레이션하는 것은 물론 물리적으로 구현할 수 있습니다.

^{그림 5: LabVIEW 컨트롤 설계 및 시뮬레이션 도구}

전달 함수, 상태 공간 또는 영점-극점-게인 형을 사용하여 첫 번째 원리에서 모델을 생성할 수 있습니다. 또한 시간 간격 응답 또는 보드 플롯과 같은 시간과 주파수 분석 도구를 사용하여 이러한 모델의 개루프와 폐루프 동작을 대화식으로 분석할 수 있습니다. MIMO (Multiple Input, Multiple Output)와 SISO (Single Input, Single Output) 시스템 모두에 내장된 도구를 사용하고 시뮬레이션 기능을 활용하여 선형과 비선형 시스템 역학을 검증합니다. 또한 내장된 도구를 사용하여 The MathWorks, Inc. Simulink® 소프트웨어에서 만든 모델을 LabVIEW에서 사용할 수 있도록 변환할 수 있습니다.

프로토타입에 I/O를 추가해야 진정한 기능성 시스템을 만들 수 있습니다. 센서 입력과 컨트롤 출력을 추가하면 설계가 제대로 되었고 실제 환경에서 구현될 수 있음을 증명할 수 있습니다. 종이에 설계 도면을 작성하고 소프트웨어에서 설계를 구현하며 버추얼 환경에서 설계를 시뮬레이션하는 것은 대부분 개념적 훈련입니다. 회의적인 투자자에게 설계의 가치를 알리려면 실제 환경에서 구현할 수 있는 기능적인 설계가 필요합니다. 프로토타이핑 작업의 데이터 또한 실제 성능을 기반으로 고객과 나머지 설계 팀의 기능적 요건을 개선하는 데 도움이 됩니다.

센서를 처음부터 시스템에 통합하고 유의미한 데이터를 얻는 데는 많은 지식이 필요하지 않지만, 실제로는 지식이 너무 없으면 예상치 못한 시간과 리소스가 소요될 수 있습니다. 기존 센서 고유의 통합 특성 때문에 각각의 설계를 변경해야 하며, 이는 비용이 많이 드는 재작업으로 이어집니다. 특히 센서와 관련하여 설계가 변경되는 경향이 있습니다. 프로토타입의 요건에 맞도록 스펙을 변경하는 것은 그 자체로 어려울 수 있기 때문입니다.

프로토타입에 I/O를 추가하는 것은 어려울 수 있습니다. 사용자 정의 I/O 솔루션을 구축하는 데 필요한 시간과 리소스의 양을 예측하기 어렵기 때문에 프로토타이핑 프로세스에서 종종 문제가 발생합니다.

I/O를 사용한 프로토타이핑의 전형적인 어려움을 극복하려면 접근 방식의 패러다임을 전환해야 합니다. 특히 디바이스를 효율적으로 프로토타이핑해야 하지만 하위 레벨 센서 인터페이스의 문제를 해결할 수 있는 전문 리소스가 없는 도메인 전문가인 경우 더욱 그렇습니다.

NI 도구는 통합 하드웨어와 직관적인 그래픽 소프트웨어, 재구성 가능한 I/O 디바이스, 성공에 필요한 IP와 지원 시스템에서 패러다임을 전환하여 이러한 장애를 극복할 수 있도록 지원합니다.

^{그림 6: CompactRIO와 신호 컨디셔닝이 내장되어 있고 핫스왑이 가능한 모듈형 C 시리즈 I/O 모듈을 결합하면 I/O를 프로토타입에 신속하게 추가할 수 있습니다.}

센서 입력과 컨트롤 출력을 기능성 프로토타입에 제대로 통합해야만 배포와 대량 생산에서 큰 진전을 이룰 수 있습니다. 이 단계는 제품 설계 과정에서 가장 큰 문제를 극복했다는 뜻입니다.

알고리즘 엔지니어링은 적용된 알고리즘 설계를 일컫는 용어입니다. 이는 대략적인 아이디어만 잡혀 있는 알고리즘을 사용하기 쉽고 강력하며 잘 테스트된 상태로 구현해 가는 프로세스를 나타냅니다. 프로토타입에서 원하는 기능을 제공하는 알고리즘을 구현하는 것은 전체 제품 개발 수명 주기에서 가장 어려운 부분일지 모르지만 가장 뿌듯한 일이기도 합니다. 실제 I/O를 적용하면 알고리즘의 기능이 눈 앞에서 실제로 구현되는 것을 볼 수 있습니다. 

기능성 프로토타입에서 알고리즘 구현이 어려운 이유에는 여러 가지가 있습니다.

프로그래밍 한계—FPGA와 같이 I/O 기능에 따라 선택되는 컨트롤 시스템 또는 프로세서는 개발자가 프로그래밍 제한을 받는 경우가 많습니다. 여러 플랫폼을 프로그래밍하려면 소수의 시스템 레벨 설계자만 능숙하게 다룰 수 있는 프로그래밍 지식이 필요합니다.

기본 알고리즘 구현—기본 기능을 위한 하위 레벨 알고리즘을 구현하려면 시간이 걸립니다. 프로토타이핑은 속도가 생명이기 때문에 일반적으로 설계자는 기존 코드 부족으로 인해 잘 알려진 알고리즘을 처음부터 구현하는 데 시간을 허비할 여유가 없습니다.

여러 플랫폼을 위한 알고리즘 재작업—기능성 프로토타입은 발전함에 따라 다른 유형의 시스템에 알고리즘을 이식하기 위해서는 알고리즘을 여러 번 다시 살펴봐야 합니다. 코드는 서로 다른 런타임 환경 간에 거의 작동하지 않기 때문에 프로토타이핑에서 배포에 이르기까지 어플리케이션을 확장하기 어렵습니다.

테스트 및 검증—일반적으로 프로세스 후반까지 시스템이 기능적 요건을 충족할 수 있는지 확신할 수 없으며 처음부터 다시 시작하려면 비용이 너무 많이 듭니다. 예를 들어 프로세서가 필요한 수의 병렬 작업을 충분히 빠르게 수행하지 못할 수 있습니다. 따라서 적절한 사이클 시간을 달성하지 못할 수 있습니다. 또한 프로세서 집약적인 분석을 리얼타임으로 처리하지 못할 수도 있습니다.

LabVIEW Graphical System Design은 기능성 프로토타입의 엔지니어링 알고리즘에 잠재된 여러 위험을 해결하고 완화합니다. Graphical System Design은 직관적인 그래픽 프로그래밍과 다양한 COTS (상용 기성품) 하드웨어를 결합하여 설계 과제를 해결하는 접근 방식입니다. 이 방식을 사용하면 설계의 모든 단계에서 단일 환경을 사용할 수 있습니다. 이제 이 접근 방식을 통해 위에서 제기한 과제를 구체적으로 어떻게 해결할 수 있는지 자세히 살펴보겠습니다.

다중 계산 모델

Graphical System Design의 장점 중 하나는 프로그래머가 구현된 계산 모델 (MoC)에 관계없이 알고리즘을 생성할 수 있다는 것입니다. 프로그래머는 알고리즘 코드가 계속해서 복잡해짐에 따라 코딩 기능을 확장하기 위해 다양한 MoC를 사용해야 합니다. 다음은 Graphical System Design에 사용할 수 있는 몇 가지 MoC입니다.

데이터 흐름―데이터 흐름은 LabVIEW 소프트웨어에서 가장 흔히 사용되는 MoC입니다. 데이터 흐름에서 작업을 수행하려면 작업을 실행하기 전에 개발자가 모든 입력에 데이터를 삽입해야 합니다. 데이터 흐름은 이를 통해 병렬 프로세스와 같은 어플리케이션을 쉽게 구현할 수 있는 직관적인 코딩 구조입니다.

텍스트 기반 연산―텍스트 기반 연산은 복잡한 함수를 쉽게 생성할 수 있는 또 다른 도구입니다. 텍스트 기반 연산은 스크립트 설명 형태로 작성하는 것이 더 쉬운 복잡한 알고리즘을 사람이 읽을 수 있도록 구현한 것입니다. 텍스트 기반 연산의 예로는 수식 노드와 LabVIEW MathScript RT Module이 있습니다. LabVIEW MathScript를 사용하면 알고리즘 개발, 신호 처리 개념 탐색 또는 결과 분석 등 어떤 작업을 하든 알고리즘 개발에 가장 효과적인 구문을 선택할 수 있습니다.

^{그림 7: LabVIEW MathScript RT Module에서 텍스트 기반 코드 재사용}

C 코드—사용하는 알고리즘이 원래 C 또는 C++로 생성된 경우가 있습니다. 이 경우 더 이상 이전 작업을 버릴 필요가 없습니다. 대신 인라인 C 노드 또는 라이브러리 함수 호출 노드를 사용하여 LabVIEW 내에서 이전 코드를 직접 호출할 수 있습니다. 기존의 C 코드에 인라인 C 노드를 사용하거나 작은 숫자형 또는 배열 알고리즘을 구현하고 라이브러리 함수 호출 노드를 사용하여 DLL 또는 공유 라이브러리의 C 코드에 액세스합니다.

개방형 소프트웨어 아키텍처

LabVIEW 플랫폼은 수년 동안 수많은 설계 분야에서 광범위하게 사용되어 왔으며 그 결과 다양한 설계와 시뮬레이션 도구를 데이터와 통합해야 할 필요성이 대두되었습니다. LabVIEW는 다양한 통합 도구, 라이브러리, 파일 포맷과 상호 호환 가능합니다. 또한 LabVIEW는 다음을 비롯한 측정 리소스 및 다양한 소프트웨어 도구와 표준 통합이 가능합니다.

• DLL, 공유 라이브러리
• ActiveX, COM, .NET (Microsoft)
• DDE, TCP/IP, UDP, Ethernet, Bluetooth
• CAN, DeviceNet, Modbus, OPC
• USB, IEEE 1394, RS232/485, GPIB
• 데이터베이스(ADO, SQL 등)

이러한 도구를 사용하면 거의 모든 종류의 측정 및 컨트롤 디바이스의 데이터와 통합할 수 있습니다. 개발자는 LabVIEW를 하드웨어 통신용 범용 표준과 결합하여 향후 수년간 호환성과 확장성을 확보할 수 있습니다.

LabVIEW 접근 방식

연산, 신호 처리, 확률, 컨트롤의 다양한 기존 알고리즘을 다루는 LabVIEW의 수백 가지 함수는 모든 사용자 정의 알고리즘의 필수 구성요소입니다. 이러한 함수를 이용하면 엔지니어가 하위 레벨 코드를 작성해야 하는 부담을 덜고 구현이 아니라 솔루션에 집중할 수 있는 시간을 벌 수 있습니다.

LabVIEW를 사용하면 실제 데이터를 쉽게 수집할 수 있기 때문에 엔지니어는 알고리즘을 튜닝하는 반복적인 접근 방식으로 실제 데이터를 사용하여 알고리즘을 테스트할 수 있습니다. 이 대화식 테스트 접근 방식을 통해 다양한 함수를 실험하여 필요한 예상 결과를 얻을 수 있는지 확인할 수 있습니다. 예를 들어 필터를 사용하여 신호를 처리할 때 다양한 솔루션 중에서 선택할 수 있고 필요한 실제 신호를 수집할 수 있으며 결과를 그래프나 파일로 볼 수 있습니다. 결과가 어플리케이션에 적합하지 않은 경우, 다른 필터를 선택할 수 있습니다. 종종 실제 신호를 수집하여 알고리즘에 적용한 후 시간을 들여 소프트웨어에서 시뮬레이션하는 것이 더 쉽습니다.

^{그림 8: NI는 프로토타입에 사용할 수 있는 수백 개의 알고리즘이 내장된 LabVIEW를 제공합니다.}

프로토타입의 목적 중 하나는 아이디어와 설계를 잠재 고객, 투자자, 동료에게 신속하게 시연하는 것입니다. 프로토타입을 만드는 또 다른 중요한 이유는 기본 소프트웨어와 하드웨어의 성능을 위해 설계를 테스트하고 검증하는 것입니다. 기능성 프로토타입의 전기, 소프트웨어, 기계적 구성요소를 결합했을 때만 문제가 분명해지는 경우가 많습니다. 

프로토타이핑 단계에서 철저하게 테스트하면 큰 매몰 비용이 발생하고 문제 해결이 불가능해지기 전에 문제를 파악할 수 있습니다. 프로토타입 테스트는 성능을 뒷받침하는 구체적인 증거를 제시하며, 이를 통해 결과적으로 신뢰할 수 있는 최종 제품을 만들어 배포할 수 있습니다.

소프트웨어 정의 인스트루먼트는 본질적으로 유연하고 쉽게 자동화됩니다. 따라서 오늘날 제품 설계 팀은 수동으로 테스트하는 데 소요되는 시간을 줄이고 실험실에서 필요로 하는 계측의 양을 최소화하여 개발 프로세스를 간소화할 수 있습니다.

LabVIEW 그래픽 소프트웨어 플랫폼을 사용하면 간단한 프로그램을 설정하여 주요 알고리즘의 품질과 안정성을 테스트할 수 있습니다. 프로토타이핑 시에는 다음 두 가지 주요 테스트 측면에 주의하십시오.

리미트 테스팅—소프트웨어 설계를 통해 데이터 포인트 범위 전체에 걸쳐 I/O 채널에서 양질의 데이터를 얻을 수 있는지 확인하십시오. 이렇게 하면 제품 개발 주기 전반에 걸쳐 프로토타입을 양질의 스펙 내로 유지할 수 있습니다.

부하 테스트—장기간의 노출과 모든 I/O 채널이 동시에 한계에 도달했을 때 스펙의 질이 유지되는지 확인하십시오. 알고리즘은 처리 중인 데이터의 오버로드가 발생하는 상황을 해결할 수 있을 만큼 견고해야 합니다.

시뮬레이션 VI를 사용하여 소프트웨어 알고리즘을 한계까지 확장하여 하드웨어 없이 테스트합니다. 다양한 신호 생성 VI를 사용하거나 실제 I/O를 정확하게 묘사하는 VI를 개발하여 LabVIEW에서 이를 실행할 수 있습니다.

^{그림 9: I/O 시뮬레이션 메소드}

데이터 수집을 사용한 I/O 측정

소프트웨어 테스트는 실제 하드웨어를 사용하는 것과는 느낌이 다르기 때문에 제한적일 수 있습니다. LabVIEW를 사용하면 COTS 하드웨어를 사용하여 실제 I/O를 테스트할 수 있습니다.

디지털 멀티미터 또는 데이터 수집 디바이스를 사용하여 실제 하드웨어 I/O를 디버깅할 수 있습니다. LabVIEW는 NI-DAQmx 드라이버와 결합되어 DAQmx 익스프레스 VI로 복잡한 데이터 수집 작업을 실행할 수 있는 사용하기 쉬운 하이 레벨 인터페이스를 제공합니다.

^{그림 10: NI DAQ 하드웨어로 테스트}

아이디어를 종이에 설계 도면으로 작성하고 기능성 프로토타입을 만들고 최종적으로 출시할 제품으로 만들기까지 설계 프로세스를 이어가는 것은 어려울 수 있습니다. 따라서 이러한 각 단계를 쉽게 이어갈 수 있는 방법을 찾아야 합니다. 가장 좋은 상황은 실제로 배포할 수 있는 프로토타입을 설계하는 것입니다. 이는 대량으로 생산하여 배포할 수 있음을 뜻합니다. 실제로는 이런 일은 자주 일어나지 않지만, 배포를 염두에 두고 설계하고 프로토타이핑하면 설계의 주요 구성요소를 배포 단계까지 지속적으로 유지할 수 있습니다. 핵심은 효과적으로 프로토타이핑하는 데 필요한 유연성과 기능을 갖췄을 뿐만 아니라 시장 출시를 지원할 수 있을 만큼 강력하고 맞춤화할 수 있는 올바른 도구와 플랫폼을 찾는 것입니다.

^{그림 11: 최종 제품과 거의 일치하는 프로토타입을 만드는 것이 가장 좋습니다.}

LabVIEW의 재구성 가능한 I/O (RIO) 아키텍처는 NI Graphical System Design 플랫폼의 필수 요소입니다. 모니터링과 컨트롤 시스템의 설계, 프로토타이핑, 배포의 최신 접근 방식인 Graphical System Design은 개방형 LabVIEW 그래픽 프로그래밍 환경과 COTS 하드웨어를 결합하여 개발을 크게 단순화합니다. 이를 통해 고품질 설계를 확보할 수 있으며, 맞춤형 설계를 통합할 수 있습니다.

LabVIEW RIO 아키텍처는 프로세서, 재구성 가능한 FPGA, 모듈형 I/O 하드웨어, 그래픽 설계 소프트웨어의 4가지 구성요소로 이루어져 있습니다. 이러한 구성요소를 결합하면 고성능 I/O로 사용자 정의 하드웨어 회로를 신속하게 생성하고 시스템 타이밍 컨트롤의 유연성을 높일 수 있습니다. 많은 NI 제품에 이러한 아키텍처가 통합되어 있습니다.

^{그림 12: NI는 최대의 유연성, 안정성, 성능을 위해 LabVIEW RIO 아키텍처를 갖춘 제품을 제공합니다.}

단일 보드 RIO 컨트롤러는 맞춤형 단일 인쇄 회로 기판으로 이를 통해 유연성을 높일 수 있습니다. I/O 터미널, 전원 공급 장치, 케이스를 제공합니다. 단일 보드 RIO를 사용하면 사용자가 최종 제품에 원활하게 통합할 수 있습니다. 유연성이 더 커야 하거나 크기가 더 작아야 하는 경우 NI SOM (System on Module)을 설계에 사용하는 것이 좋습니다.

^{그림 13: 단일 보드 RIO와 SOM 컨트롤러로 최고의 유연성을 얻을 수 있습니다.}

더 견고해야 하는 경우 CompactRIO 하드웨어가 최선의 선택입니다. 이 산업 수준의 하드웨어는 극한 상황에서도 견딜 수 있습니다. 엄청난 충격과 진동을 견딜 수 있는 디바이스가 필요하고 이러한 열악한 조건에서 작동할 컨트롤러를 자체 개발하는 데 시간과 비용을 들이고 싶지 않은 경우 CompactRIO가 좋습니다. CompactRIO 플랫폼은 견고함 외에도 단일 보드 RIO 디바이스처럼 맞춤화가 필요하지 않습니다. CompactRIO는 전력 변환, 케이스 또는 I/O 터미널을 직접 처리하지 않으려는 경우에도 좋은 솔루션입니다.

^{그림 14: CompactRIO 컨트롤러를 통해 최고의 견고함을 얻을 수 있습니다.}

실험실 환경과 같이 더 정밀한 측정이 필요하거나 PC 기반 플랫폼의 제약을 받는 경우 R 시리즈 다기능 RIO 디바이스가 효과적입니다. PCI, PCI Express, USB, PXI, PXI Express 폼 팩터로 제공되는 이 디바이스는 단일 보드 RIO와 CompactRIO보다 I/O 신호 컨디셔닝과 정확도 면에서 우수합니다. R 시리즈 디바이스는 강력한 LabVIEW RIO 아키텍처를 통해 기존의 데이터 수집 솔루션보다 기능을 더 많이 확장할 수 있도록 지원합니다.

^{그림 15: R 시리즈 데이터 수집은 표준 PC 폼 팩터에 LabVIEW FPGA를 추가할 수 있습니다.}

최대 3 GS/s 아날로그 또는 1 Gb/s 디지털 속도의 초고성능 I/O가 필요한 경우 FlexRIO가 가장 적합합니다. 테스트 비용을 최소화하거나 차세대 임베디드 시스템을 빠르게 개발하려는 경우 FlexRIO는 LabVIEW RIO 아키텍처에서 가장 빠른 I/O와 가장 큰 FPGA를 제공하여 가장 복잡한 프로토타이핑 또는 배포 문제를 해결할 수 있도록 지원합니다.

^{그림 16: FlexRIO 컨트롤러와 모듈을 통해 최대의 FPGA와 I/O 성능을 얻을 수 있습니다.}

LabVIEW RIO 아키텍처는 다양한 폼 팩터 옵션뿐만 아니라 공통 플랫폼을 공유합니다. 즉, LabVIEW RIO 아키텍처가 지원하는 모든 제품에 똑같은 코드와 프로세스를 사용하고 필요한 경우 전환할 수 있습니다. 실제로 단일 보드 RIO, CompactRIO, R 시리즈 또는 FlexRIO 간을 전환할 때 대부분의 코드를 재사용할 수 있습니다. 최종 제품의 모든 요건을 완전히 이해하지 못했더라도, 프로토타입 플랫폼을 선택할 때의 실수 때문에 모든 코드를 처음부터 다시 작성해야 되는 것은 아닙니다. 이를 통해 프로토타이핑 프로세스를 더 빨리 시작할 수 있어 개발 시간이 단축됩니다. 또한 CompactRIO로 프로토타입을 시작한 후 최소한의 기계적 재작업과 소프트웨어를 거의 변경하지 않고도 단일 보드 RIO로 배포할 수 있습니다. 이 역시 공유 플랫폼 덕분에 가능합니다.

프로토타이핑은 임베디드 설계 프로세스의 중요한 부분입니다. 투자자, 고객, 경영진에게 아이디어를 실제 제품으로 만들어낼 수 있다는 것을 보여주는 역량은 예산을 할당받을 수 있는 좋은 방법입니다. NI Graphical System Design 도구는 대규모 설계 팀 없이도 기능성 프로토타입을 신속하게 만드는 데 유용합니다. 이를 활용하여 고품질의 기능성 프로토타입을 만들면 다음 어플리케이션을 바로 시작할 수 있습니다.

관련 링크

• 다음 프로토타입을 구현하는 NI 제품에 대해 자세히 알아보기
• LabVIEW를 사용하여 다음 프로젝트를 수행하는 방법에 대해 자세히 알아보기

Simulink®는 The MathWorks, Inc.의 등록 상표입니다.