信息物理测试协议处理系统及方法与流程

1.本发明涉及信息系统，特别涉及一种信息物理测试协议处理系统及方法。


背景技术：

2.当一套系统涉及到多个物理上独立的子系统时，子系统之间需要进行数据传递。子系统之间传递的数据格式往往根据不同的业务场景，在系统设计时统一设计。设计完数据格式后，由各个子系统分别编写该数据格式的收发程序，从而完成子系统间的通信。这样的弊端是，一旦业务场景出现变化，那么数据格式也要发生相应的改变；一旦数据格式改变，对数据的处理程序也要重新编写。
3.信息物理测试系统，要面对成百上千的测试设备。这些测试设备种类繁多，而且大部分的数据格式已经定义好。如果我们要和市场上这些已知的设备，以及未来更多的未知设备进行数据通信的话，势必要对每一种数据格式进行专门的编码，这样会极大地浪费工作量。
4.目前业界的解决方案：目前业界针对类似问题，主要思想是对通信协议进行抽象，把要数据格式抽象为整数、浮点数、字符串、容器等通用概念，用户通过配置文件把要数据格式配置好，然后由统一的程序对配置文件进行解析，这样能节省一部分开发工作量，用户只需要编写针对该接口的代码即可，比较典型的产品是google开源的protobuf。
5.当前解决方案的问题：需要收发双方均用相同的中间件进行数据传递；信息物理测试系统对接的大部分产品都是独立的产品。这些产品的设计和开发并不在我们的控制中。要求这些产品为了与我们的系统进行对接而专门用指定的中间件开发是不现实的；仍需要用户编写针对于业务场景的代码；目前的方案，只是抽象了对数据的封装和传输，代码中仍需要对不同的业务场景进行针对性开发，无法做到0代码对接；不能按位对数据进行精细化操作，目前的方案，对数据格式的定义只是定义到字节级别，无法做到位级别的控制。而与信息物理系统对接的设备，为了压缩数据量，通常都会把数据格式设计到位级别。不能灵活地控制字节序，目前的方案，本地数据采用本地字节序，传输时采用网络字节序，接收到数据后再转成本地字节序。但有一些极为特殊的业务场景(可能是设计缺陷)，在数据中存在不同的字节序，这种情况目前的方案是无法支持的。


技术实现要素：

