内容


使用传感器监控的 Smarter Planet 解决方案,第 2 部分

实现更加智能的供应链的传感器解决方案

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 使用传感器监控的 Smarter Planet 解决方案,第 2 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:使用传感器监控的 Smarter Planet 解决方案,第 2 部分

敬请期待该系列的后续内容。

简介

术语供应链的含义非常广泛,可以跨多个行业使用。为了演示如何使用 IBM WebSphere Sensor Events 和其他 IBM 解决方案组件创建更智能的供应链,本文查看了一个管理药品的供应链。在该供应链中,制药公司需要保护它的供应网络和客户以避免处方药造假,以及支持药品召回等。

从表面上看,药品供应链与其他供应链相似,都具有制造商、批发商和零售商。不过,由于通过该供应链传输的是要求非常苛刻的药品,所以一般的供应链问题可能会导致问题加剧和增加潜在的财务损失。在查看针对一个假定制药公司的供应链以及该供应链面临的一些问题和挑战之后,您将:

  • 了解 IBM 解决方案组件如何解决这些问题。
  • 了解可能的解决方案的架构。
  • 查看样例代码,了解一个用例。
  • 了解如何让供应链变得更加智能。

当前的供应链

这个供应链的目的是为将药品从制造商传递到客户提供一个渠道。大部分制造商,不管它们生产的商品是什么,都不具有(或不想管理)一个向所有客户(在本例中为药店和医院)提供药品的供应网络。因此,它们必须通过批发商和分发商将尽可能多的产品分发到更多的客户手中。批发商和分发商通过复杂的供应网络分发药品:

  • 当医生开出处方时,供应链就开始了。
  • 患者将处方交给当地的药店。
  • 药店从特定的分发商处订购药品。
  • 分发商从制造商处购买药品(或从批发商或其他分发商等)。
  • 分发商将药品销售给药店。
  • 药店为患者提供药品。

这个流程看起来非常简单明了 —— 并且在许多产品的分发中很常见。但是在药品供应链中,由于存在环境限制(比如温度、湿度和光线)、时间限制(产品过期)、法规遵从性、安全和药品的高风险性,因此它比一般的分发流程更加复杂(比本文提到的情况更复杂)。

主要挑战

任何供应链都面临特定的挑战。就药品供应链而言,主要的挑战有:

  • 伪造

    根据报告,在全球范围内有大约 10% 的处方药是可以伪造的。有些报告称美国药品伪造的百分比为 2%,但是在一些欠发达的国家,药品的伪造率高达 50%。伪造对于患者的安全和公司的财务都是巨大的危险。在美国,许多州都开始立法要求药品制造商处理伪造问题。

    伪造产品是如何进入药品供应链的?在大部分情况下发生在供应链的分发阶段,对于药品而言,这个阶段是非常复杂的。在药品到达药店之前,它可能经历 4 至 8 个(或者更多)分发商。要利用供应链软肋的伪造商可能扮演愿意为更大的批发商提供 “特殊折扣” 的小批发商。如果大批发商接收贿赂,那么伪造药品就进入了供应链。处于供应链最后一级的分发商并不知道药品的源头。除非制造商能够获得特定药品到达药店需要经过多少个分发商的反馈,否则伪造药品就可能流向市场。

  • 召回

    在美国,当药品被认定为有害时,FDA 将发出 Class I 或 Class II 召回。药品制造商必须负责召回工作,并且需要对药品受害者负责。一般而言,制造商都希望识别有害药品的批次或数量,从而尽可能地减少召回的数量。这就需要通过某种方法来快速方便地定位所有有害药品,否则制造商就不能知道已经销售或召回的药品,从而导致不能够确定潜在的责任风险。客户对通常由制造商发出的召回通知能够保持高度警惕和做出反应,但对于药品使用者而言,后果可能非常严重,并且制造商面临的风险和责任也非常大。由于药品供应链的复杂性,一些制造商很难查明药品的去向。甚至少部分人还认为现行的召回系统和流程不可靠并且低效,应该加以改进。

那么,我们的目标就是更新和改进供应链,从而保护消费者的安全和制造商的信誉。

更加智能的供应链

