Copyright © 2007 IEEE. Reprinted from IEEE International Conference on e-Business Engineering (ICEBE 2007), Hong Kong, China, October 24-26, 2007, pp. 54-61. This material is posted here with permission of the IEEE. Such permission of the IEEE does not in any way imply IEEE endorsement of any of IBM's products or services. Internal or personal use of this material is permitted. However,permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from the IEEE by writing to [email protected].

Extending SOA/MDD to Sensors and Actuators for Sense-and-Respond Business Processes Han Chen, Paul B. Chou, Norman H. Cohen, and Sastry Duri IBM Thomas J. Watson Research Center, 19 Skyline Dr, Hawthorne, NY 10532, U.S.A. {chenhan, pchou, ncohen, sastry}@us.ibm.com Abstract— While the practice of Service Oriented Architecture (SOA) and Model-Driven Development (MDD) has brought efficiency gains to software development, building responsive, scalable business applications enabled by distributed sensor and actuator (S&A) infrastructure remains challenging, often involving extensive effort and skill. The results are typically one-of-a-kind, difficult to replicate or modify for different environments, and brittle in the face of changes to the physical plant and equipment. This paper examines the challenges presented by distributed S&A infrastructure in the context of business information systems, and introduces an architecture that applies SOA/MDD methodologies to the modeling, development, deployment, and management of S&A systems. In particular, the architecture focuses on the separation of concerns between logical application development and infrastructure capability management, and the support of component assembly with an eventbased programming model. The paper then briefly describes a prototype implementation of the architecture, including integrated tooling and runtime support, and illustrates its role relative to existing business process modeling, integration and execution environments with examples based on industry applications.

ordering

inventory management

shipment verification

business-process layer RFID readers

photoelectric sensors

statusindicator lights

sensor and actuator layer

Fig. 1.

The business-process layer and the sensor-and-actuator layer

listed in any of the ASNs, a status-indicator light on the portal turns red, signaling the operator that the pallet is not expected at this location and should be rejected and taken back to the truck. Otherwise, the pallet is accepted into the store. After all shipped pallets are processed by the receiving portal the received shipments are reconciled with corresponding purchase orders and invoices and payments are processed. We call this enhanced receiving process a sense-and-respond process [4] because it senses, analyzes, and responds to conditions in the physical world. A sense-and-respond process does not necessarily involve sensors: It may learn of physical-world conditions from human input on a data-entry device, for example; indeed, the term senseand-respond has been applied to business models and management styles [9] as well as to computational systems. However, this paper is primarily concerned with sense-and-respond processes that, like the receiving process, are enabled by sensors and actuators. The receiving process can be partitioned into two different implementation perspectives, depicted in Figure 1. At the higher level—the business process layer—the receiving process involves the validation of incoming goods against expected shipments and the integration with supply chain and warehouse management applications to complete the process with accurate and updated transaction and inventory data. At the lower level—the sensor-and-actuator (S&A) layer—the receiving process concerns the orchestration of sensors and actuators (such as RFID readers and status-indicator lights) and the coordination of event and control processing to produce timely and accurate data (e.g., the list of goods arriving at the portal) and behaviors (e.g., accept/reject indication by the status light). The two layers must be able to communicate with each other. The S&A layer gathers raw data and synthesizes it into higherlevel information used by business processes. Actions resulting from decisions in the business layer may be delegated to the S&A layer, so that they may be executed by actuators. We believe that the partition of Figure 1 applies to most S&Aenabled senseand-respond business processes. The question we address in this paper is how to design a system architecture and

I. S ENSORS AND ACTUATORS IN B USINESS P ROCESSES Incorporating sensors and actuators into business processes promises improved process efficiency and responsiveness and potentially leads to process transformation and innovation. One wellstudied example illustrating the benefits of sensors and actuators is the use of Radio Frequency Identification (RFID) tags in supply chain management. It has been shown [8] that 70% to 75% of retail out-of-stock cases result from poor retail store practices using inaccurate store inventory information; and RFID-enabled supply chains significantly improve on-shelf availability of products [10] with more timely and accurate product movement and inventory data. As sensor and actuator technologies continue to improve and their benefits continue to be demonstrated, attention has focused on the cost of supporting large-scale roll-outs of S&A infrastructure for missioncritical applications. A recent survey [11] shows that the cost of data integration has emerged as the top concern for RFID deployment—a shift from concerns about the cost of tags and the performance of the readers. Potential technology adopters are now more interested in realizing the value of the new technologies by integrating them into the existing business processes, or by using them to transform the existing processes for increased efficiency and effectiveness. Consider an RFID-enhanced receiving process in a retail store as an example. This process starts with a store ordering products from a distributor. The distributor processes the order and ships products to the store. At the time of shipping, the distributor sends an electronic Advance Shipment Notice (ASN) to the store. The ASN enumerates the items in the shipment, the EPC (Electronic Product Code [2]) embedded in the RFID tags of the shipped items, and the corresponding purchase order. When goods arrive at the receiving dock, an operator unloads the pallets from the truck and brings them into the store through an RFID-equipped receiving portal. The previously received ASNs are applied to associate pallets with expected shipments. If a pallet, identified by its RFID tag, is not 54

