推广 热搜: 电机  PLC  变频器  服务机器人  培训  变送器  危化品安全,爆炸  西门子PLC  触摸屏  阀门 

白话工控——剑思庭带你认识工控

   日期:2013-03-23     来源:工控之家网    作者:工控之家    浏览:27    评论:0    

        剑思庭,软件工程硕士,曾开发过各种厂商dcs和plc系统及智能仪表相对应的opcserver软件包;曾利用s7300/400系统开发过多个行业工艺控制系统;曾用SIMATIC IT技术为化工厂开发过MES管理系统和生产调度指挥系统;曾利用WINCC开发过在线设备管理系统;并获得过多项技术认证,例如Profibus总线认证、Controllogix产品认证等等。今天将用一些简单易懂的词语,带大家来认识工控,了解什么是现场总线,组态软件的构造,SFC的含义,冗余和热备的区别。

白话用户需求的重要性
 
    说到用户需求是什么呢,通俗地说就是自控项目中客户想要达到的效果和东西。而专业上来说,也就是客户对自控系统提出的自己的要求标准,这个要求标准根据自己的使用目的、工艺、用途等可以提出自己的要求。自控集成商依据客户的需求进行自控设计(或确认自己已经完成设计的项目能符合需方的要求)。   作为自控工程师在做项目之前这是过程是一定要洗礼的,弄清楚客户想要干什么和结果,是自控工程师首要任务。大家该说这还不简单!人家要什么我们就给人家编什么,其实不然不要小看了这个过程,十分重要,它是一个项目的龙头,如果它出了偏差后面设计和执行再正确也是枉然。在现实情况中我们会发现存在这样一种情况,那就是一个自控工程师在现场把在家里写的程序全部推翻在现场重新写了一份,实在让人感叹技术劳动力的脆弱。   其实很多自控项目虽说没有一个到了现场不改变的但是也绝不会出现全部重写的现象。这是为什么呢,其实这就是需求分析没有分析透彻,客户一般都是从事工艺设计和生产的,他们并不是直接了解自控的系统,即使说出来他所能知道同一个自控名词也有可能表达不同结果。同样名字不同的地域就会出现不同的结果,同理在自控项目中工艺认为的一个自控词语概念并非我们理解的概念,况且就是同一个专业还会出现不同的理解方式。   那需求该如何做呢?说简单很简单,说不简单也很难。你需要把客户的工艺思想挖掘出来,而变成自控行业能够理解的要求。按道理来说用户提出来的需求应该是系统的,也就是我们能够看懂的,但是往往这只是一种理想,要知道客户是我们的衣食父母,客户很多招标书都是由系统集成商来写的,所以现实情况很残酷。客户可能不能跟你说清楚他的需求,这个时候你就需要按照客户提供的只言片语,慢慢勾勒出来一个他想要的自控系统轮廓,经常会出现类似《开心辞典》一样情形,我们提出问题后列举四种方式或者情况,然后业主选择和他最接近的那一种。我个人理解一定要在需求阶段把用户的需求细化到极致,这样可以很方便躲避项目中技术难题(给不能实现或者不好实现的技术难题消灭在萌芽状态)和给验收和尾款带来顺利之门。在举个例子,用户在需求中会提出来要当工艺参数超限要声光报警,就是这么简单的一句话,这里边变化很大。工艺超限,大家都可以理解,就是PV大于或者小于了ALARM这个时候就要产生报警,但是声光报警的方式太多了,上位机可以发出报警声音、组态画面可以动态闪烁报警信息、控制机柜DO可以驱动报警器发出声音和LED灯的报警指示。这就牵扯到两种不同设计和实现方式,虽然不会牵扯太多的费用但是一旦采用了前者方式在改成后者,就需要硬件上有些变动,这都是大家(我们和业主)不愿意看到的。所以很有必要在用户需求的文件上附加上技术需求附件(双方签字有效的),这样可以让你在项目实施中不会处于来回变动当中。   以下我将share我在日常当中所用的部分用户需求文档模板供大家参考(这个模板是我做工程的时候保留下来其中一种),这里以SCADA系统为例。由于文字较多我只列出来文档目录和描述,如果大家需要详细模板可以向我来函索要!(QQ   :79867128 Email:jiansiting@gmail.com)
 