这些供应链问题可以总结为缺乏可见性。如果药店能够查明它收到的药品确实来自制造商,那么伪造就没有立足之地了。如果制造商能够查明药店收到的药品的批次和数量,那么就能够实现更高效、成本更低的召回系统,并且可以保护消费者的生命安全和减少责任。

解决方案是让供应链本身变得更加智能

配备仪器配备仪器

第 1 部分 所述,智能化的第一步是配备仪器。仪器为供应链的可见性提供了基础。在药品供应链中,配备仪器就是通过身份识别技术让制造商、分发商和药店能够识别流经供应链的每个药品容器。该步骤主要是由制造商负责的:制造商在生产了药品并将药品放入容器中时,它们必须为盛放药品的瓶子或盒子分配一个惟一的身份标识符。比如给药品容器分配一个序列号,该序列号伴随产品的整个生命周期。

身份识别技术已经出现有一段时间。不过,最常用的身份识别技术是条形码,它仅识别产品的类型,而不区分药品容器(即相同类型的药品使用一样的条形码)。现在的技术和标准,比如 GS1-128、2D、Datamatrix 条形码和 Electronic Product Code (EPC),让制造商能够超越类型更加精确地标识产品。通过序列化技术,给容器分配的产品身份标识能够表示容器中的产品的类型、容器的类型(瓶子、盒子、药丸等),并且为每个容器提供一个惟一的 ID。

识别产品仅是配备仪器的第一个作用。配备仪器的第二个作用,可能也是最重要的作用,就是使其他系统能够在药品流经供应链时检查它们。作为供应链的战略部分,这个步骤需要使用硬件来提供关于产品的性质、时间和地点等宝贵信息。使用的硬件可以是手持的条形码或 Radio Frequency Identification (RFID) 读取器,或者是位于制造商的包装和发货站的自动化固定读取器。最后,药店需要一个用于收货的读取器。

相互连接相互连接

在供应链的每个站点都使用身份读取点非常好。如果制造商能够在制造过程中看到产品的流程,它们将能够获得巨大的潜在收益。不过,如果没有将每个读取点、每个供应商和每个分发商相互连接起来,配备仪器的真正价值就不复存在。相互连接是指通过一个系统来接受供应链中的每个读取点的信息,并与其他内部和外部系统共享该信息。供应链的本质是产品在各个位置的流通;如果没有相互连接,就不能在供应链本身中解决问题。

相互连接能够实现信息交换。当制造商知道给分发商运送的是什么药品时,就可以使用该信息来促进其他业务流程,比如 ASN (Advanced Shipping Notice) 创建、简短声明处理、过期管理、库存管理、损失预防、诈骗检测和冷冻链管理等。

现在已经将仪器和合作伙伴关联起来,那么如何利用所有这些新数据呢?

智能化智能化

在供应链中的所有合作伙伴能够查看仪器信息并且将所有关键组件连接起来之后,整个供应链就实现了智能化:您可以将利用身份信息的智能系统、流程和过程组织起来。您可以查看药品的身份信息和在制造商的系统中查询其真实性,从而验证产品的来源。

制造商可以对药店系统执行查询,确保发送的产品通过供应链顺利到达指定的目的地。制造商还可以在药店的系统中更改药品的状态,以让药剂师知道哪些药品已被召回,帮助他们决定是否告诉客户销毁或返回需要召回的药品。

从财务上看,制造商和分发商可以利用系统不断加强的可见性来进一步优化运营 —— 减少库存、改善周转、减少运输时间和延长药品的在架时间。这样,分发链中的每个环节的库存都将更加精确、可靠和及时,从而减少产品丢失并避免审查工作。当然,转移、伪造和召回带来的损失也将减少。

整合

通过配备仪器、相互连接和智能化流程之后,曾经面临许多挑战的供应链系统变成了一个更加智能的系统:更加精确、更加可靠、更加高效、更加开放,这些优点最终让系统变得更加有价值。

让我们查看一个使用 IBM 智能供应链参考架构的解决方案(图 1)。

图 1. 智能供应链参考架构
图 1. 智能供应链参考架构
图 1. 智能供应链参考架构

