开放系统架构

开放系统架构（精选九篇）

开放系统架构 篇1

1 汽车电子云制造架构的重要性

汽车电子云制造架构能够提供出高质量的服务, 因而越来越受到高度重视。为了更好的使其发挥出效能, 可以对其进行按需管理。凭借云服务, 从而建立起一整套具有系统性的资源组织、资源获取与资源合理使用的方式, 实现各种资源的优化配置, 提高资源的增值效益, 同时践行了绿色制造的理念。服务资源爆炸是云制造发展过程中不可避免出现的问题, 服务有序化是解决该问题的重要途径之一。在汽车制造过程中, 经常会采用购买资源的方式来满足多方的需求, 这种方式尽管具有一定便捷性, 但是很容易造成多种资源的浪费。而在汽车电子云制造的建设中, 采用集约化、智能化等现代化的制造工艺, 能够提高资源的利用率, 更加直接的满足用户的需求, 节约资源, 促进汽车制造业的服务转型。

2 汽车电子标准AUTOSAR及实时SOA

2.1 汽车电子标准

汽车电子标准AUTOSAR中明确指出了汽车电子软件开发和优化方法, 这套标准具有系统化和全面性, 可以应用到不同类型的汽车开发平台, 有利于提高电子软件的利用率, 降低开发成本。现阶段, 汽车制造中的电子系统, 在AUTOSAR标准影响下, 逐步向集成化、模块化、接口可控化及系统可扩展化方向发展, 使得汽车电子系统具有更高的性能。

2.2 实时SOA

在汽车制造过程中, 经常会用SOA来表示软件构件设计与集成基础模板。实时SOA作为一种基础模板, 得到了业内人士的高度认可, 因而在汽车电子系统设计与制造中得到了广泛推广与使用。实时SOA在云计算机系统构架中作为一种基础性构件, 主要提供出了各种所需的服务。当前, 实时SOA已经逐步在各行各业中渗透, 其性能也受到高度重视。实时SOA的提出与应用, 有效弥补了实时软件在体系构架上存在的缺陷。

3 汽车电子系统云制造构架的设计

电子标准AUTOSAR实施, 是对运行总线的一种扩充, 并与实时SOA相互配合使用, 从而改变了汽车车载的封闭性环境, 为云制造的实现创造了有利条件。但是两个系统在相互对接使用时, 并没有对服务请求、服务调用频率及协议适配器等方面的内容进行描述, 这些都是云制造环境下, 实现汽车电子云制造构架的重要影响因素, 下文对有关内容进行分析。

3.1 服务请求叙述

电子标准AUTOSAR的设计与使用, 离不开SOA和Web等服务语言的支持, 并要在相关制度标准的约束下, 形成特定协议标准。近几年, 随着信息技术的不断发展, 汽车电子云制造体系架构由三个部分组成, 即对基本操作信息的描述、约束操作信息的描述及操作服务质量信息的描述。具体内容如图1所示。

在该系统架构中, 每部分的信息都能够进行相应的服务性描述语言, 在该模型基础上, 对各种语言表示进行定义, 并实现了其特有的功能, 对各种操作进行了有效指示。由于电子标准AUTOSAR也是在可扩展标记语言的规范基础上得以实现, 因而相关的服务内容及描述会很容易被协议的适配器所接受, 并且还可以被解析成WSDL的标准文档。

3.2 服务调用频率

我们知道, 调用协议的适用性、安全性及执行性是汽车开发系统实现电子云制造构架的关键性影响因素。通常情况下, 车载环境中的远程调控主要有两种方式, 即简单对象访问协议和表象化状态转化协议。

3.3 协议适配器

在AUTOSAR描述与WSDL的描述影响下, 多种服务协议能够相互转化。通过上文对服务协议相关内容的分析可以知道, 协议扩展需要在满足文档功能和安全性能的基础上实现, 并要对其中种类的描述进行分析, 进而可以形成具有标准形式的文档, 在网络技术的支持下, 对云环境提供多种服务请求。当云计算环境接受到了服务请求以后, 就会自行进行查询与科学匹配, 进而就会得到相应的服务集或者是服务。并把此作为了依据, 根据请求地址的来源把相关的服务信息反馈到汽车的对应节点中, 当汽车的节点收到了反馈信息以后, 会自动根据请求内容作出服务分解与服务组装, 对协议机械能转换。在这个过程中, 能够把原本较为复杂的WSDL文档变化成能够被车载环境所适应和理解的AUTOSDL语言。通过所提供出的转换结果, 车载环境可以进行远程调控, 并不断重复结果反馈和协议调用转换的过程。通过多次试验, 可以得到相应的REST和SOAP协议, 在对Byte和Float进行处理时, 可以判断其对数据的处理能力。通过比较分析, 可以得知, REST的数据处理能力要明显高于SOAP, 因而在构建电子云制造构架时, REST是首先的服务调用协议。

4 汽车电子云制造架构的应用

通过上文对基于汽车开放系统架构的汽车电子云制造架构的设计分析, 可以得知, 我们对原有的电子标准AUTOSAR进行了不同程度的扩展, 实现了AUTOSAR与SOA两个不同的容器, 这两个容器能够分别对车载电子与云端软件的服务请求进行描述、组成、分发及协议转化, 通过不同协议之间的有效转化与响应, 从而能够使车载化环境和云计算环境相互融合, 有利于实现云端计算与汽车制造的无缝对接。

我们在对汽车开放系统架构的汽车电子云制造架构的设计分析后可以知晓, 汽车云制造架构的实现可以对汽车进行全方位有效的控制, 但是要实现这些目标, 需要利用控制器, 并要对汽车的能量管理、电气安全、动力学控制、远程控制标定以及故障诊断进行全面分析。控制器系统的基础软件还包括了内存服务、系统服务、诊断服务和组件对象模型等内容, 可以实现模拟输出、脉宽调制行业微控制等功能, 合理应用这些功能, 有利于汽车开放系统架构的汽车电子云制造架构设计的实现。

5 结束语

社会科学技术飞速发展, 在现代化汽车制造生产过程中, 人们的要求越来越高。娱乐性、安全性和可扩展性都是汽车必不可少的重要功能。在新时期的汽车制造生产, 逐渐向服务性强、管理虚拟化及更人性化等方向迈进。要实现这些, 都离不开云技术的大力支持, 因而, 我们要对汽车开放系统架构下的汽车电子云制造架构设计有足够重视, 不断进行研究, 在依托汽车电子标准AUTOSAR及实时SOA的基础上, 不断突破创新, 结合新时期人们对汽车功能的要求, 不断加强研究与设计, 提高汽车的系统性能, 生产出功能更齐全、性能更好的汽车。

参考文献

[1]吉莉, 王丽芳, 廖承林.基于汽车开放系统架构的汽车电子云制造架构[D].计算机集成制造系统, 2012, 07 (09) :15-16.

[2]黄沈权, 王广德.制造云服务按需供应模式、关键技术及应用研究[J].浙江大学, 2013, 04 (01) :13-14.

[3]保罗·汉森.全球汽车电子行业十大发展趋势[J].汽车观察, 2013, 11 (01) :17-18.

[4]刘芳, 张海亮.“开放系统架构对汽车电子产业影响深远”——专访深圳汽车电子行业协会会长杨洪[J].信息技术时代, 2013, 05 (25) :11-12.

开放系统架构 篇2

图4-5