business process service provider

service consumer

service provider

service consumer

•

Enterprise Service Bus

SOA/MDD Environment for S&A •

sensor

sensor

actuator

actuator

sense-and-respond process

Fig. 2. Bus

Connecting sense-and-respond processes to the Enterprise Service

programming methodology for the seamless integration of these two layers. Service oriented architecture and model-driven development have been well studied and shown to be extremely beneficial for the business-process layer [6], [3]. It is clear that the S&A layer shares many characteristics of the business process layer, such as the applicability of dataflow/workflow models and software reuse through component assembly. Business components can communicate with each other through an Enterprise Service Bus, but the information exchanged within the S&A level is too low-level and time-critical for the Enterprise Service Bus. Therefore, an SOA/MDD environment for sensors and actuators is needed in the overall system architecture, as shown in Figure 2. This environment provides a container for the logic in the S&A layer and acts as an intermediary to connect the devices in the physical world to the processes in the cyber-business space. Before discussing on the extension of existing SOA/MDD tools and execution environments to S&A, it helps to note the differences between the two layers: •

•

context of physical objects (e.g., product item A arriving at dock door B to be received) to deduce information, such as stock levels, needed by business processes. Timeliness versus auditability: The two layers differ in the degree of emphasis on timeliness and transactional integrity. The business process layer places more emphasis on auditability. Every business-level event has legal significance, so it must be accounted for, processed in a manner that preserves transactional integrity, and stored persistently. The S&A layer, having to interact with the physical world, is subject to more stringent constraints on system responsiveness. These constraints are dictated by the nature of the physical activities, such as the time allowed for the light to turn red for unexpected pallets so that the operator or a forklift does not need to slow down and wait. Variations and scalability: An important value proposition of SOA/MDD is the ability to accommodate process variations effectively and efficiently. Even though the high-level business process may remain the same for different deployments, or for the same deployment at different points in its history, the S&A layer must address the differences in the underlying S&A infrastructure, for example, different sensor and actuator technologies, network configurations, communication bandwidth, and available computing resources. Equally important is the ability to scale the system to support a distribution center with hundreds of dock doors without sacrificing responsiveness and robustness.

The rest of the paper is organized as follows: Section II explains why model-driven development is especially beneficial for exploiting sensors and actuators in sense-and-respond processes. Section III briefly describes DRIVE, a platform we have built to support modeldriven development of sense-and-respond processes, and explains how DRIVE can be used to reap the benefits described in Section II. Section IV illustrates the model-driven development and maintenance of a sense-and-respond process using DRIVE. Section V presents our conclusions. II. M ODELING S ENSORS AND ACTUATORS The modeling of a business process facilitates the specification, design, implementation, and maintenance of IT systems supporting that process. Sense-and-respond processes typically incorporate processing aspects involving sensors and actuators. The modeling of these aspects, when coupled with SOA, has similar benefits for the IT systems supporting those processes. The following subsections discuss several ways in which we propose to exploit the modeldriven development of these sensor-and-actuator aspects to improve the development and maintenance of those processes:

Stakeholders: While both layers concern business processes, the business responsibilities and technical competencies of the stakeholders involved may be quite different. The stakeholders for the business-process layer are likely to be interested in agile ordering, visibility into current inventories, cost-effective use of warehouse resources, and elimination of payments for merchandise that was not ordered or was not delivered. The stakeholders for the S&A layer are likely to be more interested in the efficiency of the physical operation of moving the delivered goods from the truck into the store, and to be more knowledgeable in mechanical-electronic control systems and receiving-portal procedures. Entities of interest: The business-process layer is concerned with cyber-business entities such as supply-chain pipelines, orders, ASNs, and stock levels. The S&A layer deals with physical objects in operational environments, such as pallets, conveyor belts, RFID tags, RFID readers, and status-indication lights. The S&A layer determines the identity, location, and transactional