REVISION HISTORY 5
1.0   INTRODUCTION       6
1.1.  PURPOSE 6
1.2.  ORIGIN AND CONTEXT    6
1.3.  SCOPE      7
1.4.  DOCUMENT ORGANIZATION  8
2.0   OVERVIEW       9
2.1.  BACKGROUND          9
2.1.1.        Project Overview     9
2.1.2.        Facility Overview      10
2.1.3.        Automation Overview      12
2.2.  GENERAL SYSTEM FUNCTIONS        14
2.3.  SIMULATION SYSTEM      14
2.4.  EXCLUSIONS AND FUTURE CONSIDERATIONS         14
3.0   OPERATIONAL REQUIREMENTS      16
3.1.  FUNCTIONS      16
3.1.1.        Process Monitoring 16
3.1.2.        Alarm Management         17
3.1.3.        Basic Control   19
3.1.4.        Equipment Phase Control        23
3.1.5.        Batch Management         24
3.1.6.        Historical Data Collection and Retention        25
3.1.7.        Other Monitoring and Control Features 26
3.1.8.        Modes of Operation         26
3.1.9.        Performance and Timing 28
3.1.10.     Response to Failures        29
3.1.11.     Security    30
3.1.12.     Safety       30
3.2.  DATA         31
3.2.1.        Preliminary Data Definitions   31
3.2.2.        Capacity Requirements   32
3.2.3.        Access Speed   33
3.2.4.        Archive Requirements     34
3.2.5.        Data Security and Integrity     34
3.3.  USER INTERFACES   36
3.3.1.        General    36
3.3.2.        Process Monitoring 40
3.3.3.        Batch Management Interfaces       45
3.3.4.        Alarm Management Interfaces       46
3.3.5.        PCS Status Interface        48
3.3.6.        Programming and Configuration Interfaces   49
3.3.7.        Recipe Management Interface        49
3.3.8.        Reports    5049
3.4.  REMOTE PCS ACCESS       50
3.5.  INTERFACES WITH OTHER SYSTEMS        50
3.5.1.        Intelligent Process Interfaces 50
3.5.2.        Other Process Control Systems       5150
3.5.3.        Other Computerized Systems 5150
3.5.4.        Shared Resources    51
3.6.  ENVIRONMENT        51
3.6.1.        Layout      51
3.6.2.        Physical Conditions 5251
4.0   CONSTRAINTS 54
4.1.  PROJECT CONSTRAINTS  54
4.1.1.        Schedule  54
4.1.2.        Procedural Constraints   54
4.2.  COMPATIBILITY        55
4.2.1.        Hardware Standards and Preferences    55
4.2.2.        COTS Software Standards and Preferences    56
4.2.3.        PCS Configuration and Integration Standards         57
4.2.4.        PCS User Interface Standards 58
4.2.5.        PCS Programming Standards  59
4.3.  MAINTENANCE        60
5.0   LIFE-CYCLE       60
5.1.  DEVELOPMENT        60
5.2.  TESTING  60
5.3.  DELIVERY         60
5.3.1.        Documentation        60
5.4.  SUPPORT 62
5.4.1.        Start-up Support (list available options)  62
5.4.2.        Post Start-up Support (list post-startup support available)    62
6.0   GLOSSARY        63
6.1.  TERMINOLOGY        63
6.2.  ACRONYMS      65

白话冗余和热备的区别

  冗余其实是一个很宽泛的技术概念,而不是大家理解中的技术方法,冗余原始概念是重复配置系统的一些部件,当系统发生故障时,冗余配置的部件介入并承担故障部件的工作,由此减少系统的故障时间。冗余按类型分为主动和被动形式,所谓主动和被动主要是主从切换的能动性上来分析,主动冗余是可以主动切换,就是可以随时自行切换;被动冗余是指当正在运行的组件坏掉或者不正常的时候才会切换到备用组件,其中也包括用户手动或者用户程序切换方式,按照功能来分又分成Hot standby、Warm standby 和 Cold standby,整理以后见下图:


1、Cold standby
  冷备用,其实说白了就是backup,他是通过备份所有正常运行的组件放在一旁或者仓库里,等运行的组件坏了以后更换新的组件来完成系统的正常运行,这个冗余时间和更换时间息息相关。这种冷备用方式很少去关注响应时间,并且需要运维人员干预操作。举个例子,一套PLC运行系统,在做备件时做了完全的配置备件,当PLC在运行时因为夜晚雷电发现有一块AI卡件烧毁了,运维人员马上把系统断电,然后更换卡件,在上电运行,这就是一个完整的cold standby的过程,至于其中耽误的时间,只能视运维人员的对系统的熟练程度而定并且必须被动接受。 