这是一个典型的分层架构，分为应用层、Framework层、Native层、内核层。这似乎与我们今天要说的微服务架构没有任何关系！大家需要注意的是这是一个更为宏观的架构，在这个分层架构之下还有其他的架构模式，微服务架构就是其中最为明显的一个。Android系统按照职责分为不同的层次，但是在Java层( Java应用程序和应用程序框架)与系统服务层( Android运行环境 )这两个层之间则是通过本地C/S模式进行通信，也就是我们的微服务架构。<?www.2cto.com/kf/ware/vc/“ target=”_blank“ class=”keylink“>vcD4NCjxwPs7Sw8fWqrXA1NpBbmRyb2lkz7XNs8b0tq/KsaOstPPWwrvh1rTQ0Mjnz8LLxLK9OjwvcD4NCmluaXS9+LPMxvS2r6O7o7sgU3lzdGVtIFNlcnZlcsb0tq+juyBBbmRyb2lkz7XNs7f+zvHG9Lavo6y9q7f+zvHXorLhtb1TZXJ2aWNlTWFuYWdlctbQo7sgQW5kcm9pZNTL0NC7t76zvajBoqOssqLH0sb0tq9MYXVuY2hlcrPM0PKhow0KPHA+1Nppbml0vfizzMb0tq+686Osu+G199PDaW5pdF9wYXJzZV9jb25maWdfZmlsZbe9t6i94s72aW5pdC5yY87EvP6jrMi7uvO9q2luaXQucmPW0Na4tqi1xMP8we6horf+zvG1yMb0tq/G8MC0oaM8L3A+DQo8cHJlIGNsYXNzPQ==”brush:java;“>int main(int argc, char **argv){ // 代码省略 // 创建系统文件夹 mkdir(”/dev“, 0755); mkdir(”/proc“, 0755); mkdir(”/sys“, 0755); // 代码省略 // 初始化内核 open_devnull_stdio; klog_init(); property_init(); process_kernel_cmdline(); // 代码省略 // 解析init.rc文件 init_parse_config_file(”/init.rc“); // 代码省略 return 0;}

init.rc是由一种被称为“Android初始化语言”的脚本写成的文件。在该文件中描述了一些动作、命令、服务、选项等，我们这里只关心服务这一项。init.rc中的一个服务描述大致是这样的。

service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server class main socket zygote stream 660 root system onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart restart media onrestart restart netd

在上述代码中指定了一个zygote服务，这个服务会启动一个叫做zygote的进程，zygote是Android世界的万物之源，所以的进程都有它孵化。在启动zygote时又会启动System Server进程，System Server是所有系统服务的栖息地，也是应用与Zygote进程通信的中枢，例如需要启动某个应用时会通过System Server通知zygote fork一个新的进程。在System Server启动之后会调用com_ android_ server_ SystemServer. cpp类中的android_server_SystemServer_nativeInit函数，在该函数中会获取ServiceManager实例以及启动一些Native服务。最后会调用SystemServer内部类ServerThread的initAndLoop函数将WindowManagerService、ActivityManagerService等系统服务注册到ServiceManager中，这些服务为系统提供各种各样的功能，最后启动系统消息循环，此时Android的运行环境基本构建起来了。

public class SystemServer {// 主函数public static void main(String[] args) { // 代码省略 // Initialize native services. nativeInit(); // This used to be its own separate thread, but now it is // just the loop we run on the main thread. ServerThread thr = new ServerThread(); thr.initAndLoop(); }}// 内部类class ServerThread { public void initAndLoop() { // 1、启动主线程消息循环 Looper.prepareMainLooper(); // 代码省略 try {// 2、将各个系统服务注册到ServiceManager中// 添加PackageManagerServicepm = PackageManagerService.main(context, installer,wm = WindowManagerService.main(context, power, display, inputManager, wmHandler, factoryTest != SystemServer.FACTORY_TEST_LOW_LEVEL, !firstBoot, onlyCore);// 添加 WindowManagerServiceServiceManager.addService(Context.WINDOW_SERVICE, wm);// 数十种服务的注册，代码省略 } catch (RuntimeException e) { } // 3、启动消息循环 Looper.loop(); }} // end of ServiceThread} // end of SystemServer

Framework层（客户端）与Native系统服务（服务端）之间并不是直接调用的，而是通过Binder机制，客户端代码通过Java端的服务代理与Bidner机制向Native服务发起请求，具体的工作交给Native系统服务来实现。因此Framework和Native层的架构是如图 4-6 所示。

“炫视通”平台开放架构详解 篇3

然而，在实际操作进程中，服务提供商们都面临着机顶盒软硬件平台不统一、私有协议较多等限制，开发和移植效率低下，难以顺利完成各项业务的开展，更谈不上带来丰厚的收益。

正是在这一背景下，“炫视通”试图为增值服务提供商们搭建一个开放的平台，确切地说，这是一个“构架在双向互动宽带网络上、开放架构、具备基本视频业务的IPTV增值服务运营平台”。

总体来说，“炫视通”平台分为用户终端系统、后台支撑系统和服务三大部分。

后台支撑系统主要包括整个平台的运营支撑、安全认证、业务网关、信息发布、搜索引擎等模块；终端则由机顶盒硬件以及运行于其上的中间件平台组成；用户通过电视机所看到的一切都是“服务”，包括门户服务、电视服务、点播服务、以及各种增值服务。

应该说，这—体系结构与其他的IPTV系统并没有本质区别，但“炫视通”本身是为各种增值服务提供运行的平台，因此其最大的特点是采用开放的体系来支持各种增值服务的开发和接入，具体表现在以下诸多方面。

特色一:×86架构高端机顶盒

在IPTV系统中，机顶盒起着非常重要的作用，它负责响应用户的业务请求，从后台获取信息并通过电视机屏幕将业务展现出来。机顶盒硬件的核心由两部分组成:视频解码单元和CPU，视频解码单元负责实现视频的解码和显示，为用户提供高质量的视频服务；CPU完成除视频解码以外的其他信息显示和交互，例如EPG信息等。

前期，人们在考虑IPTV时更关注于如何在较低成本下提供高质量的视频服务，以取代目前的有线电视。于是，机顶盒大都采用DSP和RISC体系的CPU来实现。由于CPU本身能力的制约，机顶盒的运算能力、扩展能力都有非常大的局限性，难以实现复杂互动业务的开发和运行。

在“炫视通”中，我们采用了x86体系架构的机顶盒，它不仅支持对MPEG2、MPEG4等音视频格式的硬件解码，还包含一个主频1.5GHz的CPU，并配备了512M的内存和摄像头、移动设备等外设接口。这样的机顶盒硬件，除了可以实现基本的视频业务，还具备足够的能力来实现其他众多复杂的互动业务，为各种增值服务预留了足够的空间。

在这款基于X86架构的机顶盒上，我们选择了Linux作为操作系统，为这样的机顶盒开发应用，其本质与开发PC应用没有太大区别。更为重要的是，开源界众多的面向Linux的软件，几乎无需修改就可以移植到机顶盒上，开发人员可以借助于丰富的资源来实现业务，大大简化了开发过程，带来资源聚合效率的倍增。

特色二:采用E3/S架构实现所有业务

与目前互联网上的绝大多数应用一阵，“炫视通”平台的所有业务均采用B/S架构实现。不管是门户服务、电视服务、点播服务，还是其他的增值服务，在“炫视通”中实质上都是在浏览网页。机顶盒与后端系统之间的通讯全部通过浏览器完成，所以在“炫视靓通”的终端和后端之间没有任何私有协议的介入，全部采用开放的标准协议，如HTTP、SOAP等。

由于采用B/S架构，所以在“炫视通”上开发增值服务，与在互联网上提供服务几乎一样。所不同的是，“炫视通”面向电视机用户，因此每个页面、每次操作的用户感受必须符合电视机的使用偏好与习惯。这一特点，为增值服务的开发者带来一个非常大的好处，即原来开发互联网应用的技术工具，完全可以用来开发“炫视通”增值服务；已有互联网服务向“炫视通”移植，其后台系统整体架构无需做任何调整，只需要更改用户界面即可，大大降低了移植和开发的成本。

特色三:强大的浏览器中间件

纵观目前众多的IPTV系统，大都采用功能比较简单的浏览器，通常仅能支持图片和文字信息的简单显示，而无法支持更为复杂的元素，更无法支持Web2.0年代最为重要的AJAX技术，难以实现良好的用户体验。

为了解决上述问题，“炫视通”的终端软件中提供了功能强大的浏览器，它几乎支持目前所有主流的页面制作与标记技术，包括HTML、JavaScript、CSS、DHTML、XHTML、XML以及AJAX等，还提供插件扩展能力。目前，“炫视通”已提供FLASH9.0、Java5.0和视频播放等三个基本功能插件，顺利实现Java、Flash应用等复杂的网页内容。如有需要，增值服务提供商甚至可以为自己的业务开发专有插件。也就是说，人们开发互联网应用的所有Web页面制作与标记技术，都可以用来开发“炫视通”增值服务，为业务制作和开发人员提供了充分的发挥空间。

特色四:增值服务的易接人性

除了为增值业务的开发提供了强大支撑外，这些服务实际的开发和接人流程也非常简单，图2描述了一个增值服务商从有意向开始，到完成系统接入之间所需要的全部过程。

通常，增值业务在开发阶段无需过多考虑如何接入到“炫视通”中，因为后端支撑系统已打造了一套完整的面向增值服务的用户管理和鉴权认证体系，实现了各个增值服务所需要的共性功能。在依照“炫视通”开发规范完成服务开发后，接入平台仅需要两件事情:一是依照后台的接人规范进行简单功能修改，以接纳“炫视通”提供的鉴权认证体系；二是在“炫视通”平台的门户服务中开通一个人口，让用户能够通过门户进入到该服务中。

增值服务的易接人性，不仅简化了开发人员的工作难度，还为增值业务的快速移植和运营提供了保证，使得服务提供商可以投入很少的力量来快速完成移植。

开放系统架构 篇4

关键词：系统工程,模块化开放式系统架构,商用可用技术

一、引言

近年来, 随着信息技术的飞速发展, 技术的进步, 为推动开放式系统设计的广泛应用, 奠定了重要基础。

模块化开放式系统设计方法是综合的技术及商业策略, 对组成系统的硬件及软件进行模块化设计, 并对关键接口采用商用、广泛应用的接口标准。通过应用开放式系统设计方法, 可以降低系统组建费用, 缩短开发过程, 同时为解决方案提供了灵活的系统架构, 可及时地注入新的技术, 跟进技术的发展。

通过深入研究开放式系统架构设计的指导原则和基本原理, 结合模块化开放式系统架构实施的系统工程学参考标准, 对于优化系统设计与开发, 具有重要意义。

二、开放式系统基本定义

开放式系统是为满足一定需要而设计的相互作用的组件及其子系统的集合, 系统由模块化的硬件及软件组成, 各组件及子系统之间松散耦合, 采用统一的、正式的接口规范来对关键接口进行定义, 并以此作为信息交互的基础[1]。

通常, 开放式系统具备以下主要特征: (1) 采用良好定义的、广泛使用的、非私有的接口标准及协议; (2) 使用由认可的标准组织或商用领域开发或采用的标准; (3) 对系统接口进行全面定义, 以实现方便地增加新的或额外的系统功能; (4) 通过整合额外的或更高性能组件, 以对系统最小的影响, 实现系统扩展或升级[2]。应用标准的开放式系统架构, 可以极大地促进系统开发, 以及提高未来注入新技术的能力[3]。

开放式系统设计方法, 并非针对某个特定领域的私有设计方法, 而是基于系统工程学的设计方法, 提供了系统架构设计的指导思想, 适用于系统工程设计。

如上图所示, 雷达开放式系统架构模型应用了开放

◆崔昆涛孙文力孙文强

式系统设计方法, 该模型适用于综合船桥系统、VTS系统中雷达子系统设计及开发。

系统设计对整个雷达系统进行了模块化分解, 主要包括:导航雷达传感器、雷达开放式应用模块 (ROAM-Radar Open Application Module) 、导航雷达应用系统三个组成部分。导航雷达应用系统通过ROAM提供的开放式接口完成对雷达传感器的通信控制、状态反馈, 以及资源管理。

完成开放式系统设计后的导航雷达系统, 在其典型的工程应用领域, 包括:综合船桥系统、VTS系统, 在系统开发、部署过程中, 可大量采用COTS产品, 并充分利用以信息技术核心的多种先进商用技术发展所取得的优势, 体现了开放式系统的重要特征, 同时也是开放式系统应用领域的发展趋势。

三、应用开放式系统架构的指导原则

当用开放式系统架构为工程开发设计解决方案时, 架构设计人员应遵循以下基本原则, 对于架构设计过程而言, 需要在以下方面反复地向前推进。

(1) 进行开放式系统原理的培训。对于开放式系统设计而言, 需要透彻理解一些特定的关键概念, 不仅仅局限于模块化和交互性, 通过开放式系统原理的培训, 达到从系统工程学方法解释开放式系统原理关键要素的能力。 (2) 进行开放式系统架构定义方法的培训。对于架构设计而言, 需要对UML、Sys ML、Mo DAF架构设计观点有清晰的认识, 通过开放式系统架构定义方法的培训, 达到具备为这些工具的如何使用建立指导原则的能力。 (3) 建立系统边界。建立系统边界是非常重要的, 同时, 也是较为困难的。系统设计时, 需要最早地考虑系统边界。 (4) 建立初选架构。架构是一个共享资源, 整个工作组围绕架构运作, 早期的候选架构将对系统运行发挥重要作用。初选架构的粒度也是重要的设计方面, 粒度不要太粗, 也不要太细。 (5) 应用COTS产品构建基础结构。当采用COTS产品为工程解决方案构建基础设施时, 需要尽早地对基础结构和特定领域的应用程序进行区分和识别。 (6) 组件重用性。对于开放式系统, 需要对解决方案中的大多数组件进行工程化处理, 以达到实现组件重用性的目的。 (7) 为开放式架构的应用建立管理组织。系统架构设计时, 应建立专门的实体组织负责架构及接口说明的开发, 同时, 该组织应同时具备商业/法律的能力, 以保持解决方案的开放性。 (8) 理解应用程序领域和基础结构所提供的可用标准。通常情况下, 在基础结构中, 应用COTS产品进行基础架构时, COTS产品均标明可用的协议和标准, 同样对于基础结构所支持的特定领域的应用程序也有相应的适合标准。 (9) 确定组件接口。对于工程应用, 一些接口需要进行重新定义, 特别是应用程序组件之间的接口。作为新的开放式标准, 管理工作组负责获得和维护这些定义。 (10) 确立远景系统和具备可持续性增加能力的构件。开放式系统具有长的生命周期, 会由很多功能构件组成, 因此, 确立远景系统 (长远目标) 和一系列的过渡性解决方案可以确保架构设计小组有一个共同的方向。 (11) 为开放式系统建立试验和验收程序。模块化和开放性为降低测试、鉴定和认证等过程的费用提供了新的途径。 (12) 为系统整合建立采办程序。应为系统整合建立一个支持开放性采购的综合环境。 (13) 为组件建立采办程序。当确立系统架构的时候, 应考虑组件采办方面的问题。 (14) 确立架构和说明的维护程序。 (15) 建立维护构件一致性和完备性测量的方法。

四、模块化开放式系统架构方法原理

模块化开放式系统架构 (MOSA-Modular Open System Architecture) 方法优点的实现依赖于五大基本原理, 包括:建立MOSA可行的环境;应用模块化设计;设定关键接口;关键接口采用开放式标准;符合性认证, 以上五大基本原理构成了模块化开放式系统方法实施的基础。

多年来, 美国国防部积极推动电器化组件应用于武器系统部署, 以使国防部能够同步进行系统现代化改造, 或应用新的组件建立新的武器系统。

2 0 0 1年6月1 0日, 美国国防部通过官方发布《Do D 5000.2-R重要防御系统和自动化信息系统采购程序的强制流程》, 指出美国国防部将开放式系统方法用于所有武器系统的电子设备采购, 以满足更快速、更经济性保持优势作战能力的要求。

2008年12月2日, 美国国防部通过官方又发布了《Do DI 5000.02指南》指出, 要将模块化开放式系统方法用于武器装备系统设计, 以实现经济性的改进, 并满足战场交互能力的需要[4]。

对此, 美国国防部建立的开放式系统联合任务工作组, 对在国防武器系统采办中评价和鉴别MOSA实施的五大系统工程基本原理进行了说明。

(1) 建立MOSA可行的实施环境。建立MOSA可行的实施环境, 项目管理者需要确立支持性要求、商业实践、技术开发、采办、试验评估和产品支持性的整体性战略, 以满足开放式系统有效开发的需要。

在工程应用开发过程中, 我们在建立可行的MOSA环境时, 积累了一些支持性实践经验, 主要包括:明确并分配MOSA实施的职责、保证适当的MOSA环境实施的经验和培训、进行连续的市场调查、主动识别和克服可能降低或破坏MOSA有效实施的困难和障碍等。

(2) 应用模块化设计。课题组在系统设计过程中, 包括综合船桥系统、VTS系统, 从工程角度, 对系统进行适当的功能性分割, 分成不同的功能性模块, 使系统更容易开发、维护、修正或升级。对系统进行模块化设计后, 对于经常变化或随时间演变的功能模块, 可以方便地进行升级和改变, 并对系统现存的其他部分或组件产生最小的影响。

进行系统模块化设计时, 应注意以下几个方面: (1) 从系统工程学角度, 把系统分为松散耦合的、可升级的、可重用的功能性模块, 这些模块由独立的、齐全的功能性要素组成; (2) 对模块的接口进行严格而明确定义, 以面向对象的方式, 描述模块的功能; (3) 设计应容易改变, 以达到应对技术发展和满足最大程度上, 为关键接口应用通用工业标准的要求。

如图2所示, 即为模块化开放式系统架构设计模型。

(3) 设定关键接口。模块化开放式系统架构设计方法, 并不是控制和管理系统内部和系统之间的所有接口, 而是将接口分为关键接口和非关键接口来进行管理。

在实际工程实施过程中, 可通过技术稳定模块和易

变模块, 高可靠性模块和易失败的模块, 低交互性影响的模块和传输关键交互信息的模块等特征进行区分, 辨识关键接口和非关键接口。对于系统关键接口应采用开放式标准, 可以使系统达到最大的生命周期收益[5]。

(4) 关键接口采用开放式标准。接口标准规定了系统要素 (硬件和软件) 之间的物理性、功能性和操作性联系, 以实现可替代性、互联性、兼容性和通信, 并增强系统逻辑支持能力。通常情况下, 为系统接口选择合适的标准应基于对可用标准的市场调研, 以及严格的系统工程学处理特定应用。一个系统的开放程度, 很大程度上取决于其子系统、组件所采用的接口标准的开放性水平[6]。标准的选择应基于其成熟性, 市场接受性和可实现未来技术注入的允许程度。通常情况下, 应首选开放式接口标准, 其次是事实上的接口标准, 最后是政府和私有接口标准。

在识别接口标准过程中, 根据定义的接口, 对现有可能适用的接口标准进行市场调研, 以评估其开放性和成熟度[7]。应用开放式标准可以降低商业投入和技术退化的风险, 可以允许以较低的复杂性和费用实现系统的快速更新, 实现系统实施及维护的经济性。

(5) 符合性认证。系统开发管理过程中, 应建立确认和验证机制, 如符合性认证和试验计划, 保证系统及其组件模块, 符合内部和外部的开放式接口标准, 以实现模块的即插即用, 和网络为中心的信息交互。开放式系统认证和验证必须成为贯彻于整个组织变化和配置管理过程的综合组成部分。

五、MOSA实施的系统工程学参考标准

MOSA的有效性很大程度上取决于其是否是一个完善的系统工程学过程处理的综合组成部分。因此, 建议将MOSA与系统工程化过程整合, 因为, 其对系统设计产生了最大的影响, 并为用户的最终产品产生最大的效益。

MOSA是一种系统工程设计理念, 是基于模块的开放式体系设计的物化结构, 是开放式架构的发展[8]。

基于此, 在这方面, 可参考的, 作为MOSA实施基础的系统工程处理标准包括: (1) EIA 632:系统工程学处理 (Processes for Engineering a System) ; (2) ISO 15288:系统工程学—系统生命周期处理 (Systems Engineering-System Life Cycle Processes) ; (3) IEEE1220:系统工程学处理的应用和管理标准 (Standard for Application and Management of Systems Engineering Process) 。

结语

信息技术飞速发展, 应用开放式系统设计原理以及COTS技术, 充分发挥开放式系统的技术优点, 可以构建一个开放式的、面向信息的, 同时具备数字化、网络化、分布式、智能化等高级组织形态的开放式系统, 对于系统开发、部署、维护, 以及系统整个生命周期内的演变, 具有重要意义。H

参考文献

[1]李晓辉.开放体系结构计算环境发展研究[J].仪器仪表学报, 2011, 32 (6) :25-29.

[2]黄永葵, 薛秋晖, 李卫民.开放式系统结构及其标准研究[J].航空电子技术, 2005, 36 (1) :34-41.

[3]Nelson John A.Net centric radar technology and developmentusing an open system architecture approach[J].IEEE National RadarConference Proceedings, 2010, 1476-1479.

[4]DoD.Department of Defense Instruction:5000.02.2008.

[5]Swearingen Kevin, Majkowski Wayne, Bruggeman Brian etc.Anopen system architecture for condition based maintenance overview[J].IEEE Aerospace Conference Proceedings, 2007, 1-8.

[6]Nelson John A.Radar open system Architectureprovides net centricity[J].IEEE Aerospace and Electronic SystemsMagazine, 2010, 25 (10) :17-20.

[7]赵杰, 熊华钢, 朱晓飞, 等.国外通用开放式结构标准的应用情况[J].航空计算技术, 2011, 41 (2) :72-76.

物联网开放体系架构研究 篇5

从技术角度来看,物联网可以被认为是物体的信息通过传输网络,到达其他物体和人,并且能够被理解被利用,最终实现物与物、人与物之间的自动化信息交互、处理的一种智能网络。从应用角度来看,物联网可以把大范围内,甚至是世界上所有的物理物体和虚拟物体都连接到一个网络中,形成“物联网”,实现人类社会与虚拟社会的整合,从而以更加精细和动态的方式去管理生产和生活。

在这里,物联网的关键技术不仅是对物实现操控,而是通过技术手段扩张,实现了人与物、物与物之间的相融和沟通,使得他们之间能够进行更为复杂的信息交换和通信。物联网既不是互联网的简单翻版,也不是互联网的接口,而是互联网的一种延伸。

目前,国内外对于物联网还没有一个统一公认的标准定义,但从物联网的本质分析,物联网是现代信息技术发展到一定阶段后,出现的一种聚合性应用与技术的提升,它是将各种互联网技术、传感器技术和人工智能等的聚合与集成应用,使物与物能够智慧互联。物联网的发展过程可以分为四个主要阶段:

(1)传感器网络:许多在空间上分布的自动装置组成的一种计算机网络,这些装置使用传感器协作监控不同位置的物理或环境状况。

(2)传感控制网络:在传统传感器基础上通过一系列的通信信道构成一个或多个控制闭环,同时具备信号处理、优化决策和控制操作的功能。

(3)物物智慧互联:在没有人工干预的情况下,网络中的物体可以理解物体的能力,发现物体,利用物体,物体之间智慧互联。

(4)物联网时代:万物互联,物联网超越了现有的互联网,不仅包括现有互联网上的所有资源,并通过物体极大丰富了互联网资源。

其中,传感器网络和传感控制网络两个阶段技术相对成熟,是物联网实现产业化的重要基础,物物的智慧互联阶段是未来研究的关键,是实现最终物联网时代的必经之路。

物联网的发展空间虽然巨大,但是仍然有些问题需要解决。从系统架构角度来看,物联网横跨众多的行业领域,各行各业又有相应不同的特点需求,这就需要制定统一的体系架构标准,从而使参与其中的物体、个人、公司、企业、团体以及机构实现互联互通,协同开发。

要想实现这种大范围的物体协作与互联互通,有三个基本问题亟待解决:(1)物体是什么:如何对物联网物体进行语义互通的描述?(2)物体在哪里:如何在物联网中找到相应的物体?(3)物体怎么用:如何使用找到的物体?

2物联网开放体系架构

中国电子科技集团公司在总结大量互联网发展经验的基础上,从能力的智慧互联出发,创新性地提出基于能力的物联网开放体系架构,旨在解决物体的描述、发现与使用三个根本问题,提升网络的智慧能力,催生新形态物联网应用模式,推动“互联网时代”迈入“物联网时代”。

2.1架构理念

●兼容:在互联网基础能力上提升,兼容发展,推进“互联网时代”迈入“物联网时代”。

●开放:立足网络整体,提升网络对物体能力的描述与搜索,建立开放的公共基础设施。

●弹性:可扩展,从解决现实需求入手,对未来发展留有空间,支持可持续发展。

2.2架构目标

●解决物体是什么:提出物体能力描述概念,对物体的能力进行描述,并提供能力的本体构建,创建能力知识图谱。

●解决物体在哪里:构建开放物联网架构标识解析体系,兼容现有标识与解析,并提供能力的标识与解析。

●解决物体怎么用:运用平台层的技术,对物体的能力进行管理,提供能力集成服务,实现物体能力智慧互联。

2.3架构关键技术

●物体描述:解决物体是什么,针对物联网中物体描述语言不统一、能力描述不足、元数据格式不互通等问题提出的一系列解决方案。

●物体发现:解决物体在哪里,针对物联网中物体标识多元化,对能力标识解析不足、现有解析体系安全性不高提出的全新解析体系。

●物体集成:解决物体怎么用,针对物体数量众多、接口不相同,需要对外统一暴露能力等问题,构建物体集成平台,实现物体的统一管理。

物联网开放体系架构关键技术如图1所示。

3物体描述

物联网中的物体/能力种类繁多,并且同一种类的物体也可能具有不同的元数据格式,呈现出显著的异构特性。从信息层面来讲,相同的物体与能力之间的数据语义千差万别,不能实现物体之间的相互理解与智慧互联。这一方面,导致了物联网应用系统开发过程中大部分工作都在重复统一物体与网络之间的信息交互格式,使得开发难度大,开发成本高;另一方面,也导致了物体之间以及物体与网络之间无法做到互连互通互操作,从而形成孤立的物联网应用系统,无法实现广域互连的物联网。

3.1物体描述的特点

(1)能力描述:针对物体的能力进行描述,一个物体可以有多种能力,多种物体也可以具有同一种能力,实现能力与物体的分离。

(2)能力抽取:针对不同物体间相同能力和单一物体的多种能力进行共性抽取,形成一类物体或者一类能力的共性集合。

(3)能力图谱:随着共性能力的不断丰富,构建能力知识图谱,逐步规范多种能力的语义描述,形成物体与物体间的能力互通的基础设施。

3.2物体描述的关键技术

●ASAC自描述语言:把接入物联网的物体按照统一的四段进行描述,实现了物体到虚拟世界的映射,物体之间可通过相互的描述元数据实现相互识别和互操作。四段分别为:属性(Attribute)、状态(State)、动作(Action)和能力(Capability)。

●能力语义识别技术:通过ASAC描述的物体,得到了描述实体,也就是物体在虚拟世界的映射,利用ASAC描述语言的能力段描述,对能力进行语义识别,实现能力描述的规范化。

●能力本体自构建技术:以往的本体构建往往需要人工干预,并需要有相关领域专家参与,而能力本体自构建技术通过能力语义识别和前期描述形成的描述能力,可以实现无人工干预的能力本体自构建。

●能力知识图谱技术:能力知识图谱是依靠语义网技术构建的基于能力本体的大型公共服务基础设施。它融合了所有领域的能力信息,以便于物体能力的语义互通。物体能力与知识图谱交互次数越多,范围越广,知识图谱就能获取越多能力信息。物体描述的关键技术如图2所示。

物体描述方法实现了物体与网络交互特征的抽象和归一化描述。一方面使得物联网应用系统开发人员能将主要精力集中在业务流程上,节约了开发和维护成本;另一方面,使得物联网应用系统能够对异构物体与网络的交互信息形成一致性理解,是实现异构物体在不同物联网应用中互联互通、协同工作的基础,也是实现跨地域、跨行业物联网应用系统互连互通互操作和物体/信息共享的基础。

4物体发现

由于物联网的物体标识具有分散性和多样性,而互联网中的DNS只能对域名这种具有统一性和单一性的资源名称进行解析,其他的一些物名解析只是在一定范围内使用,不能互联互通。所以需要一种新型解析体系来解决这一问题。

TRS(Thing Resolution System)是用于物联网中解决物体在哪里的问题、实现物体跨域统一通信的物联网基础设施级系统,是对物联网中物体进行标识与解析的基础设施级平台。TRS不仅完全兼容DNS和现有的其他物体标识体系,还针对能力标识和位置标识模块进行了设计,不仅可以搜索物体,而且能对能力和位置进行单独搜索,极大地扩展了物联网时代的标识解析体系,三个子系统相互独立又联合运作,通过三级服务进行标识融合,既安全又全面高效。如图3所示。

因此,TRS是未来物联网应用的核心入口,是建立在其他解析系统之上的顶层解析系统。物联网中的一切解析请求,如DNS解析请求、OID解析请求、能力与位置解析请求等都交由TRS系统解析。如图4所示。

5物体集成

物联网本质上是将各种物体通过网络以服务化、模型化的方式表现出来,实现世界上所有的人和物在任何时间、任何地点都可以方便地实现人与人、人与物、物与物之间的信息交互。因此,需要通过一个广泛的平台统一广域范围内物体间信息的交互模式,并实现物体间的能力相互调用与集成。

物体集成平台(图5)的功能如下:

●物体接入管理:提供多种接入方式,对于有接入能力的物体可以进行直联,而没有能力接入的物体,提供接入网关或其他方式接入。

●描述实体与描述能力管理:平台层对物体相应的描述实体进行统一管理和维护,其物体的描述能力也由平台层进行管理,并与相应的描述实体进行映射,进而管理物体与物体能力。

●物体能力集成:物体集成管理通过平台层的构建可以根据需求对其内物体的能力进行一定层级的集成,提供集成能力服务。

物体集成平台是解决如何使用物体的软件系统,利用物体集成平台可以在服务器、PC或嵌入式设备上构建硬件承载方式、规模大小不同的物体集成平台,支撑多样化的物联网物体接入和应用构建方式。物体集成平台可以在一定程度上对物体分散的能力进行集成,可以使原来不具备相应能力的物体通过平台集成一定程度的能力,实现原本自身无法实现的功能。

6物联网开放体系架构应用

近十几年来,物联网的发展得到了各国政府和业界的持续关注,物联网产业呈现出加速发展的态势。随着物联网技术和相关产业的持续推进,人们逐步认识到封闭型、垂直式的发展模式不利于物联网产业的高效、可持续发展,越来越多的政府机构和研究组织把精力投入到开放型的发展模式和体系架构中去。为了推进“开放物联网”建设,中国电子科技集团公司实施了一系列应用示范工程、实际项目落地以及标准化工作。

●标准化工作

在国家物联网基础标准工作组提出两项立项申请,已报批国家标准立项:

(1)《面向WEB开放服务的系统实现第1部分:参考架构》

(2)《面向WEB开放服务的系统实现第2部分:物体描述方法》

在国际电联ITU-T SG20物联网与智慧城市标准工作组中代表中国提出立项申请并已立项,计划于2018年完成并发布标准:

《Requirements of things description in the Io T》(物联网中物体描述需求)

●项目落地实施

由北京物联港科技有限公司和联合楼市传媒集团,并得到国家物联网产业技术创新战略联盟支持,借助中国电子科技集团公司研发的成熟物联网开放体系架构平台,在房地产行业内推动的“易联港”项目,联合众多房地产开发商推广应用,并由智慧硬件厂商和专业方案提供方提出物联网智慧家庭、智慧社区解决方案,进而推进在房地产社区和写字楼物业中应用落地。

●智慧城市建设

开放系统架构 篇6

1 确定驻留功能的开发者

开放式IMA架构和封闭式IMA架构的选择需要考虑的最重要因素就是, 谁是驻留功能的开发者。开放式的IMA架构采用无产权的, 向公众免费开放的接口, 驻留功能的开发者使用已有的接口设计, 降低开发成本和周期。而封闭式的IMA架构, 采用的是个别公司专属的接口, 由接口设计所属公司根据采购合同为其它公司或组织提供接口规范, 用于驻留功能的开发设计。

开放式IMA架构也不能排除组织架构上管理机制, 驻留功能的集成方面的取证活动仍然需要协调, 不同驻留功能的供应商之间必须有合同约束。然而, 这种协调不仅仅是接口控制的协调。开放的标准架构不需要驻留功能供应商向接口设计公司采购接口规范, 同时排除了接口设计公司因为缺少竞争对手, 向驻留功能供应商提供接口规范时漫天要价的可能性, 从而大大减少了设计成本和风险, 同时有利于驻留功能供应商的管理。因此, 确定了驻留功能的开发者, 就决定了IMA架构的类型。

2 确定驻留功能的系统集成者

系统集成方法既要适合开放式的架构也要适合封闭的架构。开放的架构很容易将驻留功能的系统集成活动和IMA平台的开发活动分开。对开放系统来说, 作为IMA平台的开发活动, 系统集成活动可能由同一家公司的不同部门承担, 或者由第三方承担。系统集成活动是高度综合的IMA架构的重要组成部分, 当IMA平台供应商没有驻留功能系统集成方面的专家的时, 雇佣第三方供应商作为系统集成者, 是非常有必要, 能大大降低开发周期与成本。

封闭式的架构中, 接口规范是客户化的, 受人控制。由于第三方可能缺少客户化接口方面的专家, 雇佣第三方负责系统集成, 难度比较大。控制接口规范的公司或组织是最好的接口专家, 他们是驻留功能系统集成者的最佳选择。如果他们在系统集成方面有一定经验的时候, 不存在任何问题, 否则, IMA平台系统集成就存在开发风险。

3 权衡内部开发和工业支持开发

开发式接口还是封闭式接口影响IMA系统的开发方法。开放式IMA架构允许IMA系统利用工业技术成果, 这些工业技术成果可以独立于IMA系统的开发。开放的架构可以受益于现有的专家、现有的COTS (Commercial Off-The-Shelf) 产品如现有的组建和系统、现有的IMA模块的取证数据。利用现成的产品和经验, 可以大大减少系统的开发成本和周期。

封闭式接口能对开放式的标准架构带来功能和性能方面改善, 这些功能和性能是开放式接口所不能提供的。然而, 任何接口都有改善的空间。如果有计划使客户化的接口变成开放的, 那么只要花点时间, 就可以让那些忽视开放式接口的公司和组织改变观点, 接受开放的架构。如果客户化的接口仍然保留封闭式的接口, 则利用封闭式接口的公司将在开发过程受到影响与限制。

影响IMA架构类型选择的另一个因素长期的支持活动。长期的支持活动包括接口问题的解决, 接口缺陷的升级完善。封闭式IMA系统的供应商将要承诺长期开发独有的接口规范。一般公司没有途径和动机承担独有接口的开发。开放的家口获益于长期的支持活动, 开放架构可以利用工业支持, 持续开发独立于IMA系统的开放式标准。飞机的使用寿命跨越几十年, 因此, 支持是选择IMA架构一个重要的考虑因素。

4 权衡采用一型飞机支持的架构还是多型飞机支持的架构

开放式IMA架构和封闭式IMA架构的驻留功能都可能用于不同的飞机型号, 但是封闭式接口规范不可能被不同飞机型号的不同的驻留功能供应商所采用。其中有两个方面的原因, 首先, 封闭式接口趋向于客户化定制的解决方案, 不适合其它飞机型号, 除非为新的飞机型号重新定制新的方案。封闭接口的独有特性大大减少了其它公司参与设计的积极性。因此, 多个不同型号的飞机, 不可能采用同样的封闭式接口。

另外一方面, 开放式架构, 鼓励不同型号飞机重复利用相同的设计。利用工业标准、开放式接口的新型号飞机的开发团队, 也能利用使用相同接口, 驻留在其它飞机上驻留功能系统的开发成果。由于开放式接口是公开的、非私有的, 其它公司或组织选择相同接口的可能性大大增加。不仅对那些希望自己的产品在多个不同的飞机型号上使用的驻留功能开发者来说, 还是对于那些希望利用其它机型上已经运用的成熟技术的飞机制造商来说, 均能大幅度降低开发成本和开发周期。

总之, 采用封闭式的架构还是开放式的架构, 取决于IMA系统架构的开发者希望谁来负责驻留功能的开发, 谁来负责驻留功能的系统集成, 决定公司内部独自开发还是希望利用工业成熟技术, 决定采用支持单个飞机的系统架构还是利用支持多个型号飞机的系统架构。

参考文献

[1]RTCA DO-297 November 8, 2005.Prepared by SC-200 2005, RTCA Inc..

[2]ARINC REPORT 651-1.Published:November 7, 1997.

三维一体:教学内容的开放架构 篇7

《义务教育数学课程标准 (2011年版) 》总目标提出 :“通过义务教育阶段的数学学习, 学生能体会数学知识之间、数学与其他学科之间, 数学与生活之间的联系, 运用数学的思维方式进行思考, 增加发现和提出问题的能力, 分析和解决问题的能力。”可见, 数学课程标准要求教学内容需开放, 只有开放, 才能使自身更“有序”, 使学生“了解数学的价值, 提高学习数学的兴趣, 增强学好数学的信心, 养成良好的学习习惯, 具有初步的创新意识和科学态度”。

作为一线教师, 我们有责任在读懂教材的基础上创造性地利用、开发教材, 将“静止”的教材内容“活化”为教学内容。我们认为, 教学内容是非线性的, 也不是平面化的, 而是一个由长、宽、高相互关联, 相得益彰, 共同构筑起来的长方体。“架构数学知识之间的联系”成其长, “架构数学与其他学科之间的联系”成其宽, “架构数学与生活之间的联系”成其高, 三者缺一不可。

一、向长度开放:架构数学知识之间的联系

数学知识是一个结构严密的整体, 任何一个知识点、一节课、一个单元乃至一册、一个学段都不是知识孤岛, 而是联系紧密、协调发展的知识体系。所以, 我们需要用系统、开放思想来设计教学内容, 站在一个知识点要能看到一节课、一个单元、一册教材、整个学段和知识体系的长度, 要明确这一知识点的位置和作用, 不仅要找到这一知识点与旧知之间的“连接点”, 还要找到这一知识点与后续知识之间的“生长点”。

具体教学时, “知识点”要夯实, “连接点”要形成清晰的网络, 而“生长点”就是将解决问题所需要的知识点重新整合, 形成新的、解决问题的知识网络。“知识点”、“连接点”、“生长点”的形成是一个解读信息, 调动、运用知识, 重新整合的思维过程, 贯穿知识变迁而始终不变的是思想方法, 这样就形成了“前有蕴伏渗透, 后有发展提高”的开放体系, 就能很好地促进数学元学习能力的长远发展。

苏教版四年级上册的《认识含有亿级和万级的数》是认识整数领域的最后一节课, 在这节课上, 可以引导学生将“万以内的数”、“整万的数”、“整亿的数”、“含有万级和个级的数”、“含有亿级和万级的数”、“含有亿级、万级和个级的数”梳理成纵横交错的知识网络图, 使学生在新旧联系中通过同化自然获得对新知识的理解和生长点的有意义扩张。

苏教版三年级下册的《小数大小的比较》是小数大小比较的起始课, 课时学习目标是“学会比较一位小数的大小”, 但我们可以借助数轴帮助学生整体建构整数大小的比较和一位小数大小的比较, 还可以悄悄地蕴伏两位小数和一位小数大小的比较, 追问 :“1.9< ( ) <2.4, 括号里除了填2.0、2.1、2.2、2.3, 你还能想到哪些小数呢? 五年级我们将继续学习。”这就为五年级上册的小数大小比较作了思想和知识上的双重准备。

二、向宽度开放:架构数学与其他学科之间的联系

有人说学习就像钻井一样, 钻得越深看得越窄, 这话有一定道理。学科知识的发展不是相互隔离、彼此封闭的, 而是相互作用、相互开放的。数学学习和其他学科的学习一样, 其最终目的都在于促进人的发展。今天, 数学已经越来越广泛地深入到自然和社会科学的各个领域, 教师就更需要打破单纯强调学科系统的局限性, 引导学生从与其他学科联系的宽度去学习, 从而更好地理解与把握数学教育的“三维目标”。

具体教学时, 一方面, 可以通过与其他学科的联系更好地促进“学会思维”, 即通过思维方法的分析使之真正成为可以理解、掌握和推广应用的。例如复习“奇数、偶数、质数、合数”时, 请学生任意选择一个自然数用“是……不是……”或“不是……就是……”等关联词造句。再例如“认识秒”, 在体验了1秒、10秒的时间后, 教师继续让学生通过跳绳来体验30秒的长短。然后追问 :在同样的时间里, 为什么有的同学跳得多? 有的同学跳得少? 这种差别, 是因为时间的差别, 还是因为人的差别呢? 以上学科整合不仅有利于知识间的融会贯通, 更使学生在别样的活动体验中发展思维能力。

另一方面, 可以通过与其他学科的联系更好地促进人的发展。例如通过解决“废纸生产再生纸”、“树木吸收二氧化碳、释放氧气”等问题, 不仅能提高学生分析和解决实际问题的能力, 增强发现和提出问题的能力, 更是对学生进行环保教育的良好契机。再例如《轴对称图形》一课能让学生感受到数学的对称美……美术元素的有机融入, 不仅拓展了学生对数学的认识, 还能培养学生的审美感。著名数学家徐利治教授曾这样阐述数学美 :作为科学原理的数学, 具有一般语言文学与艺术所共有的特点, 它包括简单美、对称美、和谐美、静态美、动态美、结构美、形式美、符号美、机智美, 等等。

三、向高度开放:架构数学与生活之间的联系

《义务教育数学课程标准 (2011年版) 》指出, 为了适应时代发展对人才培养的需要, 数学课程要特别注重发展学生的应用意识。也就是要突出数学与生活之间的联系, 这样的数学学习才会从“纸上谈兵”的平面上站立起来, 成为有高度、有生命的活力数学。

首先, 教材多会从学生熟悉的生活情境或感兴趣的事物出发, 把教学内容和生活实际有机结合起来, 让学生经历从现实情境中抽象出数学知识与方法的过程, 从而认识到现实生活中蕴涵着大量与数量和图形有关的问题, 这些问题可以抽象成数学问题, 用数学的方法予以解决。例如教学苏教版四年级下册《用字母表示数》第二课例2, 先请学生理解题意 :一个冷水壶装有1200毫升橙汁, 倒出3杯, 每杯X毫升, 求冷水壶中还剩多少毫升果汁? 学生列出“1200-3X”的字母式子后, 再请他们说说背后的数学思考, 这可以理解为“学”的过程。

其次, 有意识地利用数学的概念、原理和方法解释现实世界中的现象, 解决现实世界中的问题, 就会使知识变得更有意义, 从而也能使学生体会到数学的价值和魅力, 提高学习数学的乐趣。教学苏教版四年级下册《用字母表示数》第二课例2, 在抽象出实际问题的数量关系式后, 教师将冷水壶的情境置换为购物情境 :如果超市里购进1200千克西瓜, —, —, —? 你能根据“1200-3X”将题目补充完整吗? 学生联系实际生活畅所欲言。

生1 :每个西瓜3千克, 卖掉了X个, 还剩多少千克?

生2 :卖掉了3筐西瓜, 每筐X千克, 还剩多少千克?

生3 :卖掉了3个西瓜, 每个X千克, 还剩多少千克?

生4 :已经卖了3天, 平均每天卖X千克, 还剩多少千克?

……

结尾, 教师再意犹未尽地追问“1200-3X还可能表示什么”。同样的X, 在不同情境中意义不同, 它所对应的式子表示的意义也不同, 这个思维发散过程不仅使学生进一步感受到“用字母表示数是简洁而概括的”, 还使学生体会到数学之应用价值。这可以理解为“习”的过程, 它着力于在使用中精进和完善所学。

开放环境下的远程证明体系架构设计 篇8

可信计算[1]的出现为各种安全问题的解决提供了一种新的思路和方法,这种新的思路和方法主要是通过在原有的硬件主板上增加一块类似于安全协处理器芯片的可信平台模块(TPM)来实现的。TPM为建立IT系统安全提供了多个重要的功能,比如用于存储加密密钥以及其它的机密数据的安全存储机制等等。TPM还可以实现向一个远程实体证明本地平台配置的能力,TCG将其称之为远程证明机制。

目前对远程证明机制的研究主要有:TCG规范提出的完整性报告机制[2]、IBM的IMA体系架构[3]以及IBM结合IMA和CW-Lite完整性模型提出的证明框架PRIMA[4]、基于属性的证明[5]、基于语义的证明[6]等等。在详细分析完这几种机制之后,本文认为在一个开放式的系统下,使用证明技术建立信任关系需要解决以下几个问题:

1) 有效地降低证明机制实施的复杂度

目前的IT系统大多是一个开放性的、非资源受限的操作环境,系统本身的复杂性限制了上述证明技术的应用,换句话说,在当前的操作环境下应用这些证明技术会增大证明的复杂性。最为有效的解决方案就是从体系架构上改变操作环境的设计,使得新设计的架构既能支持证明技术,又能降低证明技术实施的复杂度。

2) 建立一条安全有效的证明通道

