Edge X Foundry框架-设备服务层-详解
此前不了解的同学可以点此可以查看Edge X Foundry框架-设备服务层的简介
设备服务层分为三块介绍：
-虚拟设备
-SDK体系结构
-设备配置文件
1.虚拟设备
-设备虚拟微服务所处的框架位置
-设备虚拟
虚拟设备服务可以模拟不同类型的设备，以便将数据发送到核心数据微服务，用户通过命令和控制微服务发送命令并获得响应。虚拟设备服务的这些功能在执行功能或性能测试时不需要任何实际设备就可以使用。
1.设备虚拟服务总体流程
1.虚拟设备服务对核心数据和元数据微服务具有依赖性，因为初始化过程需要检查或注册配置文件，设备和值描述符，因此，核心数据和元数据服务必须在虚拟设备服务初始化之前完全启动。设备服务通过ping命令确认他们是否已经启动600秒内无响应则初始化失败
2.启动时，服务会通过从YAML文件加载“值描述符”,“设备服务”,“设备描述”来初始化，并登记在元数据微服务中，YAML文件默认存在，也可以自行创建。虚拟设备服务为元数据微服务提供回调API来管理设备实例。根据设备描述文件中定义的GET命令，有一个H2数据库（内存中）存储虚拟设备中的资源，称为“虚拟资源”。
2.虚拟资源实例：
1.启动后，虚拟设备服务15秒一次定期从H2数据库读取数据发送到核心数据微服务，频率可再配置文件中自行修改，“虚拟资源”的当前值是随机生成的
2.虚拟设备服务为命令和控制微服务提供API，索引H2数据库并返回GET命令的所需值。此时，虚拟设备服务支持两个特殊的PUT命令：自动随机和收集频率。这些命令修改H2数据库中特定虚拟资源的ENABLE_RANDOMIZATION和COLLECTION_FREQUENCY列。例如，使用示例将HTTP PUT方法发送到 http://localhost:48082/device/56b1acf1d66f9c9762581ea4/command/56b1acedd66f9c9762581e9d/put/0
{
“enableRandomization”：false，
“collectionFrequency”：6
}3.修改Command ID是“56b1acedd66f9c9762581e9d”并且device ID是“56b1acf1d66f9c9762581ea4”的虚拟资源记录。
4.将“ENABLE_RANDOMIZATION”列修改为FALSE后，虚拟资源的值不会再生成随机值。通过修改“COLLECTION_FREQUENCY”列，收集频率将在下一个收集周期后改变。可以通过H2控制台手动修改它们http://localhost:49990/console将"JDBC URL"修改为jdbc:h2:mem:testdb，然后单击“连接”
-特殊的配置
application.device-profile-paths=./bacnet_sample_profiles,./modbus_sample_profiles
application.auto-create-device=true指向上述目录中YAML配置文件的配置设备的虚拟设备服务指示符，当设置为true时自动为每个配置文件创建一个设备
application.auto-create-device=true
每次启动服务时，重新启动虚拟设备服务并使用纯净的元数据-数据库是最好的。下面的属性指示设备服务在关闭时是否应清除数据库中的任何现有虚拟设备，以便在服务开始备份时能提供干净的环境。通常设置为true，在运行/演示的环境中设置为false
application.auto-cleanup=true
设定虚拟设备服务的调度程序应该在多长时间内收集来自虚拟设备的数据。
application.collection-frequency=15
1.服务名称和主机名称
在EdgeX 设备服务中，service name（设备名称）（由application.properties文件中的service.name键或Consul配置表示）是设备服务对象的标识。该名称由EdgeX用来将有关该服务的所有信息（特别是日程安排，设备所有权等）归入该名称。但是，service.host参数用于描述如何与服务交互。服务主机的配置需要符合以下准则
部署模式（在Docker中运行所有容器）
服务主机是服务绑定到的实体的DNS或IP地址网络条目（容器，机器等），并可从其他微服务器访问。这可以确定服务的完整位置URL。在Docker环境中，主机名是运行微服务的Docker容器的名称（例如edgex-device-virtual）
在本地运行服务时， 服务名称不会像在Docker环境中那样解析为DNS条目。
对本地服务（手动配置）和docker-compose文件使用 service.host=
-系统架构
虚拟设备服务采用正常的MVC设计模式，将逻辑分为不同的层
系统架构图形
1.接口层-与其他的微服务进行交互
控制器提供RESTful API。该实现位于org.edgexfoundry.device.virtual.controller包中。
有关详细实现，请参阅org.edgexfoundry.device.virtual.scheduling包。另外，org.edgexfoundry.device、virtual.scheduling.Scheduler从元数据微服务读取调度程序和ScheduleEvent并安排收集任务。
2.服务层 -处理业务逻辑，例如执行收集任务和命令，管理配置文件和设备等等
有关更多详细信息，请参阅org.edgexfoundry.device.virtual.service.impl包。
3.数据访问对象层 -处理协议访问。
对于虚拟设备服务，org.edgexfoundry.device.virtual.dao包中的Spring Data JPA接口。
Spring框架将处理访问H2 数据库的通信工作。
4.数据层 -一个H2 数据库来模拟设备资源。
-设备配置文件定义
如果结构符合“设备和设备配置文件模型”，用户可以定义任何YAML格式的虚拟设备配置文件。通过将文件路径分配给应用程序属性“ application.device-profile-paths ”，虚拟设备服务将加载该文件夹下的所有YAML文件，并且该属性接受用逗号分隔的多个值。例如，以下设置会导致虚拟设备服务加载./bacnet_sample_profiles 和 ./modbus_sample_profiles 文件夹下的所有YAML文件
#The paths of device profile definition files
application.device-profile-paths=./bacnet_sample_profiles,./modbus_sample_profiles除了配置文件定义之外，ValueDealthor还被定义在“DrofeReSurvis.Frofile”部分的配置文件定义中。该结构需要符合“设备配置文件”中的配置文件属性（在“设备和设备配置文件模型”下面的图形中），并且在设备创建回调过程中，将创建ValueDebug描述符并将其发送到核心数据微服务。
通过分配应用程序属性“Apvest.AutoCudio设备”＝TRUE（默认值为true），虚拟设备服务在启动期间自动为每个配置文件创建设备实例，并且设备实例开始向核心数据微服务发送事件和读数
-数据模型
1.虚拟设备服务数据模型-设备和设备配置文件模型
2.虚拟设备服务数据模型 - 命令模型
3.虚拟资源
虚拟资源是从设备实例生成的数据对象，并保存在H2数据库中。
数据字典类
| 类 | 描述 |
| ScanList | The object containing a protocol discovery method query |
| Transaction | The asynchronous helper object used for gathering sets of device responses |
2.SDK的体系结构
3.设备配置文件
设备配置文件框图显示 设备配置文件对象类 