• • •

•

•

by providing a framework for articulating a sensor-actuator system at a high level of abstraction; by enabling the reuse of high-level designs; by enabling the tailoring of high-level designs through the substitution of device-specific reusable components for generic placeholders; by enabling automatic generation of executable code, freeing the developer from concern with mundane platform-specific details; and by enabling rapid adaptation of a system to evolving requirements.

The development and execution environment we describe in Section III supports these goals. 55

and a virtual lookup component that translates a product code into a product description. In one deployment, we can map the acquisition device to a bar-code scanner and the lookup component to Uniform Product Code (UPC) lookup table; in a different deployment, without modifying the template, we can map them to an RFID reader and an EPC lookup table, respectively. By facilitating the reuse of a design (and reuse of the domain-specific knowledge inherent in the design), a model can facilitate the rapid deployment of sensor-actuator applications.

A. High Level of Abstraction An IT system managing sensors and actuators must deal with a wide variety of details, including the programming interfaces of individual devices, messaging, timing, exception handling, and configuration of the physical and logical interconnections among devices and computing platforms. It is easy for the fundamental business logic of collecting data from sensors and sending commands to actuators to get lost in this maze of details. A platform-independent model of sensor-actuator processing abstracts the essential structural and behavioral properties of such a system, hiding implementation details. A high level of abstraction can be achieved by modeling sensoractuator processing as a network of components that consume and produce events. These events are, in general, lower-level events than those seen in business-process models. Typical sensor-actuator events, ranging over a spectrum from lower-level to higher level, include: raw sensor inputs and actuator commands; filtered data indicating, for example, that a particular set of RFID tags has been detected or meta-commands indicating, for example, that the individual commands necessary to move a crane from point A to point B should be executed; computed situations such as a mislabeled or incompletely packed case or wide-ranging commands such as a signal that emergency assembly-line shutdown operations should commence. The components in such a model include sensors, modeled as components that produce but do not consume events, actuators, modeled as components that consume but do not produce events, and intermediaries that both consume and produce events. Intermediaries may, among other tasks, filter events, transform events, emit a small number of output events that summarize the information from large numbers of input events, issue output events indicating that a pattern has been recognized in a stream of input events, or synthesize lowlevel events from a wide variety of sources to compute a higher-level event. Each component has zero or more input ports through which it consumes events and zero or more output ports through which it produces events. A model consists of a set of such components plus a set of event flows connecting an output port of one component to an input port of another. Component-based modeling separates what DeRemer and Kron [7] call programming-in-the-large—the design of component interfaces and connections—and programming-in-thesmall—the internal logic of components. Abstraction can be further enhanced by the use of hierarchical composition to model a component as a set of subcomponents connected by event flows. The hierarchical composition can be developed top-down, by stepwise refinement of components into networks of subcomponents, or bottom up, by abstracting the function of a set of interconnected components into a single enclosing component. Different levels of abstraction are useful at different times and for different purposes, and hierarchical composition allows one to choose the level of abstraction at which to study a model.

C. Implementation Reuse Just as many sensor-applications that differ in detail share the same overall design, so many sensor applications with fundamentally different purposes and designs share the same details—details concerned with particular devices, data-format translations, or averaging schemes, for example. Such details can be encapsulated in reusable components stored in a library. Thus, the rapid development of sensor-actuator systems is facilitated by the symbiosis of reusable designs and reusable components for refining the designs. D. Elimination of Programming Details Very little of the code found in a sensor-actuator application is concerned with the logic of the application. Rather, a typical sensoractuator application consists largely of boilerplate code to convert between data formats, invoke the underlying message system, and perform the housekeeping necessary to coordinate several simultaneous activities. None of this boilerplate code reflects the substance of the model; it is simply part of the mechanics of implementing the model on a particular platform. Automatic generation of this boilerplate code makes application developers profoundly more productive, eliminates opportunities for clerical coding errors, and keeps the developers focused on the substance of the application logic. Not every application can be generated entirely from reusable parts, of course. Many applications include small amounts of customwritten code specifically addressing the substance of the application. For example, a system monitoring a warehouse for temperaturesensitive merchandise might include a mathematical algorithm to estimate the temperature at an arbitrary specified location in the warehouse, given the readings obtained from temperature sensors at a few fixed locations. The code to perform this computation ought to be concerned entirely with the mathematical algorithm, and not with the mechanics of receiving and sending data or scheduling periodic recomputations. Some of the components in a model may be placeholders for logic supplied by the application developer in a conventional programming language such as Java. The code generated automatically for such a placeholder would be a stub, for example a Java class with an empty method to be filled in by the programmer with custom logic. The stub should be declared in such a way that it isolates the programmer from the context in which the computation is invoked, and from implementation details of the execution platform. For example, the method might take an array of temperature values at known locations, and a target location, as input parameters, and return the estimated temperature at the target location. Such a method can be written by a domain expert who has no knowledge of the execution platform. The generated boilerplate code, in conjunction with the execution platform, is responsible for gathering the input-parameter values, invoking the method at the appropriate time, and dispatching an output event containing the value returned by the method. Should the developer modify the model, the boilerplate code can be regenerated automatically in accordance with the revised model. The