使用TPM实现远程证明机制面临的诸多挑战之一就是如何确定在证明系统和证明者之间建立一条安全通道并且保证这条通道的安全性。如果此通道不是以一种安全的方式建立的,那么攻击者就可能会把这个证明挑战转发给另外一个主机,并且将其主机伪装成可信主机。现有的几种机制着重关注的是证明的实施,而没有考虑安全通道的建立及维护,因此面临着伪装攻击的危险。

3) 充分考虑平台隐私泄露的问题

远程证明的一个核心就是将完整性度量日志发送给证明方以便让证明方验证整个平台配置的完整性(基于属性的证明和基于语义的证明除外,但是这两者均需要转换平台配置及相应的属性/语义,因此会引发巨大的性能开支,在实际应用中是不可行的),攻击者简单分析截获到的响应消息,就可以发现包含所有运行着的进程在内的整个平台的配置信息,进而引发隐私泄露的问题。因此需要提供一种隐私保护机制,以便在不泄露平台具体配置的情况下,确定平台的信任级别。

虚拟化技术将分隔机制融入到了操作系统中,其主要思想是使用一个监控程序或者虚拟机监控器来建立多个隔离的、互不影响的执行环境,其中任一个环境中的错误/缺陷都不会对其它环境产生影响,Madnick和Donavan曾经形式化证明过这种方法可以大大地提高软件安全性和可靠性[7]。但是,虚拟化方法本身并不是万能的,因为它并不能保证一个组件,比如监控程序能够如预期般执行,而这正是可信计算要解决的问题。因此,越来越多的组织和研究单位逐步转向了对如何有效地结合虚拟化和证明技术来增强系统安全性的研究。结合虚拟化和证明,可以使用户信任某一平台是真实可信的,并且平台也没有受到恶意软件组件的危害。与此同时,还可以构建相互隔离的虚拟机环境,使得某一要保护的组件免受其它组件的干扰,进而构建强大的自我防御系统,免受敌手的损害。