2、Warm standby

  温备用,是两套完全一样的配置组件,一个正常运行被视为主,另一个带机并不运行备用被视为从,每隔一段时间,主从的内容相互交换一次,当运行组件出现故障,备用组件才会运行承担工作。举个例子,西门子的300软冗余系统,两台微处理器的冗余方式就是温备,主处理器控制系统的输入和输出(I / O),而备用处理器上电和主处理器停止控制过程中的等待时间。当发生这种情况,备用处理器承担的I / O控制,并采取指定的主处理器,处理器允许脱机成为次要处理器,并可以在不牺牲过程控制维护。

   在正常操作中,主处理器提供定期更新的备用处理器。这些更新通常发生在每个程序扫描结束,并可能在任何时间只涉及了部分数据。因此,当转换发生时,备用处理器可以工作过的数据不完整,因为它可能会采取一些备用处理器程序扫描追上来这里的主要是前转换。这可能有助于在转换过程中颠簸。

   从硬件的角度来看,温,热冗余系统几乎相同,所以很容易混淆。


 
3、Hot standby

  热备用,是两套完全一样的组件,全部都是上电并运行的状态,两个组件同时进行数据采集、数据处理和计算,只是主组件担任输出控制任务,两个组件实时交互,当主从切换的时候必须完成无扰动切换。而且热备组件系统是随时切换同时检测组件状态并报告。


 

   热备系统即使在一瞬间也不能让系统go down,当主从切换的时候,需要完成系统通讯消息和数据更新以及堆栈的同步,从而苛刻实现程序执行的速度和堆栈段内容都是一致的,为了确保热备系统的操作正确性,全部数据需要实时主从交互,其交互方法有两种,第一种就是常规的扫描和传输方法,这种技术早期被施耐德的PLC广泛使用,首先先是在程序扫描结束后传输所改变的内容,首先程序扫描时间是程序执行和传输的时间组合,这也就是PLC的执行周期为什么有时间周期定义之说了,这样就不是每次把PLC内全部程序进行交互,减少同步任务复合,但当从plc内没有程序的时候,主plc会把全部内容同步过去,但这个过程只是上电或者首次运行时候做一次比较。这种热备方式是一种经典和准确的热备方法,并且这种方法延续至今。

   第二种方法就是异步传输方法,在异步传输,主系统中在其电路有两个独立的微处理器。第一个微处理器执行程序。在执行结束,所有数据被传递给第二个微处理器。这第二个微处理器处理所有的传输任务,而第一个微处理器执行下一个程序扫描。因此,一个微处理器是执行,而另一种是传输到备用处理器的数据。 由于这种从主处理器辅助处理器的数据传输是异步的程序扫描,它随时的数据传输,而不会影响程序执行和系统负荷。这种热备异步传输的方式是AB的Contrologix一项技术,他的冗余配置中主从系统各有三个CPU,第一个就是执行程序的CPU,第二个就是起到数据总线的背板CPU,第三个就是同步模块RM的CPU,所以他的任务被分配在多个CPU当中。

   最后还是要说一下,其实大家理解中的冗余技术其实就是热备的方法,因为传统DCS进入大家视野比较早,DCS厂家把冗余概念做到了极致,它把两套物理硬件在逻辑上封装成为一个独立体,所以造成很多技术人员认为只有物理上两个组件但在逻辑上是一个组件被称为冗余,逻辑上是两个组件的叫做热备。
白话SFC 

SFC的历史

  SFC是一个英文字母的缩写,它的英文全称是Sequential Function Chart,中文名字叫做顺序功能流程图。SFC的历史来源于传统的DCS系统,当年HONEYWELL的TDC2000和横河的uXL都提供各自顺序控制工具,TDC2000使用CL语言一种类似Basic语言的方式来完成顺序控制而uXL使用顺控表以一种填表方式来完成。时至近代随着混合型DCS的走入自控时代,大型PLC厂商和DCS厂商都纷纷提供了基于windows平台使用SFC工具。并且SFC进入了工业控制编程语言形成了国际化标准,这就是IEC61131-3的标准。