6.本发明所要解决的技术问题是，克服现有技术存在的上述缺陷，提供一种信息物理测试协议处理系统及方法。
7.一种信息物理测试系统，包括fmu(功能模型单元)模型、可视化编程模块、终端系统仿真模块、参数与故障注入模块、数据分析与状态显示模块、以及用例自动化测试模块。
8.一种信息物理测试方法，其特征在于，包括以下步骤：解析配置文件：解析协议属性，解析根节点名称、寻包方式和字节序；遍历数据类型，遍历所有的数据类型，把所有类型保存在类型容器中；遍历包，遍历所有的数据类型，把所有类型保存在包容器中；遍历联合，
遍历所有的数据类型，把所有类型保存在联合容器中；以根节点为初始点，构造协议树从根节点开始，依次遍历根节点包含的数据如果包含的数据是基本类型，则直接构造叶子节点；如果包含的数据是包类型，那么以包为子树的根节点，构造该包的子树。
9.一种信息物理测试系统数据接收方法，包括以下步骤：寻包，通过特定包头进行寻包；确定本次数据的每个字段的起始位置、长度和数据类型均；填充数据，用已构造好的协议树，从根节点依次遍历每个叶子节点，当叶子节点是基础数据时，由于每个字段的起始位置、长度和数据类型均已确定，那么直接从数据流中获取相应的值保存在节点中即可；当叶子节点是包(子树)时，递归遍历这颗子树；提供读取数据的接口，协议中的每个基础数据，均有一个唯一的id，用一个专门的容器存放这些数据的id与名称的对应关系，当要获取某个字段的数据时，根据名称转换为对应的id，再根据id在容器中查找对应的数据，返回给调用程序。
10.一种信息物理测试系统数据发送方法，包括以下步骤：填充数据，用户根据业务需要，填充协议中的各个字段，由于协议树已经生成，填充数据时直接写入相应的叶子节点既可；确定本次数据的每个字段的起始位置、长度和数据类型均；检查数据完整性，发送数据时，必须把所有基础数据都填充完毕，才能形成完整的协议数据，如果有默认值，而该字段并没有被填充，则填充默认值；固定值，如果是固定值，不管该字段是否被填充，均填充固定值；检查数据正确性，检查所有字段，是否满足最大值和最小值的限制。生成数据流，遍历协议树的每个叶子节点，如果是基础数据，则填充到二进制流中。
11.本发明的有益效果如下：分析了信息物理测试系统的数据交互和数据处理模块分析。研究了数据交互流程、协议调用流程、协议数据库、通信周期、协议结构设计等五个方面，对协议设计过程中几个关键节点进行了论述与说明。
12.根据信息物理测试系统数据交互和数据处理部分的需求，采用构建协议模型的方式，将数据交互与处理过程标准化为组包与解包的设计与配置。通过该方式，解决了数据交互与处理过程中的差异化、非兼容、配置冗余等问题。同时在编程设计过程中采用了模块化、接口化的设计方式，使协议设计和应用过程能够引用各类协议模板，并支持本地修改功能，以实现测试任务中协议复用的功能，从而提高了仿真效率。在数据交互和数据处理的结构与设计中，由网络页面展现给系统使用者的是协议的构建与应用，对内部细节进行封装处理。以可视化编程的方式应用模型，通过端口连线将协议模型应用至测试任务中，对具体的实现方式，不做具体显示，提升工作人员使用友好度。
附图说明
13.图1为本发明系统结构示意图；图2本发明数据交互流程图；图3为本发明协议调用流程图；图4 为本发明数据解析流程图；图5为本发明协议结构图；图6为由本发明数据处理时序图；图7为本发明接收数据流程图；图8为本发明发送数据流程图；图9为本发明协议功能图；图10为本发明ui页面图。
具体实施方式
14.为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图对本发明的具体实施方式做详细的说明，使本发明的上述及其它目的、特征和优势将更加清晰。在全
部附图中相同的附图标记指示相同的部分。并未刻意按比例绘制附图，重点在于示出本发明的主旨。
15.参见图1，信息物理测试系统大体可以分成fmu(功能模型单元)模型的创建、可视化编程任务设计、终端系统仿真运行、参数与故障注入、数据分析与状态显示、用例自动化测试这六个部分。每个流程各司其职，前后紧密衔接。
16.首先，对系统所涉及的各类器件和分系统变量进行fmu模型构建。其中模型构建还包括被测部件的硬件配置建模和数据传输格式配置建模两部分。其中的fmu模型依靠第三方仿真建模平台(如 dymola、jmodelica、simulink等软件)上创建器件模型，其模型接口以fmi为标准。将所生成的fmu 文件在平台的模型管理界面添加到平台中，生成固定的图标，以便于实现可视化编程。同时添加在模型数据库中方便终端随时调用。
17.其次对仿真任务进行可视化编程，将与硬件相关联的其他模型和环境模拟模型以软件形式构建在仿真设计平台上的，将被测软件所在仿真平台通过资源加载连接到虚拟测试控制软件。被测模型与其他相关模型导入完毕后，将它们按照实际的接续关系，连接输入/输出端口，设置各个测试模型的初始参数和仿真配置，将众多模型集成为一个完整的测试系统。
18.平台的构建与设计属于分布式半物理仿真系统，在每次仿真任务开始注册的时候需要选择终端仿真资源，可以理解为每一个仿真资源都是一台独立的计算机，拥有完整的软硬件资源，从而实现分布式计算机仿真系统。每次终端启动，simumaster程序便开始运行，监听任务信息，当仿真任务开始时每一个终端的程序会有simumaster拉起一个具体的执行程序simuslave进行仿真任务初始化和仿真运行工作，在初始化过程中系统会根据半物理仿真任务创建唯一的id标识，并且识别保存任务中的全部模型与连线关系。
19.另外，如需要在半物理仿真测试过程中对仿真任务进行参数注入、故障注入等操作，可在测试控制软件中配置相关参数。如果测试后得到仿真结果需要进行可视化显示，则可通过测试控制软件来选择所需显示端口信息和显示形式等，最终由显控软件对半物理仿真结果进行展示。
20.创建自动化测试用例是虚拟测试技术中的关键一步。自动化测试用例可通过专用软件生成，能够将复杂的测试任务模型化，方便修改测试任务和进行复测。首先根据仿真任务明确测试逻辑，调用专门软件中原子库的相关模型，生成测试用例。然后进行测试用例的数据配置，如定义等待5秒后执行、判断条件后执行、合适的注入数值、超时结束指令、仿真结束条件等等，最终生成自动化测试用例。其还可以保存至数据库以供后续仿真任务使用。
21.当信息物理仿真测试控制软件上的测试模型系统连接和仿真控制设置完毕，同时测试用例软件生成数量可观的测试序列后，即可进入到半物理仿真测试中主要的测试环节。在该环节中，可以根据测试任务的需要，对被测系统进行暂停、继续、参数注入、结束测试等操作。测试过程中的选取显示的端口信息在先前配置的结果显示平台上以所需的方式展现出来。测试结束后，测试数据自动保存在仿真结果数据库中并可供查看。
22.最后，如果需要对测试数据进行分析诊断，可将测试的数据传入到数据的分析软件中。数据分析软件在测试数据中采集有用的信息，这些信息通过故障诊断算法、数据判读等操作，可以对半物理仿真测试中被测系统的故障进行识别、诊断和定位等。
23.在运行过程中由控制计算机负责收集各类器件的传感数据，将数据组包后由硬件
系统传输给接收系统进行解包处理。遥控过程与之相反，由地面发出遥控指令组包数据，由硬件系统接收后，交给控制计算机将指令数据解包，按照指令信息进行控制。
24.在数据交互流程中涉及了组包和解包两种数据交互和数据处理的方式，本发明中将这两种方式统称为协议。首先对信息物理测试系统的仿真验证平台上的数据格式进行设置，然后在半物理仿真任务初始化过程中，将所设置的仿真协议传给终端系统，由任务属性决定对数据进行组包还是解包。
25.图2为数据交互流程，组包过程涉及到了将仿真数据和指令生成组包数据使用1553b、串口等通信方式发送给被检测的器件，器件产生的结果数据也使用相同的通信方式再传输给终端系统。解包过程则由终端系统通过解包协议将数据回传给仿真平台。数据还会传输给平台系统的显控软件，用于数据验证分析以及最终由平台系统进行数据存储。
26.与被测器件相连接的1553b总线板卡、r422接口板卡和网络板卡等，其所识别的数据流为二进制数据，实现半物理仿真过程的数据根据通信双方所约定的数据格式进行二进制数据与业务数据的转换与处理，是信息物理测试系统中数据交互与处理流程中的关键一环。
27.为了解决二进制数据与业务数据的数据交互的差异性、继承性和兼容性，本发明采用协议构建与复用的方式，以统一的标准和形式定义组包和解包协议，以便于灵活高效的描述不同的数据格式。数据协议的创建在半物理仿真测试过程中起到翻译官的作用，在协议配置模板库中创建好的协议，会在工程任务的创建中的模板库体现出来，每一个工程任务可以根据自己的需求选择创建模板或直接引用修改。对于每个任务来说，协议引入后可以随意调参修改，然后在通过中间件redis传给终端系统进行解析，通过对数据格式的分析，将其他进制的数据与机器识别的二进制语言进行相互转换，并分配相应的内存空间，以此完成信息物理测试系统中数据交互和数据处理的组包解包过程，协议调用流程如图3所示。
28.通过协议配置库文件的调用来实现数据格式的定义，目的是减小协议配置与其他平台以及每一项测试任务的耦合性，其摒弃了数据格式与编码转译软件“一对一”通信的弊端，数据格式的修改并不会导致编码转译软件的迭代或者维护，可以处理各类半物理仿真测试任务，适用性强，通用性好。同时在借助现代信息科技的发展成果基础上，使用高性能计算机通过其强大的计算能力和数据处理能力，解决了每次仿真初始化过程中协议解析所降低的仿真任务执行效率降低和执行时间延长的问题。
29.协议存储数据库分为两类，其中一类是模板数据库，另一类每个任务中所涉及的全部协议，两者为复制关系，都存储在mysql数据库中。这样的设计保证了每个单独任务对协议的改动不会影响到其他任务，也不会对模板造成更改，减少了因为人为误差所造成的不可逆转的工程任务毁坏。同时还不会因为模型库中的协议数据属性的升级更改而影响到已经创建完成的任务中。各部分层级分明，相互关联却不相互影响。
30.协议配置过程如图4所示，协议配置完成后，根据页面信息确定key-value键值对，并通过redis 通道传输给终端系统。redis发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。redis客户端可以订阅任意数量的频道。
31.平台操作控制系统在数据订阅服务器redis和数据库服务器mysql的辅助下，能够负责数据的接收、处理、转发以及设备的管理工作，响应总控操作台对协议数据的处理操
作，存储和广播设计图中fmu 模型、协议模型和硬件模型接口连接的映射关系。
32.一般在数据格式中以“帧(frame)”作为基本单位，但在本发明研究中，将信息物理测试系统的数据统一定义为“包(packet)”。其作为tcp/ip协议通信传输中的数据单位，一般也称“数据包”22.。信息物理测试系统中数据除了可以利用局域网协议进行传输，还可以实现系统与之间的有线连接并使用其它数据通信协议。因此，为了统一本文数据交互的理念和保留数据原有设定格式，在协议涉及将不再进行“包”和“帧”的区分，其双方的结构特征将会被提炼抽象为协议属性设置中的包结构及字段。
33.其次，无论是传输帧主导头、传输帧数据域，还是其他传输帧部分
23.，其本质都是数据，只是数据内容和协议包结构不同，因此在协议模型(包)的构建过程中，主要针对数据类型和数据结构完成统一标准的设计与实现。
34.数据类型的设计主要是来源于数据中主导头和数据域中存在的各类数据，其可以分为常见的数据类型和特殊的数据类型。其中，常见的数据类型本发明中定义为8种基本数据类型，特殊的数据类型本发明中定义为自定义数据类型。通过对基本数据类型的实例化定义和自定义数据类型的抽象化配置，这样的设计方案可以满足数据交互和数据处理模块分析对各种类型数据的需求。
35.从实际的数据包格式分析中，还可发现数据格式的本质是对不同大小的数据进行了排列与组合。我们可以将数据格式进行抽象化，分为root包、包头、包长、数据、子包和校验，协议基本结构如图5所示。
36.其中root包作为协议模型根节点，有且只有一个，并作为数据处理过程中识别入口。再通过实例化各部分，形成数据通信协议，或者说一种全新的自定义的数据格式。基于编程的思维来说，相当于root 包、包头、包长、数据、子包和校验是类，拿出来经过创建的是对象，整体的一个包是一个大的struct (自定义结构体)，
37.基本数据类型，把只保存单一数据的类型定义为基本类型。包括：整数(1/2/4/8字节，分为有符号和无符号)、浮点数(float、double)、布尔、字符串、二进制buffer；基础数据，把类型为基本类型的数据定义为基本数据；包，包是多种数据的合集，这些数据即包括基础数据，也包括“包”类型的数据，还包括“联合”类型的数据。整个协议，可以看成一个包。根节点永远是包。
38.如图5所示，把整个协议构造成一颗树，根节点是虚拟的，代表数据的开始部分。子节点分别为该协议包含的各个数据字段。子节点可能是一个基础数据，也可能是一个包。计算当前所有数据字段的起始点和长度。根据该数据字段的起始点、长度和数据类型，读写该字段。
39.针对信息物理测试系统的半物理仿真任务的执行过程，如何协调fmu模型、协议模型、硬件模型的数据交互的步调，也是设计中的关键一环，这里采用的策略是，仿真任务的仿真步长根据各个fmu 的通讯步长所确定，并在仿真任务开始后保持不变。硬件数据的传输在软件层面不做具体调控，根据硬件通信接口的波特率决定，在数据缓存过程中来多少数据则处理缓存多少数据，在fmu读取周期中有两个数据包传输时，则舍弃读取上一个数据包，只读取距离时间节点最近的数据包。与器件相连接的硬件板卡接口与fmu模型的数据进行解包数据处理的时序设计如图6所示。
40.解析配置文件：解析协议属性，解析根节点名称、寻包方式和字节序；遍历数据类
型，遍历所有的数据类型，把所有类型保存在类型容器中；遍历包，遍历所有的数据类型，把所有类型保存在包容器中；遍历联合，遍历所有的数据类型，把所有类型保存在联合容器中；以根节点为初始点，构造协议树从根节点开始，依次遍历根节点包含的数据如果包含的数据是基本类型，则直接构造叶子节点(类型信息在类型容器中获取)；如果包含的数据是包类型，那么以包为子树的根节点，构造该包的子树(递归思想)。
41.接收数据，如图7所示，寻包，从第三方设备发来的数据，可能是连续的，也可能是离散的。如果是离散的，比较好处理，每次收到的数据都是完整的一份。如果是连续的，那么一份数据可能会分成几部分接收；接收的数据，即可能包含上一份数据的后半段，也可能包含新数据的前半段，所以需要进行额外处理。当数据是连续发送时，用户需要配置如何寻找包的方法，有如下几种：通过特定包头区分，每份数据在开始处均包含一段特殊的数据，称之为“包头”。第三方设备保证除了包的数据部分绝不会包含与包头重复的数据。这样我们通过扫描数据，并寻找到两个包头，那么两个包头中的部分即是包的数据部分。在指定字段中标志包的长度，用户也可以在包中的某个字段中标明包的长度，我们接收到对应长度的数据后即认为已接收到完整的数据。如果本次接收未达到规定的长度，那么该段数据则会保存起来，下次接收时，一旦新数据达到了规定长度，那么再跟已保存的数据一起组成一份完整的数据。通过包头和长度区分，本发明是上述两种方式的合集，既指定了包头内容，又指定了数据的长度。
42.确定本次数据的每个字段的起始位置、长度和数据类型。
43.填充数据，用已构造好的协议树，从根节点依次遍历每个叶子节点。当叶子节点是基础数据时，由于每个字段的起始位置、长度和数据类型均已确定，那么直接从数据流中获取相应的值保存在节点中即可；当叶子节点是包(子树)时，递归遍历这颗子树。
44.提供读取数据的接口，协议中的每个基础数据，均有一个唯一的id。我们用一个专门的容器存放这些数据的id与名称的对应关系。当要获取某个字段的数据时，根据名称转换为对应的id，再根据id 在容器中查找对应的数据，返回给调用程序。
45.发送数据，如图8所示，填充数据，用户根据业务需要，填充协议中的各个字段。由于协议树已经生成，填充数据时直接写入相应的叶子节点既可。
46.确定本次数据的每个字段的起始位置、长度和数据类型。
47.检查数据完整性，发送数据时，必须把所有基础数据都填充完毕，才能形成完整的协议数据，有两个例外：默认值，如果有默认值，而该字段并没有被填充，则填充默认值；固定值，如果是固定值，不管该字段是否被填充，均填充固定值。
48.检查数据正确性，检查所有字段，是否满足最大值和最小值的限制。
49.生成数据流，遍历协议树的每个叶子节点，如果是基础数据，则填充到二进制流中。
50.信息物理测试系统的数据交互和数据处理研究过程中，其涉及的主要的开发设计任务包括以下几点。
51.(1)设计协议模型结构：主要分为root包(根节点)、子包、数据等；
52.(2)设计协议字段：basetype、rootpackage、package、formula等；
53.(3)确定基本数据类型：int、float、double等以及自定义数据类型fixed buffer、terminal等；
54.(4)分析页面需求，设计页面功能；
55.(5)分析终端需求，编写终端代码。
56.根据主要的开发任务，确定了在信息物理测试系统中数据交互和数据处理模块的功能设计方案。在平台页面的功能设计中，采用三列竖状模块的设计方式，使三个模块在同一个页面是为了便于减少层级，易于查看和展示，同时便于工作人员构建协议列表，其协议功能设计如图9所示。
57.在平台的协议列表中主要功能的设计需求分为三个部分。第一部分在协议列表中要能够创建协议文件夹，可以将相同类型的协议进行分类整理，对于数据类型，整体分为两个部分，一个是基本类型，一个是自定义类型。
58.第二部分在设计协议配置过程中添加协议对象，用来实现特定的数据功能。其中包括协议编号，用于作为协议对象的身份id，可以在数据库中快速检索查阅。还包括协议名称、协议类型、创建人、创建时间、更新时间、相关描述等信息，协议名称需要使用者自己填写，以方便在平台的增删改查，协议类型会在已创建的协议列表分类汇总选取，相关描述作为非必填项也由使用者自行填写，而创建人、创建时间、更新时间则由系统填入。同时为了避免协议过于复杂，设计了展开可收起功能。
59.第三部分考虑协议跨平台应用的场景，为了满足协议复用的需求，设计了协议的导入和导出功能，其中还包括了对配置所生成的json协议进行查看校验以及保存。
60.在协议页面中还包含了其他的小功能的设计，其中有协议各级文件夹和协议本身的增删改查功能、数据类型中不包含基本数据类型的其他数据类型的增删改查功能、协议包中各部分数据、子包、公式、包头、包长、校验等增删改查的功能。
61.协议的结构设计一般包含组包设计和解包设计两部分，结合信息物理测试平台的具体需求，本文在组包与解包的结构设计过程中，将其统一为一套设计方案，即协议配置一次分别生成组包模型和解包模型，其数据端口在组包模型中多一个使能端口作为模型开关，其他则端口一致。主包即头层包的设计为 root包，其确定了信息物理测试系统数据的寻包方式、有无包头、包长、校验。其他类型还包括普通包、数据。需要注意的是包头、包长和校验不能直接从包结构中删除，只能在在设置中选择是否存在于包结构之中，其他类型则可以进行增删改查的功能。
62.同时，平台的web页面的结构与功能设计形式，对信息物理测试系统的数据交互和数据处理模块的易用性和健壮性有着至关重要的作用。根据开发任务的项目需求，本文在设计过程中选择了ztree控件实现了“协议树”的构建。其使用原因主要包含了以下三点。
63.(1)其核心代码按照功能进行了分割，不需要的代码可以不用加载；
64.(2)兼容ie、firefox、chrome等多款浏览器，并且支持json数据；
65.(3)灵活的编辑(增/删/改/查)功能，可随意拖拽节点，便于调整协议模型的结构顺序。
66.节点类型和节点位置是构成树形数据结构的重要因素，以节点的添加为例，使用javascript将动态的文本放入html页面，以实现页面展示的灵活变化，具体实现过程的伪代码如表1所示。
67.表1树形节点添加伪代码
[0068][0069]
根据信息物理测试系统半物理仿真过程数据包层级分明，存在“上下级”关系结构的特点，在数据库中使用关联表存储信息，在终端后台中使用哈希表快速查找，这样可以迅速定根节点以及明确每个节点的属性。因此整个包以树形拓扑结构进行构建和展现，效果直观，易于阅读，定义任意一个数据类型在添加下级数据时会自动变为包结构，除却包头、包长和校验只能在创建层级上进行拖动外、其他的包结构类型可在相同层级和不同层级之间相互拖动。在展现上逻辑清晰，在配置上灵活多变是协议结构设计中的一大亮点。
[0070]
在本发明数据交互过程中，主要包含两个方面，平台系统与终端系统通过各类协议完成数据交互和平台系统与使用者通过页面配置完成数据交互过程。基本平台系统本身的设计特点和本发明的数据交互 ui开发的需求，使用了轻量级的ui类型库knockout作为平台协议页面的框架，这样可以使ui设计更为简洁，提高代码编写工作效率。
[0071]
同时，因为在ui交互页面的开发中的涉及了多数量节点dom构造，所以我们使用了jquery ui插件完成平台系统的协议配置页面。jquery ui是插件工具，它能够更为便利的操作元素和事件，其包含了许多维持状态的小部件(widget)，jquery ui的小部件是基于部件库(widget factory)创建的，小部件库提供了通用的api。
[0072]
为了实现数据交互页面配置的简洁易用性，协议各部分的属性配置也大体相同，所以ui页面的开发方法在本发明的研究中较为统一。以页面设计的下拉列表为例，使用html语言开发的伪代码如表2 所示。
[0073]
表2ui页面开发伪代码
[0074][0075]
该伪代码中，使用了通用的格式化设计与编写，options所指向的是数组或ko.observablearray()， knockout会将数组元素转换为下拉选项。如果是ko.observablearray()，当动态增加或移除阵列元素时，下拉选项也会马上跟着增减。optionstext和optionsvalue用来产生下拉选项的数组元素，其可以是具有多个属性的javascript对象，通过optiontext,optionvalue设定属性名称字符串。value指向viewmodel 的特定属性，属性一般以ko.observable()声明。如此当下拉菜单选取新值，会将选项《option》中的value 值更新到viewmodel属性上，而一旦该属性被程序修改或因使用者输入改变，下拉菜单也会自动切到新值对应的《option》选项上。optionscaption是下拉选项的默认选择，文本域和文本框通过css类来设计所在页面中的位置和大小，由knockout来绑定使用者所输入的value值。
[0076]
将以上所上述的ui页面开发方法应用到工程实践中，编写具有统一设计格式的ui页面开发代码，其所实现的结果如图10所示。
[0077]
协议模型中所应用的数据类型本文将其分为两类，其中一类是基础数据类型，由平台系统定义，不可更改且使用频率较高，另一类是自定义数据类型，由使用者根据数据格式自定义，灵活多变，可满足各种类型的数据格式。在平台配置页面中第一列协议列表中提供了数据类型设置的入口，根据模块化设计原则，同时为了降低系统程序的耦合性，数据类型由单独的小窗口进行配置和查看。
[0078]
在数据类型中提供了基础的数据类型，其中包括bealoon代表了布尔类型其单位为字节，编码方式为int64位。整型数据类型int1、int2、int3、int4，其单位为字节，编码方式为int64位。无符号整型数据类型有uint1、uint2、uint3、uint4，其单位为字节，编码方式为uint64位。单精度数据类型有float1、float2、float3、float4，其单位为字节，编码方式为double类型。双精度数据类型有double，其单位为字节，编码方式为double类型。长整型数据类型有long，其单位为字节，编码方式为int64位。
[0079]
自定义数据类型在设置过程中需要填写类型名称，选择编码方式，其中包括双精度类型double、整型64位int64、无符号整型64位uint64、固定大小缓冲区类型fixed buffer、终止符类型termial。其中编码为double、int64、uint64类型的需要选择单位为位或者字节(默认字节)并填写数据长度，描述可以选填。编码类型为fixed buffer需要选择单位为位或者字节(默认字节)并填写数据长度，描述可以选填。编码类型为termial需要填写终止符内容和终止符长度，描述可以选填。
[0080]
对于协议模块的设计而言，编码方式代表了数据在终端系统所占用的数据内存大小。fixed buffer 是一块固定长度的空间地址，长度的类型和大小由使用者填写。而termial则可以看作是一个可以自定义终止符的数组，这样可以提升字符串使用的灵活度，但在系统内部依然遵循字符串默认格式结尾添加“\0”。
[0081]
对于默认的数据类型，出于降低使用难度和误操成本的目的，并不设置修改和删除功能。但是对于使用者自定义的数据类型来说，修改和删除功能必不可少。在“协议树”的数据节点类型设计中，能够将基本数据类型和自定义数据类型应用其中，满足协议构建过程中对各类数据的需求。
[0082]
root包作为数据包的主包，其层级结构处于最高级，通过定义寻包方式，大小端的选择以及是否校验等核心属性实现协议包位置的定位功能。
[0083]
在本发明中，以实现通用化设计为目标，以各类数据格式为基础，将寻包方式定义了四种形式：不寻包、以包头寻包、以包头 固定长度寻包、以包头 不固定长度寻包。在协议组包的寻包方式属性设置方面，实现了包头与包长可存在与包结构，或经由通信双方约定不存在于包结构中。在协议解包时，root 包又作为识别包起始位置和包结束位置的依据。这里将组包和解包的应用场景抽象为属性，创新性的应用了数据交互和数据处理的格式特征。
[0084]
不寻包的方式以接收一段稳定连续的数据为设计场景，数据发送时不配包头，数据接收时，不对数据包的开始数据进行检测，接收什么即是什么。
[0085]
以包头方式寻包，在数据交互过程中会配以通信双方所约定好的包头，以包头为每包数据的开始位置，确保在离散接收数据之时，数据包可以被正确定位。以eb90包头为例，eb90123456eb90789、 456eb90123这两段信息的有效数据为123456、789456。采用的策略为未检测到下一个包头数据时，半截数据先缓存不做解析处理，等待下一个包头，两个包头之间的确定为有效数据。
[0086]
以包头 固定长度为寻包方式，还设计了无包长字段，无包长字段两种情况，而包长并不以结构化的形式出现在包结构中，而是默认通信双方工作人员已共同知晓包长，只需填写包长(字节)作为寻包的依据。在有包长字段的情况下，填写包长(字节)作为寻包的依据，并且包长会以结构化的形式出现在包结构中。两者之间的区别在于包长本身是否在包结构中体现出来，占有一定的空间，这样可以满足数据的配置多样性的设计需求。
[0087]
以包头 不固定长度为寻包方式，将包长以结构化的形式构建在包结构中，包长大小会根据包长的起始位置和结束位置自行计算。
[0088]
大小端的设计是为了适应不同硬件厂商所设计生产的存储处理硬件，打破信息交互的厂商壁垒。以 c语言为例，除了有一个字节(8个bit)的char，也有两个字节(16个bit)的short，或者四个字节(32 个bit)的long(在不同的编译器下可能不同)，对于16位或者32位的处理器，即就是大于8位的处理器，由于寄存器的宽度大于一个字节，那么就存在如何将一个多字节的变量的数据如何存放的问题，所以就有了大小端之分
[34]
。大小端是指的是表示数据在存储器中的存放顺序。小端模式是将数据的高字节，存放在高地址中。而大端模式是将数据的高字节，存放在低地址中。
[0089]
校验提供了在数据交互过程中判断数据是否有丢失，有错误的检验方式，在数据交互过程中根据当前任务需求由使用者自身判断是否使用，以及使用什么样的校验算法。
在协议构建中，root包作为根节点，其属性选择可以定义整体的寻包方式和整体交互数据的大小端选择，校验方式则同其他包属性一致，包头的ui开发能够将其所涉及的配置参数应用于半物理仿真过程中。
[0090]
包头的属性配置中有类型、长度(字节)、位置(字节)和内容，其中类型分为十六进制和ascii 形式，尽管在输入显示过程中有所不同，但是在实际下发给终端时，数据以十六进制的形式下发。长度 (字节)指的是包头在包结构中所占的空间大小，位置(字节)指的是包头所在位置距包结构起始位置的大小，默认为0，内容则是包头的具体数值，如eb90。包头属性的ui开发结果能够适用于包头各种属性的配置，能够将类型、长度、位置和内容的配置参数应用于半物理仿真过程中，便于在数据交互和数据处理过程中查找拼装包数据。
[0091]
包长存在于包结构中时可以对包长进行属性配置，其中分为展示属性和配置属性，其中展示属性是在root包设计过程中进行的属性配置，分为是否是固定包长和有无包长字段，其在包长属性设计中不可更改。配置属性包括包长字段长度(字节)，包长其实字段和包长结束字段。包长字段是包长本身存在包结构中所占的空间大小，包长的起始和结束字段的选择可以灵活控制包长的计算范围。
[0092]
在包长属性设计中尤为重要的一点是包长是如何自动计算的。在选择上包长的开始字段和包长的结束字段应该是确定存在的数据，这点会在ui设计中过滤掉相关的选项。包长属性ui开发适用于root 包节点和其他普通包节点，包长位置的参数选择和包长的自动计算，不仅能将相关参数应用到半物理仿真结果中，还能够提升工作人员的仿真效率。
[0093]
校验是对数据包传输数据的检查，用来判断是否数据缺失、重复或错误，发现数据有问题所采用的策略是丢包重传，本发明中使用的校验方法包括crc-16、crc-32和xor校验。此外还需设计校验字段长度(字节)，用于在包结构中占有一定的空间，这样是为了存储校验结果，利于数据验证对比。校验的起始字段和结束字段的选择，同包长范围选择的策略一样，在校验运算开始时包结构具有唯一确定性。
[0094]
本发明中所涉及的校验算法如下：
[0095]
crc称为循环冗余校验是通过利用除法及余数的原理来建立数据位和校验位的约定关系，是一种用于校验数据交互中信息传输准确性的计算方法。数据组包的一方，数据交互的处理过程中会使用crc 的检验公式。
[0096]
crc-16、crc-32在本质上并未差别，主要区别在于算法的不同如3-1和3-2所示：
[0097]
x
16
x
15
x2 1
ꢀꢀ
crc-16(3-1)
[0098]
x
32
x
26
x
23
x
22
x
16
x
12
x
11
x
10
x8 x7 x5 x4 x2 x 1
ꢀꢀ
crc-32(3-2)
[0099]
计算出校验范围内组包数据所含信息的校验值，并将校验值填充在校验所在包结构中的地址空间上，对数据进行解包的一方则对校验范围内的解包数据采用相同公式方法进行计算。如果这两个crc 结果不一致，则说明在数据交互过程中出现了差错，接收方会进行丢包处理，并且要求发送方重新发送该数据包。
[0100]
crc校验的优势在于，其可以高比例的纠正信息传输过程中的错误，可以在极短的时间内完成数据校验码的计算，并迅速完成纠错过程，通过数据包自动重发的方式使得信息物理测试系统数据交互过程中的通信速度大幅提高，对通信效率和安全提供了保障。由于crc算法检验的检错能力极强，且检测成本较低，因此在数据交互和数据处理中使用较为广泛。
[0101]
xor校验是一种异或校验，它以8bit数据，即每两位十六进制的数据为一个计算单位，依次异或直至最后一个字节。这里我们假设包头为f3e2(十六进制)，数据是423a(十六进制)，其中本文在异或校验的设计工作中采用的计算过程如下示。
[0102]
(1)在数据包中，包头也是以数据的形式存在于包结构中，f3、e2、42、3a可以看做是四个字节的十六进制数据，共32个字节。
[0103]
(2)计算第一步：将第一个字节(8bit)数据与第二个字节(8bit)数据进行异或操作，并保存计算结果用于迭代计算。这里以包头数据为例对f3和e2进行异或操作，其计算过程如下：
[0104]
1111 0011(f3)
[0105]
xor 1110 0010(e2)
[0106]
结果：0001 0001(11)
[0107]
(3)将上次计算结果，与第三个字节(8bit)数据再次进行异或操作(迭代)，再次保存计算结果用于下次迭代计算
[36]
。本示例中为11与42进行异或操作，其计算过程如下：
[0108]
0001 0001(11)
[0109]
xor 0100 0010(42)
[0110]
结果：0101 0011(53)
[0111]
(4)再将上次计算结果，与最后一个字节(8bit)数据进行异或操作(迭代)就可以得到正确的异或校验(xor)结果了
[37]
。本示例中为53与3a进行异或操作，计算过程如下：
[0112]
0101 0011(53)
[0113]
xor 0011 1010(3a)
[0114]
结果：0110 1001(69)
[0115]
组包过程中，确定唯一的包结构形式后，会根据校验的范围大小，将校验的结果填充在包结构中的校验位中，校验位的长度大小(字节)由使用者自定义设置，一旦溢出会抛出异常并结束程序。在解包过程中，根据收到包结构和校验范围内的数据，再次计算校验位，并与组包中的校验位数据进行比较，发现错误即丢弃该包进行重传。
[0116]
校验属性ui开发结果能够满足检验算法和校验位置的参数选择以及检验字段长度的参数填写，其参数的应用对半物理仿真过程数据处理有重要作用。
[0117]
针对协议模型中的数据属性的设计相对复杂，在属性功能设计中，会根据数据类型和输入类型的不同，平台页面的协议属性配置设计也会随之改变。
[0118]
(1)在数据属性设计的节点类型中为基本数据类型，该属性作为包节点识别的默认属性，不可更改。数据类型可选，包括数据类型设计中所自定义的数据类型和平台中所默认存在的数据类型。
[0119]
(2)通用属性：该属性只在特定的数据类型中存在，其中包括默认或者自定义的各种数据长度的 int类型、uint类型、long类型等整型的数据类型中，当选择float类型、double类型、longdouble类型等非整型的数据类型时则不会出现通用属性。通用属性包含两个属性设计，分别是大小端和位序，在信息物理测试系统的数据交互和数据处理过程中，因为涉及到分布式仿真和跨平台交互，数据传输过程中的传输顺序和内存中的存放方式就有着非常重要的作用，其中大小端在root包属性设计中有简单说明，这里将做更为详细的介绍。
[0120]
1)大小端
[0121]
大小端属性中设计了两类，大段或者小端，在信息物理测试系统中大小端所控制的本质上是字节序，字节序分为两类：big-endian和little-endian。采用标准的big-endian和little-endian的定义如下：
[0122]
a)little-endian就是低位字节排放在内存的低地址端，高位字节排放在内存的高地址端。在读取发送过程中，小端会从最低位有效字节位开始读取。
[0123]
b)big-endian就是高位字节排放在内存的低地址端，低位字节排放在内存的高地址端。在读取发送过程中，大端会从最高位有效字节位开始读取。
[0124]
在实现过程中主要使用了两种库函数，分别是htonl()函数和ntohl()函数。其中htonl()函数将主机数转换成无符号长整型的网络字节顺序，ntohl()函数将一个无符号长整形数从网络字节顺序转换为主机字节顺序。
[0125]
以实例说明，定义一个无符号整型数组unsinged char buf[4]，无符号整型数据为0x12345678，其中 0x12、0x34、0x56、0x78各为一个字节。假设地址从0x8883地址开始，其在存储和传输顺序如表3所示：
[0126]
表3大小端对比示意表
[0127][0128]
虽然大端小端的存储方式不同，致使数组所对应的值也发生改变，但是可以通过指针的移动，按照符合人类正常的阅读顺序进行字节读取
‑‑
先高字节后低字节。
[0129]
若数据存储按照地址由低到高的顺序，则十六进制数0x12345678可以看做大端数据，其由左向右将四个字节放入内存中。反之小端数据由右向左将四个字节放入内存中，结构如下所示。
[0130]
左
‑‑‑‑‑‑‑
》0x12 34 56 78《
‑‑‑‑‑‑‑
右
[0131]
2)位序
[0132]
位序以bit为单位，所关注的是字节内的bit位与bit位之间的先后顺序。若以二进制01110101为例，结构如下所示。
[0133]
左
‑‑‑‑‑‑‑
》01110101《
‑‑‑‑‑‑‑
右
[0134]
a)：低位在前：在二进制的8bit数据内，由右向左依次将10101110存放在0地址单元中的第0位到第7位，如表4所示。
[0135]
表4低位在前示意表
[0136][0137]
b)：高位在前：在二进制的8bit数据内，由左向右依次将01110101存放在0地址单元中的第0位到第7位，如表5所示。
[0138]
表3.5高位在前示意表
[0139][0140]
3)大小端(字节序)和位序简单来说，小端模式和高位在前总是由右向左的读取和传输数据，而大端模式和低位在前总是自左向右的读取和传输数据，他们的区别仅在于是以byte为单位还是以bit为单位。在属性设置中，默认为大端且低位在前，即从左向右读取和传输数据。
[0141]
将组包协议属性的配置和解包协议属性的配置整合到一起，进而对组包和解包的功能进行了抽象化设计，配置信息较多的组包属性的设计单独做成数据属性设计中的子模块，解包的协议模型中则不会调用相函数，忽略此部分信息，不作反应。
[0142]
组包属性中包括输入类型的选择，其中设计了十六进制的数据输入或者十进制的数据输入，默认属性为十进制数据输入。在是否是固定值的选择上，选择“是”则需要输入固定值的大小，同时需要注意，这里所采用的策略是，固定值数据不会在协议模型中生成端口，这样可以减少协议模型的复杂度，提升使用者使用的友好度。公式用于后期测试人员对数值进行灵活的调整，公式可识别的范围为简单二项式，能够实现对数据x进行简单的数据调整，调整形式如公式3-3所示。
[0143]
ax b
ꢀꢀ
(3-3)
[0144]
在平台页面的设计中，当是否是固定值设置为“否”的时候，意味着该数据由fmu输出端口传入数据。在没有fmu数据输入时其初始化的数据即为默认值，对所传入的数据需要进行一定的约束，所以需要填写最大最小值，防止出现不可控错误导致程序崩溃。
[0145]
组包属性ui开发结果能够实现组包过程区别于解包过程的特殊属性配置，其中包括输入类型、固定值、默认值、最大最小值以及公式的参数选择与填写，在半物理仿真的组包过程中，该参数的配置为数据交互和数据处理提供了组包依据。
[0146]
在数据类型选择到编码方式为fixedbuffer和terminal的数据时，其输入类型默认为ascll，除此还设计了十六进制数据输入类型，单位为自定义数据类型时所设置的字节或位，长度对应下面的填充，为了提升工作人员使用体验，降低配置繁琐性，可循环填入相同内容直至最大长度。
[0147]
协议普通包。首先，普通包的构建设计中，其逻辑策略是在一个数据节点下添加另一个新数据，这样原来的数据节点就会变成一个包节点类型，其目的是为了实现多层包结构的构建。其次，当包节点类型为普通包时，有无包长字段和有无校验两种属性。其中平台界面的设计中若选择有包长字段即包长存在于包结构中，则需填写包长字段长度(字节)、包长起始字段和包长结束字段。与root包长相比，该包长并不用于寻包过程，只是对子包长度进行计算说明。若选择有校验，校验属性的设计包括校验算法的选择，校验字段长度(字节)的填写，还要选择校验的起始字段和校验的结束字段。与root包相比，校验起始字段和结束字段的选择范围只在该普通包内，不包括上级和同级包结构内的唯一确定性数据。
[0148]
数据处理的字段设计，数据处理的字段设计是为了实现将平台系统ui交互页面的协议配置信息以字段和数值的形式传输给终端系统，这样能够便于信息物理测试系统中两部分程序的信息交互。如何将协议配置信息定义为终端系统易于识别的字段的形式，是其中尤为重要的一环。协议字段的设计过程需要由平台系统和终端系统双方共同定义，这样在数据交互和数据处理模块中平台系统才能生成可被终端系统所识别的字段信息，最终字
段信息将作为仿真数据交互的重要依据。
[0149]
字段信息的json描述。协议配置信息的传输形式是基于字段信息的，使用何种数据描述语言就成为数据处理字段设计的关键一步。json(javascript object notation)即javascript对象表示法，其作为一种数据交互和数据处理的中间语言，采用纯文形式传输，多用来存储和交换信息。json是相对轻量级的数据交互和数据处理文本格式，在结构形式上与xml类似，但是json的体量比xml更小、语法更加简单，所以在数据交互和数据处理过程中速度更快。
[0150]
总体结构字段设计，value由使用者进行选择或填写后，将会与所设计的字段进行对应，并一起传输给终端系统进行处理。为了便于区分，本发明中key和value的名称统一规定为字段和类型，下文中将不再赘述。
[0151]
表8总体结构字段表
[0152][0153]
如表8所示，basetype字段定义了默认数据类型和自定义的数据类型，其作为数据交互协议的基本数据类型定义及使用。其在整个json协议中以数组的形式存在，而且是必须存在具体内容的。
[0154]
rootpackage字段所定义的是整个root包的特有属性，其属性类型较少，结构单一，所以没有采用数组的类型，直接使用了json协议中的对象属性特征key-value形式。其作为包的根节点也是必须存在且有内容的。
[0155]
package字段中定义了整合包结构中所有的节点的属性，是数据协议包结构的逻辑展现，类型是以出数组的形式固定在json协议中。其中包括了包头、包长、校验三种包固有属性，还有信息物理测试中的交互数据以及各类包结构中产生不同的普通包(子包)属性。
[0156]
formula字段定义为简单的公式属性字段，在信息物理测试系统的数据交互和数据处理中，需要使用者自行填入的公式属性在该字段中由平台系统传输给终端系统。同样的该字段可以选择不填写，该字段保留但是字段内容为空，如果出现在json协议中，其以数组的形式出现。
[0157]
除此之外，对于协议构建生成的组包与解包模型，组包模型中的输出端口定义为inchannel，而解包的输入端口定义为outchannel。这两个端口的定义除了模型本身的输出输入需要，还会由终端程序进行查找识别，为数据交互和数据处理提供设计支撑。
[0158]
basetype字段设计
[0159]
表9 basetype字段表
[0160][0161]
basetyp字段中通过数组类型的使用定义了name、size、len_type、encoding四种类型的字段，含义分别是类型名称、类型长度、类型长度的单位还有编码类型。四种类型分别是字符串、整数、字符串、字符串。其取值范围如表9所示，类型名称不可重复、类型长度无限制、类型长度的单位取值提供了字节和位两种形式、编码类型提供了的选择也就是数据处理过程中预留的空间大小。
[0162]
rootpackage字段设计
[0163]
表10 rootpackage字段表
[0164][0165]
如表10所示，rootpackage字段中通过对象类型的使用定义了name、search_type、endian字段，含义分别是root包名称、寻包方式和字节序。类型都是string类型，包名称的取值无范围。寻包方式中none 为不寻宝，by_header为通过包头寻包，by_header_fixed_len为通过包头加固定长度寻包， by_header_unfixed_len为通过包头加不固定长度寻包。字节序中value值只有两种，一种是little小端，另一种是big大端。
[0166]
同时还有保留字段“encode_control”，其含义为使能，设计该字段的原因是增加使能端效果，输入为“0”则协议有效，继续开始数据交互和数据处理过程，输入为“1则协议无效”，暂停终止数据交互和数据处理过程。
[0167]
rootpackage字段设计
[0168]
表11 package字段表
[0169][0170]
[0171]
package字段如表11所示，设计中定义了两大类关键字：attr关键字和data关键字，attr代表了各个层级与节点的包属性设置，data则代表了各个层级与节点中数据类型的具体属性设置。这种设计方案可以通过package检索到各个包节点以及其中的数据，使整个协议包的结构明了，逻辑清晰。其检索的关键字为name，通过key值名称来确定包节点和数据，这样也就要求了使用者在数据名称中和各类包节点名称中不能出现同名情况，否则会报错退出。attr字段数值类型为对象，data字段数值类型为数组，在这两种字段中嵌套的其他字段的数值类型则为更常见的bool(布尔)、string(字符串)、integer(整型)。
[0172]
本发明首先从功能设计和协议结构两个方面对数据交互和数据处理的总体结构进行设计说明。然后介绍了相关的ui页面的开发方法，对协议构建过程的数据类型、root包、包头、包长、校验、数据、普通包等关键属性阐述了设计原因和设计思路。并通过ui开发代码的实现得到了协议配置中各部分属性的ui开发结果，其与协议的设计能够相互对应，进而可以通过ui页面完成协议的构建与配置工作。
[0173]
协议相关的配置信息通过json语言进行了描述，并下发给终端仿真执行程序。字段的设计是对应着json的数据格式中的key，字段的值则相当于json的数据格式中的value，最终对协议转换为json 数据格式所需要的字段进行功能与作用的详细描述，为信息物理测试系统的数据交互和数据处理研究建立夯实的基础框架。
[0174]
在以上的描述中阐述了很多具体细节以便于充分理解本发明。但是以上描述仅是本发明的较佳实施例而已，本发明能够以很多不同于在此描述的其它方式来实施，因此本发明不受上面公开的具体实施的限制。同时任何熟悉本领域技术人员在不脱离本发明技术方案范围情况下，都可利用上述揭示的方法和技术内容对本发明技术方案做出许多可能的变动和修饰，或修改为等同变化的等效实施例。凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所做的任何简单修改、等同变化及修饰，均仍属于本发明技术方案保护的范围内。