B. Design Reuse It is common for a class of sensor-actuator applications to have essentially the same structure, but to differ in details. For example, one dock-door receiving application may have two bar-code scanners named “North Loading Dock” and “South Loading Dock” while another may have twelve RFID readers named “Port 1” through “Port 12,” but the two applications may share the same basic tasks and architecture. A sufficiently abstract model of a dock-door receiving application can serve as a template for the design of either application. The template will have a generic (or virtual) code-acquisition device 56

service provider

service consumer

service provider

service consumer

computing nodes (JVMs), but presents the image of a single virtual distributed runtime to component code. As an embodiment of the approach proposed in [5], DRIVE is more than just a runtime framework. Its goal is to support the entire life-cycle of an S&A solution, including development, deployment, management, and monitoring. In this paper, we limit our description to the development and deployment aspects of the system. A DRIVE application is built out of components that consume and produce events. There are two kinds of DRIVE components— composite components consisting of subcomponents connected by event flows and atomic components specifying basic event processing in a programming language. The author of a DRIVE model creates a composite component by using a graphical editor to draw a diagram in which boxes represent subcomponents, points at the edge of boxes represent input and output ports, and arrows leading from output ports to input ports represent event flows. The author of the model creates an atomic component by specifying its name and properties, in particular the names and types of its input ports and output ports. It is also possible to model a composite component whose configuration changes dynamically. Such a component includes a state machine whose state is controlled by events coming into the component. The current state determines which subcomponents are currently active. DRIVE has a component repository that includes components created by application developers, but which is initially populated with reusable parts. These reusable parts include composite components specifying reusable designs for common classes of sensoractuator applications, usable as templates for specific applications. The reusable parts in the component repository also include atomic components corresponding to particular devices, device simulations, and event transformations, which can be dragged onto the graphical editors drawing canvas when building new composite components. DRIVE generates Java code from the model components. In the case of composite components, DRIVE generates Java code to bind ports and event flows. An application developer may specify the logic of an atomic component either in Java or in a language called EventScript, to be described in a forthcoming paper, which uses extended regular expressions to match and respond to patterns of incoming events. In the first case, DRIVE generates a stub class with a method filled in by the application developer; this method is specially tagged to tell DRIVE that its contents should be preserved when code for the model is regenerated. In the second case, the application developer writes an extended regular expression and DRIVE generates tables for a state machine that recognizes the event pattern specified by the regular expression.

Enterprise Service Bus

DRIVE

component

component

sensor

component

component

sensor

actuator

component

actuator

Fig. 3. DRIVE as the execution environment for sense-and-respond processes connected to the Enterprise Service Bus

regeneration process should preserve custom-written code that is part of the substance of the solution, and replace code that was generated automatically from the model. By drastically reducing the cost that results from a change to the model, automatic code generation frees the model developer to experiment with the model and fine tune it. This is in marked contrast to the traditional “water-fall” model of the software life cycle [13], in which specifications are cast in concrete before development begins. E. Adaptability While sense-and-respond business processes are largely stable, the sense-and-actuator infrastructure is not. Businesses expand and contract; physical space is reorganized, sensors and actuators are installed in new locations, and old equipment is replaced with more modern equipment having different specifications. All the ways in which a model-driven approach facilitates the rapid development of sensor-actuator systems also facilitate rapid modifications to such systems. Changes in requirements can be reflected directly in models at a high level of abstraction, perhaps by incorporating different reusable components. Code for the revised model can be generated automatically, preserving the investment in custom-written components. Moreover, models expressed in terms of sufficiently general virtual devices are readily adaptable to changes in equipment: Such changes are simply new refinements of the same model.