SFC的构成

  SFC主要是一种可视化并且支持拖拽形式的组态方式,它的主要构成包括四部分,分别是步(STEP)、转换(Transition)、行为(Action)、锁(interlock)的功能。

SFC的白话

  SFC的这种语言编程形式对于没有接触过的人来说可能有点抽象,还是延续我以前一贯的叙述方式,SFC的执行更类似炒菜一个过程。

步骤(STEP)就是像是炒菜中的每一个步骤
过渡(Transition)就像是炒菜中每个步骤的前提条件
行为(Action)就像是炒菜中的每个动作
锁(interlock)就像是炒菜中事故的掌控

  炒菜开始,首先进入准备步骤,然后产生切菜和切葱姜行为,然后进入一个条件判断,这个条件是判断菜切好了吗?葱姜切好了吗?如果切好了就进入点火步骤,如果没有切好就一直等待。进入点火步骤以后就进行点火和放油行为并且启动一个延时,然后等待这个延时然后判断火是不是点着了?油有没有放进去,判断油温符合要求吗?如果这仨个条件都符合就进入炒菜步骤,如果不符合就一直等到延时超时启动赶紧中断炒菜这个过程(锁的功能)可能出现煤气灶点不着火或者油有问题。进入炒菜这个步骤之后,就要产生把葱姜和菜还有盐和味精放入锅内进行搅拌这些行为,并且启动一个计时,然后进入判断等待这个计时是否到时条件,如果计时到时就进入出锅这个步骤,如果没有到时就继续等待。进入出锅步骤以后就产生了把炒好的菜放到碟子里这个行为,然后又一次产生一个循环继续炒下一个菜。在这个炒菜过程中一直监控燃气灶火是否正常,油温是否过高,菜的火候是否过老,一旦发生上述条件任何一个出现问题,就进入关火端锅下灶(锁程序)。

SFC的IEC描述

  经过上述描述我想大概有了一些思路上的理解了,那么下面我就用IEC61131-3语言在描述一遍。
步(STEP)用矩形框表示,描述了被控系统的每一特殊状态。SFC中的每一步的名字应当是唯一的并且应当在SFC中仅仅出现一次。一个步可以是激活的,也可以是休止的,只有当步处于激活状态时,与之相应的动作才会被执行,至于一个步是否处于激活状态,则取决于上一步及过渡。

  过渡(Transition)表示从一个步到另一个步的转化,这种转化并非任意的,只有当满足一定的转换条件时,转化才能发生。转换条件可以用ST、LD或FBD来描述。转换定义可以用ST、IL、LD或FBD来描述。过渡用一条横线表示,可以对过渡进行编号。

  动作(action)每一步是用一个或多个动作(action)来描述的。动作包含了在步被执行时应当发生的一些行为的描述,动作用一个附加在步上的矩形框来表示。每一动作可以用IEC的任一语言如ST、FBD、LD或IL来编写。每一动作有一个限定(Qulifier),用来确定动作什么时候执行;标准还定义了一系列限定器(Qulifier),精确地定义了一个特定与步相关的动作什么时候执行。

  锁(interlock)表示通过ST、FBD、LD或IL列举一系列用户判断条件,来监控整体SFC的执行,一旦用户条件满足,SFC就中断执行进入一种HOLD保持状态,等待用户处理SFC执行的状态。
白话组态软件

  最近碰上了一个沈鼓的自控调试技术人员,我们在路上攀谈起来。他向我问起监控组态软件到底是什么,到底里边有什么?当时我也是一愣,很少有人会问起组态软件是什么并且有什么,因为这个圈子里这些问题应该入门知识,但是经过了解才发现很多从事机械自动化或者工厂自动化还真不了解组态软件到底有什么由什么组成,他们往往偏门于PLC、变频、伺服等,最多也就是接触最简单的HMI。
 
  下面我来讲一下监控组态软件,首先声明我不算是这方面的专家,也只是略知一二。监控组态软件主要是以下几方面组成。

1、实时数据库

  实时数据库,顾名思义就是一种处理和存储实时数据的数据库,它分为两种构成模式,第一种就是利用开发工具直接开发二进制文件模式,自己开发sql引擎,建立索引以及配置文件等机制,例如IFIX;另外一种就是依托于成熟的关系数据库,把实时数据放在二进制文件中但sql引擎,索引,以及配置文件都利用关系数据库等机制,例如WINCC。

