LabVIEW中測試測量數(shù)據(jù)的存儲（2）

NI軟件平臺上針對于測試測量的數(shù)據(jù)，有很多不同的文件格式，其中有幾種是支持TDM模型的。并不是說這些文件都能滿足以下技術要求，我只是先羅列出來：

1）寫文件速度必須要快。很多情況下需要一邊采集數(shù)據(jù)一邊就把數(shù)據(jù)寫到文件中，采集卡的速度已經(jīng)相當快了，這時候瓶頸常常是在寫文件這個步驟上。相反，讀文件可能并沒有如此高的要求。

2）向文件追加（append）數(shù)據(jù)的時候，速度要快，這個時候不能讀取文件中的信息。這其實也是常用的一個use case，采集數(shù)據(jù)寫入文件的動作可能經(jīng)常要進行（比如在一個循環(huán)中），往往又是往同樣的文件中寫入信息。

3）寫文件的速度不能與文件大小成正比。我們希望不管文件有多大，寫文件的速度總是保持相對恒定，不能文件越大就寫得越慢。

4）支持隨機的讀取。比如我想讀文件中某個位置的某些內(nèi)容，不能要求把這個位置之前的所有數(shù)據(jù)都先讀出來（即讀到內(nèi)存中）。

5）支持分別讀寫描述性信息和原始數(shù)據(jù)。這是上一條的延伸，讀描述性信息（meta data）的時候不要求把原始數(shù)據(jù)（raw data）讀進來，同樣，讀原始數(shù)據(jù)的時候也不要求把描述性信息讀進來，否則，勢必影響讀文件的速度。

6）對讀文件的速度也有一定的要求。這個要求主要來自于搜索數(shù)據(jù)。無數(shù)浩瀚的數(shù)據(jù)，怎樣才能快速的找到用戶需要的數(shù)據(jù)，這一直是一個難題。

7）文件不能太大。存儲同樣的數(shù)據(jù)量，文件自然越小越好。

技術要求暫時就寫這么多，其實總結起來，無非兩點：1）快；2）方便。我們對照TDM的數(shù)據(jù)模型，對于“快速”，暫時看得不明顯（以后可以談談為什么TDMS文件可以達到“快速的要求”），但是說它“方便”，還是可以理解的。

這個模型的設計完全是依照用戶的應用實例。首先，它是分層次的。比如說我們需要測試汽車發(fā)動機的各個指標。我們用8個通道的采集卡采集發(fā)動機振動的數(shù)據(jù)，8個通道分別采集8個部位的振動，存到文件中，作為一個組（group），組的名字就叫做“發(fā)動機振動”。我們還需要采集發(fā)動機的進氣管、排氣管壓力，又作為一個組。還要采集發(fā)動機的溫度，可能也用8個通道的采集卡采集8個部位的溫度，每個部位的溫度數(shù)據(jù)作為一個通道（channel）存到文件中，8個通道作為一個組，叫做“發(fā)動機溫度”等等。我們可能會采集多次，其他參數(shù)都不變，只是數(shù)據(jù)每次都附加在文件的后面。我們有很多的測試工程師，每個工程師做的測試分別存成一個TDM模型的數(shù)據(jù)文件?？梢园l(fā)現(xiàn)，這樣的三層結構還是很清晰的。這就好比用LabVIEW些程序，VI大了，就不知道怎么管理了，那就多用幾層SubVI嘛。

其次，它具有描述性信息。比如可能需要把測試的日期、測試者的名字、測試的環(huán)境配置等信息寫下來。有些描述性信息是針對“文件”這個層次的，比如測試者的姓名。有些信息可能針對“組”這個層次，比如采集的是“溫度”，單位是“攝氏度”。有些信息則可能針對“通道”，比如采集的是發(fā)動機哪個部位的溫度等等。描述性信息比較利于他人閱讀文件，并且，在搜索文件數(shù)據(jù)的時候，可以派上大用場，可以先利用這些描述性信息進行定位。當然，這些信息最好能和“原始數(shù)據(jù)”（raw data）放在一起，要是放在兩個文件中，一是難以對應起來，而是不利于維護。這也好比是寫LabVIEW程序，你寫的程序，別人也要能看到，沒太多的好辦法，就多寫點注釋吧。

這樣的TDM模型也有其缺點。至少看起來有點復雜，同時有原始數(shù)據(jù)和描述性數(shù)據(jù)，還要實現(xiàn)那么多的技術要求，著實有點困難啊。其次，這個模型寫下來就固定了，一共就3個層次，說到底在某個文件中也就2個層次，不能擴展，不像XML那樣方便。我有時候就想要把數(shù)據(jù)寫到一個“通道”中，我還非得先造一個“組”出來（其實可以不寫，默認會造一個出來，但是邏輯結構上不能缺少）。還有其他限制條件，比如原始數(shù)據(jù)必須寫在“通道”這個層次，不能寫在“組”這個層次等等。

總體來講，TDM數(shù)據(jù)模型利大于弊，比較適合測試測量領域的數(shù)據(jù)的存儲，是一套不錯的解決方案。