本文首先给出了在开放环境下使用远程证明建立信任关系需要解决的问题;接着,结合虚拟化和可信计算技术,提出了一种适用于分布式环境的安全体系架构Sec_TV,阐述了在此安全体系架构下如何建立多个具有不同信任级别的、相互隔离的执行环境来增强分布式环境的安全性及可信性;第三,给出了Sec_TV下的远程证明协议设计;最后,从Sec_TV体系结构及远程证明协议两个方面讨论了这个远程证明体系架构的安全性。

2 安全体系架构Sec_TV

如第1节所述,当前可用的操作系统环境本身的设计比较复杂,并且没有提供执行环境间的强隔离机制,为了使用证明技术来确定特定的目标应用程序是可信的,操作系统的所有可执行组件都必须要求是完全可信的,即便这些组件对目标应用程序并没有直接的影响。另一方面,由于要度量所有这些可执行组件,因此就会产生许多的度量值,而每一个度量值都需要提供一个可信的参考值,这些可信参考值的存储受限于TPM的硬件能力及extend函数的aggregate操作的限制。因此,可以说,在当前可用的非受限操作系统环境中使用证明技术是不可行的。因此,本文结合虚拟化技术,为开放式的非资源受限平台提出了一种新的安全体系架构Sec_TV,如图1所示。