B. Modeling and Development Methodology With the DRIVE tool and runtime, we propose a general methodology for transforming a business process into sense-and-respond processes enabled by sensors and actuators, as outlined in Figure 4. First, a business analyst captures the existing business process using a process modeler. Working with the business process owner, the analyst improves the process to be a sense-and-respond process. In this step, the sense-and-respond process can be completely technology-agnostic, and therefore remains a valid template for embodiments using different technologies. Second, a solution architect evaluates potential technology candidates and makes a decision on the technology to be used based on customer’s requirements and other constraints. Given behavior and characteristics of the chosen technology, the analyst further refines the sense-and-respond process to include process details related to

III. A N E NVIRONMENT FOR M ODEL -D RIVEN D EVELOPMENT OF S ENSOR -ACTUATOR A PPLICATIONS In this section, we describe an environment for model-driven development of sensor-actuator applications called Distributed Responsive Infrastructure Virtualization Environment (DRIVE), which supports the approach described in Section II. We then propose a general modeling and development process for sense-and-respond processes enabled by S&A. A. Distributed Responsive Infrastructure Virtualization Environment As shown in Figure 3, DRIVE provides the execution environment for S&A depicted in Figure 2. The DRIVE execution environment, shown as the shaded box in Figure 3, potentially spans multiple 57

Business Analyst

Capture Existing Business Process

Process Modeler

Goods Available Order Fulfillment

Process Model Enhance BP to be S&R

Work Order

Process Modeler S&R Process Model Cycle Counts

Solution Architect and Developers

Evaluate Potential Technologies

Refine SRBP with Chosen Technology

Process Modeler

Sale/ Return

Refined S&R Process Model with S&A

Publish

Fig. 5.

DRIVE Solution

IT Manager

Generate DRIVE Deployable Code

Policy Update

Demand Forecasting

DRIVE

Direct Replenishment

OOS Alert

Goods Arrival Alert

Shelf Replenishment

Point Of Sale

Create DRIVE Solution Model Reuse

Shelf Inventory

Product Movement

Receiving Inventory Update

Perpetual Inventory

Inventory Update

Overview of the consumer-driven replenishment process

DRIVE

IV. E XAMPLE : C ONSUMER -D RIVEN R EPLENISHMENT

the periodic “Cycle Count” physical inventory process, the Fulfillment process, and the transaction data from Point of Sale. RFIDtagging is applied at the product item level to simplify the Receiving, Point of Sale, Cycle Count, and Order Fulfillment operations. To further demonstrate the value of SOA/S&A for sense and respond processes, we add a “Direct Replenishment” subprocess. On occasions when a product is out of stock both on the sales floor and in the back room, it is desirable to move the product directly to sales floor upon its arrival at the receiving dock door. The Direct Replenishment subprocess receives stock-out alerts from the Shelf Replenishment process and goods arrival alerts from the Receiving process, and initiates direct replenishment orders as appropriate. The Direct Replenishment subprocess can be easily added without changing other parts of the Consumer-Driven Replenishment process. This malleability is one of the benefits of coupling processes through events [12]. Using the IBM WebSphere Integration Developer, we have implemented a prototype of the high-level process that runs on the WebSphere Process Server, using a combination of workflow and business state-machine models. In the following subsections, we will drill down the implementation of the receiving process to introduce the use of DRIVE for the implementation of the S&A layer of the process.

In this section, we illustrate our approach by using the DRIVE tool described in Section III to implement a sense-and-respond business process supported by sensors and actuators.

B. Modeling an RFID-Enabled Sense-and-Respond Receiving Process

Deployable DRIVE Code Model Device Infrastructure

Deploy DRIVE Solutions

DRIVE Console

Fig. 4. Modeling and development methodology of creating a sense-andrespond process using S&A

the technology elements. This can be done with a traditional process modeler. Based on the refined process, solution developers create solution components in DRIVE using constructs such as event-flow diagrams, state machines, Java programs, and EventScript regular expressions. While creating these components, they reuse existing assets as applicable and publish their creations as new reusable components. The DRIVE code generator creates deployable artifacts from the component models. Finally, the IT manager is responsible for procuring devices as prescribed by the solution architecture. The IT manager registers the devices using an administrative console provided by DRIVE, then deploys the components and creates proper bindings among components.

