LabVIEW中测试测量数据的存储.docx

这里说的测试测量数据是指配合NI的硬件，如PXI卡采集所得的测试测量数据。对其他的测试测量应用场景我还不熟悉。
NI原先是缺乏一个比较优秀的测试测量数据存储方案的，NI后来也意识到了这个问题,于是在德国收购了一家公司，这家公司专做数据要求主要来自于搜索数据。无数浩瀚的数据，怎样才能快速的找到用户需要的数据，这一直是一个难题。
7）文件不能太大。存储同样的数据量，文件自然越小越好。
技术要求暂时就写这么多，其实总结起来，无非两点：1）快；2）方便。我们对照TDM的数据模型，对于''快速〃，暂时看得不明显（以后可以谈谈为什么TDMS文件可以达到''快速的要求〃），但是说它''方便〃，还是可以理解的。
这个模型的设计完全是依照用户的应用实例。首先，它是分层次的。比如说我们需要测试汽车发动机的各个指标。我们用8个通道的采集卡采集发动机振动的数据，
8个通道分别采集8个部位的振动，存到文件中，作为一个组
（group），组的名字就叫做''发动机振动〃。我们还需要采集发动机的进气管、排气管压力，又作为一个组。还要采集发动机的温度，可能也用8个通道的采集卡采集8个部位的温度，每个部位的温度数据作为一个通道（channel）存到文件中，8个通道作为一个组，叫做''发动机温度〃等等。我们可能会采集多次，其他参数都不变，只是数据每次都附加在文件的后面。我们有很多的测试工程师，每个工程师做的测试分别存成一个TDM模型的数据文件。可以发现，这样的三层结构还是很清晰的。这就好比用LabVIEW些程序，VI大了，就不知道怎么管理了，那就多用几层SubVI嘛。
其次，它具有描述性信息。比如可能需要把测试的日期、测试者的名字、测试的环境配置等信息写下来。有些描述性信息是针对''文件〃这个层次的，比如测试者的姓名。有些信息可能针对''组〃这个层次，比如采集的是''温度〃，单位是''摄氏度〃。有些信息则可能针对''通道〃，比如采集的是发动机哪个部位的温度等等。描述性信息比较利于他人阅读文件，并且，在搜索文件数据的时候，可以派上大用场，可以先利用这些描述性信息进行定位。当然，这些信息最好能和''原始数据”（rawdata）放在一起，要是放在两个文件中，一是难以对应起来，而是不利于维护。这也好比是写LabVIEW程序，你写的程序，别人也要能看到，没太多的好办法，就多写点注释吧。
这样的TDM模型也有其缺点。至少看起来有点复杂，同时有原始数据和描述性数据，还要实现那么多的技术要求，着实有点困难啊。其次，这个模型写下来就固定了，一共就3个层次，说到底在某个文件中也就2个层次，不能扩展，不像XML那样方便。我有时候就想要把数据写到一个''通道〃中，我还非得先造一个''组〃出来（其实可以不写，默认会造一个出来，但是逻辑结构上不能缺少）。还有其他限制条件，比如原始数据必须写在''通道〃这个层次，不能写在''组〃这个层次等等。
总体来讲，TDM数据模型利大于弊，比较适合测试测量领域的数据的存储，是一套不错的解决方案。
今天谈谈如何选择合适的文件格式。
在LabVIEW中可以使用的文件格式有好几种，争对于测试测量数据的文件格式也不少。每种文件格式都有自己的优缺点，很难说孰优孰劣。关键的问题在于要选择合适自己的文件格式。
那么，在选择具体的文件格式时，有哪些指标可以参考？
1）性能。测试测量数据的一个比较重要的usecase就是要一边采集数据一边存储数据，NI现在采集数据的速度已经非常快了，性能的瓶颈往往是在存储数据到文件中去这个步骤上。当然，有些usecase对于读取数据的性能也有要求，比如要做实时的数据分析等。因此，在选择合适的文件格式时，需要考虑性能的问题。
2）兼容性。采集数据、存储数据、分析数据，用的可能不是同一套软件，很有可能在不同的平台、不同的软件中完成这些不同的功能。那么就需要采用一种比较通用的文件格式。
打个比方，XML就是一种比较通用的文件格式。
3）支持的数据类型。并不是每种文件格式都支持所有的数据类型。有些可能不支持存储二维数组、不支持存储时间、日期等等，在选择文件格式时需要注意到这一点，以免将来带来不必要的麻烦。
4）是否方便使用。有些人可能喜欢定义一套自己的文件格式，对于高手来讲也未尝不可，但是对于一般的用户就需要考虑是否有这个必要。有些文件格式，在LabVIEW中已经有现成的、丰富的API，那就直接拿来用吧。
5）可维护性、可移植性。写完的文件很有可能将来还会修改，还可能会拿去给别人去修改。别人是否看得懂这样的文件？别人是否方便修改这样的文件？
6）文件大小。存储相同的信息量，当然文件越小越好，信息存储紧凑一点好。
当然还有其他很多方面的指标可以参考。暂时先说这些，以后还会有更深入的内容介绍。