跟Terra[8]一样,Sec_TV使用了不同类型的VMs来实现隔离的执行环境,这些VMs都是单独的实例,因此我们可以向其中一个实例而不是向整个操作系统环境来证明其可信性。这些VMs可以划分为三类:① 可信VM,负责运行高敏感度的代码;② 开放VM,负责运行任一低信任级别的软件组件,比如Web浏览器或者Office应用程序因此不是本文关注的重点;③ 管理VM,负责启动、停止以及配置VMs。

2.1 可信虚拟机监控器(TVMM)和管理VM

VMM是一个软件层,其主要目的就是划分底层硬件并且为当前运行在平台上的VMs提供访问硬件的接口。由于它具有访问底层硬件的特权,并且可以授权访问正在运行的VMs以及撤销来自正在运行的VMs的访问(比如CPU调度),所以要求这个VMM必须是可信的。目前,VMM的属性已经在相关文献中得到了广泛研究:隔离性、有效性、兼容性及简单性。而在Sec_TV中,TVMM与管理VM紧密相连,可以为虚拟机提供附加的安全服务:完整性度量、安全存储以及TPM支持等等,可以说,TVMM与管理VM一起共同形成了Sec_TV的安全基础:

(1) 平台的完整性度量 Sec_TV支持完整性度量功能以提供对虚拟机配置的明确描述。管理VM提供了一个完整性度量引擎,它可以在管理VM产生VM之前对VM的软件映像进行SHA1度量,以提供对虚拟机配置的明确描述,并且将获取的度量值存储到VM的vTPM安全存储内。