Traditionally, the receiving process involves accepting the pallets and stowing them in a put-away area. As discussed in Section I, we can enhance the receiving process and turn it into a sense-andrespond receiving process by, first, validating the incoming shipments against known ASNs so that incomplete shipments can be detected and wrong shipments turned away; and, second, generating an event to indicate the goods arrival so that other processes can be triggered. The transformation of the receiving process is depicted in Figure 6. Notice that the sense-and-respond receiving process is general: It only declares what steps need to be taken, not how they are implemented. In particular, it does not specify the technologies to be incorporated. Suppose we make the following design choices regarding sensors and actuators and the coupling mechanism with other subprocesses:

A. Overview of the High-Level Process To improve its on-shelf product availability, a hypothetical apparel retailer implements a Consumer-Driven Replenishment process. There are eight subprocesses and services working together as outlined in Figure 5, one of which is the receiving process we introduced in Section I. The eight subprocesses are coupled together via an ESB using service invocation (depicted with solid arrows in the diagram) and asynchronous events (depicted with dotted arrows). For each product there is a policy that states the minimum and maximum quantities of the product to keep on the store shelves and the product’s replenishment point. The policy is updated periodically using a “Demand Forecasting” service. When the “Shelf Replenishment” process detects that the shelf inventory level of a product has fallen below its replenishment point, the process issues a replenishment order to restock the shelf. The “Order Fulfillment” subprocess manages the replenishment order execution and updates the Shelf Replenishment process with associated product movements. A perpetual shelf inventory is maintained by combining the data from

• • •

58

Pallets are tagged with RFID. The receiving dock is instrumented with an RFID reader. Two light beams are installed on either side of the dock to detect forklift and pallet entering and leaving the dock.

Fig. 8.

Portal receiving DRIVE module

• Yes Open Dock

Move Pallet Through dock

Put-away Pallet

More Pallets?

• No

Done

•

Traditional Receiving Process Yes Open Dock

Move Pallet Through dock

Put-away Pallet Yes

Acquire Pallet ID

Is Pallet Valid?

More Pallets?

Done

The refined receiving process is then carried out in the following steps, shown in Figure 7:

Generate Receipt Event No

•

Return to Truck

•

Sense-and-Respond Receiving Process

Fig. 6. Enhancing traditional receiving process to be a sense-and-respond process

Open Dock

Return Pallet To Truck

Put-away Pallet

Wait for Entry Beam

Turn on Red Light

Turn on Green Light

Turn on Amber Light

Is Pallet Valid?

Turn on RFID Reader

Perform Validation

Generate Receipt Event

Collect Pallet Tag

Wait for Exit Beam

Turn off RFID Reader

More Pallets?

• •

No

Done

Turn off Lights

•

No

Fig. 7.

Wait for 5 seconds

Yes

Red, amber, and green lights are used to give operators visual feedback of the operational status. The validation of the incoming shipment is handled by a separate subprocess connected to the enterprise service bus. Upon receipt of a successfully validated shipment, an EPCIS [1] conforming Object Event is published to the ESB via a message queue.

Write to ESB Queue

• S&A Layer

•

Refined receiving process with S&A

59

When there are no pallets in the receiving dock, the RFID reader is turned off and all three indicator lights are off. When the pallets arrive at the dock as detected by the entry light beam installed in front of the dock, the RFID reader is turned on and the amber light is turned on to indicate that the portal is now operational. The tags read by the reader are filtered to remove duplicates. Unique tags are stored in local memory temporarily. When the pallets leave the dock as detected by the exit light beam installed behind the dock, the RFID reader is turned off. Meanwhile, a validation request with all the tags just seen is formed and sent to the external validation subprocess. The receiving process then waits for the validation result to arrive. If the result is “ACCEPT”, the green light is turned on to reflect successful receipt of a shipment, indicating that the operator can move the pallets to the put-away area. Meanwhile, an EPCIS Object Event with all the tag codes is generated and written to an output message queue. If the result is “REJECT”, the red light is turned on to alert the operator to turn back the shipment. No EPCIS event is generated in this case. In either case, all indicator lights are turned off after 5 seconds so that the next receiving cycle can begin.

Fig. 9.

Fig. 10.

Transition in the state machine

Fig. 11.

ARCOMDeviceLayer module

Portal controller