这个解决方案架构的组件包括:

  • Data Capture

    在实现智能供应链的过程中,Data Capture and Delivery 组件是在传感器设备和 WebSphere Sensor Events 服务器实现处理的 “第一站”。WebSphere Sensor Events 的数据捕捉组件由驻留在传感器设备上的软件堆栈组成。它提供一个允许您为设备通信构建设备适配器的框架。在智能供应链中,传感器通常是某种类型的身份读取器。当产品在供应链中流通时,传感器将检测到它们的出现并报告产品出现的时间及其身份。来自传感器的原始数据对企业资源规划系统和仓库管理系统没有任何用处,并且对促成智能业务流程的价值不是很大。因此,必须以某种方式对原始数据进行处理,以实现其价值。数据捕获软件堆栈提供一个能够执行跟踪数据处理的框架,比如可以执行几种数据过滤和聚合。数据捕捉框架可用于为处理和转发原始传感器数据开发智能规则。

  • WebSphere Sensor Events

    因为 Data Capture and Delivery 组件通常运行在用于储存和处理数据的资源比较有限的分布式平台中,所以必须将数据转发到服务器平台中。可以根据几种不同的协议使用传感器事件网关组件将传感器设备的数据发送到 WebSphere Sensor Events 服务器。受支持的渠道为 HTTP、JMS 和 Web 服务。以事件的形式将传感器数据从传感器或分布式平台发送到服务器。事件使用规范化的格式,让 WebSphere Sensor Events 服务器能够针对事件执行几种常见的服务,比如持久化和过滤。

    WebSphere Sensor Events 服务器还提供一个框架,用于为处理由传感器生成的事件构建应用程序。这个框架允许您构建称为 Reusable Components 的事件处理组件。稍后将更加详细地讨论 Reusable Components,现在知道 Reusable Components 是在 Service Component Architecture (SCA) 组件之后建模的事件处理组件就可以。服务器以 Reusable Components 的形式提供一组预定义的服务,并且这些服务使应用程序构建器能够将过滤并增强后的数据提供给后台系统。

  • WebSphere Business Events

    处理传感器事件包括能够在传感器数据经过系统时找出它们的模式和差异。在这个参考架构中,该角色由 WebSphere Business Events 担任,它提供一个平台,允许解决方案构建者和使用者编写数据模式的检测规则。在检测到模式之后,就可以通知相关组件或执行某些操作。如果有必要,WebSphere Business Events 可以让操作一直进入到传感器设备本身,以关闭设备或更改电源级别等。

  • WMS/EDI

    这个组件表示用户的当前后台系统。这些系统可能包含仓库管理系统 (WMS)、Electronic Data Interchange (EDI) 或企业资源规划系统。期望用户修改后台系统以支持新的数据是不现实的,因此必须通过相互连接将数据提供给后台系统。

  • IBM InfoSphere Traceability Server

    将数据连接到本地系统并监控这些系统可以为内部操作和库存级别带来巨大的价值。不过,更智能的供应链的支柱是与供应链系统中的其他合作伙伴共享信息和数据。IBM InfoSphere™ Traceability Server 在参考架构中担任了该角色。它实现定义 EPC Information Services (EPCIS) 接口的 EPCglobal,该接口提供一种标准的方式来将事件提供给 EPCIS 储存库。一旦进入储存库之后,就可以和合作伙伴共享来自这些事件的信息。合作伙伴需要了解的数据包括产品的运输时间和订单是否发送等。同样,制造商可能需要检查订单是否实际到达。后面会讨论 EPCIS。

  • IBM Cognos Business Intelligence

    这个架构提供了捕捉数据的方式、提供过滤、增强和为数据添加业务上下文的工具,以及提供一种能够与合作伙伴共享数据的安全方式。要让供应链变得更加智能,所有这些步骤都是必要的。不过,实现智能化的最终本质就是进行数据驱动决策。

    IBM Cognos® Business Intelligence 为捕捉到的数据和该数据如何影响智能业务决策和智能流程之间提供衔接。此外,Cognos Business Intelligence 使更智能的解决方案能够:

    • 监控性能并下钻获取事务细节。
    • 在性能下降时识别关键指标并接收警告。
    • 提供常规的报告和分析,识别趋势和反常条件,从而帮助采取正确的措施和进行优化。

接下来,我们查看一个简单的例子,它展示如何使用 WebSphere Sensor Events 来实现更加智能的药品供应链解决方案。