(2) 完整的信任链 Sec_TV的TVMM通过一个虚拟化的TCM接口,为上层VMs提供了底层硬件TCM的一个抽象(即vTCM),并且实现了vTCM与底层硬件TCM的绑定,进而可以将TCG的可信引导过程扩展到终端用户应用程序(即可信虚拟机TVM内),从而建立了一条从底层硬件到上层应用的完整信任链。

(3) 远程证明 在Sec_TV中,运行在TVM内的证明服务可以向认证本地系统状态的远程方报告包括本地平台状态,实现平台认证的功能,这个平台状态不仅包括本地硬件环境,而且还包括运行在TVM内的所有启动进程、配置文件、内核模块以及脚本在内的所有组件的状态,进而保证了证明的完备性,解决了传统操作系统环境下的不完全度量引发的问题。

(4) 安全存储 Sec_TV将某一特定的内存隔离区域划分为安全存储区域,实施对敏感数据(比如特定状态的vTCM数据、VM镜象、VM特定数据等等)未授权访问的控制。安全存储是受TPM硬件保护的,只有在认证证书正确的情况下,才可以授权访问这个安全存储。

(5) 强隔离 平台证明特性可以及时陈述特定平台特定点的信任级别,但是,它不能确定可能会导致系统转换到非可信状态的状态转换,因此TVMM必须提供相应的机制,仅允许系统发生那些不会影响TVM的状态转换,这个特征是通过TVMM的强隔离属性来实现的。

2.2 可信VM(TVM)

TVM可以看作是一个运行敏感软件进程的容器,通常情况下,每一个TVM仅被装配了一个安全事务应用程序及极少数的操作系统内核组件及用户空间软件。这种方法大大增强了系统的安全性,因为攻击者利用系统弱点发生攻击的机率会随系统复杂度的增加而增加。另一方面,为了确保TVM的状态转换不会影响到TVM的可信性,必须配置运行在TVM中的操作系统只能达到某些完全可信的状态,因此,必须配置TVM的操作系统禁止执行其它的软件组件,包括内核模块或用户应用程序。这种方法是可行的,因为TVM仅由一些特定目的的特定应用程序组成,而不需要执行其它的软件组件。

每当创建一个新的TVM时,vTCM管理器需要为其创建并初始化一个vTCM实例,初始化过程是将底层硬件TCM的PCRs[0-15]的值依次填充到vTCM实例的PCRs[0-15],并且将该TVM镜象的度量值填充到对应vTCM的PCR[16]中。TVM产生到TVM应用的流程如下:

VM管理器启动一个新的TVM→从安全存储加密该TVM映像→度量引擎度量该TVM映像→ vTCM管理器创建一个vTCM实例对其进行初始化后指派给此TVM→vTCM管理器创建一个vAIK证书→请求使用此TVM的远程实体证明此TVM的身份可信性及状态完整性→使用此TVM。

2.3 VM的证明

为了使TVM可以向远程实体报告其完整性,需要将信任置于其使用的系统配置中,因此,需要使用远程证明技术。在Sec_TV安全体系结构中,证明服务是置于TVM内的,与文献9中将证明服务置于安全内核(管理VM)中的方法相比,它具有两种优势:

(1) 可以降低TCB的复杂度 因为此时安全内核仅结合了完整性报告的唯一组件,比如度量引擎。

(2) 可以支持满足不同安全目标的多种不同证明方法的实现 这对于分布式环境下证明平台身份及状态是非常有用的。

VM的证明是本文所要关注的重点。