C. Implementing the Receiving Process in DRIVE Given the description of the refined receiving process, we can implement a DRIVE solution easily with existing reusable components. Two different techniques are used to create the receiving solution—an event flow diagram and a state machine. Figure 8 shows the overall solution in the form of an event flow diagram assembled from components connected by wires. The dark components represent concrete instantiations of existing components, for example, a duplicate removal filter and an EPCIS Object event formatter. The light components, on the other hand, are placeholders that are bound to concrete implementations at deployment time. For example, the Reader component signifies the requirement for an RFID reader for this solution to function; however, the details of this reader, such as its model, IP address, and port number, are not defined here. By using this modeling construct we capture the core business logic of the receiving process so that it can be readily reused. The solution developer determines the best way to use other component while assembling a solution. In this example, we choose to declare the message-queue writer for EPCIS event as a placeholder—MQSender—but use a concrete HTTP client component—HttpClient—to perform the validation request. The Controller in Figure 8 is a nested composite component, whose details are shown in Figure 9. It contains a state machine that models the different states of a receiving portal. Status changes in the light beams and other events cause transitions among states, which in turn trigger additional output actions to affect the behaviors of other components. For example, Figure 10 shows the properties of the transition from “Idle” state to “Reading” state. This graphical modeling approach allows solutions to be quickly and accurately created from a process diagram. More importantly, it allows design changes in the process level to be filtered down much more easily to the solution level than hand-written code does, thus making solution customization more manageable.

Viper controller with an 8-input/8-output digital I/O board on the network. The light stack is driven by the output pins on the digital I/O board, while the two light beams are connected to the input pins. We create another simple DRIVE module, “ARCOMDeviceLayer,” shown in Figure 11, to model the physical connection of the light stack and the light beams to the digital I/O board. In this module, we import a DigitalIO component and export three other components. Addressable physical devices (specific real-world instances of the AR400 RFID reader and the ARCOM Viper digital I/O controller) are then added to the infrastructure, which include the computing nodes capable of hosting the DRIVE runtime, physical devices (the reader and the DIO board), and cyber devices (the message queue on the ESB). We then deploy an instance of the “ARCOMDeviceLayer” module and name it “P1Devices”. The placeholder DIO device is bound to the DIO device in the platform. As a result, there are three exports available from the “P1Devices” module. Finally, we deploy an instance of the “PortalReceiving” solution and name it “DDR1”. The placeholders in DDR1 are bound to exported components in the “P1Devices” module. E. Expected Benefits of the Methodology We are currently validating the methodology with industry practitioners. We have observed the following benefits during our experimentation with DRIVE solutions: • Better continuity in the design process: Without an MDD tool for devices, developers need to make a giant leap from business process model to actual implementation code. Tools like DRIVE provide much better continuity in the mental process. At higher level, DRIVE uses event flow diagrams and state machines as the programming model, which is close to business process models. At lower level, DRIVE allows actual implementation code to expose its capabilities through ports and parameters and participate in the higher-level composition. • Better design reuse: The SOA style solution composition provided by DRIVE allows developers to capture the invariant

D. Deploying the Receiving Module Notice that the DRIVE receiving solution abstractly describes the requirements for a reader, two light beams, a light stack, and a message-queue writer. At deployment time, we need to create concrete binding targets for these placeholders. In this hypothetical deployment, we have a Symbol AR400 RFID reader and an ARCOM 60

We have created DRIVE, a development environment and runtime platform that supports the MDD and SOA approaches both during initial system development and subsequently, as sensor-and-actuator systems evolve. Our early experiments point to a number of benefits of the proposed approaches. First, tools such as DRIVE help developers translate a sense-and-respond process into actual implementation by providing better continuity in the design process. Second, common solution patterns can be easily captured as reusable templates. Third, developers become more productive as they focus solely on the substance of the solution. Finally, the resulting solutions can be easily customized to accommodate variations in business requirements, and deployed on varying sensor-and-actuator infrastructures. We are validating and enhancing DRIVE based on real-world uses. ACKNOWLEDGMENT Fig. 12.

•

•

This work is partially supported by the IT839 project from the Institute of Information Technology Assessment and Ministry of Information and Communication in Republic of Korea. We would like to thank the team members who contributed to the prototype system: ChangWoo Jung, SooYeon Kim, KangYoon Lee, and YongHoon Um of the Ubiquitous Computing Lab of IBM Korea, and Johnathan Reason and Danny Wong of IBM Research. We would also like to thank Scott McFaddin, Stephen Buckley, and Jeff Elliott who contributed to the development of the Consumer Driven Replenishment concept and prototype, and Francis Parr for many valuable discussions.