样例场景

这个样例供应链中包含 3 个合作伙伴:Biggie Pharmaceuticals, Inc. 研发和制造药品。它将药品直接分发给大型零售药店,同时通过分发商 Speedy Distributors Co. 将药品分发给小的零售连锁药店和独立的药店。在供应链中的最后一环是 Mom & Pop's Pharmacy,一个独立运营的小药店。

假设 Mom & Pop's 下了一个订单,需要购买一箱 Biggie Pharmaceuticals 生产的偏头痛药品 MigHelp。MigHelp 是药片形式的,每瓶 100 片。这个例子将跟踪一瓶 MigHelp 在制造之后从 Biggie Pharmaceuticals 运输到 Speedy Distributors 再到 Mom & Pop's 的轨迹。当这瓶 MigHelp 到达 Mom & Pop's 药店之后,您将检查它是不是来自 Biggie Pharmaceuticals 的那瓶 MigHelp。

Mom & Pop's 订购的 MigHelp 在供应链中经过以下步骤:

  1. Biggie Pharmaceuticals:
    1. 产品的身份标识:在这个步骤中(在 EPCIS 技术中称为 commissioning),生成 EPC 值来惟一地标识每个 MigHelp 容器。RFID 打印机将每个 EPC 值写到嵌入在纸质标签中的 RFID 芯片的内存中。这个芯片和纸质标签构成 RFID 标记。该打印机还打印标签上关于识别药品、生产日期、批号及其制造商的信息。将打印好的 RFID 标记粘贴到 MigHelp 容器。在这个步骤完成之后,每个 MigHelp 容器都被惟一地进行了标识,并且可以在供应链中进行跟踪。
    2. 包装:将 MigHelp 容器放入箱子中然后装入运输袋中。
    3. 运输:将 Speedy Distributors 订购的 MigHelp 和其他产品装载到卡车上,然后运输到 Speedy Distributors 的中心仓库。
  2. Speedy Distributors:
    1. 接收:来自 Biggie Pharmaceuticals 的货物到达 Speedy Distributors 的中心仓库。从卡车卸载 MigHelp 和其他药品。
    2. 储存:拆开运输袋,将每箱 MigHelp 储存在 Speedy 的仓库中。
    3. 包装:将 Mom & Pop's 订购的一箱 MigHelp 和其他药品装入另一个运输袋中。
    4. 运输:将装有 Mom & Pop's 订购的 MigHelp 装载到卡车上。
  3. Mom & Pop's:
    1. 接收:来自 Speedy Distributors 的货物到达 Mom & Pop's Pharmacy。
    2. 储存:从运输袋中取出订购的一箱 MigHelp,并将每瓶 MigHelp 摆放到药店的货架上。

在这个场景中,MigHelp 容器在可以在 Mom & Pop's Pharmacy 出售之前,必须经过供应链中的 9 个步骤。在供应链的每个这些步骤中执行 RFID 数据读取。读取的数据使您能够跟踪这箱 MigHelp 在供应链中的情况,通过确定它是否是正品来隔离掺假的源头。

这个解决方案的组件包括打印和读写 RFID 标记的物理硬件、WebSphere Sensor Events 和一个 EPCIS 储存库产品,比如 IBM InfoSphere Traceability Server。

EPCIS 规范

让我们简单查看一下 EPCIS 规范,以更好地了解 EPCIS 储存库是如何在解决方案中发挥作用的。

EPCIS (Electronic Product Code Information Services) 来自 EPCglobal 组织的软件接口规范,它关于共享相关的 EPC 信息。它的目的是帮助贸易合作伙伴通过共享相关的 EPC 数据来利用 EPC 数据。数据共享可以发生在企业内部,也可以发生在多个企业之间。

原始 RFID 读事件包括带标记药品的 EPC 值、读取 EPC 的时间和 EPC 读取器的 ID。不过,它们不提供发生事件的业务上下文的信息。EPCIS 规范允许使用关于供应链中的标记药品的上下文信息增强来自原始读事件的信息。将该描述性信息与原始读数据合并创建 EPCIS 事件。EPCIS 事件提供重要的业务信息,比如时间、位置、分布和观察标记药品的业务步骤。例如,一个事件可能表示一个药品在特定的日期和时间运输。