3 Sec_TV的远程证明协议设计

图2给出了Sec_TV虚拟机远程证明协议的一个简图,严格来讲,我们可以将这个证明过程划分为两个阶段,一是vTCM的初始化阶段,另外一个就是虚拟机的证明阶段。初始化阶段包括AIK证书的产生及vTCM和TCM之间的绑定。证明阶段是由置于证明实体内的证明服务触发完成的,用于证明TVM状态的可信性。

3.1 Sec_TV虚拟机远程证明协议初始化阶段

3.1.1 AIK证书的产生

AIK证书是通过收集与客户方平台有关的信息并且发送给可信第三方,称之为隐私CA(PCA),由这个可信第三方来创建的,客户方平台从PCA处获取AIK证书的一般过程如图3所示。

客户方平台首先收集与AIK证书相关的信息,并使用公开的PCA密钥加密证书创建请求,发送给PCA,PCA接收到客户方平台传输过来的数据之后,首先使用其私有PCA密钥对数据进行解密,然后再验证EK证书、平台证书以及一致性证书的有效性,若验证通过,则创建AIK证书,并且使用客户方平台的AIK公钥对其进行加密并发送回客户方。

3.1.2 vTCM-TCM的绑定

为了能够准确地向远程实体报告TVM的平台配置情况,vTCM管理器必须提供一种机制实现vTCM和底层硬件TCM之间的绑定,否则的话,TVM很可能会向远程实体报告一个不能反映底层硬件TCM度量结果的度量值列表。

vTCM-TCM的绑定主要考虑的是密钥的产生和管理,因为密钥是制定算法、存储以及整个系统安全的主要实体,在vTCM内产生的密钥并不会像硬件TCM中产生的密钥那样安全,所以我们可以考虑使用硬件TCM密钥来封装vTCM的密钥,这样不仅可以增强vTCM密钥的安全性,而且还可以增强vTCM-TCM的绑定力度。目前有多种不同的方法可以实现vTCM和TCM之间的绑定(文献[15]),作者在认真考虑之后,决定对第三种方法稍做修改:vTCM的密钥由vTCM本身产生,但是使用硬件TCM的相应密钥对其进行封装,比如使用硬件TCM的AIK封装vTCM的AIK,即连接每一个vAIK到硬件AIK以实现vTCM-TCM的绑定,如图2中的“vTCM-TCM绑定”部分所示,其具体流程如下:

(1) vTCM创建一个vAIK,并且向vTCM管理器发起vTCM-TCM绑定请求(nonce);

(2) vTCM管理器将请求以及vTCM的vAIK转发给TCM;

(3) TCM创建其自身的AIK,并且通过一个隐私CA(也可以通过DAA系统)获取一个对应的AIK证书;

(4) 主机TCM使用其自身的AIK对vTCM所提供的nonce、TCM的PCRs[0-15]的值进行签名,并随AIK证书一起发送给vTCM管理器;

(5) vTCM管理器创建vAIK证书,并使用vEK进行加密传输给vTCM实例。

至此,完成了vTCM-TCM的绑定,也为远程证明创建了可以证实平台配置可信性的vAIK证书。

3.2 Sec_TV远程证明阶段协议设计

证明阶段的主要任务是由置于证明实体内的证明服务来触发完成的。证明服务接受来自远程挑战方的证明请求之后,首先需要在远程挑战方与证明实体(待证明VM)之间建立一条安全可靠的证明通道,如第1节所述,这是确保远程证明有效实施的基本条件。然后由证明服务收集可以证实证明实体身份及完整性的相关信息,发送给挑战方。最后由挑战方根据度量日志中的事件序列重新计算度量值后,与传输过来的vPCRs值进行比较,若一致,则认为证明实体的完整性没有被破坏,证实实体是可信的,否则认为证明实体是不可信的。

下面是结合安全通道的平台远程证明协议:

协议描述:证明实体响应挑战者的证明挑战,建立一条安全可信的证明通道,并协商保证此通道上传输信息安全性和完整性所使用的密钥。

协议实体元素及符号:A表示挑战者,B表示证明实体,KAB表示A与B之间协商的密钥。

(1) 协议消息序列

A→B : nonce, ga mod p,g,p (1)

A←B : Cert(vAIK, KvAIK ),{nonce, vPCRs, gb mod p}K-1vAIK (2)

A←B : {nonce, gb mod p}K-1B (3)

A→B : {finished}KAB (4)

A←B : {finished}KAB (5)

A←B : {nonce, SML}KAB (6)

A→B : {trust/distrust}KAB (7)

(2) 协议描述

(a) A使用一个160bit的nonce向B发起证明挑战,并且选择一个恰当的素数p及产生器g,g∈ℤ*p,2≤g≤p-2,并选择一个随机数a,计算ga mod p,将结果与p,g一起随nonce发送给B。

(b) B选择一个随机数b,2≤b≤p-2,计算gb mod p,并且使用vAIK签名所请求的vPCRs值及A发送过来的nonce,并将其与vAIK证书一起作为证明响应发送给A。

(c) 为了提供用户认证,B使用一个用户特定的密钥K${}_{\text{B}}^{-1}$对除vPCRs之外的所有信息进行签名,并且将此签名值一并发送给A,同时,计算与A之间的协商密钥KAB=(ga)b mod p。

(d) A接收到B发送过来的消息之后,计算协商密钥KAB=(gb)a mod p,并且发送一个finished消息给B。

(e) B接收到A发送过来的finished消息之后,使用协商密钥将nonce和SML一起发送给A,同时也发送一个finished消息给A。

(f) A接收到证明响应之后,执行下面的步骤:

• 首先检查vEK、一致性证书以及平台证书以验证vAIK证书是否属于vTCM。

• 从vAIK证书中提取出vAIK密钥,对接收到的数据进行解密,读取物理TCM的AIK证书、vPCRs值以及nonce。

• 将读取的nonce值与挑战请求中的nonce值比较,以验证证明消息的新鲜性。

• 确定AIK证书来自一个真实的TCM。

• 检查vPCRs的有效性。根据SML的信息重新计算哈希值,并将其与PCR值做比较,如果一致,且上面的步骤都是成功的,那么这个系统将被认为是可信的。否则的话,则认为平台不可信。

(g) A回应信任/不信任B的平台配置。

4 安全评估

4.1 Sec_TV的安全评估

首先需要说明的是,本文针对“如何在开放式环境下建立信任关系”提出了一种新的安全体系架构Sec_TV,该架构本身的安全性,笔者在另外一篇文章中给出了详细论述[10]。本节主要是从如何解决传统模式下应用证明技术建立信任关系所面临的问题来对Sec_TV进行评估。

Sec_TV结合虚拟化和证明技术来建立信任关系,这种方式相比较于传统方式应用证明技术具有两种明显的优势:

(1) 可以简化证明技术实施的复杂性

传统方式下的证明技术需要证明包括运行在机器上的所有进程在内的整个平台配置的可信性,而在Sec_TV架构下,则只需对那些要求是可信操作的进程(通过为其创建单独的可信虚拟机)进行证明,那些不负责与远程实体进行通信,也不要求处理机密数据的进程,可以不包含在完整性度量列表之内(通常将这些进程放到普通虚拟机内),在这种情况下,完整性度量和报告仅包含了那些对整个事务处理有重要影响的敏感进程,而排除了诸如e-mail、多媒体之类的一般应用程序,因此简化了证明的复杂性。

(2) 在一定程度上解决了实施证明技术所面临的隐私泄露问题

传统方式下的证明技术是将完整的度量日志发送给证明方以便让证明方验证整个平台配置的完整性。攻击者简单分析获取到的响应信息,就可以包含所有运行着的进程在内的整个平台的配置信息,进而引发隐私泄露的问题。Sec_TV则简化了用于描述平台配置信任级别的信息数量,验证者只能获取整个平台配置的一个子集,而不能获取包括所有运行着的进程在内的整个平台配置的所有信息,因此在一定程度上解决了传统的证明技术所面临的隐私泄露问题。

4.2 证明协议的安全评估

根据攻击者在远程证明协议的位置,可以将远程证明协议所面临的攻击粗略的划分为三大类[11]:

(1) 网络入侵者的攻击,主要是通过截取、篡改、重放等攻击手段在网络中对远程证明展开攻击。主要方式有:中间人攻击、伪装攻击、平台配置窃听等。

(2) 平台内部攻击者的攻击,主要是通过攻击完整性度量架构以及TPM硬件实施的攻击。主要方式有: TOCTOU攻击、恶意修改度量引擎、TPM硬件攻击等。

(3) 验证方平台的攻击,主要是通过分析证明数据得到证明平台的身份、配置信息,从而破坏远程证明的隐私性。主要方式有:平台配置隐私泄露等。

其中,在证明架构设计过程中,充分考虑下面的条件,可以规避第2种和第3种类型的攻击:

① 平台的CRTM(BIOS)和CPU是可信的;

② TCM的设计及应用遵循TCG规范;

③ 完整性度量引擎不存在bug。

因此,在证明协议的执行过程中,攻击者参考平台证明过程进行攻击的一般目标就是在通信过程中试图重放一个不新鲜的平台配置,以便将一个不可信的平台配置伪装成可信的来实施的。在Sec_TV架构下的证明协议,首先在远程挑战方与证明实体(待证明VM)之间建立了一条安全可靠的证明通道,该协议使用了一个密钥建立阶段扩展了原有的远程证明协议以确保这条证明通道是真实的,如第1节所述,这是确保远程证明有效实施的基本条件,接下来的所有消息都是使用双方协商的会话密钥KAB进行封装过的,对于攻击者来说,不要执行某种类型的中间人攻击并且在远程挑战方和验证实体之间建立两条不同的加密会话是不可能的,这是因为攻击者不可能修改证明实体B的证明响应。另一方面,会话密钥KAB是由可信操作系统保护的(比如存储此密钥到安全内核的一个特定区域或者是存储到一个特定的虚拟机中),因此,在正常的运行条件下是不可能提取此密钥的,而改变可信操作系统环境提取此密钥则会在证明阶段被检测到。因此可以说Sec_TV证明协议通过一条安全可靠的证明通道保证了在Sec_TV架构下实施的远程证明协议涉及的消息内容的真实可靠性,进而保证了远程证明结果的真实可靠性。

5 结 语

