IBM WSE Device Kit 开发硬件接口的架构

  过去的一周时间,都在专研着,怎样使用IBM WebSphere Sensor Events的Device Kit开发硬件接口,WSE是IBM智慧地球最具威力的产品,这免不了和硬件直接挂钩,IBM将接口开源,提供为开发者使用的工具,这个接口就是EPC,是现在国际上使用最广泛的物联网接口,IBM率先的提出智慧地球,其实,在于对这些标准的支持的强大能力。

  关于WSE的整体架构,其实本人已经花了两个月的时间去琢磨,而现在开始研精。

  要想实现对Device Kit的使用,起码要学习一下的内容:

  1.熟练的掌握Java 

  2.设计模式

  3.OSGi

  4.Junit能使开发周期变得非常短。

  因为这个接口的目的是为了支持所有硬件的,所以接口本身的复杂度很大。

  简单的图例如下:

  

看见这张图,大家可能很快就联想到互联网通信的五层模式!

对了,细细的研究下,我发现他们之间是神似啊!

首先是物理层,就是硬件了,硬件厂商将提供说明书,指明该硬件支持的通信格式(Url,RS232。。。),这个层上通信的码字还是十六进制的(通常情况下,但都不是字符类型的,也就是都是“××进制”),在这个层上,硬件实现的物理功能是多方面的,各种传感器,来者不拒。

在物理层之上就是传输层,传输层是面向连接和无连接的两种,也就是包括了(UDP,串并口,485等等),在定义每一个Device时,都要有相对应的transport,这个transport就是为这个传输层服务的,这里在一个XML文件中定义connection和各种commnd和signal。但是,其实,传输层没有逻辑判断,就是将前面来的各种command和signal转换成制定的格式流,而通过定义好的connection将他们传过去,而硬件在得到这些命令的时候,会将各自的状态,还是需要的信息传输上去。完成功能,整个传输层都在这个功能上提供output和input,在上层的应用(application)都是OSGi架构的,都是监听模式的,他们将对特定的command和signal监听,一旦发生变化就能玩激活这个程序。

不小心将application也说了,但其实这个Application是非常重要的,如果我们捕捉的信息受到后,需要将它们格式化成标准的IBM Sensor Events 格式的xml,通过JMS或是Micro Broker传给server,这个server 就是host所有传感器信息的处理中心,至此,Sensor介入了SOA,  CHEERS!

在整个架构的最上层,我们看到的是Profile,其实这个Profile是定义一个Agent的,一个终端叫Controller,每个Controller可以运行多个Agents。每个Agents的运行框架就是OSGi。

在每个层上,还有个很重要的:Adapter。这就是个适配器,我们在Profile有统一的名字去定义各个方法,接口,但是各个厂家的硬件功能不一,需要适配,OK,You Know What I Mean !

下面就是开发阶段的测试:

 Junit是个好东西,Big Bang‘s  Favourites

框架如下:

The major components of the Validation Testing Framework are the Test Agents, the Test Controller and the Test Manager. A Test Agent provides one or more testcases. The Test Controller manages the execution of tests provided by Test Agents. The Test Manager provides a user interface to select and execute a test script specifying configuration and test actions, and to view test progress and results.

A validation test can for example test the implementation of a device adapter to be tested for conformance to a profile or profiles that it implements. Validation tests are implemented as test agents in the validation test framework that is part of the device kit. The device kit provides a wizard that lets you create the projects for a new validation test. To run a validation test, a test manager servlet lets you select and run a test script, and review the test results.

Since the goal is to test adapters for physical devices, the framework supports manually assisted testing. As part of the test a tester can be prompted to assert certain conditions or perform certain actions.

The Test Agent and the Test Controller

The Test components will be instantiated and configured on the target system from a factory via the OSGi Configuration Admin service, using the mechanisms provided by SAT, or programmatically in a non-OSGi environment. TestAgents can be run stand-alone, or controlled by a TestController and a TestManager.

A TestAgent manages the configuration and running of a single JUnit Test, which can be either a TestSuite or a TestCase. Either a standard JUnit Test can be run, or a TestCase or TestSuite that extends base classes provided by the TestAgent framework.

The TestAgent framework provides the following base classes for implementing a TestCase and TestSuite:

  • ConfiguredTestSuite and ConfiguredTestCase � an abstract implementation of TestSuite and TestCase that receives configuration information and other context-specific information from the TestAgent.
  • NotificationClientTestCase � an abstract implementation of TestCase that can broadcast and receive messages using the NotificationService that is provided by the Device Kit. A NotificationClientTestCase is also a ConfiguredTestCase.

The TestAgent also optionally provides the TestSuite and TestCase with a TestSynchronizationService that allows the test to interact with a test user for the purpose of taking manual actions and performing verification external to the system under test.

A TestController, of which one instance is deployed on the target system, creates, updates, and destroys TestAgent instances, as well as other components like profiles, device adapters and agents via the OSGi Configuration Admin service. TestAgent instances will be run by the TestController and TestAgent instances report progress and results back to the TestController. Tests will synchronize during their run with the test environment via the Test Controller.

Figure 1 depicts the TestAgent and TestController in relation to JUnit and the Edge Configuration, which are prerequisites of the framework. The diagram also shows (in gray), a concrete example Test based on the framework.

 

 

 

The Test Manager

As explained in the previous section, the TestController is responsible for running tests locally on a target. The TestController in turn, is managed by a TestManager, as is shown in the next diagram, Figure 2.

 

 

The Test Script

The tester commands the Test Manager to run a test script. The test script is an xml document specifying:

  • The target system(s) under test.
  • A collection of test steps to run either sequentially or parallel. Test collections can be nested to allow test sequences to be run in parallel, or collections parallel tests to be run in sequence.

Each test step specifies either:

  • A set of configuration updates create and configure and possibly destroy tests, devices, adapters, profiles, transports and connections.
  • One or more TestAgent instances to run concurrently on a specific target system. 

 

Hai Liang Wang 深度学习 算法 自然语言处理
Chatopera 联合创始人 & CEO,运营聊天机器人平台 https://bot.chatopera.com,让聊天机器人上线!2012年开始从事业务流程云,业务流程引擎开发,2015年开始探索聊天机器人的商业应用,实现基于自然语言交互的流程引擎、语音识别、自然语言理解,2018年出版《智能问答与深度学习》一书。
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值