EPCIS 规范定义两个接口:

  • capture 接口指定 EPC 数据为什么要与业务上下文数据合并,并对其他主要使用它的应用程序开放。
  • query 接口指定如何在捕捉到 EPCIS 数据之后查询它,通常通过与 EPCIS 储存库连接进行查询。

WebSphere Sensor Events 将业务上下文数据与标记读数据合并,从而创建 EPCIS 事件并通过 JMS 将它们发送到后台 EPCIS 查询系统。WebSphere Sensor Events 还提供可用于供基于 WebSphere Sensor Events 的应用程序查询 EPCIS 储存库的 API。

在更智能的药品供应链场景中,WebSphere Sensor Events 将用于在每次读取 MigHelp 容器上的 RFID 标记时创建一个 EPCIS 事件。在某些情况下将创建 EPCIS 事件,例如,当在 Biggie Pharmaceuticals 的运输流程中或在 Speedy Distributors 的接收流程中读取 RFID 标记。由 WebSphere Sensor Events 创建的 EPCIS 事件将储存在 InfoSphere Traceability Server 提供的 EPCIS 储存库中。这个场景还将使用用于查询后台 EPCIS 系统的 API,以在供应链中跟踪 MigHelp 容器的轨迹。

Reusable Components

应用程序使用 WebSphere Sensor Events Reusable Components 通过后台 EPCIS 查询系统创建 EPCIS 事件和接口,WebSphere Sensor Events Reusable Components 是为访问业务级功能提供 API 的 WebSphere Sensor Events 编程模型的组件。Reusable Components 可以看作是可供基于 WebSphere Sensor Events 的应用程序构造业务级任务的构建块。对于更智能的供应链解决方案,这些任务包括 EPC 值的管理、打印 RFID 标记和 EPCIS 事件的创建。EPCIS 事件表明在什么位置观察带标记的药品或者决定带标记药品上一次出现的位置。

大部分 Reusable Components 都是为了与外部后台系统连接。对于更智能的供应链解决方案,后台系统通常是 EPCIS 系统,比如 InfoSphere Traceability Server。不过,Reusable Component 框架将 Reusable Component 接口从后台系统实现分离出来。这一分离使您能够通过配置选择需要使用的后台系统。大部分 EPCIS 连接 Reusable Components 可配置为使用 WebSphere Sensor Events 数据库而不是外部 EPCIS 系统。这允许仅使用 WebSphere Sensor Events 来原型化和开发更智能的供应链,从而减少启动成本和降低复杂性。

Reusable Components 被实现为消息驱动的 EJB,并通过无状态 bean 方法、Web 服务和 JMS 消息公开它们的函数。下面列出关于每个 EPCIS 连接 Reusable Component 组件的简短函数描述(查看 WebSphere Sensor Events 信息中心了解更多细节)。

  • EPCIS Connector 将传感器事件转换成 EPCIS 事件。其他 Reusable Components 调用这个组件来创建 EPCIS 事件。
  • Aggregation 记录后台系统中一个或多个子 EPC 值和父 EPC 值之间的关联。
  • Disaggregation 删除后台系统中一个或多个子 EPC 值和父 EPC 值之间的关联。
  • Commissioning 在后台系统中激活 EPC 值。
  • Decommissioning 在后台系统中停止 EPC 值。
  • Observation 创建一个 EPCIS 事件,用于标识在什么时候和什么地方观察到带标记的 EPC 药品,以及观察到它的业务上下文。
  • EPC 生成和解码 EPC 值。
  • Info 通过查询后台系统了解 EPC 值的详细信息。
  • Locating 通过查询后台系统确定最近观察 EPC 值的位置。
  • Reporting 通过查询后台系统了解观察特定的 EPC 值的位置,或在特定时期内在指定位置上观察到的 EPC 值。
  • Validation 通过查询后台系统确定当前是否分配了一组 EPC 值。

在本文提供的样例场景中,您将:

  • 使用 Validation、Commissioning、Observation 和 Reporting Reusable Components 初始化分配给您正在跟踪的 MigHelp 容器的 EPC 值。
  • 创建 ECPIS 事件,识别在何时何地看见(或观察到)容器。
  • 生成容器在供应链中的轨迹的报告。