本文首先给出了在开放环境下使用远程证明建立信任关系需要解决的问题,接着,结合虚拟化和可信计算技术,提出了一种适用于分布式环境的安全体系架构Sec_TV,阐述了在此安全体系架构下如何建立多个具有不同信任级别的、相互隔离的执行环境来增强分布式环境的安全性及可信性,第三,给出了Sec_TV下的远程证明协议设计,最后,从Sec_TV体系结构及远程证明协议两个方面讨论了这个远程证明体系架构的安全性。

摘要：虚拟化技术和证明技术相互依赖,只有两者相互结合,才能为安全系统奠定坚实的基础。首先给出在开放环境下使用证明技术建立信任关系需要解决的问题,然后提出一种支持远程证明的安全体系架构SecTV,讨论该架构如何结合虚拟化和证明技术来增强系统的安全性,并给出SecTV下远程证明协议设计,最后,从SecTV体系架构本身及SecTV远程证明协议两个方面讨论这个远程证明体系架构的安全性。

关键词：可信计算,虚拟化,远程证明,TCM,vTCM

参考文献

[1]http://www.trustedcomputing.com/.

[2]Stumpf F,Tafreschi O,Roder P,et al.A Robust Integrity Reporting Pro-tocol for Remote Attestation[C]//Second Workshop on Advances in Trusted Computing(WATC'06Fall),Tokyo,Japan,November2006.

[3]Sailer R,Zhang Xiaolan,Jaeger T,et al.Design and Implementation of a TCG-Based Integrity measurement architecture[R].IBM Research Report.

[4]Jaeger T,Sailer R,Shankar U.PRIMA:Policy-Reduced Integrity Meas-urement Architecture[C]//SACMAT'06:Proceedings of the eleventh ACM symposium on Access control models and technologies,New York,NY,USA,2006:19-28.

[5]Chen Liqun,Landfermann R,Rohe M,et al.A protocol for property-based attestation[C]//STC’06:Proceedings of the first ACM workshop on Scable trusted computing,2006:7-16.

[6]Haldar V,Chandra D,Franz M.Semantic Remote Attestation:A Virtual Machine Directed Approach to Trusted Computing[C]//USENIX Vir-tual Machine Research and Technology Symposium,2004.

[7]Madnick S E,Donovan J J.Application and Analysis of the Virtual Ma-chine Approach to Information System Security and Isolation[C]//Pro-ceedings of the Workshop on Virtual Computer Systems,New York,NY,USA,1973:210-224.

[8]Garnkel T,Pfa B,Chow J,et al.Terra:A Virtual Machine-Based Plat-form for Trusted Computing[C]//SOSP'03:Proceedings of the nine-teenth ACM symposium on Operating Systems Principles,New York,NY,USA,2003:193-206.

[9]Jansen B,Ramasamy H,Schunter M.Flexible Integrity Protection and Verication Architecture for Virtual Machine Monitors[C]//Second Workshop on Advances in Trusted Computing,2006.

[10]于颖超,刘了.一种结合可信计算和虚拟化技术的安全平台架构设计[J].高性能计算技术,2011(4).

开放系统架构 篇9

1 物联网的关键技术

物联网的关键技术主要包含了智能网关技术、统一编码技术、IPv6 技术等, 如何实现开放式全局范围内的物与物互联, 重点需要解决的是统一编码、传感网络路由 (智能网关) 等关键技术。开放式物联网的应用, 必将是架构在internet网络基础之上, 数据包封装在TCP/IP协议之内, 那么如何实现物联网数据包的智能传递, 从任意的internet网络终端, 通过通用的物联网终端识别设备, 读取物品的RFID芯片信息, 标识的信息能在网络上找到对应的信息服务器, 反馈回物品的详细记录数据。只有解决了开放式物联网的体系架构和应用技术, 物联网的应用才能真正实现普及应用。

1.1 物联网的层次结构

物联网层次结构通常可分为三层:感知层、网络层和应用层。

(1) 感知层由传感器和传感网关构成, 各种传感器包括常规的一些温度传感器、湿度传感器、光感传感器、声音传感器、烟雾传感器、化学传感器、红外传感器、二维码标签、RFID标签和读写器、GPS等感知终端。感知层的作用它是物联网识别物体, 采集信息, 并且将信息传递给智能网关, 由网络层传递给应用层进行处理。

(2) 网络层可以是由各种类型网络, 包含专有网络、光纤网络、有线和无线通信网、网络管理平台等组成, 其核心是Internet网, 网络层相当于人的神经中枢, 负责传递和处理感知层获取的传感信息。

(3) 应用层是物联网和用户的应用接口, 它与行业应用相结合, 实现物联网具体的智能化应用。

1.2 物联网的编码技术

目前, 国际上还没有统一的RFID编码规则, 我国的RFID标准还未形成。现有的欧美支持的EPC (Electronic Product Code, 电子产品码) 标准和日本支持的UID (Universal Identification, 泛在识别) 标准是当今影响力最大的两大标准。EPC编码有通用标识 (GID) , 也有基于现有全球唯一的编码体系EAN/UCC的标识。

物联网上的任何信息的流动, 都需要给物体做一个唯一的识别码 (身份标识) , 包含物体的一些具体身份信息与内容, 同时这个识别码能够在网络上被传送和识别, 如何有效地把物体的RFID编码与最新的IPv6 编码相结合, 是物联网技术与INTERNET有机集合的关键, 也是物联网广泛应用和技术突破的瓶颈。

1.3 ONS的架构层次化机理设计

ONS是将一个EPC映射到一个或多个URI服务器地址服务, 通过这些服务器地址可以查找到在EPCIS (或web) 服务器上关于此产品的其它详细信息记录。ONS存有制造商产品服务器位置的记录, 而DNS则是到达EPCIS服务器位置的记录, 其工作原理与网络技术的DNS一致。ONS系统的层次和DNS的层次结构都是分布式的, 主要由根ONS、ONS服务器、本地ONS、本地ONS缓存 (Cache) 及映射信息组成。根ONS服务器是ONS层次中的最高层, 它拥有EPC名字空间的最高层次域名。ONS本地缓存则是保存经常、最近查询的URI。而映射信息则是ONS系统所提供服务的实际内容, 它指定了EPC编码与其相关的URI的映射关系, 并且分布存储在不同层次的各个ONS服务器记录中。如图1所示。

1.4 EPC信息服务 (EPCIS)

EPCIS用PML为系统的描述语言, 包括了客户端模块、数据存储模块及数据查询模块三个部分组成。客户端模块主要实现物联网EPC标签信息向指定EPCIS服务器传输终端;数据存储模块将通用数据存储于服务器的数据库中, 在产品信息初始化的过程中调用通用数据生成针对每一个产品的原子信息, 并将其存储于PML数据库中;数据查询模块根据客户端的权限和查询要求, 访问相应的PML数据及信息, 返回给客户端。如图2 所示。

1.5 物联网RFID及组网技术研究

RFID:射频识别技术 (Radio Frequency Identification, 简称RFID) 是物联网发展的关键与起源。RFID是20 世纪90 年代开始兴起的一种自动识别技术, 是目前比较先进的一种非完全接触识别技术。在“物联网”体系的构想中, RFID标签中存储着规则的且具有交互作用的信息, 通过传感网络把它们自动采集到信息服务器上, 实现物品 ( 商品) 的识别和信息的中间处理, 进而通过开放性的计算机网络实现信息交互和处理, 从而实现对物品的“透明”管理。

Zigbee:Zigbee是IEEE 802.15.4 协议的代名词。根据这个协议规定的技术是一种短距离、低功耗的无线网络通信技术。其包含了距离近、复杂度低、具备自组织性、功耗低、数据传输速率也低、成本低等特性。主要适合于远程自动控制领域, 可以嵌入到各种电子设备中。简而言之, Zig Bee就是一种便宜的, 低功耗的近距离无线通讯组网技术。

WSN:无线传感网络 (WSN) 是由大量传感器节点通过无线通信方式形成的一个多跳的自组织系统, 其目的是传感器节点之间协助地感知、采集和处理网络覆盖区域中传感器节点的信息, 它能够实现数据的采集、网络融合和传输应用。

2 开放式物联网体系架构设计与分析

现行物联网的应用都集中于单体的应用, 其应用的特点是闭环于一个具体的应用, 因为的服务器IP地址都是固定的, 在客户端没有安装其客户端软件的情况下是无法访问其服务器端平台, 而要实现物联网的通用开放, 必须实现通用的射频识别和通用化的网络支持, 其原理架构图如图3 所示。

物联网要得到广泛的普及化应用, 必将是架构在internet网络基础之上, 数据包封装在TCP/IP协议之内, 那么如何实现物联网数据包的智能传递, 从任意的internet网络终端, 通过通用的物联网终端识别设备, 读取物品的RFID芯片信息, 标识的信息能通过本地ONS、大类ONS、行业ONS服务器, 最后检索到物品生产厂家的产品服务器的地址, 把物品的标识信息发给厂家的产品信息服务器, 由服务器给智能网关和终端提供物品的详细信息。只有解决了物联网的体系架构和关键技术, 物联网的应用才能真正实现普及广泛应用。如图4 所示。

3 结束语

物联网是一个新兴产业, 其技术的应用也是多个学科技术的集成, 包含了传感技术、通信网络技术、软件技术等多个学科的技术内容。而现阶段的物联网的应用, 还处于局部单体的应用, 还没有形成一个开放的统一的物联网架构体系及技术标准, 本文在研究物联网的现有架构及关键技术的基础上, 提出一个整体的开放式的物联网体系架构模型, 以适应物联网与INTERNET网络的无缝结合, 为物联网的广泛应用提供架构标准, 推动物联网的普及与应用。

参考文献

[1]李甲, 吴一戎.基于物联网的数字社区构建方案[J].计算机工程, 2011, 33 (7) :263-265.

[2]物联网智慧农业实验室建设解决方案[Z].http://www.frotech.com/index.php/Program/detail/id/24.html, 2015.

[3]孔灵, 李晓东等.物联网资源寻址模型[J].软件学报, 2010, 21 (7) :1657-1666.

[4]物联网业务特征与业务模型研究[w].http://www.docin.com/p-462765721.html, 2014.

[5]黄映辉, 李冠宇.物联网:标志性特征与模型描述[J].计算机科学, 2011, 38 (10) :4-6.