2、内核通讯

  说起内核通讯一般谈及组态软件很少涉及,因为它是一种根本看不见摸不着但具有决定组态软件的构架。市面上比较流行就是两种通讯框架,一种是与实时数据库通讯为核心框架,图形界面、脚本、通讯驱动等都是围绕实时数据库来完成相应功能,另一种就是消息通讯为核心框架的,这种框架就是类似SOA构架,首先建立通信数据元素,把所有用于访问的数据格式包含在其中,然后通过消息发布出去,是那个组件接受那个组件完成相应的指令,消息通讯在今天的组态软件行业里也分为内存消息型和端口消息型,内存消息性就是利用MFC的在内存中消息来同志别的组件,其优点就是快速和稳定缺点就是所有组件不能脱离一台机器,这也是国内很多组态软件厂商最初的手法,而端口消息型,就是利用sock的端口进行消息通讯,不管是不是在本机一概采用端口通讯,这样的优点就是把可以把很多组件分布到每台机器上,其中CS和BS构架就用利用这种机制,缺点就是消息元素复杂,指令繁多,需要谨慎考虑其健壮性。

3、图形界面

  图形界面其实没有什么好说,就是图形显示,图形绘制、报警、曲线,报表等,但是从市面上来说它们分为基于VC6中MFC开发的和.net fm开发的,从界面来说mfc开发的速度快,稳定性高,但界面简单,画质不是很绚丽,.net开发的界面绚丽,3d动感性强再结合GDI+,那就是界面中利器,而他的确定就是运行速度慢,另外对于安装机器的配置要求较高。

4、脚本

  脚本算是组态软件中的灵魂,多数组态软件一看脚本就可以分辨出来高中底端产品,脚本分为编译型和解释性,编译型需要在组态软件没有运行之前,就把语句编译一边,然后嵌套在框架的函数和事件中,例如WINCC的C脚本,另外一种就是解释型,它是在组态软件运行之中被语法解释器边解释边运行,例如IFIX的VBA脚本。对于市面上可以看到脚本分为自定义、VB类、C类和其他类,自定义脚本例如intouch、组态王、力控;VB类例如IFIX的VBA、RSVIEW的VBA、杰控的VBS;C类例如WINCC的ASCI c、九易思的C#;其他有一些组态软件利用开源的脚本引擎例如TCL LUA等。底端脚本多数是采用自定义脚本,它的可扩展性很有限而且依赖于厂商自己的开发能力,中端脚本就是采用c脚本和开源脚本,它的成熟技术应该很广当时不方便普及和掌握,对于一些常用访问技巧,例如访问关系数据库,API以及DLL和控件不是很方便,而高端脚本则首推VBA系列,高效的访问工具、成熟的控件资源以及强大的API调用。
 
5、通讯驱动

  通讯驱动则相应发展比较缓慢,这也是因为它实在是太成熟了,先说说它的框架结构都是采用封装通讯框架和开发数据流方式结合,也就是说开发人员不需要懂得组态软件的框架结构以及如何把数据对应数据库变量,只需要安装给出的框架,把数据流拆包解包和打包放入指定的结构缓冲区内就可以了。再说说驱动,一提到驱动它应该是两部分组成第一部分就是接口另外一部分就是协议,先说第一部分接口对于组态软件的生存平台PC来说,接口其实就是RS232/485/422,USB,TCP/IP(wifi)和板卡这几个种类,而对于另一部分的协议来说,那就太多了我就简单些介绍几种modbus rtu/asci/tcp,profibus,opc,s7等太多了,因为设备厂商的增多就以为协议的增多。

6、接口开发工具

  接口开发工具其实就是组件开发工具,它是一种开发工具包,是寄宿在组态软件本身开发工具(vc/VS。net)上的一个框架向导,利用这些框架或者向导可以通过开发工具开发出来基于组态软件的扩展组件,方便组态软件的功能扩展和客户订制,例如关系数据库和实时数据库的导入导出的组件等,另外也可以开发局基于图形界面的图形组件。

