简介这是一份围绕能源管理系统EMS的专题演示文稿面向工厂、建筑、园区等领域的能源管理工程师、系统集成人员及节能改造项目负责人。内容系统梳理了EMS由过程监控与能源信息管理两大部分构成的整体框架重点讲解信息采集层、实时处理数据层、应用管理层三层架构以及如何通过PLC、智能仪表等设备实现水电气油煤数据的统一采集、分析与优化调度帮助读者快速掌握企业能源管理平台的实施思路与关键要点。资源为单个PPTX文件压缩包大小约9.72MB已有246人学习。PPT中不仅覆盖EMS的七大作用和大型公共建筑、高耗能企业、工业园区、政府监管平台等典型应用前景还包含系统建设注意事项、能耗财务分析、节能诊断与报表管理等功能模块说明有助于在方案编写、内部评审和培训交流中建立统一认识适合作为技术汇报与基础教学参考。1. 能源管理系统EMS一份系统集成方案文档到底能帮你解决什么问题先说你最关心的问题这份《1能源管理系统(EMS).pptx》不是软件源码也不是安装包而是一份 17 页的系统集成方案讲解文档来自系统集成方温绍林的整理。它干的事情是把能源管理系统是什么、分为哪几层、有哪些功能模块、怎么落地、能用在哪些场景完整地串了一遍。如果你正在做工厂或大型建筑的能源管理项目需要跟客户讲清楚 EMS 的价值或者自己刚接手一个能源管控平台项目想知道架构怎么搭、采集层用什么设备、和 ERP 怎么交互这份文档能让你在半小时内建立起完整的技术框架。我拆完这份 PPT 后最大的感受是它不像很多方案书那样只讲概念而是把三层架构、七大作用、六个应用场景都落到了具体的设备和系统关系上对售前沟通和项目初期的需求梳理非常有用。接下来我按实际的落地路径把这份文档里的技术点掰开讲。2. 三层架构怎么落地信息采集、实时处理与应用管理各干各的活2.1 信息采集层PLC、RTU、智能仪表怎么选PPT 里把 EMS 从功能上拆成三层底层是信息采集层中层是实时处理数据层上层是应用管理层。这个分层几乎是所有能源管理系统的基础骨架理解它后面所有功能才能挂上去。先说底层的信息采集层文档里明确提到由 PLC、RTU、远程 I/O、智能仪表等设备实现数据的采集与控制。这里的选型逻辑并不复杂但有个关键点容易被忽视采集层设备不是越贵越好而是要根据现场点位分布和通讯条件来定。常见的做法是现场已经有 DCS 或电力监控子系统的优先通过通讯方式从子系统取数而不是重复安装仪表现场没有子系统、只有散落设备的才考虑加装智能电表、水表、流量计、温度变送器等计量装置。PLC 和 RTU 则更多用在需要就地逻辑控制或数据汇集的场合比如锅炉房、空压站、换热站这类需要把多路信号汇总后上送的区域。采集层还有一个容易踩坑的点通讯协议的适配。现场设备来自不同厂家Modbus RTU、Modbus TCP、IEC 60870-5-104、DL/T 645 电表规约甚至一些私有协议混在一起这时候就需要在采集层做协议转换。PPT 里虽然没有展开讲协议但摘要里提到“温度、压力、流量等参数采用通讯方式集中到一块”这句话背后就是大量协议对接工作。我的经验是采集层设计时最好留出 20% 的余量因为现场总会有你没想到的设备要接入。I/O 服务器是这一层的核心设备它负责和 PLC、RTU、智能仪表通讯把离散的现场数据变成统一的实时数据流。I/O 服务器的选型要考虑通讯点数、采集周期和协议驱动数量。通常一个中等规模的工厂电、水、气、油加起来上千个测点一台 I/O 服务器跑 500ms 到 1s 的采集周期是够用的但如果涉及电气参量电压、电流、功率的高频采集周期要缩短到 200ms 左右这时候对通讯链路和服务器性能的要求就上来了。2.2 实时处理与历史归档I/O 服务器不是只管收数据中层是实时处理数据层主要设备是 I/O 服务器完成数据的实时处理和历史归档。很多人容易把 I/O 服务器理解成一个“数据中转站”实际上它承担了三件事数据质量判断、实时计算、历史存储。数据质量判断是容易忽略的一环。现场仪表故障、通讯中断、超量程这些情况产生的数据不能直接进实时数据库否则后面做的趋势分析、能耗统计全是错的。常见的做法是在 I/O 服务器上配置质量戳Quality Stamp区分 good、bad、uncertain 三种状态上层应用查询数据时按质量位过滤。PPT 里提到的“分区分时的存储至实时数据库中”这个“分区”其实包含了两层意思一是按能源介质分电、水、气、油、煤二是按区域分车间、产线、楼栋。历史归档的策略也值得单独说。实时数据库的存储策略一般是“变化存储”和“周期存储”混合使用——模拟量测点用死区变化存储变化超过阈值才写库状态量用变位存储开关变位才记录再叠加一个定时轮询存储兜底。这样既保证了数据的连续性又不至于让存储量爆炸。比如一个 5000 测点的项目如果全按 1 秒周期存一天就是 4.3 亿条记录任何历史库都扛不住但用变化存储实际写入量可能只有这个数字的十分之一不到。中层还需要处理一件事断线缓存。现场通讯不可能永远稳定I/O 服务器和上层应用服务器之间一旦断链数据不能丢。一般做法是在 I/O 服务器本地做环形缓冲区断线期间的数据先写本地恢复后按时间戳补传。这个功能在项目验收时一定要测很多系统运行一段时间后出现历史曲线“断崖”就是没做断线缓存导致的。2.3 应用管理层工程师站、操作员站和 ERP 交互的边界上层是应用管理层主要设备是应用服务器、工程师站、操作员站。这三类站点的分工要搞清楚工程师站负责组态和维护操作员站负责日常监控和操作应用服务器跑的是数据分析、报表、报警服务。小项目中工程师站和操作员站可以共用一台机器但大项目中最好分开避免组态调试影响运行监控。PPT 里特别提到“与企业资源计划系统(ERP)的信息交互”。这个交互的边界很多项目没划清楚导致后期扯皮。我的理解是EMS 和 ERP 之间传的是“结果数据”而不是“过程数据”。EMS 把能耗成本、产量单耗、能耗计划完成率这些分析结果给 ERPERP 把生产计划、产量数据给 EMS 用于分摊能耗两边不应该直接共享实时数据库。接口方式一般走 WebService 或中间库定时同步避免 ERP 的并发请求拖垮 EMS 的实时服务。应用管理层的功能模块PPT 列举得很清楚能源计划与预测、能源审计、能源考核统计、能耗对比分析、定额管理和超定额收费、优化运行、报警及事故管理。这些模块的数据来源都是实时数据库和历史库本质上是把底层采上来的数据加工成管理层能看懂的指标。比如“定额管理”这个功能需要先配置每个车间或每栋楼的能耗定额值系统周期性对比实际消耗和定额值的偏差超了自动触发报警并生成超定额费用单。这些功能做起来不复杂难的是定额值怎么定——一般是取前三年历史数据平均值再乘一个系数这个系数要靠运营人员和工艺人员一起商量软件只是把规则落地而已。3. 过程监控和能源信息管理实时看状态和事后算总账是两件事3.1 过程监控画面组态怎么组织才能让操作员看得懂PPT 把 EMS 分成过程监控和能源信息管理两大部分这个划分很值得琢磨。过程监控的重心在“当下”把现场的实时状态通过画面展现给用户能源信息管理的重心在“事后”利用实时数据库里的信息和 ERP、MES 提供的生产计划信息做精细化管理。两者用到的数据是一样的但使用方式完全不同。过程监控的落地形式是监控画面HMI。画面组态不是把设备图标摆上去就完了组织逻辑要跟着操作习惯走。常见做法是分层组织总貌图看全厂能耗总览和关键指标区域图看某个车间或某个站房的详细状态设备图看单台设备的实时参数。总貌图上出现的数字越少越好因为操作员盯着的往往就那么几个关键指标——总电耗、总水耗、当前的峰谷平电价、有没有报警。PPT 里提到的“能耗支路信息图以 web 的形式展示”这是近年来的趋势B/S 架构的画面可以在任何浏览器上看不需要装客户端。报警管理是过程监控里最考验功底的模块。报警不能一窝蜂地全推给操作员要有分级紧急报警设备跳闸、管道泄漏走声光报警并弹窗一般报警参数越限只在报警列表里高亮提示类报警通讯暂时中断只记录不提醒。报警阈值也要分层设置——越限报警、偏差报警、变化率报警各有各的用途。比如蒸汽流量只设上限肯定不够流量瞬间掉到零可能是管道断了或仪表故障这时候变化率报警比越限报警更快发现问题。3.2 实时数据库的选型测点容量和存储策略怎么定实时数据库是整个 EMS 系统里最核心的软件组件PPT 里提到“把所有信息进行归纳整理分区分时的存储至实时数据库中”这句话决定了实时数据库选型的基本参数。选型时主要看三个指标单机支持的测点容量、写入吞吐量、历史数据压缩比。测点容量很好理解一个测点就是一个数据项比如“1号变压器A相电流”5000 测点容量的数据库和 5 万测点容量的数据库价格差一个数量级。选多大要看未来 3-5 年的扩展空间我一般建议按当前需求的 1.5 倍配。写入吞吐量决定采集层能不能把所有数据都写进去一般实时数据库都能做到每秒几万条写入但要注意采集周期短200ms 以下的高频测点会占用大量写入资源。历史数据压缩比决定了同样一块硬盘能存多久的历史数据旋转门压缩Swinging Door是主流算法压缩比一般在 10:1 到 20:1 之间具体要看数据波动幅度——波动越大压缩比越差这属于实时数据库的“玄学”领域实际效果得拿现场数据测。存储周期也要提前定好。太短了浪费存储太长了看不出变化趋势。我的经验值供参考电参数电流、电压、功率1 秒或 2 秒一个点温度和压力 3-5 秒一个点流量累计量 1 分钟一个点就够了。PPT 里提到的“趋势、报警、报表”这三样东西对存储精度的要求完全不同——趋势曲线要细粒度数据报表只要分钟级或小时级汇总即可设计数据库时可以按不同粒度分别存储原始数据存 1 个月分钟汇总存 1 年小时汇总存 10 年兼顾查询速度和存储成本。3.3 能源信息管理的核心模块定额管理、报表与分析对比怎么做能源信息管理是 EMS 区别于单纯数据采集系统的分水岭。PPT 里列了能源计划预测、能源审计、考核统计、定额管理、超定额收费、优化运行、报警事故管理这几个模块这些功能全部建立在数据分析和对比的基础上。我挑几个落地时最容易出效果也最容易出问题的模块说。定额管理是公共建筑类的刚需。比如一栋写字楼按楼层或按租户设定单位面积能耗指标每月统计实际能耗超了要加收费用。这套逻辑在 PPT 的“分户能耗分析”里讲得很细按商户、部门、地区分户管理看单位面积能耗、用电功率峰值、实时统计电价。落地时关键是维护好分户关系表——哪个电表属于哪个租户哪个水表属于哪个商铺这张表建不清楚后面所有分摊和收费都是糊涂账。报表打印这块很多人低估了工作量。PPT 里列了设备集报表、分户报表、财务报表、能耗参数报表、环境参数报表、HVAC 参数报表等百种报表类型。这背后其实是报表引擎的灵活性——能自由设计模板、批量生成、定时推送。我的经验是别自己从零开发报表引擎用成熟的开源报表工具如 JasperReport或者实时数据库自带的报表模块把精力花在报表模板的设计上否则开发周期会拖得非常长。分析对比模块直接对应 PPT 里强调的“数据建模的技术手段进行分析、预测、优化”。常见做法是把本期数据和去年同期比、和上月比、和定额比、和同类设备比异常偏差自动推送。这个模块做好之后才谈得上“节能诊断”和“节能足迹”——每一次节能改造前后各取一段时间的能耗做对比改造效果就量化出来了。很多节能项目为什么做了之后说不清楚效果就是因为改造前没有完整的能耗基线数据这套系统就是用来补这块短板的。4. 六大应用场景拆解从公共建筑到政企监管平台需求完全不同4.1 大型公共建筑分户计量和能耗财务分析是核心PPT 里第一个应用场景是大型公共建筑能源管理平台包含八大板块设备集能耗分析、分户能耗分析、用电参数实时监控、能耗财务分析、报表打印、节能足迹、节能诊断和新闻搜索。这里面最核心的需求是分户计量和能耗财务分析。分户计量解决的是“谁用了多少能、谁该付多少钱”的问题。写字楼和商业综合体里租户众多每个租户的空调费、电费、水费怎么分摊传统的公摊方式是按面积均摊租户意见大。装了 EMS 之后每个租户的独立支路电表、水表、冷量表数据自动汇总账单自动生成收租和管理都硬气多了。PPT 里提到的“实时统计电价”和“分项能耗统计”就是为这个目的服务的。能耗财务分析是另一大亮点。建筑用能有峰谷平电价用能大户比如数据中心需要关注最大需量MD——如果一个月的最大需量值是 5000kW但实际平均功率只有 3000kW那基本电费就亏大了。EMS 可以帮助选择合理的 MD 值这单靠人工盯是不现实的需要系统按历史负荷曲线做模拟测算。4.2 高耗能企业和工业园区节能优化调度是真正的硬骨头传统高耗能企业钢铁、水泥、化工的能源管理平台PPT 里的描述是“降低重要能源介质放散提高能源介质的回收和梯级利用水平实现多能源介质的协同平衡与优化利用”。这段话在钢铁行业特别好理解——高炉煤气放散意味着能源白白浪费转炉煤气回收率直接关系到企业成本。这类项目的技术难度远高于公共建筑因为涉及多能源介质的平衡调度。比如一个钢厂高炉煤气、转炉煤气、焦炉煤气热值不同、压力不同、用户也不同调度员需要实时知道每种煤气产了多少、消耗多少、还有多少余量才能决定是用煤还是用天然气替代。PPT 里说的“能源优化调度、节能控制系统建设”在钢铁行业就是做煤气管网的压力平衡和热值匹配甚至要联动到发电机组做煤气-蒸汽-电力联调。工业园区能源监管平台则更强调广度和整合。PPT 里提到“基于 B/S 技术结构可通过互联网随时进行管理”“实时监控园区企业清洁生产、废水分类收集、污染物治理排放、能源使用、危废处理、风险源等情况”。这意味着园区级的平台要接进每家企业的数据不可能都给每家企业做采集改造更务实的方案是企业侧配数据网关把企业已有的计量数据加密上送到园区平台园区平台做展示、报警和统计。这里最容易翻车的是通讯协议和网络安全每家企业的数据格式都不一样而且企业会担心生产数据泄漏需要在接入方案中明确数据脱敏策略和访问权限控制。4.3 政企监管云平台数据接入是最大的工程PPT 最后一个场景是“地区性能源管理监控云平台低碳云城市平台建设实现辖区能耗在线监测和能源综合管理”。这类平台的本质是能耗数据的“政府版大盘”关键技术点是物联网接入、地理信息系统GIS、动态图表。这个场景里最常被低估的是接入环节的工作量。一个区可能有上千家重点用能单位每家都要装计量装置、配数采设备、做通讯调试光这个环节就要占整个项目一半以上的工期。数据上来之后还要做清洗和审核——会存在数据缺失、数据异常某个月能耗突然变成 0、口径不一致有的企业报标煤有的报原煤这些问题。PPT 里提到的“整合、共享、开发和利用当地能源信息”落地时最大的功夫就花在这里。政府侧平台的报表格式也是固定的必须按国家或地方能耗在线监测平台的标准字段要求上报这些规范文件最好在项目启动前就拿全不然后期改起来非常痛苦。这六类场景虽然都是 EMS但技术重心差异很大。公共建筑重分户计量和财务分析工业企业重平衡调度和节能优化园区重多企业数据整合政府重监管和上报。做项目的时候第一件事就是把场景定准——不同场景对应的系统功能模块、硬件配置、软件选型都不一样这个定位错了后面全跑偏。5. 系统建设避坑指南六条注意事项背后的血泪经验PPT 里列出了六条系统建设注意事项了解行业生产工艺和能源分布、能源数据采集点现场情况和数量统计、及时了解用户需求、现场监测仪表改造和新增、数据传输组网方式及通讯信息接入方式、数据接入的扩展性和兼容性。这六条看起来像套话但每条背后都有具体的坑。我结合做过的项目把它们展开成踩坑记录。5.1 生产工艺没吃透就设计采集点系统上线就变摆设现象系统上线后调度员和操作员基本不用觉得“系统里的数据跟现场对不上没什么参考价值”。原因设计采集点时没有深入了解行业的生产工艺和能源分布只按通用模板设计测点。比如某个工序是间歇式生产能耗主要集中在某几个时段但采集点位没有覆盖到关键设备导致系统反映不出真实能耗规律。解决在采集点设计前和工艺工程师一起梳理流程。重点搞清楚三件事每个工序的能源输入和输出是什么、哪些设备是主要的耗能设备、哪些区域有节能改造潜力。把这些整理成测点清单后再核对现场实际情况确认每个点位的位置、仪表的安装条件、通讯可达性。宁可前期多花两周做调研不要上线后花三个月返工。5.2 仪表通讯协议五花八门接口调试做到怀疑人生现象现场几十台仪表Modbus、DL/T 645、CJ/T 188水表规约什么都有还有些进口仪表用私有协议I/O 服务器只能一台一台调接口调试进度被拖死。原因前期没有做现场仪表调研不知道已有的仪表型号和支持的通讯协议。评估工作量时按“统一用 Modbus”来估算结果现场一半的设备不支持。解决进场第一件事就是做仪表台账逐个确认型号、通讯协议、寄存器地址表。不支持的协议先分类看是否有协议转换网关能转成标准协议确实转不了的才考虑更换仪表。另外在合同或方案里要写清楚接口调试的责任边界——哪些仪表由业主负责开放协议哪些需要EMS集成方去协调处理这个不写清楚后期扯皮比技术问题更耗时间。我一般会在方案里附带一张“现场仪表接口调研表”要求业主方配合填写表里包含仪表的品牌、型号、协议类型、通讯参数波特率、数据位、校验位、变量列表等内容这样我们的实施团队进场前就能预估工作量业主也能提前准备相关技术资料。5.3 组网方式拍脑袋决定采集数据丢包、延迟还没人背锅现象项目运行时历史曲线经常出现断点怀疑是通讯问题但找不到具体是哪个环节丢的数据。原因组网方式选型没有结合现场条件。比如厂区地域广、电磁干扰大却选了无线通讯方案或者现场点位分散到不同建筑却没规划好光纤链路走向导致部分节点通讯质量差。另外通讯设备的配置没有考虑通过辅助开关如交换机的VLAN划分、串口服务器的端口隔离来优化网络结构使得不同区域的通讯相互干扰。解决组网方式必须在调研后确定。同一厂区优先用工业以太网点位分散且布线困难的区域考虑 4G 无线或 LoRa 方案干扰强的环境优先光纤。通讯链路设计要留冗余重要采集站点如变电站等关键节点用双链路。还要在 I/O 服务器上做断线缓存和通讯质量统计哪个站点掉线、掉线多长时间、恢复后补没补数据这些都要能查到。通讯故障和数据丢失问题最怕的就是没有记录无法定位。5.4 只顾当前需求忽略扩展性新增点位要推翻原有架构现象项目验收后业主新增了一批计量仪表结果发现 I/O 服务器的通讯端口不够了license 点数也不够甚至实时数据库容量也告急被迫升级服务器费用比预想的高很多。原因前期只按当前测点数做设计没留余量。PPT 里最后一条“数据接入的扩展性及兼容性”写得很明白但往往被忽视。测点数量、I/O 服务器的通讯端口、实时数据库的授权点数这三个参数是最容易“到顶”的。解决测点按实际需求的 1.5 倍设计I/O 服务器选型时留足够的通讯端口和 CPU 余量。实时数据库授权点数建议按测点数上限的 2 倍购买——授权点数是软件按“可配置的测点总数”卖的不是按“实际接入的点数”卖只要以后要加的测点数不超过这个值不用重新买。这一条如果预算允许一定要做因为后期补购授权往往比首次购买贵得多。此外在系统架构上采用可扩展的采集框架比如使用模块化I/O机架或带扩展槽的采集网关新增点位时只需增加模块而不必更换主设备。5.5 硬件和软件脱节装完系统才发现数据库容量跑不动现象项目做到一半发现实时数据库软件的授权点数不够用或者服务器配置跑不动设计的数据容量只能追加预算还可能延误工期。原因分不清 EMS 是个软件工程而不是单纯的硬件安装工程。前期在硬件选型和采购上花了大功夫轮到软件配置和应用开发时预算已经花得差不多了只能买个小规格的实时数据库将就着用。解决方案设计阶段就把“软件授权点数 历史库存储容量 服务器配置”作为一个整体来规划。实时数据库厂商一般会提供容量规划工具把测点数量、采集周期、存储策略输入进去它会给出推荐的服务器配置和历史存储需求。这个规划结果要写进方案里作为采购依据。不要省软件的预算因为一个 EMS 系统的核心是软件平台而不是那一堆硬件。硬件是载体软件才是灵魂。5.6 用户需求没闭环开发完才发现不是客户要的现象系统开发完成后业务部门试运行时说“这不是我们想要的功能”比如报表格式不对、统计口径不一致、报警阈值设置不符合实际操作规程。原因PPT 第三条说“及时了解用户的需求以便研发人员对系统功能的开发”。但需求的收集不能停留在“组织一次座谈会、记几页纪要”的层面。能源管理系统的用户至少分三层操作员要的是方便快捷的监控和报警处理体验能源管理员要的是能帮他出周报月报、能对应上绩效考核的数据支撑老板要的是能源成本下降的结果。这三层需求经常互相冲突比如操作员嫌报警太多打扰日常操作但能源管理员恰恰需要完整报警记录用于事故追溯。解决每个需求都要落到具体的功能单据和界面原型上和用户确认后才能进入开发。流程上做到“需求收集 → 原型确认 → 开发实现 → 阶段验收 → 试用反馈”闭环重点是让用户在每个阶段都能看到实物而不是只看文档描述。这中间还要预留需求变更的空间能源管理系统的需求变动率比一般管理系统高得多因为能源统计口径如峰谷平时段划分、考核周期会随政策和管理要求变化变更流程要定清楚否则开发团队天天被需求折腾。6. 把 17 页 PPT 变成你自己的方案素材演示、立项与避坑的三种用法这份文档虽然只有 17 页但如果你正在做 EMS 相关项目它完全可以当做一个方案骨架来用。我自己拿到这类资料后的习惯是先快速拆解出它的逻辑主线系统是什么 → 架构怎么分 → 功能有哪些 → 各场景怎么用 → 建设要注意什么。然后把它转成三个可复用的交付物。第一个交付物是给客户演示用的简版方案把 PPT 里的“能源管理系统结构示意图”“架构图”重新整理成一套流程清晰的图示再把“七大作用”改成从客户痛点出发的表述比如客户如果抱怨能源成本高就重点讲第 6 条通过优化能源调度和平衡指挥系统节约能源如果客户担心管理混乱就重点讲第 3 条建立客观的能源消耗评价体系。第二个交付物是项目立项时的需求清单把 PPT 里“系统的作用”和“主要建设内容”逐条拆成可验收的指标比如将“完善能源信息的采集、存储、管理和能源的有效利用”拆成“覆盖电、水、气、油、煤五种介质采集点数不低于 X 个历史数据保存不低于 X 年”。第三个交付物是实施前的风险清单把 PPT 里的六条注意事项加上我上面踩过的坑做成一张检查表在现场勘察时逐项确认。还有一个实际技巧做售前演示时不要一上来就放整份 PPT太散。我一般会从“能源管理系统架构图”那页开始先讲清楚三层结构和数据流向再根据客户行业跳到对应的应用场景页——公共建筑客户就看分户能耗分析工厂客户就看能源优化调度。这样演示一个场景客户就能建立起直观的认知。演示过程中要引导客户关注数据间的关联性而不是单独展示某个功能页面因为 EMS 的价值在于打通数据链条。比如从“能耗采集”到“数据分析”到“定额管理”再到“节能诊断”这个链条能讲通客户就会明白这不是一个简单的监控软件而是一个管理工具。按照这套逻辑去讲即便你手上的素材只有这 17 页也能讲出完整的方案感。这套“三层架构 两大部分 六大场景”的结构我后来在多个能源项目里反复用不管是给物业公司讲分户计量还是给钢厂讲煤气平衡都能套用。从那以后我每次拿到类似的方案文档都会先动手把它拆成架构、功能、场景、避坑四件事再按自己的项目情况重新组织而不是直接拿原文档去讲。希望这份拆解能帮你在做 EMS 项目时少走几步弯路不管是去讲方案、立项还是做设计都能有个清晰的抓手。本文还有配套的精品资源点击获取