接下来,我们实现样例场景。

实现样例

在真实的实现中,RFID 读取器、打印机和 WebSphere Sensor Events 的 Data Capture and Delivery 组件是在读取器和 WebSphere Sensor Events 之间的处理链的 “第一站”。为了简化样例(以及安装和样例代码),您将使用表示粘贴到 MigHelp 容器的 RFID 标记的预定义 EPC 值和一个轻量级 Web 应用程序 SmarterPharma 来代替这些组件,并模拟先前在供应链流程中定义的点读取的 RFID 标记。

要运行样例,您需要将 SmarterPharma 应用程序(可以从本文 下载)安装到 WebSphere Sensor Events 所在的应用服务器。应用程序安装完成之后,您可以通过以下链接访问 SmarterPharma Web 页面: http://<sensor_events_host_name>:9080/devworks/SmarterPharma.

SmarterPharma 页面(图 2)允许您分配在样例场景中使用的 EPC 值,并为每个已定义的供应链位置生成 RFID 标记读取数据,就像从一个真实的读取器中发出一样。在真实的实现中,此时数据捕捉组件应该处理来自读取器的数据(即规范化、过滤、聚合和梳理数据)、将数据转换成 XML 并通过 JMS 将它发送到服务器网格,然后在 IBM WebSphere Application Server 消息引擎上发布。相反,Smarter Pharma Web 页面将等效的事件直接插入到 WebSphere Application Server 消息中。

当您生成了所有将 MigHelp 容器从 Biggie Pharmaceuticals 移动到 Mom & Pop's Pharmacy 所需的读取数据时,您可以生成一个跟踪容器在供应链中的轨迹的报告。

图 2. Smarter Pharma 样例 Web 页面
图 2. Smarter Pharma 样例 Web 页面
图 2. Smarter Pharma 样例 Web 页面

WebSphere Sensor Events 应用程序流程

为了与 WebSphere Sensor Events 服务器通信,将通过应用程序生成 ISensorEvent XML 并将 XML 发送到 WebSphere Sensor Event 的网关进行处理。网关将 XML 转换成 ISensorEvent 对象并将该对象发布在为 WebSphere Sensor Events 配置的 WebSphere Application Server 消息引擎中。当事件对象被发布之后,发布和订阅消息引擎 (pub/sub) 将把该事件提交到所有已订阅的 Java™ 2 消息驱动 beans (MDB)。MDB 包含应用程序逻辑,它在 WebSphere Sensor Events 中称为任务代理。

决定执行哪个操作

在这个例子中,Smarter Pharma 应用程序将事件 XML 发送到使用惟一源 ID 值(表 1)的网关中,它对应于在用户界面中选择的事件位置(意味着生成事件的事件位置)。例如,在分配 EPC 时,源 ID 为 Biggie_commissioning。当选择在 Biggie Pharmaceuticals 包装位置中读取 RFID 标记时,源 ID 为 Biggie_packing。

表 1. 样例应用程序位置和源 ID 值
位置源 ID
CommissioningBiggie_commissioning
Biggie Pharmaceuticals PackingBiggie_packing
Biggie Pharmaceuticals ShippingBiggie_shipping
Speedy Distributors ReceivingSpeedy_receiving
Speedy Distributors StoringxSpeedy_storingxx
Speedy Distributors PackingSpeedy_packing
Speedy Distributors ShippingSpeedy_shipping
Mom & Pop's ReceivingMomPop'ss_receiving
Mom & Pop's StockingMomPop'ss_stocking

样例应用程序逻辑

在这个应用程序中,重要的操作是分配。应用程序逻辑(图 3)检查事件源 ID 是否表明事件是分配事件。如果是分配事件,应用程序将检查 EPC 是否已经分配。然后应用程序才分配 EPC。最后,在所有情况中应用程序都观察该事件。

图 3. 样例应用程序逻辑流程
图 3. 样例应用程序逻辑流程

实现样例应用程序逻辑

遵循 WebSphere Sensor Events 工具箱中的说明创建一个 EJB 项目。这个 EJB 项目包含任务代理 MDB。清单 1 显示了来自样例应用程序任务代理的相关源代码。