XR400DeviceLayer module

process logic and defer the decisions about devices and other services to deployment time. The result is that the logical design of a process can be preserved while the devices evolve over time. As an example, we have modified the scenario described in Section IV-B to install a second receiving portal using a completely different set of devices. For this portal, P2, a Symbol XR400 reader is used and the light stack and light beams are connected to the GPIO pins of the reader itself, eliminating the need for a separate controller box. In order to support the receiving process at P2, all we have to do is to create another module “XR400DeviceLayer”, with a placeholder for a ReaderWithIO component, that exports a normal reader, a light stack, and two light beams, as shown in Figure 12. After we deploy the new XR400 reader and an instance of the “XR400DeviceLayer” module called “P2Devices”, we can simply deploy another instance of “PortalReceiving” called “DDR2” and bind its placeholders to the components exported by “P2Devices”. No changes to the “PortalReceiving” solution itself are needed in order to accommodate the new devices. Simplified component coding and better component reuse: DRIVE allows developers to create components and define its external interface in terms of ports and parameters. This makes component reuse a lot easier than at code level. In addition, the code generator creates all the necessary glue code to pass events among components, whether they reside in the same address space or in different ones, so that developers can focus on the core logic. Easier solution customization: In most cases, changes in business process or requirements can be reflected in DRIVE solutions easily via 1) parameter value change, 2) adding or deleting components, 3) changing the flow diagram, 4) modifying the state machine. None of these requires low-level coding. Occasionally, new components need to be created from scratch, a task which is made relatively easy by the code generation.

R EFERENCES [1] EPC Information Services (EPCIS) Version 1.0 Specification. www.epcglobalinc.org/standards/EPCglobal_EPCIS_ Ratified_Standard_12April_2007_V1.0.pdf. [2] EPC Tag Data Standards. www.epcglobalinc.org, EPCglobal, 2004. [3] Service Oriented Architecture. IBM System Journal, Volume 44, Number 4, 2005. [4] Workshop on End-to-End, Sense-and-Response Systems, Applications, and Services (EESR ’05). ;login: The USENIX Magazine 30 (5), October 2005. [5] H. Chen, Y. Choi, and P. Chou. An Architecture for Programming and Managing Sensor and Actuator Networks in Enterprise Environment. In OOPSLA 2006 Workshop on Building Software for Sensor Networks, Portland, Oregon, October 2006. [6] P. Chowdhary, K. Bhaskaran, N. S. Caswell, H. Chang, T. Chao, S.-K. Chen, M. Dikun, H. Lei, J.-J. Jeng, S. Kapoor, C. A. Lang, G. Mihaila, I. Stanoi, and L. Zeng. Model Driven Development for Business Performance Management. IBM System Journal, 45(3):587–605, 2006. [7] F. DeRemer and H. Kron. Programming-in-the-large versus programming-in-the-small. In Proc. Intl. Conf. on Reliable Software, Los Angeles, California, pages 114–121, April 1975. [8] T. Gruen, D. Corsten, and S. Bharadwaj. Retail Out-of-Stocks: A worldwide examination of extent, causes and consumer responses. Grocery Manufacturers of America, 2002. [9] S. H. Haeckel. Adaptive Enterprise: Creating and Leading Sense-AndRespond Organizations. Harvard Business School Press, 1999. [10] B. Hardgrave, M. Waller, and R. Miller. RFIDs Impact on Out of Stocks: A Sales Velocity Analysis. Information Technology Re-search Institute, Sam M. Walton College of Business, University of Arkansas, June 2006. [11] R. Klein. Can RFID Deliver the Goods? The Manufacturer’s Visibility into Supply and Demand. Aberdeen Group, January 2007. [12] D. Luckham. The Power of Events. Addison-Wesley, 2002. [13] W. W. Royce. Managing the development of large software systems: Concepts and techniques. In Proc. 9th Intl. Conf. Software Eng., pages 328–338, Monterey, California, 1987.

V. C ONCLUSION Business processes can be made more efficient and responsive through the use of sensors and actuators. The benefits of MDD and SOA for traditional business processes are well known. This motivates us to extend these approaches to sensor-and-actuator systems. Since the concerns arising from the implementation of business processes are different from those arising from the coordination of sensors and actuators, the latter requires different treatment. 61