7、WEB发布

  WEB发布算是一种近年来十分流行的一个组态软件功能,因为SCADA市场和MES市场的扩大,使得厂级化管理越来越流行,也成为组态软件厂商热炒概念中的一部分,因为web的使用,可以让用户利用普通PC的IE浏览器就可以看到组态软件的图形界面和实时数据而让大多数的业主得到认同。web的发布技术基本上是三种方式,第一种activeX方式,一般这种WEB方式多数组态软件是采用vc6开发的,它直接封装一个图形浏览exe在com组件中,当用户ie浏览的时候会提示安装一个插件,然后这个exe就安装在客户pc上,通过IE调用exe,用就可以看到组态界面,这种也就是被称为准WEB方式它的优点就是速度快因为它使用cs模式缺点就是必须开用户指定端口一旦遇到路由器就不能看到,另外一种就是通过java方式,就是把用户组态的工程通过java重新转换一边,这种技术的优点就是无论你使用什么网络设备管理网络只要能开发80端口就可以看到数据,缺点数据刷新较慢但是可以接受的那种另外就是它需要重新编写一边组态软件比较耗时,然后发布出去。最后一种就是.net的web service技术,毋庸置疑他当然是最强大的,但是你的框架开发工具就必须使用.net。
白话现场总线 

    说起现场总线,这项技术不能说是这两年自控领域讨论最广的话题,但也能算得上自控厂商相互角逐争夺市场一项技术。从siemens早在10年前全球推广的profibus到近年来profinet,再到emerson推广的FF以及rockwell的推广的devicenet和ethernet/ip,其实自动化厂商心里很清楚,谁掌握了现场总线,谁就掌握了标准,谁掌握了标准,谁就掌握了市场谁就是技术领头羊。那现场总线到底是什么,对于自动化技术人员又能带来什么呢?
 
  现场总线,主要是由物理通讯形式+通讯协议+网络调度机制这三部分组成。    物理通讯形式,我想大家理解起来不会很难,其实就是RS485、RS232、RS422、TCP/IP这几种物理通讯形式。将来可能会出现无线,但是现在无线技术的通讯稳定性和行业和国家还没有形成一些规范,所以未来几年也不会大量使用无线作为现场总线。
 
  通讯协议,通讯协议对于自控人来说并不陌生,但是很少有人深刻理解和掌握,现场总线的协议,主要是每个现场总线站点需要通讯数据以何种形式通过通讯形式传输。    网络调度机制,大家可能觉得通讯协议和网络调度机制是不是一回事,其实他并不是一回事,这是现场通讯特点,普通总线只是关键通讯数据,而现场总线要支持带有时间标签和优先级,也就是这个调度机制主要是保证通讯数据的实时性和及时性。
 
  在这里不妨举个例子:现场总线等同于生活中交通系统通讯形式=交通上水陆空通讯协议=交通上的交通规则网络调度=交通上交警指挥系统    生活中人们不论何种方式出行,都不会离开水陆空这三种形式,而不论作何种交通工具,都是要遵守交通规则。只有遵守交通规则才能正常行驶并到达指定地点,而交警的工作就要解决在正常运行当中一些由于干扰造成的交通拥堵,交警主要是来解决拥堵,并保证关键道路的通行,并有效地实施了交通上的优先级。    我想经过这样的介绍,大家应该对于现场总线有一个梗概性的了解。那对于自控人员现场总线又能给我们带来什么呢?可能大家对于这个技术还没有“山雨欲来风满楼”的感觉,现场总线技术确实改变了传统总线控制思维,常规的总线控制都是由一个主控CPU通过总线把子站数据拿过来进行计算,然后根据结果再通过总线把控制要求下发给另一子站,这样其实就是浪费总线带宽的资源,通过现场总线技术,可以把控制分散到各个子站,而每个子站有时数据采集的终端和执行者,这样可以有效地减轻中央CPU的负担,并且改变常规的控制模式,以前很多人都说现场总线可以节省大量布线成本,其实线缆成本是有一些但绝不是现场总线技术为之存在的理由,它是一种改变常规控制的革新式技术,它把控制的核心通过总线技术下放到各个站点,在总线上的各个通讯站点,不再是数据采集和控制执行的终端,而是具有控制逻辑的大脑。

 

 

 

 

 
打赏
 
更多>同类环保知识
0相关评论

推荐图文
推荐环保知识
点击排行
网站首页  |  免责声明  |  联系我们  |  关于我们  |  网站地图  |  排名推广  |  广告服务  |  积分换礼  |  RSS订阅  |  违规举报  |  鲁ICP备12015736号-1
Powered By DESTOON