清单 1
private static CommissioningHome commissioningHome;
private static ObservationHome observationHome;
private static ValidationHome validationHome;

protected void onIBMSensorEvent(ISensorEvent ise) {
   try {
      // extract the original event ID
      String originalEventId = ise.getHeader().getEventId();
      
      // extract the sourceId
      String sourceId = ise.getHeader().getSourceId();
      sourceId = sourceId != null ? sourceId.toLowerCase() : "";

      // is this a commissioning event?
      if (sourceId.endsWith("commissioning")) {
         // has the EPC already been commissioned?
         Validation validationRuc = validationHome.create();
         boolean isCommissioned = validationRuc.validateEvent(ise);  
         
         if (!isCommissioned) {
            // guarantee event ID uniqueness
            ise.getHeader().setEventId(UUID.createEventUUID());
            
            // commission the EPC
            Commissioning commissioningRuc = commissioningHome.create();
            commissioningRuc.commissionEvent(ise);
         }
      }
      
      // restore the original event ID
      ise.getHeader().setEventId(originalEventId);
      
      // record the event
      Observation observationRuc = observationHome.create();
      observationRuc.observeEvent(ise);
   } catch (Exception e) {
      e.printStackTrace();
   }
}
public void ejbCreate() {
   try {
      InitialContext ic = new InitialContext();

      Object commissioningObj = ic.lookup("ejb/com/ibm/premises/reusable/
		commissioning/CommissioningHome");
      commissioningHome = (CommissioningHome) PortableRemoteObject.narrow
		(commissioningObj, CommissioningHome.class);
      
      Object observationObj = ic.lookup("ejb/com/ibm/premises/reusable/
		observation/ObservationHome");
      observationHome = (ObservationHome) PortableRemoteObject.narrow
		(observationObj, ObservationHome.class);
      
      Object validationObj = ic.lookup("ejb/com/ibm/premises/reusable/
		validation/ValidationHome");
      validationHome = (ValidationHome) PortableRemoteObject.narrow
		(validationObj, ValidationHome.class);
   } catch (Exception e) {
      e.printStackTrace();
   }
}

public void onMessage(javax.jms.Message msg) {
   super.onMessage(msg);
}

在这段代码中:

  • ejbCreate 方法缓存所有必要的 Reusable Components 的 EJB 主接口。
  • onMessage 方法将控件传递给超类 onMessage 方法,然后它调用 onIBMSensorEvent 来处理事件。
  • onIBMSensorEvent 是任务代理的核心并且包含来自流程图的逻辑实现。通过从事件头部提取源 ID 值,该代码能够确定这是不是一个分配操作。如果它是一个分配操作,该代码将通过调用 Validation Reusable Component 检查 EPC 是否已经分配。如果还没有分配 EPC 值,Commissioning Reusable Component 将在 EPCIS 数据储存中定义 EPC 值。最后,该代码调用 Observation Reusable Component 来记录在 EPCIS 数据储存中读取的 EPC RFID 标记。

运行应用程序

部署和运行样例 SmarterPharma 应用程序:

  1. 在部署样例应用程序之前,在 WebSphere Application Server 中创建一个带有以下属性的 JMS 激活规范:
    • Scope:server1
    • Provider:default messaging provider
    • Name:SmarterPharmaAS
    • JNDI name:eis/SmarterPharmaAS
    • Destination type:Topic
    • Destination JNDI name:jms/ibmse
    • Message selector:ibmse LIKE '%/report/TagReport' OR ibmse LIKE '%/report/TagAggregationReport'
    • Bus name:ibmsensorevent
  2. 重启 WebSphere Application Server 激活新的 JMS 激活规范。
  3. 将样例应用程序 EAR 部署到 WebSphere Application Server。
  4. 要运行样例应用程序,打开 Web 浏览器并访问: http://<sensor_events_host_name>::9080/devworks/SmarterPharma
  5. 如前所述,这个 Web 应用程序将模拟在供应链的不同阶段中生成的传感器事件。该流程中的第一个步骤是制造商为药品容器分配惟一的身份标识符。在这个步骤中,将为 RFID 标记分配一个惟一的 EPC 代码,然后将该标记粘贴到药品容器上。接下来需要记录 EPC 代码与该药品的关联。这就是分配。在这个应用程序中,单击 Commission 按钮分配 EPC 代码。对于供应链流程的其余步骤,也使用该应用程序进行模拟。
  6. 接下来,要为 Biggie Pharmaceuticals 包装和运输生成读取数据,以及为 Speedy Distributors 接收和储存位置生成读取数据,从 Locations 下拉列表选择这些位置并单击 Read 按钮。在这里,您跟踪的一箱 MigHelp 已经从制造商转移到分发商。因为您的贸易合作伙伴是通过共享的 EPCIS 储存库连接起来的,所以 Speedy Distributors 能够查询 EPCIS 储存库并获取药品容器的 EPCIS 事件列表,从而能够检查到 MigHelp 容器的真伪。
  7. 单击 Report 按钮显示为 MigHelp 容器生成的 EPCIS 事件。报告应该包含类似于图 4 的 5 个事件。
    图 4. 样例报告
    图 4. 样例报告
    图 4. 样例报告
  8. 在报告中显示的 EPCIS 事件表明在供应链中的预定位置中观察了 MigHelp 容器,从而保证了它是正品。现在,您已经准备好将 MigHelp 容器从 Speedy Distributors 运输到 Mom & Pop's Pharmacy。要在供应链中继续移动药品容器直至最后一个位置,从 Locations 下拉列表选择 Speedy Distributors packing and shipping locations 和 Mom & Pop's receiving and stocking locations,并单击 Read 按钮。
  9. 当 Mom & Pop's Pharmacy 收到容器之后,Mom & Pop's 可以通过在共享库中查询容器的 EPCIS 事件来查看容器的轨迹。最终的报告应该一共包含 9 个事件,如图 5 所示。
    图 5. 最终的报告
    图 5. 最终的报告
    图 5. 最终的报告

现在,在这个简单的报告视图中,您可以访问之前不可用的关键供应链数据。在部署场景中,这种类型的供应链可用于进行接近实时的操作流程监控、短期和长期分析和流程优化,以及在指示板和监控器中显示关键的度量指标,从而反映潜在的瓶颈以便于采取前摄性修复措施。这是继产品真伪验证和篡改检测之后的又一个功能。

使用 InfoSphere Traceability Server

运行样例应用程序不需要 InfoSphere Traceability Server,因为在这里已经构建了它。不过,在实际的供应链部署中它的地位是十分重要的,需要使用它来实现药品在整个供应链流程中的可见性(相互连接性)。

要将 InfoSphere Traceability Server 用作 EPCIS 数据储存,以及配置 Validation、Commissioning、Observation 和 Reporting Reusable Components 以使用 EPCIS 后台,请遵循 WebSphere Sensor Events 文档中的以下说明:

结束语

到目前为止,本系列已经探索了如何通过传感器解决方案和 WebSphere Sensor Events 实现 Smarter Planet —— 配备仪器、相互连接和智能化。本文主要关注供应链,这是一个跨多个行业和解决方案的区域。它在一个样例药品跟踪场景中介绍了商品运输、接收和分发,并演示了如何使用传感器技术和 WebSphere Sensor Events 处理捕捉关于业务的关键部分的信息。新的智能为构建更加智能的供应链提供基础。

在 WebSphere Sensor Event 处理中,您看到如何利用将传感器数据集成到 InfoSphere Traceability Server 的现有服务来在供应链中跨多个销售商跟踪产品。样例代码是一个参考,可用作开发和交付更智能的供应链解决方案的起点。

本系列的下一篇文章将查看医疗领域,并展示传感器解决方案如何为连接的健康解决方案提供关键的患者监控。我们简单讨论 InfoSphere Traceability Server 在跨供应链的整个系统中共享数据扮演的角色,并详细描述如何通过集成的业务事件处理产品 IBM WebSphere Business Events 从连接的健康场景中的原始传感器事件数据生成业务级事件。还将讨论 RFID 之外的传感器设备集成技术,以展示 WebSphere Sensor Events 如何为各种传感器平台提供设备集成。


下载资源


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=475626
ArticleTitle=使用传感器监控的 Smarter Planet 解决方案,第 2 部分: 实现更加智能的供应链的传感器解决方案
publish-date=04292010