TDMS (Technical data management streaming)는 내쇼날인스트루먼트 소프트웨어에서 수집된 데이터 채널을 저장하기 위해 가장 보편적으로 사용하는 파일 포맷이며 타사의 데이터 관리 툴에서도 사용할 수 있습니다. TDMS 파일 포맷과 이러한 파일을 읽고 쓰는 여러 프로그램, API의 장점에 대해서는 다음 문서를 참조하십시오.
Developer Zone 튜토리얼: NI TDMS 파일 포맷
TDMS 파일의 비트 레벨 바이너리 구조를 살펴보시려면 다음 문서를 참조하십시오:
Developer Zone 튜토리얼: TDMS 파일 포맷의 내부 구조
때론 TDMS 파일 타입으로 데이터를 저장하는 것만으로는 충분하지 않은 경우가 많습니다. 이 문서에서는 수집한 데이터 채널을 효율적으로 찾고, 분석하고, 비교하고, 보고할 수 있도록 효율적인 TDMS 파일을 생성하는 방법을 소개합니다. 이러한 TDMS 파일 권장사항을 참고하면, 추가적인 데이터 관리 기능을 활용하고, 채널 타이밍을 향상시키고, 로딩 속도를 최대화할 수 있습니다.
TDMS 데이터 파일에는 실제 데이터가 들어있는 벌크 데이터와 실험 조건이나 최대/최소값, UUT 시리얼, 테스트 엔지니어등의 정보가 포함되어 빠른 검색을 돕는 메타 데이터가 포함되어 있습니다. TDMS 파일은 벌크 데이터를 채널이라고 부르는 개별 1D 배열에 저장하며 메타 데이터를 이름-값 쌍으로 저장하고 이것을 프로퍼티라 부릅니다. 이 프로퍼티는 파일 레벨, 채널 그룹 레벨, 또는 채널 레벨에 설정할 수 있습니다. 어떤 정보를 프로퍼티로 저장하는지, 어떤 레벨에 그 프로퍼티를 정의하는지, 각 프로퍼티의 이름을 어떻게 지정하는지에 따라 데이터 관리의 목적으로 메타 데이터를 얼마나 유용하게 사용할 수 있는지가 달라집니다.
메타 데이터를 채널이 아닌 프로퍼티에 쓰기
메타 데이터는 값을 검색할 수 없는 데이터 채널이 아닌 검색 가능한 프로퍼티에 저장해야 합니다. TDMS 데이터 채널은 그래프나 분석을 위한 데이터 배열입니다. 단일 값으로 구성된 설정 정보와 결과데이터를 하나의 데이터 채널에 저장하면 읽어오는 어플리케이션이 혼란을 일으킵니다. "실제" 데이터 채널과 "가짜" 데이터 채널이 섞이기 때문입니다. 이름이 지정된 이러한 정보를 프로퍼티에 별도로 저장하면 내쇼날인스트루먼트의 LabVIEW이나 DIAdem과 같은 여러 TDMS 읽기 어플리케이션에서 탐색 및 검색이 훨씬 편리해집니다. 그림 1에서 채널 데이터 값(그래프)과 채널 프로퍼티(테이블)가 직관적으로 동시에 표시되는 모습을 확인할 수 있습니다:
그림 1. 채널 데이터 및 프로퍼티
유효한 이름을 가진 프로퍼티 쓰기
TDMS 프로퍼티는 프로퍼티 값, 프로퍼티 이름, 프로퍼티 레벨의 세 가지 요소로 구성되어 있습니다. TDMS 파일 포맷을 사용하면 어떤 문자도 프로퍼티 값에 사용할 수 있지만, 대부분의 TDMS 파일 읽기 및 쓰기 어플리케이션에는 프로퍼티 이름에 대한 제약사항이 있습니다. 프로퍼티 이름에 대한 다음 권장사항을 따르면 사용하는 TDMS 읽기 어플리케이션의 종류에 관계 없이 프로퍼티 이름이 변경되지 않습니다.
모든 TDMS 파일에서 중요하게 사용하는 두 개의 특별한 프로퍼티 이름은 다음 테이블과 같습니다:
표 1. 특수 프로퍼티 이름
레벨 | 이름 | 설명 |
파일 | DateTime | 전체 TDMS 파일의 시작 날짜와 시간 |
채널 | Unit_String | 채널 단위를 문자열로 나타낸 것 |
올바른 TDMS 레벨에 프로퍼티 쓰기
TDMS 프로퍼티는 프로퍼티 값, 프로퍼티 이름, 프로퍼티 레벨의 세 가지 요소로 구성되어 있습니다. TDMS 파일 포맷을 사용하면 프로퍼티를 파일, 파일 내에 있는 모든 채널 그룹, 또는 모든 채널 그룹내의 모든 채널에 저장할 수 있습니다. 프로퍼티를 저장하는 장소에 따라 활용도가 크게 달라집니다. 다음 권장사항을 참고하면 하나 또는 그 이상의 프로퍼티 조건을 기반으로 하여 최대한 효율적으로 TDMS 파일의 원하는 부분을 검색할 수 있습니다.
프로퍼티가 해당 채널에만 규칙은 반대로도 적용됩니다:
자주 발생하는 실수 중 하나가 설정 프로퍼티의 모음을 채널이 없는 Setup Info라는 채널 그룹에 쓰는 것입니다. 이런 경우 설정 프로퍼티 조건을 만족시키는 선택된 채널 그룹이나 선택된 채널을 검색할 수 없습니다.
수집한 데이터 채널은 함축적(일정한 샘플링 속도) 또는 명시적(시간 값의 채널) 형태로 타이밍 정보를 가지고 있습니다. TDMS 파일을 읽을 때에는 이 타이밍 정보를 안정적으로 찾을 수 있어야 자동으로 분석이 가능합니다. 여기에서 사용되는 ‘타이밍’과 ‘타임’이라는 용어는 우리가 일반적으로 생각하는 ‘x축’보다는 큰 의미를 가지고 있음을 알고있어야 합니다.
수집한 데이터는 시간을 나타내는 x축을 기본으로 하여 플롯하는 경우가 대부분이지만 각도, 주파수, 변위 등을 x축 정보로 사용하는 경우도 있습니다. 다음 권장사항은 다른 x축 정보에도 모두 동일하게 적용되지만 여기서는 간단한 설명을 위해 시간을 사용했습니다. 관련된 타이밍 정보를 기록하기 위해 가장 보편적으로 사용되는 두 가지 방법은 함축적으로 저장되는 웨이브폼 채널 프로퍼티와 명시적으로 보이는 날짜/시간 채널입니다. 두 가지 모두 완전히 문서화하기 위해서는 여러 개의 추가적인 채널 프로퍼티가 필요합니다.
관련된 시간 채널과 데이터 채널
수집한 데이터 채널과 연관된 TDMS 파일의 시간 값이 하나 또는 그 이상의 명시적 시간 채널에 저장되어 있는 경우 (즉, 별도의 시간 채널을 가지고 있는 경우), 어떤 데이터 채널이 어떤 시간 채널과 관련되어 있는지를 나타내는 규약이 필요합니다. 규약이 필요한 이유는 TDMS 파일 포맷에 이런 연관 관계를 나타내는 기능이 내장되어 있지 않기 때문입니다.
가장 확실하고도 간단한 방법은 각 채널 그룹에 오직 하나의 시간 채널만 두고, 해당 시간 채널을 채널 그룹의 첫 번째 채널 위치에 놓는 것입니다. 이렇게 하면 보통 두 가지 상황이 발생합니다. 다음 그림과 같이 각 채널 그룹에 하나의 명시적 시간 채널과 하나의 수집된 데이터 채널이 존재하는 경우(XY), 또는 각 채널 그룹에 하나의 명시적 시간 채널과 여러 개의 수집된 데이터 채널이 존재하는 경우(XYYY)입니다:
그림 2. XY 채널 그룹
그림 3. XYYY 채널 그룹
전체 DateTime 채널과 프로퍼티 쓰기
TDMS 파일은 프로퍼티와 데이터 채널 모두에 사용할 수 있는 고유한 datetime 데이터 타입을 제공합니다. Datetime 정보를 저장할 때에는 반드시 이 내장 datetime 옵션을 사용하십시오. TDMS 파일을 읽고 쓰는 어플리케이션마다 시작 datetime 값과 증가 단위(초 또는 일)에 대한 규칙이 다르기 때문에 경과된 초의 숫자값을 쓰는 것만으로는 datetime을 정확히 기록할 수 없습니다. NI LabVIEW 프로그램의 경우, 다음 그림과 같이 항상 갈색의 datetime 와이어를 직접 프로퍼티 값 또는 채널 데이터 입력에 연결해야 합니다:
그림 4. LabVIEW의 DateTime 프로퍼티 및 데이터 채널
Datetime 값과 관련하여 추가적으로 고려해야 할 사항은 지리적 위치(시간대)를 기록하고 읽는 것입니다. TDMS 파일을 읽고 쓰는 어플리케이션 중에는 상대적 위치(같은 시간대라고 가정)를 사용하는 것이 있는가 하면 절대적 위치(영국 그리니치를 기준으로 하는 UTC)를 사용하는 것도 있습니다. TDMS 읽기 및 쓰기 어플리케이션과 예상하는 지리적 위치가 서로 일치하지 않으면 읽는 datetime 값과 쓰는 datetime 값이 달라질 수 있습니다. 이러한 문제가 발생하지 않도록 하려면 TDMS 쓰기 어플리케이션과 그리니치 표준시 사이의 시간차를 저장하는 UTC_Offset 프로퍼티(실수)를 추가적으로 사용하는 것이 가장 좋습니다.
전체 웨이브폼 채널 쓰기
데이터 채널을 불규칙한 시간 간격으로 수집한 경우 타이밍을 정확하게 기록하기 위해 명시적 시간 채널이 필요합니다. 그러나 그보다 흔한 것은 모든 데이터를 일정한 샘플링 속도, 일반적으로 하드웨어 타임에 맞춰 수집하는 경우입니다. 이 때에는 단순히 타이밍 정보를 채널 프로퍼티의 세트로 저장하기만 해도 충분히 타이밍을 정확하게 기록할 수 있으며, 명시적 시간 채널은 필요하지 않습니다. TDMS 파일에 사용되는 표준 웨이브폼 프로퍼티 이름은 다음 테이블을 참조하십시오.
표 2. 표준 웨이브폼 프로퍼티 이름
이름 | 예제 | 필수? | Description |
wf_xname | 시간 | 필수 | x축 수량의 이름 |
wf_xunit_string | 초(s) | 필수 | x축 수량의 단위 |
wf_start_offset | 0 | 필수 | x축의 시작 오프셋 값 |
wf_increment | 0.001 | 필수 | x축의 증가값 |
wf_start_time | 옵션 | 시간 축의 시작 DateTime 값 | |
wf_samples | 필수 | x축 값의 개수 |
프로퍼티 이름은 대소문자를 구분하며 반드시 소문자로 지정해야 합니다. wf_xname 및 wf_xunit_string 프로퍼티는 NI LabVIEW에서 기본으로 설정되지 않으므로 TDMS 파일의 모든 웨이브폼 채널마다 이 프로퍼티를 직접 추가해야 합니다.
TDMS 파일 포맷은 최대한 빨리 데이터를 스트리밍 하면서도 수집 과정에서 채널 수와 샘플링 속도를 변경할 수 있도록 설계되었습니다. 그러나 데이터 파일의 스트리밍 저장속도가 빠르다고 해서 반드시 로드가 빠른 것은 아닙니다. TDMS 파일은 여러 구획으로 구성된 2진 파일이며, 파일에 쓰기 작업을 할 때마다 한 구획 위에 다른 구획이 겹쳐집니다. 이러한 구획에는 하나 이상의 채널에 할당된 데이터 값의 버퍼 및 하나 이상의 레벨에 적용된 메타 데이터 프로퍼티가 포함되어 있습니다. 일반적으로 TDMS 파일에 구획이 적을수록 로딩 속도가 빨라집니다.
TDMS 파일에 쓰기나 읽기 작업을 할 때마다 2진 구역의 맵이 포함된 TDMS_Index 파일이 생성됩니다. 그 이후 같은 TDMS 파일을 읽으려는 경우 TDMS_Index 파일을 확인한 뒤 올바른 바이트 위치를 판단하여 TDMS 파일의 각 채널과 프로퍼티 모음을 읽어옵니다. TDMS_Index 파일의 크기가 TDMS 파일의 크기와 비슷한 경우, 이 TDMS 파일은 "분할된(fragmented)" 상태라고 합니다. 이것은 파일에 구획이 지나치게 많아 로딩 속도가 느려진다는 의미입니다. 따라서 불필요한 구획의 수를 줄이고 TDMS 파일의 읽기 속도를 최대화 하기 위해 수집 도중 또는 수집 이후에 몇 가지 방법을 사용할 수 있습니다.
분할 최소화하며 TDMS 파일에 쓰기
우선 NI 데이터 수집 하드웨어로 데이터를 수집하는 경우에는 TDMS 파일 쓰기 작업에서 자동으로 분할을 방지해주는 NI-DAQmx TDMS 쓰기 기능의 활용을 고려해 보십시오. NI LabVIEW를 사용하여 데이터 채널을 수집하고 있다면 TDMS 고급 팔레트에 있는 VI를 선택하여 분할을 최소화하면서 TDMS 파일 쓰기 작업을 할 수 있습니다. 표준 TDMS 쓰기 함수를 사용하는 경우, 다음 팁을 활용하면 TDMS 파일 분할을 최소화하는데 도움이 됩니다.
수집 후에 TDMS의 조각모음하기
데이터 수집 제약사항 때문에 어쩔 수 없이 분할된 TDMS 데이터 파일이 생성되었다 하더라도 수집을 마친 후에 이 문제를 해결할 수 있습니다. NI LabVIEW를 사용하고 있다면 TDMS 조각모음 함수를 실행하여 분할이 최소화된 TDMS 파일로 변경합니다. 또한 TDMS 데이터 파일을 NI DIAdem에 로드한 후 간단하게 다시 저장해주기만 해도 분할이 최소화된 TDMS 데이터 파일이 생성됩니다.
로딩 속도 향상 채널 프로퍼티 쓰기
TDMS 파일을 읽어오는 타겟 어플리케이션이 NI DIAdem인 경우, TDMS 파일의 모든 데이터 채널에 다음과 같은 4개의 프로퍼티를 생성하면 NI DIAdem으로 로딩하는 속도를 크게 향상시킬 수 있습니다. TDMS 데이터 채널이 로딩될 때 이 4개의 프로퍼티가 모두 존재하지 않으면 NI DIAdem이 그래프 축 오토 스케일의 속도를 높이기 위해 자동으로 프로퍼티 4개의 값을 전부 계산합니다. 반면 이러한 프로퍼티가 이미 생성되어 유효한 값으로 설정되고 TDMS 파일의 각 데이터 채널에 지정되어 있다면 TDMS 파일을 NI DIAdem으로 훨씬 빨리 로딩할 수 있습니다.
표 3. NI DIAdem의 로딩 속도를 향상시키기 위한 프로퍼티
Name | Example | Description |
Minimum | -3.14 | 채널의 최소값 |
Maximum | 3.14 | 채널의 최대값 |
Monotony | Not monotone | 채널이 모노톤이면 상승 또는 하강 |
NoValueKey | No | 채널에 NaN 값이 있는지 여부 |
데이터를 수집하는 이유는 해당 데이터를 기초로 하여 의사 결정을 내리기 위해서입니다. 그러나 원시 데이터를 비효율적으로 처리하면 데이터를 분석할 때 문제가 발생할 수 있습니다. 어플리케이션에서 데이터를 효율적으로 처리하기 위해서는 현재 시스템의 요구사항을 고려하고 향후에 개발할 어플리케이션에서 이 파일을 어떻게 활용할 수 있을지 생각해야 합니다.
|